Student Projects - Fall 2009

  • SPARC64 port-bind shellcode on NetBSD
  • Vulnerability analysis of the Flash file format
    - Quick guide to the Flash file format
    - Analysis of current exploits
    - Investigation of mitigation strategies
  • Reverse selected CSAW challenges from Stephen Ridley
  • Botnet take-over
    Specific botnet, contact me for details
  • ImmDBG/PyDebug script for automated malware analysis
    Specific malware family, contact me for details
  • Vulnerability analysis of Java deserialization bugs
    - Quick guide to deserialization bugs (if that's even possible)
    - Analysis of the calendar deserialization flaw
    - Development of simple tools to aid in discovery of additional flaws
  • Fuzz a custom web application
  • Fuzz a file format(s). Target: archive manager.
  • Fuzz a file format. Target: document reader.
  • Fuzz a file format. Target: Chinese software.
  • Find remote and client-side 0days in Win98

This post will be updated as more students submit status updates.

Mid-Semester Lessons Learned

Security Tools Reviews - not for students

I think I'm asking students to do too much here. Do homeworks, do a project, do readings, AND write presentations on tools they've never heard of before every week? This would work better if I laid out a schedule of tools and did the demonstrations myself. Maybe next year.

Non-local Professors - awesome!

Aaron, Pete, and Colin all delivered, without the benefit of speaking to me in-person about the class. Note to self for next time: have a disaster recovery plan in case of travel failures.

A Mole - worth it

I've previously talked about the benefits of having a "mole" in the class, someone who you can check in with each week to make sure you and your students are on the same page. I don't have one this semester and I feel like a rudderless ship.

Final Projects - direct students more

I introduced the final projects the second week this semester, but students didn't seem to settle on anything until about 8 weeks in. I need to have a solid list of pet projects I want done at the beginning of the semester.

Get an IDA license

The choice between IDA 4.9 with no features or IDA 5.2 restarting every 15 minutes is pretty sucky. I have to get someone to buck up and pay for a few licenses that I can use. Everything else seems to have decent free replacements.

Next Week

I'll be posting a list of all the project ideas that students came up with and are working on. Let me know if you can help any of them!


Security Tool Reviews

We haven't gone over "advanced hacker tools" in this course historically. The focus has always been on basic technical skills and the tools that can help students learn them. Things like IDA, Immunity Debugger, Metasploit, and Burp Proxy. The one thing we're not doing here is training script kiddies.

My views on this changed after a student of mine asked what Nessus was after handing in their final project. I was proud of this at first, really proud of this, but then I realized that this lack of exposure could be a weakness, if only because they might be misled by clever marketing in the future. Taking inspiration from a recurring series of presentations that Erik Cabetas and I put on for OWASP NY/NJ, I now devote the first 15 minutes of each class to honest discussions on security tools and their limitations. Even better, I ask students to research and present them. 

I'll be asking students to post their own slides to this blog each week. If the tool they review is open-source, I'll forward the feedback to the developer so that hopefully the tool can be improved.

If you have suggestions for topics for these presentations, feel free to post them below. I set the pace and did the first one this week on Fortify SCA, which Fortify Software donated for use in the class, and I'll be posting my review later this weekend. Thanks Fortify!

Patching and Hooking Students (Part 2)

We left off in the last post with an Remote File Include we discovered (cough planted) through auditing source code in a Wordpress plugin. This vulnerability allows us to execute arbitrary code in the context of the webserver user.

I wanted to keep this demonstration as true to life as possible. That means a recent, common operating system in its default configuration. I chose CentOS 5.3, released in March 2009, and I left SELinux in enforcing mode for added effect. What I didn't realize was just how locked down Apache httpd is in the default SELinux policy. Apache httpd is configured with directory indexes turned on by default but the SELinux privileges httpd_can_network_connect and httpd_can_network_relay are both disabled! I also wasn't able to execute certain binaries like wget and /bin/bash from the httpd process.

In reality, many (most?) CentOS webservers are going to allow httpd_can_network_connect/relay so they can do things like authenticate to LDAP or connect to a remote database server. I could have disabled those privileges by themselves with setsebool, but with limited time remaining to finish the demo, I decided to switch SELinux from enforcing to permissive mode.

Sidenote: How else might I have bypassed SELinux in this scenario? Instead of including PHP code to execute a shell, I could include an exploit for the PHP interpreter itself. Stefan Esser documented how to do this in extreme detail at this year's Blackhat conference. From there I might have been able to escalate privileges or mess with SELinux more easily. I might have done this if I knew the first thing about Linux exploitation (gdb can DIAF).

Free of these restrictions, I was finally able to execute a simple PHP web shell on the server. I went with the capable and modern (postmodern?) PHP-RPC shell included in the Ronin exploitation framework. I loaded the shell over a browser instead of via irb to make the demonstration a bit more in-your-face for the students watching.

I had pretty clearly taken over the website at this point. I could view the wp-config.php file to obtain the MySQL database password, connect directly to it, and pilfer all of the restricted information being stored inside. But real hackers don't stop there. Time to break out the local roots and backdoor this target.

Problem #1: Most local root exploits are made to be executed in a real terminal and they usually spawn a root-owned bash shell. Forget about blocking IO or launching a new shell with an RFI, we're executing remotely over a stateless protocol. That root-owned /bin/bash process you just launched will get lost forever. We have to backdoor the victim non-interactively in a way that gets us better access than this web shell.

Lucky for me, spender released his null dereference kernel exploitation framework complete with three recent kernel exploits a few days prior. His framework can be easily customized in C to launch arbitrary payloads upon successful exploitation. I wanted to avoid touching as much of his code as I could, so I replaced the guts of the RUN_ROOTSHELL if statement in exploit.c with the following code:

mkdir("/root/.ssh", 0700);
FILE *file = fopen("/root/.ssh/authorized_keys", "a+");
if(file) {
  fprintf(file, "%s", SSH_KEY);
chmod(/root/.ssh/authorized_keys", 0400);

I also commented out a bunch of code where it prompted you to select an exploit and just hardcoded "wunderbar_emporium" instead. That code right there, as simple as it looks, was the result of about an hour of trial and error. It turns out that the Linux kernel really doesn't like it when you open and modify files from inside kernel memory, so try and avoid that where possible.

Where SELinux was previously a mitigation and interfered with our exploitation of an RFI, it actually enables us to use spender's exploits to escalate our privileges from apache to root. The attack surface of this LSM is completely exposed when executing code locally and some of its design choices (?) allow us to exploit previously unexploitable bug classes (null dereferences).

Here are the goods:

This is where I stopped for the demo, I figured that students could come up with their own ideas for manipulating the Beta Two Labs members now that they had root access to their server.

That, is how you start off a class.

Thanks for reading and I hope you learned something!

Patching and Hooking Students (Part 1)

The semester has to start off with a bang. Students need to know why they are there, what they are going to learn, and be pumped about it. Somewhere in between I need to sneak in some ideas that will grow over the course of the semester.

Taking inspiration from recently released details about the Heartland data breach, I decided to simulate a fairly sophisticated attack against a public facing website and introduce them to threat modeling while I was at it.

Introducing, our target, Beta Two Labs, an uberl33t haxxor space located in Brooklyn Heights.

It's always more interesting when you have a fun target :-).

The scenario:

Beta Two Labs is using their website to organize an upcoming party at their hackerspace. You have been hired to disrupt the planning of this party and to infiltrate their organization. What do you do?

The attack surface here is extremely wide and you can accomplish your goals with a variety of techniques physical, client-side, or server-side. I let them think it out for a few minutes, and then I presented my own view of this challenge.

Step 1: Fingerprint and enumerate their web presence

Like most "hackerspaces", Beta Two Labs is running Wordpress which is absolutely riddled with bugs. It's also well known that Wordpress leaks its version information in "generator" meta tags hidden through its pages. This is too easy, so I hid the generator tag with wp-security-scan. There are lots of better ways to detect the version, like comparing diffs of different published versions for modified functionality or files. To make things simple, I left the readme.html file in the webroot:

I wasn't counting on anyone in the class dropping WP 0day, so I assumed this would be a dead end for them. Auditing the Wordpress codebase is a pain in the ass anyway, I kept an easier route open.

Wordpress plugins are installed at a predictable URI path. If we poll for a few of the top plugins, we should be able to identify which ones they have installed. Even simpler, if we're smart, we can figure out they have wp-security-scan installed from the lack of a generator tag. Code quality in plugins is probably going to be much less than in wp-core.

It turns out that wp-security-scan is a fairly complicated plugin and the potential for some good bugs is there. Again, I made things easy and injected a remote file include vulnerability into it, so that we could assume we would find a bug eventually and to demonstrate that security technologies themselves can generate huge exposures if you're not careful (which should be a recurring theme in this course).

To be continued in Part 2...