Sunday, October 20, 2013

By the gods, he lives! (Part 1, MDC3)

Hello again,

It's been quite a long time since I've posted anything here or posted any updates on github for autosnort OR H1N1 for that matter. well, let me tell you what I've been up to lately, this'll probably be over multiple posts, so I hope you're ready to be shotgunned with updates  >:) so let's start with MDC3.

For those who don't know about MDC3, what it is and why I'm interested in it, it's a yearly event sponsored by SAIC among other organizations. It's mainly a "suitcon", where managers in industry meet up, and a bunch of security vendors come on down to the Baltimore convention center with whitepapers and statistics and other things as to why you want to buy their wares.

In addition to that, MDC3 hosts a yearly cyber challenge event that I use as a sort of whet stone for keeping myself sharp. There are 5 rounds in total. The first 4 rounds are done online/offline with friends at a place of your choosing, with the final round at the "suitcon" live.

Out of the four online/offline rounds, the first two are practice rounds while the next two rounds are qualifier rounds for the finals. The practice and qualifier rounds are very similar -- either you're given VM images to examine, or you are given forensic and crypto challenges to perform. -- things ranging from "Here's a VM with an operating system of some sort running on it. It's owned in various ways and has several security holes. Close the holes." to "Here's a PCAP, answer these questions", where the questions range from "What was the admin on this box doing while the system was being compromised?" to "The attacker used FTP to exfil data off the system. Give us the name and an md5sum of the files downloaded."

We skipped the practice rounds this year, though in retrospect, I kinda wish we had gotten the files so I could practice more. So for the first qualifier round, we ended getting a windows server VM that was owned in various ways. The server was running IIS and had simple TCP services enabled. In addition to that, no patches, no security countermeasures, no firewalls, several netcat backdoors, user applications (firefox and chrome installed -- plus firefox was backdoored with another netcat listener), etc.

The round was scored out of 20 points or 20 vulnerabilities to remediate. Our team ended up getting 19 out of 20 and passing the round. Essentially all we did was more or less manually revert the host back to a clean,default install with DISA STIG recommendations applied, full patches, all services disabled, user account passwords changed and other common sense things you would do to a system that was compromised. We had no requirements to keep IIS running or core services on the VM that were required to be running, so we just uninstalled everything.

Some of you may be running, how would SAIC know what was going on with the VM and whether or not you remediated something? They had a really crappy java client called cybernexs installed on the VM with a special account running a service that would start on boot, that you would register to a scoring server. This service would phone home and say what you had fixed.

Theoretically, you could reverse engineer the client and make it pretend to call back stating everything was fixed, but we never got around to doing that. I know I'm not skilled enough to do that, but there were some on our team that probably could have done it.

Back to the competition. So overall I'll call round 1 a success, however it's disappointing: In a real-live production environment, your server is responsible for providing a service (at minimum 1 service, sometimes many), the fact that we were given free reign to uninstall all services and applications installed on the server flies in the face of reality.

So the second round this year was network forensics and crypto.  We were given a packet capture to analyze and the following questions:

1. What files were transferred from the victim?

2. What directory were files initially copied to?

3. What is MD5 hash of files transferred to the attacker? (Use lowercase letters)


4. What port is the backdoor listening on?


5. What was the admin doing during attack?

6. What is the name of the backdoor user?

7. What is the password of the backdoor user?

8. What is root's password?

9. What software on the victim allowed the attack?

10. Repair the zip file and answer the challenges within.

I managed to do most of these questions easily. The only tools I used this were Wireshark, Network Miner, md5sum and DiskInternals zip repair utility. Managed to answer all the questions except question 8.... a portion of the pcap showed the attack managed to get a copy of /etc/shadow. Even after throwing JohnTheRipper at it for 24 hours straight, I never cracked the password or got any hint in the pcap as to what root's password was. Bummer.

Question 10 was a multi-parter. Part of the forensic challenge indicates there were files transferred during the attack. One of the files was a zip file. It was in plaintext and was easy to single out with wireshark and tcp stream separation. After exporting the bytes of the TCP stream, I was able to reconstruct it as a zip file. The problem was that the zip file was broken. Another one of our team members who knew more about forensics than me was able to manually fix it. There was some sort of discrepency between the zip file's size and the zip file record's reported size that needed to be repaired. I ended up using diskinternal's zip file repair utility and that fixed it for me. That was as far as I got there, I relied on other team members to resolve the crypto challenges since I'm absolutely terrible at crypto and cipher schemes.

