The 4th Annual IT Security Automation Conference is around the corner; September 22nd – 25th. If you’re in the Maryland areas and have $95 to drop it should be worth it. Myself and a couple others from CIS will be there so let us know if you plan on attending. 

The Blackhat Vegas classes went really well – minus a couple hiccups with the DVDs

Mike and I will be traveling to Argentina for BA-CON where we’re putting on another two day class of fuzzing with Peach. If you’re going to be in Buenos Aires at the end of September drop us an email.

Take one part vanilla memory corruption bug. Add three parts ActionScript Virtual Machine KungFoo. Beat. Alot. Bake at 98.6 degrees. Let cool and serve.

Go here for the coolest exploit I’ve seen since this one.

Yesterday, I created some files that would pass file(1) yet contained HTML to determine if IE would render them as HTML. The goal of this was to underscore that discrepancies between file type detection mechanisms, especially those found in a browser and web platform, may result in security issues. In this testing a pattern emerged; none of the files (PNG and JPEG) that contained upper ASCII characters rendered as HTML. The other  formats, void of upper ASCII, rendered as HTML. This got me supposing that IE’s content-sniffing may look for upper ASCII characters when deciding to consider data HTML or not. I thought about that again this morning and determined that my original thought was incorrect because I’ve seen IE render valid PDFs and BMPs as HTML. So something else is going on with PNG and JPEG. I probably won’t  look into that anytime soon as my initial goal in this research is to determine what I *can* do.

I did some more testing this moring by creating various files, including GIF and BMP, that contain upper ASCII, sent them with the appropriate image/(gif|bmp) content-type and each test resulted in rendered HTML. 

The take away from this is:

•  If you want to bypass a file(1) based file type detection mechanism and cause IE to render HTML all in one shot GIF, BMP, and PDF are valid options while JPEG and PNG appear otherwise. I’m certain there are heaps of other formats that will work as well.

I was referred to Billy (BK) Rios’s blog as an article there somewhat relates to research I conducted on how browsers react when faced with different combinations of content-types, dispositions, and data. This is where I became aware of the term “Content Ownership” – the concept is familiar but the pretty term was not.

It’s pretty clear that taking ownership of other people’s content is risky business. Especially, given Internet Explorer’s willingness to render data as HTML despite the advertised Content-type. However, serving up other people’s content is often a requirement. Having that content look pretty is also a requirement. Flickr surely can’t send images with a Content-Disposition type of ‘attachment’ without killing their user experience. We are left with a need for additional validation. So how do we do that? File extensions surely don’t work. Nor will anything else that originates from the user and makes claims about the content format. What about file(1) and magic(4)?

For those unfamiliar, magic(4) contains a grammar that is used by file(1) to determine a file type based on the file’s content. For example:

blake@cecilia ~ $ file /bin/ls
/bin/ls: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), ...
blake@cecilia ~ $ file /etc/passwd
/etc/passwd: ASCII text

At first glance, this seems like a viable options. However, as some simple testing will show, those utilizing file(1) and magic(4) to perform content-type validation are in for a surprise. 

I was able to construct a GIF, PDF, Macromedia Flash (FLS), Macromedia Flash Video (FLV), and Compressed Macromedia Flash (CWS) files that satisfy file(1) yet render as HTML/JavaScript in Internet Explorer 7. It’s worth noting that I also attempted creating a simple JPEG and PNG in a similar manner but IE would not render them as HTML. I suspect this is due to the upper ASCII characters found within these files – more testing on that later. The implications of this are that if anyone is relying on file(1) or magic(3) for making content ownership decisions they may have a problems.

Below are the files I used for testing:

JPEG:
0000h: FF D8 FF E0 00 10 4A 46 49 46 3C 68 74 6D 6C 3E  ......JFIF<html>
0010h: 3C 73 63 72 69 70 74 3E 61 6C 65 72 74 28 29 3B  <script>alert();
0020h: 3C 2F 73 63 72 69 70 74 3E 3C 2F 68 74 6D 6C 3E  </script></html>

PDF:
0000h: 50 44 46 3C 68 74 6D 6C 3E 3C 73 63 72 69 70 74  PDF<html><script
0010h: 3E 61 6C 65 72 74 28 29 3B 3C 2F 73 63 72 69 70  >alert();</scrip
0020h: 74 3E 3C 2F 68 74 6D 6C 3E                       t></html>

FWS:
0000h: 46 57 53 3C 68 74 6D 6C 3E 3C 73 63 72 69 70 74  FWS<html><script
0010h: 3E 61 6C 65 72 74 28 29 3B 3C 2F 73 63 72 69 70  >alert();</scrip
0020h: 74 3E 3C 2F 68 74 6D 6C 3E                       t></html>

FLW:
0000h: 46 4C 56 3C 68 74 6D 6C 3E 3C 73 63 72 69 70 74  FLV<html><script
0010h: 3E 61 6C 65 72 74 28 29 3B 3C 2F 73 63 72 69 70  >alert();</scrip
0020h: 74 3E 3C 2F 68 74 6D 6C 3E                       t></html>

CWS:
0000h: 43 57 53 3C 68 74 6D 6C 3E 3C 73 63 72 69 70 74  CWS<html><script
0010h: 3E 61 6C 65 72 74 28 29 3B 3C 2F 73 63 72 69 70  >alert();</scrip
0020h: 74 3E 3C 2F 68 74 6D 6C 3E                       t></html>

