Slides from ShmooCon

So this has been way overdue, but here are my slides from my ShmooCon presentation, Ring -1 vs. Ring -2: Containerizing Malicious SMM Interrupt Handlers on AMD-V.

Honestly, I'm a little disappointed in myself for the presentation. I think it went well but I didn't really have time to make the talk as accessible as I would have liked, also this was my first time presenting at a conference so usual jitters apply, hopefully I'll get the chance to do it again.

A little explanation: The goal of this project was to determine how to protect a virtual machine monitor from a malicious System Management Mode Interrupt handler.

When I started working for Crucial Security my main focus was on building a hypervisor that was able to isolate a process from a malicious OS, the idea being that we wanted to ensure that even if an attacker got access to a server they'd still have to exploit the specific service to gain access to its data. During development we kept discovering new avenues of attacking the VMM, one of the most damaging ways was to use a malicious SMI handler as was done in Rafal Wojtczuk and Joanna Rutkowska's presentation on Attacking Intel's TXT.

The defense against their attack that Intel responded with was that the VMM developer should run the SMI handler inside of a virtual machine. Joanna's counter point was that, no one has good documentation on how to do that. Since I was developing a tiny VMM for security, I took that challenge and on the AMD-V platform developed a hypervisor that could run a limited SMI handler inside of a virtual machine as a PoC.

Unfortunately almost all of my time was spent developing and debugging the PoC, with less attention than I would have liked going to the actual presentation. Anyway I still need to get the source off of back ups since my corporate laptop died. However it should be up by the end of May. Comments and feed back are greatly appreciated.

My hope is that this helps VMM developers get a better idea in what's involved with isolating an SMI handler and in rare cases where that level of paranoia is needed, that my work can help other people find the information they need more quickly.

Content Finally

As people following along via RSS may have noticed I'm finally putting some of my old blog articles into this blog. The process has been really enlightening, some of the posts are embarrassing as I find old promises, to write articles that would have been a lot of fun to research.

The nice part about this is that I can follow through on my promises since I never put a date on them. Anyway my personal goal is to start blogging again as it's both cathartic and a good means of keeping notes for research.

Cheers,

-Pete

How'd You Get Into Security?

One of the most important things in a professionals career is their sense of what is and isn't possible. The caveat here is that this is often colored by your perception of what is and isn't easy to do, in other words your experience. In a recent conversation with Russell, this topic came up in the conext of information security professionals. As the conversation progressed two points stuck out in my mind, 1. that I came to security from a development background, 2. that it may not be as common as I thought.

Before I'd ever thought about networks, security or anything else related to information security, I'd learned C, and pascal in high school. I'd been doing basic bat scripting since my grandfather bought my family their first computer in 1993. Until I went to Northeastern University and majored in computer science my interest in the computer was primarily in figuring out how the box worked at the computer architechture level which I dabbled with on again and off again.

So how'd I actually get into this field? It was the summer of 2001, it was a hard summer for finding co-op assignments. For those of you not familiar with co-ops, it's basically a stint where you work in your field sort of like an internship. I'd already done some minor contract work with the chemistry department to write a visual basic program (eww in hindsight) to do some post processing of mass spectrometer results. I'd landed a job working as a JSP developer building a web based college advising system and things started to go wrong when a fellow student (Jon) walks in and says I've hacked your database.

Before I get into recounting how we were completely owned and what I did about it. Let me give you some background on the system. I was roughly the sixth developer, had never touched apache, tomcat, MS-SQL or JSP before this. It was a good learning experience. Though the project was doomed from the start. Too many developers had worked on it and then left and then in the middle of working on the project the professor and his two graduate students (who basically only spoke chinese which I can not speak) left. Leaving me with a collection of JSP pages and db tables that had each made sense to one of the previous devs.

Jon had found numerous SQL injeciton bugs which since we were using MS-SQL gives him shell access. What's worse is that this was a college advising database that of course contained student id numbers and contact informaiton. Like most universities Northeastern used social security numbers for student ids, game over. I spent the better part of a week building a really simplistic filtering library, going back and forth with Jon until he was unable to compromise the box via SQL injection. Looking back I'm sure there was XSS and enough other vectors to make everyone involved cringe in horror.

