-vv shows password in clear text #407

UweSauter · 2018-12-04T22:49:10Z

When running openfortivpn with "-v -v" it will show the password in clear text inside the POST request.

With this config file test.vpn:

host = XXX.XXX.XXX.XXX
port = 443
username = testuser
password = testpw
set-routes = 0
set-dns = 0

I get (important part)
username=testuser&credential=testpw&realm=&ajax=1&redir=%2Fremote%2Findex&just_logged_in=1

complete output:

DEBUG:  openfortivpn 1.8.0
DEBUG:  Loaded config file "test.vpn".
DEBUG:  Config host = "XXX.XXX.XXX.XXX"
DEBUG:  Config realm = ""
DEBUG:  Config port = "443"
DEBUG:  Config username = "testuser"
DEBUG:  Config password = "********"
DEBUG:  Resolving gateway host ip
DEBUG:  Establishing ssl connection
DEBUG:  server_addr: XXX.XXX.XXX.XXX
DEBUG:  server_port: 443
DEBUG:  gateway_addr: XXX.XXX.XXX.XXX
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation succeeded.
INFO:   Connected to gateway.
DEBUG:  http_send : 
POST /remote/logincheck HTTP/1.1
Host: XXX.XXX.XXX.XXX:443
User-Agent: Mozilla/5.0 SV1
Accept: text/plain
Accept-Encoding: identify
Content-Type: application/x-www-form-urlencoded
Cookie: 
Content-Length: 90

username=testuser&credential=testpw&realm=&ajax=1&redir=%2Fremote%2Findex&just_logged_in=1
DEBUG:  http_receive : 
HTTP/1.1 405 Method Not Allowed
Date: Tue, 04 Dec 2018 22:45:43 GMT
Server: xxxxxxxx-xxxxx
Set-Cookie:  SVPNCOOKIE=; path=/; expires=Sun, 11 Mar 1984 12:00:00 GMT; secure; httponly;
Set-Cookie: SVPNNETWORKCOOKIE=; path=/remote/network; expires=Sun, 11 Mar 1984 12:00:00 GMT; secure; httponly
Transfer-Encoding: chunked
Content-Type: text/html
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

66a   
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<link href="/style.css?q=4961b89f42459412586d4947fc9e03d6" rel="stylesheet" type="text/css">
<script type='text/javascript' src='/remote/fgt_lang?lang=en'></script>
</head>
<body class="main">
<table class="container" cellpadding="0" cellspacing="0">
<tr>
<td><table class="dialog" width=300 align="center" cellpadding="0" cellspacing="0">
<tr>
<td><table class="header" cellpadding="0" cellspacing="0">
<tr>
<td id="err_title"></td>
</tr>
</table></td>
</tr>
<script>document.getElementById('err_title').innerHTML=fgt_lang['error'];</script>
<tr>
<td class="body" height=100><table class="body"><tr><td id='err_val' title='405' align="center">
<script>
var errval_elem=document.getElementById('err_val');
var errval=errval_elem.getAttribute('title').split(',');
var err_str = fgt_lang[errval[0]];
if (err_str == undefined) {
   errval_elem.innerHTML = "some unknown error!<br>";
} else {   if (errval.length == 2) {
       err_str = err_str.replace("%d", errval[1]);
   }
   errval_elem.innerHTML = err_str;
}
</script></td></tr></table></td>
</tr>
<tr><td>
<table class="footer" cellpadding="0" cellspacing="0">
<tr><td>
<input id="ok_button" type="button" value="" onclick="chkbrowser()" style="width:80px">
</td></tr>
</table>
</td></tr>
</table>
</body>
<script language = "javascript">
document.getElementById('ok_button').value=fgt_lang['ok'];
function chkbrowser() {
if (window.location.pathname == "/remote/login")
window.location.reload();
else
window.location.href = "/remote/login";}
</script>
</html>

0


ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.
DEBUG:  HTTP status code 405
INFO:   Closed connection to gateway.
DEBUG:  server_addr: XXX.XXX.XXX.XXX
DEBUG:  server_port: 443
DEBUG:  gateway_addr: XXX.XXX.XXX.XXX
DEBUG:  gateway_port: 443
DEBUG:  Gateway certificate validation succeeded.
DEBUG:  http_send : 
GET /remote/logout HTTP/1.1
Host: XXX.XXX.XXX.XXX:443
User-Agent: Mozilla/5.0 SV1
Accept: text/plain
Accept-Encoding: identify
Content-Type: application/x-www-form-urlencoded
Cookie: 
Content-Length: 0


DEBUG:  http_receive : 
HTTP/1.1 200 OK
Date: Tue, 04 Dec 2018 22:45:43 GMT
Server: xxxxxxxx-xxxxx
Set-Cookie:  SVPNCOOKIE=; path=/; expires=Sun, 11 Mar 1984 12:00:00 GMT; secure; httponly;
Set-Cookie: SVPNNETWORKCOOKIE=; path=/remote/network; expires=Sun, 11 Mar 1984 12:00:00 GMT; secure; httponly
Content-Length: 643
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<html><head><script>function fgt_clear_cookies() {var cookies = document.cookie.split(';');var domain = document.domain.split('.');var new_date='; expires=Thu, 21 Sep 1979 00:00:01 UTC';if (domain.length > 1) {domain.shift();}for (var i = 0; i < cookies.length; i++) {var spcook =  cookies[i].split('=');document.cookie = spcook[0] + '=; path=/' + new_date;document.cookie = spcook[0] + '=; domain=.' + domain.join('.') + '; path=/' + new_date;document.cookie = spcook[0] + '=; domain=' + domain.join('.') + '; path=/' + new_date;}window.location.href ='/remote/login';}</script></head><body><script>fgt_clear_cookies();</script></body></html>
INFO:   Logged out.