PNG:
0000h: 89 50 4E 47 0D 0A 1A 0A 3C 68 74 6D 6C 3E 3C 73  .PNG....<html><s
0010h: 63 72 69 70 74 3E 61 6C 65 72 74 28 29 3B 3C 2F  cript>alert();</
0020h: 73 63 72 69 70 74 3E 3C 2F 68 74 6D 6C 3E        script></html>

GIF: 
0000h: 47 49 46 38 3C 68 74 6D 6C 3E 3C 73 63 72 69 70  GIF8<html><scrip
0010h: 74 3E 61 6C 65 72 74 28 29 3B 3C 2F 73 63 72 69  t>alert();</scri
0020h: 70 74 3E 3C 2F 68 74 6D 6C 3E                    pt></html>

and the file(1) output for these files:

blake@cecilia ~ $ for i in `ls`; do file $i;done
compressed_flash.cws: Macromedia Flash data (compressed), version 60
flash.fla: Macromedia Flash data, version 60
flashvideo.fla: Macromedia Flash Video
gif.gif: GIF image data 28020 x 15980
jpeg.jpg: JPEG image data, JFIF standard 104.116, thumbnail 99x114
pdf.pdf: Macintosh PDF File (data) : F<html><script>alert();</script
png.png: PNG image data, 1668442480 x 1950245228, 101-bit

This brings up a bigger issue – the need for those writing browsers and those writing web platforms to agree on a standardized method for identifying content types. As we can see above, the differences in detection mechanisms will more than likely result in very real security implications.

Microsoft’s Research team created a pretty cool HIP (Human Interactive Proof) system, ASIRRA, which requires a user to select a set of images depicting all dogs or cats (supplied by PetFinder) to prove they are non-software. About a month ago, smart folks at the Palo Alto Research Center went Doogie Howser on this system and subsequently released a paper titled Maching Learning Attacks Against the ASIRRA CAPTCHA. Here’s a portion of the abstract:

Our classifier allows us to solve a 12-image ASIRRA challenge automatically with probability 10.3%. This probability of success is signicantly higher than the estimate given in [6] for machine vision attacks. The weakness we expose in the current implementation of ASIRRA does not mean that ASIRRA cannot be deployed securely. With appropriate safeguards, we believe that ASIRRA offers an appealing balance between usability and security. One contribution of this work is to inform the choice of safeguard parameters in ASIRRA deployments.

Big fat brains strapped to compilers is typically going to result in software capable of almost anything – including solving pretty sophisticated computer vision/imaging problems. Full disclosure – I don’t know jack about solving computer vision problems. I do, however, find myself reading more and more whitepapers, written by significantly smarter people than myself, about targeted software capable of breaking today’s most difficult graphical HIPs. This research is yet another example of how traditional graphical HIP systems are failing. Hopefully, it will become standard practice to integrate thresholds to protect sensitive site functionality and we’ll all be rid of CAPTCHAs.

Mike Eddington will be presenting on the Peach Fuzzing Platform at CanSecWest this March 26th – 28th.  In his presentation, Mike will be demonstrating some of the new capabilities added to Peach 2.0, including the state machine, data definition language, and PeachBuilder UI. Go here or here for more info.

There’s been some recent updates to areyouahuman.org. Chief among them are:

• It’s less ugly
• Graphical and SMS HIPs/CAPTCHAs are working (better)
• Example code in PHP, PERL, and C# for integrating with both APIs

Items left to complete include:

• Complete threshold and blacklist funcationality
• Add APIKey functionality to support per-site customizations

Feedback is definitely welcome.

I recently finished up phase one of some research into how various browsers react when presented with HTML-like data along with contradictory Content-Types. The goal of this exercise was to identify instances when each browser would successfully render the data as HTML. I chose this goal because the implications, from a content host and consumer’s perspective, are quite severe if delivered content is unexpectedly rendered by the browser. See also: XSS, CSRF, etc.

Here’s a quick overview of what was determined.  For the complete writeup, go here.

I tested current versions (as of this writing) of Internet Explorer, Opera, Safari, and FireFox all on the Windows platform.  I used 735 differerent content types which resulted in a total of 13158 tests.

• Internet Explorer rendered HTML for 696 different Content-types in the Internet Zone.
• Opera rendered HTML for 14 different Content-types.
• FireFox rendered HTML for 8 different Content-types.
• Safari rendered HTML for 7 different Content-types.

Another interesting point, which is obvious once you say it outloud, is no test resulted in rendered HTML when the Content-Disposition type was set to “attachment”. Zero. This is good news for media sharing sites that typically host untrusted content. Hopefully, this will start to catch on a bit more.

 The Center for Internet Security has been busy the last six months, releasing 16 updated and/or new security benchmarks. This includes:

• Windows Server 2003 (Domain Controller & Member Server)
• Solaris 11, 10, and 8
• HPUX
• Red Hat Linux
• Debian Linux
• Cisco IOS
• Cisco PIX, ASA, and FWSM
• CheckPoint Firewall
• Exchange Server 2007
• Apache
• MySQL
• IIS 6,5
• OpenLDAP
• Free Radius
• VMWare ESX
• General Virtual Machines

Check em out, there’s a lot of good information in there. The benchmarks are free for the home user but a subscription is required if you plan on using them commercially.