We did well enough as a team to make it to the finals. The format of the final round is completely different from the previous rounds. It's essentially a king of the hill style CTF challenge. There are several systems (with more being added over the duration of the event) that are vulnerable and very exploitable. The goal is to get on the system, and plant your flag (a flag.txt file with a hash that represents your team in a specific directory on the host) and keep it there. You can lose shell access to a system, but as long as your flag is there, the system is still yours.

Well, I was in charge of exploiting windows systems, and here was my run-down: Most of the Windows 2000, w2k3 and XP systems were vulnerable to some fort of MS08-067 (If you don't know what this is, it's essentially a 4+ year old SMB exploit for windows versions ranging from windows NT to Server 2003 as well as several service pack revisions, it's pretty old, but is still used as a point of reference for many security conferences and classes because it's very reliable and a shining example of Remote Code Execution exploitation) MS03-026 (this exploit is mainly focused around windows 2000, early versions of XP and early versions of server 2003. It's an RPC DCOM exploit that is also another popular remote code execution exploit used as an example in lots of training courses.), etc.

The most unique windows box I had to throw against in the network, another team member found was vulnerable to file upload via webdav, and handed off to me to finish owning. There's a metasploit module that exploits the file upload and uploads an ASP script which then gives you a meterpreter shell as an unpriveleged user. At that point, you could plant the flag as an unpriv'd user, or you could be like me, rummage through armitage and metasploit's post-exploit modules and find a privilege escalation that would give you SYSTEM access...As an attacker, why would I want system access? Well, there are a number of reasons, we'll get into that in a moment. after several unsuccessful tries, I managed to get system through ms11-080. I wish I was smart enough understand how it worked, but the gist of it is that it's a driver that executes in ring 0 (kernel space, SYSTEM space) and through some voodoo magic or another, you load shellcode into memory and tell this driver to refer to your shellcode, and BAM you have a system shell (smarter hackers will skewer me... but I did what I could with what I know.)

So, what was the point of gaining system access the windows boxes? system access enables you to utilize a post-exploitation module known as hashdump. hashdump allows you to dump the contents of the SAM (Security Accounts Manager) database. This contains hashes for all the users on the system, from the lowliest of users to all system administrators.

What good are hashes without having the cracked, you may ask. Well, in windows, you don't necessary need to crack the hashes in order to be able to utilize them. A common exploit for windows is a technique called "Pass the Hash". PTH exploits a weakness in windows filesharing that allows you to authenticate to a remote windows system by simply giving the remote system a copy of that user's hash as opposed to the actual password and having the remote system do hash checking. Pass the hash can be used to do anything that user can do -- map drives, execute commands, upload and execute metasploit payloads, etc.

So, when you exploit a windows system, the first thing you want to do is esclate privs and get system access as soon as you can. After you have system access, you want to dump hashes and get hashes for admin users, since it's extremely easy to gain system access as an admin user. Once you have hashes for admin users, this allows you to use psexec/pass the hash to maintain access to an exploited host, or easily regain access to the host if you've somehow lost your initial access.

So, in spite of getting hashes for multiple systems and repeatedly managing to get back on as SYSTEM, we didn't get very far in terms of placement, because others would simply beat us to our targets and had better methods of planting their flag and keeping it there. I didn't know enough about acls and cacls to figure out how to fix file permissions to undo what they did to their flag file to leave it on the host, then drop our file and lock it to where other teams couldn't modify it. It was really frustrating. Also, in addition to that, I would repeatedly lose my meterpreter shells in spite of doing things the right way (e.g. migrate processes and load meterpreter into a system process that an adversary would not want to kill, etc.)

While I was thrashing windows boxes, others were doing everything they could in linux and unix hosts. And once again, we would get access (managed to plant our flag briefly on one), and lose it, then the hole would be closed, locking us out of that host.

So, in spite of all things, and not having won the competition, I was satisfied because of the fact that I did manage to pop some windows boxes and be a massive annoyance to other teams. I was annoyed because either the network was incredibly unstable, or the hosts we were attacking were incredibly unstable. I'm guessing a combination of the two, but the systems we attacked and got on to would get REALLY bogged down after a little while. I was also disappointed. SAIC didn't give us much swag this year for making it to the finals. Last year, we got challenge coins for making it to the finals, this year, we got a craptastic backpack. registration for the event was something like 300 dollars per team in the professional level. What gives? Sigh. Oh well.

So, that's a run-down of my MDC3 adventures.

Part 2: the secret weapons that never were. Look forward to a script release...

No comments:

Post a Comment