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.