Monday, October 21, 2013

By the gods, he lives! (Part 2: Secret weapons that never were)

So,

Last post I had talked about MDC3, and my role along with the rest of the unallocated team in making it to the finals. Sadly, we didn't win, but even worse, we never got to utilize the secret weapons we were planning on bringing with us. Once again, I had my involvement on the secret weapons front.

Most of our weapons weren't exactly that secret -- we had plans to bring massive password cracking wordlists with us from freely available sources, and essentially bring a package of updated tools with us.

My job was to re-spin Kali with the most up-to-date tools available for use, as well as provide us with some (not-so) secret weapons that are tailored towards CTF usage. Unfortunately, they outlawed use of your own special software or tools for the competition (in my opinion, that didn't keep others from downloading their tools and using them, but we played by the rules, regretfully)

So I worked at this shell script only to find out we couldn't use it for our CTF event. Well, our loss is now your gain. I present to you, updater.sh

What does updater.sh do?

Updater is a script specifically for Kali Linux that performs the following tasks:

.5: checks to see if you're root. If you're running on Kali, you should be, but still.

1. Generates new ssh host keys for your Kali installation, starts the ssh daemon and makes it start on boot -- this was something that was somewhat of an annoyance to me. Kali has every other service and capability known to man on it, but doesn't have sshd started by default. Well, I fixed that.

2. Adds the Kali Linux bleeding edge repository -- There isn't that much to say that hasn't already been said here. Basically there are certain tools that update frequently that were included by default with Kali. The bleeding edge repo was Kali's answer to those tools. Right now, the bleeding repo only has a small subset of tools, but dammit I want the latest and greatest, so I added the bleeding repo to Kali's /etc/apt/sources.lst

3. The almighty apt-get update and apt-get -y upgrade (dist-upgrade) -- What would an update script be without apt-get update and upgrade? I know, this is braindead simple stuff, but I wanted to automate it regardless. Just to give you fair warning: make sure you have ample time when running this script. This is the longest portion of the script. Why? Default Kali install pulls 400+ packages of varying size (some over 100+mb), then has to install all that.

You might wonder, why the hell would I choose to use dist-upgrade as opposed to just upgrade? I noticed when I ran the updates initially there was a number of packages that were "held back". Doing my homework, held back packages can be force updated via dist-upgrade when updating packages. I don't see a reason to hold back security tool packages, so I opted for the simplest way to fix it.

4. Msfupdate -- So you've updated your OS installations core tools and bleeding edge tools, what next? Kali's heart is metasploit. So msfupdate seemed logical to me. Takes a moment or two, but not nearly as drawn out as the apt-get package pull and the benefits are definitely noticable if you have any tasks where you'll be using or relying on the framework.

5. If you have the flash installer package for linux (.tar.gz) and/or the Nessus .deb package (with a home or professional feed provided to the script), they are automatically installed -- drop the adobe flash play for linux package in the root ("/") directory and/or the nessus installer package and provide the shell script with a home or professional feed key, and the script will auto install both.

Some of the more security conscious saw flash player and probably did one of these , but flash is required for a wide variety of web consoles (nessus included), so I included the option of installing it if the script detects you downloaded it and have it in the right place. If you don't want it installed, just don't download flash. That simple.

6. Couple of minor customizations -- As a part of the updater, some packages that I found to be missing on a deafault Kali install I configured apt-get to install:

armitage -- The popular graphical front-end to the metasploit framework by Raphael Mudge of Strategic Cyber. Also installs the teamserver (armitage collaboration) program. Was very surprised this was not installed by default.
mimikatz -- a popular program for dumping plaintext passwords -- basically if a user is logged in, lsass stores a plaintext copy of that user's password within lsass' memory space in memory. mimikatz can dump it and reveal the passwords stored.
terminator - a terminal emulator program that supports tabbed terminal sessions and also has a unique feature that allows you to split your terminal screen vertically and horizontally as many times as you want. For those with an OSX background, think of this as the Linux version of iterm/iterm2
unicornscan - a leightweight asynchronous network scanner. Doesn't have all the fancy bells and whistles of nmap, but sometimes all you want is a list of open ports. unicornscan does this fast and it does it well.
zenmap - the graphical front-end to the ever popular nmap scanner. Was also very surprised that this was not installed by default as well.

7. A collection of scripts and tools from other CTF veterans and pentesters alike who were willing to share their armaments, including:

1. The github collection of Cortana .cna scripts for automated red-teaming and post-exploitation. Cortana is touted as a "Red team force multiplier". Translated from cyber-ese, Cortana is a bot platform for armitage. Basically you provide scripts to Cortana and they can do things ranging from updating functionality in Armitage and allowing you to do new things to, automated scanning, to automatically throwing exploits at new targets seen on the network that have certain points open and/or listening services to post-exploitation modules to maintain persistence to hard-won hosts. If you're familiar with the sleep language, (The strange perl dialect that much of Armitage is written in along with java) then you can write your own, or simply modify the pre-existing scripts to suite your needs.

2. Unsploitable tools: Unsploitable is a collection of tools/scripts that when you feed them the results of a nessus scan will tell you what exact patch will fix the vulnerabilities listed. Good for situations where you have to perform triage quickly.

3. Defense Tools for the Blind (DTFTB): a set of scripts for unix systems that sort of allow you to ghetto rig security for unix systems and kinda triage the system/provide emergency defensive countermeasures for when you don't have the time or resources to fully patch out your vulnerabilities. For example, one script is a while true that scans ps output for /bin/sh or nc or netcat and kills the associated processes, killing post-exploit shells and simple backdoors.

4.New custom build of smbexec by Brav0hax. Basically this is a copy of the smbexec functionality found in metasploit re-written to get around some security products catching metasploit smbexec and flagging it as a non-legitimate service installation.

That's it. Lot of simple things, that make Kali that much more awesome and makes it that much easier for you to gear up for the CTF or pentest.

As with the autosnort scripts, the script tells you what it's doing and gives you success or failure indicators. If there's a failure the script bails.

The script logs the entirety of output for each of the installation steps to a dedicated log file in /var/log named kali_updater.log

If you're looking for a challenge, troll through it, figure out what failed, fix it, contact me, tell me my script is broken and how you fixed it. If you're lazy or not looking for a challenge, tell me my script is broken and ship me a copy of the updater log.

As usual, along side any post where I announce a new tool or script, it's available via github

My final installation in the 'what the hell have you been doing series: BSIDES DC!

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...