In one window, log into a Linux server (RHEL 5.3 in my case) as root. In another window, use ssh to log from a remote machine into the server:
jhall@bourdain ~$ sftp guest@myserver
Connecting to myserver...
guest@myserver's password:
When it prompts for the password, hop back over to the server and run ps to figure out which process is handling the connection:
[root@myserver ~]# ps auxf | grep ssh
root 28705 0.0 0.0 60672 1184 ? Ss 12:32 0:00 /usr/sbin/sshd
root 29361 0.0 0.0 86856 3116 ? Ss 14:36 0:00 \_ sshd: guest [priv]
sshd 29362 0.0 0.0 62016 1384 ? S 14:36 0:00 \_ sshd: guest [net]
What you need from this is the PID of the sshd process with [priv] next to it. In this case, 29361. Use strace to hop in and monitor this process (redirecting STDERR to a file, for later reference):
[root@myserver ~]# strace -p 29361 2> strace.log
Go back over to the remote system and type in the password. Go back to the server, cancel the strace, and then take a look at the log file. On my system, the 3rd line down had the payload:
Process 29361 attached - interrupt to quit
read(6, "\0\0\0\f", 4) = 4
read(6, "\v\0\0\0\7inmelet", 12) = 12
getuid() = 0
open("/etc/passwd", O_RDONLY) = 4
The text that we're looking for here is "inmelet", which is our sample password. In the clear.
Of course, this was a very manual process. But plenty of techniques exist would would allow us to monitor sshd, and launch strace automagically every time a user logged in. Of course, if you're using ssh keys, then there would be no password to see in the clear anyway. I haven't tested to see if you could steal the ssh key though. That might be a fun excercise too.
Good writeup. I found this a bit troubling at first, but then thought that the password has to get to the server in plain text, and strace is just catching it. But then, does it? Maybe the SSH client could MD5 the password, and send the hash to the server instead. That wouldn't work too well, I suppose, and different operating systems use different hashing mechanisms in their password databases (MD5, SHA256, SHA512, Blowfish, etc). Interesting, nonetheless.
ReplyDeleteOn hashing the password first -- that doesn't ifx anything. All the attacker needs to do is use a modified ssh that lets him provide a pre-hashed password rather than a password to hash.
ReplyDeleteOn stealing the key - no, it won't let you steal the key. The key is never sent over the wire.