As expected, the web app never really got off the ground and it left me rather disappointed. The experience of potentially losing 400+ students social security numbers was too much for me, it made me realize that if I'd wanted to continue in development I'd need to learn about security and I've been doing that ever since.

So how does this relate to my original point? I like to build things, I was a developer. Therefore I look to build things when possible. It colors the decisions you're likely to make.

So how'd you get into information security?

ISC's Four Methods of Decoding Javascript + 1

After reading CGISecurity today I was pointed to an article over at the ISC. It listed four methods of decoding javascript as illustrated in the following table.

Note: The table values are taken from Daniel Wesemann's ISC post

Method	Description	Pros	Cons
The Lazy Method	Edit your copy of the hostile HTML so that it only contains the necessary HTML headers and the Javascript you're interested in. Then hunt down all occurences of "document.write" and "eval" inside the Javascript and replace them with "alert". Copy the modified file onto a web server of yours, or to some other place from where you can easily open it with a web browser, which should make the decoded JavaScript appear inside one (or several) pop-up "alert" windows.	Quick and easy to accomplish	Usually only decodes one (the first) encoding stage. Don't be disappointed if you get the next level of gibberish in your alert pop-up.
The Tom Liston Method	The idea is that you replace occurences of eval(stringVal) and document.write(stringVal) with document.write("<textarea rows=50 cols=50>");document.write(txt); document.write("</textarea>");	Quick and easy to accomplish, and in case the textarea reveals another stage of encoded Javascript, this method allows for easy cut-and-paste to continue the decoding.	Careful with typos. If you have a typo in the leading textarea definition, the following "document.write(txt)" will go right to the browser, as it originally would have, and the exploit will execute.
The Perl-Fu Method	Try to make sense of the Javascript decoding routine, and then re-create it with a short code block in PERL.	Very easy and fast for use on the dumber encoding methods like XOR, Caesar ciphers (character permutations), etc. Also the "safest" method, as this approach alone does not actually execute the hostile code.	You have to speak Perl and be able to translate the Javascript decoding into Perl. Much too tedious an approach for very convoluted Javascript, or JavaScript codes using functions which are hard to translate into Perl (like the arguments.callee codes seen frequently in fall 2006)
The Monkey Wrench Method	Use the stand-alone Javascript interpreter "SpiderMonkey" to run the encoded Javascript block. Replace the document.write(txt) with print(txt) before doing so, SpiderMonkey doesn't have any document object by default.	Little hassle, good results, fast method to get around a hard "outer shell" of a Javascript block encoded multiple times, works well in combination with the Perl-Fu method.	Fails for Javascript code deliberately written to only uncompress on Internet Explorer.

First a few quibbles about the list. One the Perl-fu method is really about translating javascript into your language of choice. It's a bit difficult as it doesn't handle interaction with the DOM. The monkey wrench method has some trouble with browser specific interpreter issues such as handling subscript notation.

So my little addition to this for javascript is the use of firebug. Firebug in case you've missed it is a javascript dubugger in the form of a Firefox extension. This allows you to among other things set breakpoints and single step through javascript lines. The method breaks down like this:

1. Put the javascript in an HTML page, we'll call a test page


2. Modify the javascript to have a debugger statement at the start of the javascript.


3. Make sure firebug is enabled


4. Load the test page in Firefox


5. Now set breakpoints where you want and single step

Since I copied the pros and cons from the ISC list I figure I'd better contribute my own row for the firebug method.

Method	Description	Pros	Cons
Firebug Method	Adding a debugger statement to the start of the javascript, and then single step your way through the code setting break points to speed up the work. Stopping to examine the DOM. etc.	This allows you to examine the code for side effects like manipulating the dom. Gives you the power of a debugger.	Does not work with browser specific javascript except for Firefox. Can be slow if you just single step your way through.

For example if I have a sample file:

<html>
<script>
while(1){
 alert('fooo');
}

</script>
<body>

<body>
<html>

I can simply add a breakpoint before the alert call by adding the statement

<html>
<script>
while(1){
debugger;
alert('fooo');
}