The text was updated successfully, but these errors were encountered:

mrbaseman · 2018-12-05T10:00:53Z

Hi Uwe,

well, that's what one would expect from a complete traffic log. It is correct that we have added the http traffic in 1.8.0 to the debug output, because we had several cases with authentication problems which were difficult to debug, especially when the end users don't control the vpn service. When we ask for the full traffic log we usually instruct the users to anonymize any sensitive data.

On the contrary, the regular debug output line

DEBUG:  Config password = "********"

is rather questionable, because it is hard-coded like this and printed always no matter if a password is stored in the configuration or supplied via command line or entered interactively.

I'm not sure how we should proceed here. We could replace any occurrences of the clear text password by a starred string in the traffic log, but when trying to debug encoding issues of special characters, this might be a new obstacle during debugging. I'm inclined to say that we should rather remove the stared password line from the regular debug log, or print it depending on some condition.

DimitriPapadopoulos · 2019-05-08T08:06:17Z

@UweSauter I tend to agree with @mrbaseman: the password in clear is by construction, for debugging purposes. I would like to close this issue, would that be OK?

UweSauter · 2019-05-08T18:40:49Z

I still disagree that debug log files should contain clear text passwords. If a clear text password would be needed to debug encoding issues this should be a separate option. But if you want to keep current behavior, go on. This issue was meant to express my concern, not to force anything.

mrbaseman · 2019-05-09T08:30:11Z

well, maybe -v -v -v for the password would be an option that is relatively easy to implement

mrbaseman · 2019-05-09T08:46:14Z

Ah, sorry. It is not easy to implement at all, because the password is part of the packet content that is shown. So, we would have to match the content of the packets and replace everything that matches the password that has been entered before printing the packet content to the screen.

mrbaseman · 2019-05-10T11:44:56Z

PR #443 addresses this issue. The "easiest" implementation actually was to search for occurrences of the password in the debug output buffer and wipe them out. The implementation literally overwrites the characters, so that some password problems may still be spotted at the number of stars that are shown. I think the exact length of the password is a piece of information which is acceptable to be shown in the detailed debug output.

mrbaseman · 2019-06-13T12:04:09Z

I have merged #443 on the current master. The solution to this issue will be in the next release.

mrbaseman · 2019-06-17T10:51:42Z

the fix went into the 1.10.0 Release.

andreworg · 2020-01-02T10:37:25Z

Looks to me #443 does not work when the password contains special chars that get urlencoded. -vv still shows the urlencoded password.

DimitriPapadopoulos · 2020-01-02T10:55:44Z

Ah right. We store the raw password in tunnel->config->password and encode it when necessary in auth_log_in():
https://github.com/adrienverge/openfortivpn/blob/0157f73/src/http.c#L585

DimitriPapadopoulos · 2020-01-02T10:58:46Z

Therefore we also need to encode the password before searching it in the log stream:
https://github.com/adrienverge/openfortivpn/blob/0157f73/src/http.c#L82

mrbaseman · 2020-01-09T13:40:51Z

#535 is a fix for the case in which the password contains characters that need to be url_endoded. When there are no special characters, the result of the encoding routine is the same as the input.

DimitriPapadopoulos · 2020-03-04T07:17:47Z

Fixed in openfortivpn 1.12.0.

mrbaseman closed this as completed Jun 13, 2019

This was referenced Dec 18, 2019

blank password in default config #507

Closed

add a clear warning about sensitive information in the debug output #523

Merged

DimitriPapadopoulos reopened this Jan 2, 2020

DimitriPapadopoulos closed this as completed Mar 4, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

-vv shows password in clear text #407

-vv shows password in clear text #407

UweSauter commented Dec 4, 2018

mrbaseman commented Dec 5, 2018

DimitriPapadopoulos commented May 8, 2019

UweSauter commented May 8, 2019

mrbaseman commented May 9, 2019

mrbaseman commented May 9, 2019

mrbaseman commented May 10, 2019

mrbaseman commented Jun 13, 2019

mrbaseman commented Jun 17, 2019

andreworg commented Jan 2, 2020

DimitriPapadopoulos commented Jan 2, 2020

DimitriPapadopoulos commented Jan 2, 2020

mrbaseman commented Jan 9, 2020

DimitriPapadopoulos commented Mar 4, 2020

-vv shows password in clear text #407

-vv shows password in clear text #407

Comments

UweSauter commented Dec 4, 2018

mrbaseman commented Dec 5, 2018

DimitriPapadopoulos commented May 8, 2019

UweSauter commented May 8, 2019

mrbaseman commented May 9, 2019

mrbaseman commented May 9, 2019

mrbaseman commented May 10, 2019

mrbaseman commented Jun 13, 2019

mrbaseman commented Jun 17, 2019

andreworg commented Jan 2, 2020

DimitriPapadopoulos commented Jan 2, 2020

DimitriPapadopoulos commented Jan 2, 2020

mrbaseman commented Jan 9, 2020

DimitriPapadopoulos commented Mar 4, 2020