Asbru-cm: Proxy credentials exposed in the process list

[popxunga]

Hi ...

While using a global proxy, the credentials can easily be seen in the output of a ps -ef | grep ssh command like follows:

local_uid 32508 32492 0 17:07 pts/2 00:00:00 sh -c ssh -p 22 -o ProxyCommand='ncat --proxy xxx.xxx.xxx.xxx:yyyy --proxy-type socks5 --proxy-auth proxy_uid:pwd %h %p' -l remote_uid zzz.zzz.zzz.zzz 2>&1

I confirmed that the same issue occurs when the proxy is defined at session level and not globally.

Thanks.

[gfrenoy]

Mmm. Checked the man page of ncat but did not find any option to hide that information.

[popxunga]

Yeap ... I saw some discussions where the credential values were got from previously exported variables which I think is not a good solution as well.
No sure if there's other alternatives, but one to consider is the integration with Linux seahorse using the secret-tool command.

[gfrenoy]

Sorry, don't understand how seahorse can help ?

[popxunga]

Hi @gfrenoy

Maybe a bit far-fetched but the idea is to store the password in the keyring with:
printf "Proxy_Password" | secret-tool store --label='Asbru_Proxy_Credentials' Asbru_Proxy_Userid Proxy_Userid

And then retrieve it at execution time with:
$(secret-tool lookup Asbru_Proxy_Userid Proxy_Userid)

Does this makes more sense to you ?

[gfrenoy]

Mmm, I'm wondering if creating a temporary file (with the full command) for connections wouldn't be better...? As a matter of fact, I think we have the same kind of issues with RDP or VNC as well...

[popxunga]

Humm, didn't check with RDP or VNC but anything that uses a proxy is affected.
While using a temporary file does not totally avoid the exposure (unless the file is encrypted) it reduces it drastically as long the file is deleted imediately after being used, which is far better than we have now. It would be nice if Asbru could encrypt those temporary files.

[gfrenoy]

Found something interesting (I think):

https://stackoverflow.com/a/3319056

[popxunga]

Well ... there's a lot of different things on that topic, so not sure which one(s) you consider interesting).

I would give a try with gpg to encrypt the temporary files. The key to be used with gpg could be:

• a value randomly generated before each connection command execution (not sure how much it will slowdown Asbru-cm and it looks unnecessary to me);

• a value randomly generated upon Asbru startup (this would be my first choice);

• a value stored in the Asbru config (not a good idea as it would be easely hackable);

• a value read from KeepassXC (will not solve the issue for those who don't use KeepassXC).

[gfrenoy]

Tried various things but at the end of the day, the ProxyCommand option is spawning the ncat process to establish the proxy and that process is exposing the password.

I think we should report that issue to the upstream project (https://github.com/nmap/nmap).

[popxunga]

I guess you're right. I wonder if the issue is caused by ncat itself or the the way ssh spawns the ncat process via ProxyCommand...

[gfrenoy]

I would blame ncat : it is supposed to hide the password from the command line after it has been read or propose alternatives way to provide (environment variable or configuration file, among other options).

Actually, xfreedrp is doing it fine, see here.

I created an issue -> https://github.com/nmap/nmap/issues/2060

In the meantime, there is not much we can do fear...

[popxunga]

Thanks for opening the issue on nmap.
But even if they decide to implement something it will take a long time until those modifications reach the EL distro channels.
So thanks for this :-)

[popxunga]

Meanwhile I tried with the latest loki build, and I'm still seeing the command with the exposed proxy credentials in the process list... I guess that the mentioned change is not committed yet along with some other related modifications I just seen. No hurry :-)

[gfrenoy]

Mmm, this requires a few more explanations...

1) For ncat: there is nothing we can do to hide the password ; it's a design flaw in ncat, only the upstream project can fix this.

2) Until they fix it and it reaches your distrib and if this should be an issue, I do fear you should not use that feature

3) The above fix is only helping for RDP/VNC ; xfreerdp, as an example is correctly hiding the password ; without the above fix, we we disclosing the password in some intermediate statements ; the new way is improving this.

I'm sorry we cannot provide a final answer but this is the best I can do for now.

[fyodor]

We are hoping to make this change for Ncat at some point (will be faster if someone commits a tested pull request). But in some ways the underlying "vulnerability" is in the system giving out sensitive information (the processes and command-line arguments run by other unprivileged users) in the first place. Even ignoring particularly sensitive data like passwords, there are many reasons you might want to keep this information private. You can turn this disclosure off on Linux with the hidepid option and I wish more Linux distributions would do that by default. More details: https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/

[syco]

N.B.: I edited this reply as it had a second issue I didn't notice at first and 2 replies one after the other seemed too much text..
The new $do_connection_cmd is constructed this way exclusively to remove cmd_file as soon as possible, without waiting for sh to terminate.

Hi, I'm testing loki on openSUSE, and..

I have several connections that don't use the default VNC Method, but instead use a Generic Command Method with this (or similar) string: vncviewer -passwd ~/vnc_pass 10.0.0.250:5900 -compresslevel 9

My issue is that the command file is removed before the spawned shell can read it.
I was able to take a screenshot by changing the file lib/asbru_conn from $do_connection_cmd = "sh $cmd_file"; to $do_connection_cmd = "sh $cmd_file; /bin/bash";
(please excuse my connection names)

My solution would be to have the spawned process remove the command file, not the spawner (it makes sense).
This would be how:

diff --git a/lib/asbru_conn b/lib/asbru_conn
index 07c47b9..ed684f2 100755
--- a/lib/asbru_conn
+++ b/lib/asbru_conn
@@ -1010,11 +1010,6 @@ sub _hardClose {
     my ($EXP, $uuid)  = @_;
     my $pipe = "$CFG_DIR/tmp/pipe_$uuid";
     my $sock = "$CFG_DIR/tmp/$uuid.ctl";
-    my $cmd_file = "$CFG_DIR/tmp/cmd_$uuid.run";
-
-    if (-e $cmd_file) {
-        unlink($cmd_file);
-    }

     if ($proxy_jump == 2 && -e $sock) {
         system "ssh -F $CFG_DIR/tmp/$uuid.conf -S $sock -T -O exit jumpserver";
@@ -1319,7 +1314,7 @@ if ($METHOD ne 'PACShell') {
     chmod(0400, $CMD);
     print { $CMD } $connection_cmd;
     close($CMD);
-    $do_connection_cmd = "sh $cmd_file";
+    $do_connection_cmd = "CCMMDD=\$(cat $cmd_file; rm -f $cmd_file); eval \"\$CCMMDD\"";
 }

 # Spawn the session
@@ -1930,9 +1925,6 @@ elsif (!$MANUAL) {
     }
 }

-# Once spawned, remove the temporary file (that may contain sensible information)
-unlink($cmd_file);
-
 $SIG{'WINCH'} = sub {
     if (!$CONNECTED) {
         return 1;

command.file.patch.txt

I also have to add that neither sh $cmd_file nor CCMMDD=\$(cat $cmd_file; rm -f $cmd_file); eval \"\$CCMMDD\" hide sensitive informations. A simple ps faux can easily reveal exactly what is executed as a child of sh.