</script>
<body>

<body>
<html>

This drops me into firebug at the debugger line. I can now single step my way through the code and inspect the DOM in the GUI.

For more information on using Firebug check out this video here

A Short Week And See You At Shmoocon

So this week is a short week for me while since I'll be attending Shmoocon in Washington DC. If you're attending Shmoocon or just for hanging out in DC drop me an email..

Shmoocon 2007 Notes and DC Wrap Up

So my trip to DC and Shmoocon was interesting to say the least. I'm still not used to visiting somewhere I lived. It's always amusing to actually know your way around (well as much as I can with my messed up sense of direction.) and since my departure to sunny California, I've really missed my old friends from DC, so meeting up with them was great.

I have to admit that I've always enjoy cons -- the people, the free flow of ideas and concerns. It's great, I usually find something new and interesting to look into. This time I picked up Craig Nevill-Manning's thesis. Which is the basis for most of Dan Kaminsky's work on using inferred structure with fuzzing. More in a later post.

Before The Con

My con experience started off by meeting Ben Laurie and helping him set up the Google table at the con. No sooner had we finished setting up when a woman accosted us regarding recruiter spam. Now I'm not anywhere near the recrutiers at work for the most part so I'm not sure what they are or are not doing. Needless to say this woman was upset. Ben took her information and said he'd look into it. Around this time I realized that I needed breakfast. So I'd wandered up to get coffee and some food from the Starbucks inside the Wardman Park hotel when I ran into Richard Bejtlich. Who was looking for Chris Lee who was speaking at a NovaSec meeting. So I abandoned my search for food and drink and crashed the meeting.

Chris Lee presented on various networking monitoring and Honeynet related projects. One of the more interesting projects was Flowtag. Basically it's a way of taging flows that are extracted from a pcap. The idea being that you can improve analysis by subsequently looking at the tags applied by other humans at flows and sort of have a del.ico.us of network data. Very cool though I want it to have a rule language so that when I tag something Ican then see if my pattern or tag could be applied elsewhere.

I ran into Kathy and while talking to her ran into Billy Hoffman. We ended up talking about some conversations we'd been having regarding a barage of topics from Javascript to Honeyclients.

Day 1 Talks

H1kari -- Hacking the Airwaves with FPGA's

This talk was about using (Field Programmable Gate Arrays) FPGAs to enhance brute forcing attacks against varioius wireless protocols such as WPA, WEP and Bluetooth. I'd seen Hikari talk on this before so I didn't fine myself learning a whole lot other than that some hashes were computationally expensive to calculate on purpose to discourage brute force attacks. I think the real take away from the talk was that FPGAs are coming down in price. H1kari mentioned that their new expresscard based FPGAs were about $1950 US. This means that the whole technology is easily within reach for a small company or determined individual. If the price comes down more I'd wonder how long it will be before we hear that it's time to increase our key sizes?.

Eoin Miller and Adair Collins -- Auditing Cached Credentials with Cachedump

This talk was disappointing. The main focus of the talk was the risks associated with windows cached credentials. The talk focused on first introducing you to the need for cached credentials followed by the implication cracking a Domain Administrator's credentials on an unsuspecting laptop. This talk closed with a demo of using cache dump. Questions from the audience centered around how long does it take to crack these hashes and what data consituted the hash. The speakers seemed to be at odds with the contents of the hash.

Adam Shostack -- Security Breeches are Good For You.

Adam's a very sharp guy and I highly recommend you read his blog.

The basic premise was that with new legislation requiring companies to disclose breaches we (as in the security community) now have new hard data that we can start using. This referenced California's SB 1386 as the law that started it all. Some points were made regarding the lack of standardization interms of information required to be disclosed. To quote Adam "We can do science..." with this data. I especially like the idea of verifying the effectiveness of adding countermeasures. E.g. after a breach has been reported and a company has implemented some sort of countermeasures do they get breached the same way again or do the total number of reported breaches decrease? The caveat I see to this is that it's not entirely perfect as your threats could just ignore you for a long while.

I wanted to see the keynote but as I had a date (too long of a story for me to explain here). I went back to my hotel to get ready. The short of it is that this made my trip to DC complicated. I had a great time but found myself soul searching on a few things.

