Settling down for a hacking session usually means lots of hard work and a long grind towards target data. You've got to juggle a large stack of systems and testing constraints, all while learning about the environment from the ground up. You can spend 3 hours trying to land a shell on a box, just to find it gets you nowhere.
However, sometimes a beautiful beam of light shines down from the heavens and opens up a door or two for you (or maybe its just the sun reflecting off of something in my office, either way).While increasingly rare, these open doors can result in some pretty hefty gains. Usually the product of an overworked admin, or a 'test' scenario gone production. Here are some situations I stumbled across in the past few months that came packaged up with a bow:
Just shout your creds to me
When you are on a network full of Windows machines, its typically pretty easy to enumerate their NetBIOS machine name using a wide array of tools. Using things like Nmap, a module out of Metasploit, or even just native smb tools, you can gather a list of machine names very quickly:
10.1.6.84 is running Windows Server 2008 R2 Enterprise 7601 Service Pack 1 (name:BANANA1) (domain:PEEL)
In this case, the NetBIOS name is 'BANANA1'. Since its so easy to enumerate this information, it would be bad to use it as a username or password. Sometimes, I find that's the case, and thankfully Medusa has an option just for this:
# medusa -h 10.1.6.84 -u administrator -p blah -m PASS:MACHINE -M smbntMedusa v2.1.1 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks ACCOUNT CHECK: [smbnt] Host: 10.1.6.84 (1 of 1, 0 complete) User: administrator (1 of 1, 0 complete) Password: BANANA1 (1 of 1 complete)ACCOUNT FOUND: [smbnt] Host: 10.1.6.84 User: administrator Password: BANANA1 [SUCCESS]
Excellent, a user compromise using nothing but the NetBIOS name. NetBIOS names should be used as just that, a name. Never use them as credentials.
Bash is all you need
Most of the time, when I compromise a Linux system, I am dropped on the box as a non-root user. There's lots of paths I can take, but usually I run right to 'sudo' if I know the account's password. This one was interesting, as the admin had blacklisted certain sudo commands:
bob@blaster:~$ sudo su[sudo] password for bob:Sorry, user bob is not allowed to execute '/bin/su' as root on blaster.
bob@blaster:~$ sudo /bin/bash[sudo] password for bob:Sorry, user bob is not allowed to execute '/bin/bash' as root on blaster.
So I can't run bash or su from sudo, what about a different shell?
bob@blaster:~$ sudo /bin/csh[sudo] password for bob:# whoamiroot# bashroot@blaster:~# iduid=0(root) gid=0(root) groups=0(root)
So the admin had blocked be from running 'bash' or 'su' from sudo, but forgot about the 'csh' shell. Once I was root in csh, it was easy to just hop back to bash (or just continue to use csh). Obviously, the correct way to do this is to whitelist certain sudo commands, or find some other way to limit excess permissions.
Jot that one down for me
One of my top priorities when I first compromise a box is to take a quick peek at what files are lying around. Users like to treat /home and Desktop's as a temporary file dump for all sorts of interesting things. On this system, I found the following file on a user's Desktop named "john's quick decryption test". The same passphrase worked on encrypted production data:
echo 'G0rillas<3Bananas33' | gpg --batch --passphrase-fd 0 -o c:\test.txt -d c:\test.txt.gpg
All the advantages of encrypting data are lost of the passphrase is stored somewhere that's easily accessible. Even worse when the passphrase is stored on someone's Desktop, but also decrypts data on non-domain production systems.
In the same genre, I found a libexpect script that a user was using to log in to every router and firewall, hop to enable, and backup the configurations.
#!/usr/bin/expectset timeout 60set server [lindex $argv 0]set tftpserver [lindex $argv 1]set tftpfile [lindex $argv 2]spawn ssh -l configbackup $serverexpect -re ".*assword:"send "silverb@ck54\r"expect -re ".*>" { send "ena\r" expect "Password:" send "kingG0rill@\r"...
Hard-coding credentials is like playing with fire. Especially when the credentials cross security zones.
Finding things like these help to uncover some gaps in the human side of the network. They might hurt at first glance, but identifying and fixing such things only helps in the long run.