Day 2 Talks

Matt Fisher, Cygnus and PresMike -- Web Application Incident Preparation

In fairness the presenters made it clear that they didn't expect to give this talk until last minute so it came across as unpolished. However I really found myself disliking this talk. They spent a lot of time trying to discuss how incident response for a web application is different than tradditional incident response. I found myself walking out of this talk and then back in. Specifically they brought up the fact that you have to look at logs and that traditional signs of an incident aren't present. This seemed obivous. To make IDS useful they talked about using canary values, in your data such that you could identify when it's left you webapp. Of course this led into the next topic which was how does SSL hamper your ability to identify attacks. Recommendations such as terminate SSL at an accelerator were passed around.

At about this time I was getting annoyed so I walked out. Why was I annoyed? Because no one had bothered to discuss detection at the app layer. The SSL question can be nullified side if you're willing to do some detection at the application layer, products like modesecurity allow you to do just this in Apache.. The detriment of doing this is that it's a fairly large investment, requiring modification of software. However the benefite of doing this is that you can effectively remove a choke point in your network which allows you to scale. Also it allows you to detect things even when load balancing is in play.

Not discussing the effects of load balancing I thought was remiss. Even if I'm terminating SSL on an accelerator, but keep going to differnt datacenters or locations because of load balancing or some form of CDN what can I actually detect? Another issue that comes into play with a large website is the size of the pipe how effectively can I monitor a 1GB+ line?

Billy Hoffman -- JavaScript Malware for a Grey Goo Tomorrow

This talk was about Jikto his Javascript based attack tool. I got called and paged during this talk so I don't have the best of notes as I had to leave the talk. I'll write something up for this after the slides come out.

Backbone Fuzzing by Raven

This talk was pretty good. The main focus was that there doesn't seem to be a lot of fuzzing being done on the backbone protocols e.g. RIP, OSPF and company. Her research was started by a bug disclosed in Cisco's in which advertising a previous version of IOS in the packet would crash the infrastructrure. The rest of the talk was on her methodology of how she'd go about fuzzing and how she did just that with the General Purpose Fuzzer (GPF).

One complaint that Raven made was that it wasn't easy to write fuzzers for protocols like BGP, RIP, etc. I really wanted to talk to her after and point out Dug Song's dpkt which makes packet crafting pretty simple. The crowds were big so I never got a chance. I guess that's why there's email.

The Audience got weird during the Q & A session for this talk. One member asked Raven why she was qualified to do backbone security when should couldn't keep her laptop secure at another con. This was a pointless question and seemed to show that fuzzing is a topic that many people seem to have trouble following. However it set the stage for encountering a hostile audience at the next talk I attended which was Dan Kaminsky's.

Dan Kaminsky -- Weaponizing Noam Chomsky, or Hacking with Pattern Languages

I've seen Dan talk at cons for close to 4 years always entertaining. Plus he usually gives me something fun to try and rewrite so I can understand all of the nuances to what he's saying.

This talk was a continuation of the talk that he gave at Defcon. He started by making a quick point "Why is fuzzing still useful in 2007?" He then proceded to discuss context free grammars and their applicability to machine generated data. He then proceded to discuss Craig Nevill-Manning's work on infering sequental structure from a sequence of data, and his implementation of Nevill-Manning's Sequiter algorithm. All of this was to leading how Dan is using his implementation of sequiter to help his fuzzing. Dan called this the CFG9000, the idea feed it input and it figures out the symbols in the output and attacks parser at the symbolic level. In other words his fuzzer gains a basic syntactical understanding of the data and then uses this to add in it's data generation.

Dan also showed how one could use linguistic methods of comparison to find differnces between subsequent versions of data. Namely he used dot plots. (More on this in a future post).

Like Raven's talk the audience was somewhat hostile. The Shmooballs flew and the Dan tried to get through his talk. Many of the questions and interuptions from the audience were off topic. For example there was a tangent on the wheather or not PKI was in fact dead. Personally I found it annoying, but it was illustrative that the audience was not following what Dan was saying.

As to quality of presentation I'm a little mixed in my review. I found it easy to follow Dan because I talked to him about it the night before. Dan was moving very fast to try and cover the full amount of material he had and I think the transitions weren't entirely clear. If I had to give advice to Dan I'd say walk people through a few examples to make sure they follow you.

I'd love to see Dan's sequiter linked up with some of the semantic web stuff as I think he could use RDF and OWL for some cool stuff. (Again more on this in a later post.)

Chris Paget -- WPAD: Proxy Attack

After Dan's talk this one seemed amazingly straight forward. Essentially the Windows Proxy Auto Detection protocol relies on names in WINS, NetBIOS, DNS and DHCP. By either registering the name WPAD.your.domain or winning the resolution race an attacker can become the WPAD host and have everyone in a network trying to use them as their proxy.

Chris then showed his proxy that could be used to both intercept this traffic, and conduct attacks on hosts using him as a proxy. All in all very scary.

The problem here is that there isn't a way for the client to verify where they get their proxy information from or even if it makes sense for the client.

Day 3 Talks

I wasn't feeling so good so I didn't get to the conference until the last talk. Which was about the one laptop per child though I again left the talk to catch up with a few people last minute. I regret not seeing Ben Laurie speak.

Conclusion

Shmoocon was fun though due to some aftermath from Friday night this visit was tainted for me. I look forward to it next year. Though hopefully with less drama.

Unified Output File API in python

So after reading this post. I thought, "Hell I'd like something like that in Python". So I ported the Unified file API from Ruby to Python. Feel free to send any comments my way.

Note: it's not tested yet but hey this is open source so release early and release often.

unified.py

OS X Hardening Guides

OS X has always been an interesting to me. It's almost unix but not quite and unique enough under the hood that it bears looking into. For years I've been meaning to get off the user only side of OS X and start getting into the internals of the beast. As a first step I'm looking at hardening guides.

So far I've found

• Cosaire's 10.4 Hardening Guide


• NSA Hardening Guide for OS X 10.4

Update:Found another OS X hardening guide here cannot remember the original link but I think I got it through SANS.

If you have another guide let me know.

The Network As An Indicator

The Idea

A year ago this was posted about the Iraqi IP space. I found myself revisiting the page today and it got me to thinking -- how does the state of the network correllate to the conflict in Iraq? The network obviously requires power. So I should be able to get an estimate of the state of the power grid by simply checking across all IP blocks that were listed in the previously mentioned link.

How to Determine if This is True?

1. Acquire a list of IPs in Iraq.




You can use the list in the article or pull it down from http://www.ipdeny.com




2. Geolocate those IPs as best as you can




You can pull this data from a number of sources.




3. Group IPs into known regions / cities of interest



4. Ping sweep the IPs in groups of cities marking hosts up / hosts down



5. Repeat ping sweeps and delete / add new IP blocks if necessary and repeat for n weeks.



6. Correlate data with estimates of outages from sources like the UN

As an added benefit you can try to correlate dates of your sweeps with various news articles and military actions.

This is Great / Introduction to OS X Hacking

Over at Matasano's Blog they have an article on how to identify potentially exploitable conditions on OS X using CrashReporter.app and Malloc. This is a great introduction and I didn't realize how easy it was to make CrashReporter.app more verbose. I've been looking through the log files all this time.

Forgetting Things

Knowledge is of no value unless you put it into practice. -- Anton Chekhov

Recently it's come to my attention that I've not done very much C in the past two years. So much so that I've forgotten a good bit of it. To restore my rusty knowledge I'm planning on putting my notes from K & R and Programming Linux By Example: The Fundamentals by Arnold Robbins on this blog as a series of articles. I'm on call this weekend so I can't really go out so the first few chapters of K & R will probably end up on here soon.

Using dpkt to Create Packets

So one of the things that I enjoy doing from time to time is playing with network packets. In that light dpkt has been an excellent tool. The only issue with it is that the documentation doesn't extend much more than the pydoc. Luckily it's not that hard to use

As an example here's a program that generates random UDP packets and then sends them via raw sockets.

#!/usr/bin/env python2.4

import dpkt
import optparse
import random
import socket
import struct
import sys

def createUDPPackets(options):
  """create packets to send"""
  udp = dpkt.udp.UDP()
  if options.sport:
    udp.sport = options.sport
  else:
    #pick a random sport
    udp.sport = random.sample(xrange(65536),1)[0]
  if options.dport:
    udp.dport = options.dport
  else:
    udp.dport = random.sample(xrange(65536),1)[0]
  if options.checksum:
    udp.checksum = options.checksum
  if options.length:
    udp.ulen = int(options.length)
  else:
    # take into account MTU - space for a large IP Header
    udp.ulen = random.sample(xrange(1340),1)[0]
  if options.data:
    udp.data = data
  else:
    udp.data = ""
    for i in xrange(udp.ulen):
      udp.data += struct.pack("B",random.sample(xrange(255),1)[0])
  return udp.pack()

def createRawIPSocket():
  """ """
  sock = socket.socket(socket.AF_INET, socket.SOCK_RAW,\
                       socket.IPPROTO_UDP)
  #sock.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)
  return sock

def parseArgs():
  """parse command line arguments"""
  usage = """%s: [-s|--sport sport][-d | --dport dport][-x|--data data] target  IP"""  % sys.argv[0]
  op = optparse.OptionParser(usage)
  op.add_option('-s','--sport', dest='sport',type='int',\
    help='set source port')
  op.add_option('-d','--dport', dest='dport',type='int',\
    help='destination port')
  op.add_option('-c','--checksum', dest='checksum', action='store',\
    help='UDP checksum')
  op.add_option('-l','--length',dest='length', action='store',\
    help='length of packet')
  op.add_option('-x','--data', dest='data',action='store',\
    help='set a value for the data field')
  return op.parse_args()

def main():
  options, args = parseArgs()
  sock = createRawIPSocket()
  while 1:
    msg = createUDPPackets(options)
    sock.sendto(msg, (args[0], int(options.dport))

if __name__ == "__main__":
  main()

# vim: set ts=2 et sw=2:

What's wrong with this script? It generates random data but not in a repeatable way. If I find a crash I have to replay the stream that I generated and not just rerun the script with a given seed. Additionally, I kinda fudged the MTU stuff but with this you should get an idea of how to use dpkt.

Running Bay To Breakers

So tomorrow I'm going to run in the Bay to Breakers race. Unlike last year where I was running all the time, this year I've been spending less time working out and more time just doing work and commuting, ugh. This of course means that I don't expect to run the whole thing. I'm probably going to walk a lot of the 7 1/2 miles. But it'll be fun anyway. If you're doing the race too maybe I'll see you there.

Sort of Back to Blogging and Security Metrics

Since I've moved to California a little over a year ago I've been finding it exceedingly difficult to find time to blog. Part of this has been to a rather long and arduous adjustment to working at Google and living far away from many friends and family back on the East Coast. Suffice to say I'm back at this now and plan to post at least a on a bi-weekly basis.

First up, I've started reading Security Metrics by Andrew Jaquith of SecurityMetrics.org fame. I have to say that the book has a very enjoyable tone and presents its material rather well. Although I'm only through the first few chapters, I think it's important to highlight a few of the things pointed out in the first chapter. Specifically the notion that.

Brief Thoughts on Return Oriented Programming Without Using Return Instructions

Recently, Two grad students out of UC San Diego published a paper on Return Oriented Programming without using return instructions. While praised by some members of the infosec community, it has also been called out as yet another example of academics rediscovering the folklore of hacker culture.

My take?

The paper was kind of disappointing. At 18 pages, it can kind of be summarized as use

POP %reg

JMP %reg

pop

instructions instead of RET. The paper then goes on to show that this type of instruction sequence is equivalent to RET and that the instruction sequence is prevalent enough within a Linux binary to construct gadgets.

While I agree that the thoroughness of the paper is necessary for academic rigor, it came across as disconnected from the body of work that is the security communities lore. Again it serves as a reminder that infosec research has been done in communities with minimal overlap, for the past two decades.

On the other hand given that the paper sites a few phrack articles, I'm hoping that this is the beginning of a trend where the communities can start sharing more reference information between the two of them.