Protocol Realism: AOL Instant Messenger and TLS

The latest Application Protocol & Strike Pack includes support for AOL Instant Messenger, version 6. AIMv6 (as opposed to AIMv4 and earlier) has built-in support for conducting most of its business over an encrypted channel on port 443, and this encrypted communication is on by default. If that sounds like TLS/SSLv3 to you, you'd be right -- up to a point. There is an area where the encrypted AIM traffic (in its default configuration on Windows) diverges rather starkly from your usual TLS traffic, and I'd like to highlight that today to illustrate the value in realistic protocol implementation.

Cryptographic Traffic Analysis

While researching the post-authentication sequence for AIM, I noticed that certain message lengths and message sequences kept popping up during particular phases of the protocol. For example, message lengths of 32 bytes seem to be common from the client to the server during the post-authentication sequence of setting a user's initial status, retrieving buddy list information, and filling in the online/offline properties of buddies. In fact, the initial post-authentication sequence is quite static, from the message length and message sequence standpoint. It looks something like this for the first dozen application data packets:

It goes on from here and gets more varied the further in we get to the post-authentication sequence. More importantly, it does happen every time an AIMv6 user logs in, and this is distinct from "normal" TLS in some important ways.

First, the usual use of TLS over port 443 is for secure web browsing. These sessions tend to have a client request of between five hundred and a thousand bytes, followed by a slew of server responses with sizes all over the place, varying wildly by site and page the user happens to be requesting. Because we see here some relatively small message lengths, and a more even client, server, client, server request and response pattern, it's clear that this is more interactive than your typical web browsing.

Secondly, the stacked Application Data messages are pretty unusual. Most client/server TLS implementations will dedicate each message to a TCP packet, and won't normally concatenate small messages into larger (and more bandwidth efficient) packets. When I first captured some AIM traffic to look at, this jumped out immediately and I needed to double-check that this wasn't a transmission or capture error, since I've never seen it before in normal traffic.

So, who cares?

People who are into DPI, that's who. Let's say you wanted to build a device that, among its many wonderful inspection capabilities, should be able to pick out AIMv6 traffic from other encrypted traffic for the purpose of rate limiting or ensuring QoS or whatever. Well, without the above insight, that task may be an expensive proposition -- a DPI device would have to monitor connections to first find the AOL keyserver certificate, then deduce from that connection where the communications channel is going to show up (either through guesswork or some clever man-in-the-middle SSL proxy shenanigans). Alternatively, they could keep tabs on the IP addresses AOL uses for their AIM switchboard servers, and just go by those addresses to pick out the interesting from the uninteresting encrypted data...but they risk false positives/false negatives any time AOL removes or adds an IP address to their switchboard server farm. Since these approaches are unreliable hassles, I would go for traffic analysis to decide if I'm looking at AIM.

Maybe there's some other reason why modeling encrypted applications accurately is important. Imagine there's an inspection device (like an IPS), that performs a length check on the Application Data messages of TLS sessions, and due to a parsing error, that device blows up if it sees TCP packets with four or five of them all stacked together. That fault wouldn't be detected if a testing apparatus didn't include some of this unusual traffic -- traffic that is otherwise perfectly realistic and based on real-world network usage.

Perhaps there's some other reason that we haven't thought of here yet. After all, some of our customers can be the secretive sort, since they tend to be designing, building, and testing the next generation of network hardware, so we don't always have perfect insight into what they're up to with our Application Simulator protocols. Hopefully, with BreakingPoint's dedication to protocol realism, those customers are able to test features and discover bugs that we haven't anticipated yet.

Slowing U.S. Broadband: Necessary Security Tradeoff or Poor Testing?

Today I went through Akamai's Quarterly "State of the Internet Report", which compiles much of the data the company gathers while running the "world’s largest content delivery network". The report, which gains a lot of media and blogger coverage, is broken down into a few different buckets including security, performance, Internet penetration and geography. One of the most important nuggets within this most recent report, for me at least, is the fact that the United States ranks 30th worldwide in "fast" broadband speeds.

In the United States 64% of Internet connections are 2 Mbps or higher (what Akamai calls "fast") and nearly 6% are below 256 Kbps, leaving 30% somewhere in the middle of this very large range. This is actually a decrease of 9.3% from the previous report. In comparison global broadband "fast" connectivity increased by 6.8% and countries such as Tunisia, South Korea, Belgium, Japan, the UK and Germany are looking at 80% or higher getting 2 Mbps or more. The question of course is why? The report does not provide a lot of analysis on this subject since that is not Akamai's goal, but if you go back to the beginning of the document the security section may lend some evidence.

The United States is second behind China in top attack traffic originating countries and certainly would be at or near the top in destination countries. Obviously here in the United States we take network security seriously and have thrown security in front of, within and behind our network connections.  Since we serve as a prominent target we have to do what it takes to keep our network infrastructure safe. Does all of this security have anything to do with the resulting degradation in bandwidth performance? Of course, but how much I'm not sure, but I would wager that it is an important element in this debate. The more important question is whether we are making a necessary trade-off for a more secure infrastructure or if this is a result of improper network equipment testing?

We have talked at length on this blog about the notion that testing security is testing performance and vice versa. When you are testing the performance of any network device, whether it be deployed for security purposes or not, you must test it with realistic traffic including live security strikes. Testing in this manner will allow you create better performing AND more secure devices. If everyone added this element of truth into their testing would we see some sort of trickle up effect in terms of opening up those bandwidth pipes? Honestly, I think so, but these are thoughts that crossed my mind this morning reading the document, what do you think? Beyond better network performance and security testing what is contributing to the decreasing percentage in the United States?

CanSec West 2009 Overview

The CanSecWest security conference just occurred in Vancouver last week. This three-day conference, preceded by two days of dojo training sessions, features a single track of mostly high-quality talks. Another feature of the conference is the third consecutive Pwn2Own contest, which gives researchers the chance to win hardware and cash awards for compromising various laptops and mobile phones. Three members of the BreakingPoint Labs team attended this year, HD Moore, Todd Manning and Sean Bradly, and we wanted to give our review of the talks presented.

Mobile technologies were the main focus of talks on the first day with iPhone, Android, Windows Mobile, Palm and Symbian mentioned in several talks. Sergio Alvarez started the mobile device theme with a presentation covering mobile platforms and finding and exploiting bugs in them. This talk ended with a demonstration of an iPhone exploit that didn't go completely smoothly, but the information presented was a great reference for attacking smartphones. This talk was the first mention of the meme of "No More Free Bugs," which was later expanded upon by Charlie Miller during Thursday's lightning talks.

The second day of the conference broke from mobile platforms, and was the most diverse of the conference. Anibal Sacco and Alfredo Ortega from Core presented a very interesting talk entitled Persistent BIOS Infection (link to slides). The presentation was full of great information, and the demo, which showed their infected BIOS patching binaries on both Windows and OpenBSD were really cool. They focused on the Phoenix BIOS, but their techniques should be fairly applicable to other BIOSes. Next up was Loíc Duflot presenting on abusing Intel System Management Mode when writing rootkits. We found this talk to be fascinating, but will definitely have to read the slides again and dig into our Intel manuals before fully understanding the techniques he presented.

Thursday's third talk was quite possibly the most entertaining talk of the conference. Andrea Barisani and Daniele Bianco presented two ways of remotely sniffing keystrokes with two very different methods. The first used a very simple and cheap circuit to analyze keystrokes leaked onto the buildings power wires. The second was a more intriguing approach involving yet another simple, cheap and homemade device, a laser microphone. This could let the attacker sit hundreds of meters away and listen in on the clicking sounds of a keyboard. Their signal analysis technique for the recorded keystrokes used some voice recognition algorithms and some letter pattern matching ("Wheel of Fortune" style) to determine which clicking sound corresponded to a specific key. Not to mention their hilariously well done video.

On the last day of CanSecWest, four Microsoft researchers presented on two exploit-related topics.

The first talk, by Matt Miller and Tim Burrell, provided an excellent rundown of the changes Microsoft has made to prevent exploitation of programming flaws. This talk covered /GS, /SafeSEH, and the upcoming SEHOP chain validation system. Their presentation covered not only the successes that Microsoft has had, but also the failures where existing methods were bypassed (MS08-068, MS07-017). More information from the presenters can be found on the Security Research and Defense blog.

The second talk that day, by Jason Shirk and Dave Weinstein, covered a WinDBG extension that handles the grunt work of determining whether a given crash is exploitable. This extension is valuable for anyone using fuzzers, since it provides an easy way to determine what bugs are worth investigating. Couple this extension with Byakugan and WinDBG becomes an end-to-end platform for vulnerability research and exploit development.

One of the bigger stories of the conference for the past three years has been the Pwn2Own competition, in which competitors stand to win both a laptop or mobile phone, and cash. Charlie Miller made a prediction that Safari would be the first browser to fall, and thanks to the random name draw, he had the first opportunity to attack one of the four browsers (Chrome, Firefox, IE8, and Safari). He'd obviously done his homework, and walked away with a MacBook and $5,000. As impressive as that is, the big story of Pwn2Own this year was Nils' "trifecta," in which he exploited IE8, Safari, and Firefox. Nils won a Sony Vaio, and $15,000 in prize money

Did you attend CanSecWest? What did you think?

News and Insights for the Layer 2-7 Testing Community

One of the resources we provide outside of the blog is "The Test Insider", a newsletter supplying insight for the Layer 2-7 testing community. The newsletter is packed with links to articles, white papers, videos and more. You can subscribe and still get our Layer 2-7 Testing Poster (see poster to the right) if you want, but as we were putting together the content for the newsletter I ended up rereading many of our blog posts from the past six weeks.

Ultimately the newsletter included some interesting content from the blog and I wanted to share with all of you in case you missed them the first time:

Using Virtualization in Your Test Bed
Want to reduce time-to-test even more? BreakingPoint Labs’ Sean Bradly uses a VMware server to quickly switch between different devices under test without frequent trips to the lab. This article takes you through a range of sample tests you can run against a virtual Linux host and provides a good example of how you can combine tools to reduce your time-to-test even further.

Unified Computing Begets Unified Testing
The idea of unified computing has been around for several years and recently many organizations are introducing technologies that will help make this a reality. One must wonder as we move towards a computing fabric how this will alter the network equipment testing industry. The need for realistic testing, due to the push towards next-generation content-aware network devices, becomes even more important with unified computing. Read how unified computing is driving the push towards unified testing.

Simulating DDoS Attacks White Paper
Download "Simulating Distributed Denial-of-Service", a new white paper written by BreakingPoint Labs researchers Dustin D. Trammell and Todd Manning. The paper describes how to configure testing products to emulate a number of DDos attack scenarios. Read the blog post and get access to the white paper and product test cases for immediate use.

HTML Strikes that are Served Over the FTP Protocol
It is important that your network equipment is consistently up-to-date to face the latest security attacks. Tod Beardsley of BreakingPoint Labs writes about how browser exploits also work over FTP. This post details how ActiveX buffer overflows, image parsing bugs, spyware drive-by download sites and more can all work perfectly over FTP. Read more on how network inspection devices can be evaded by this security threat.

Testing with 100+Gbps of Blended Application Traffic
BreakingPoint Elite was recently used in testing the first network device with more than 100 Gbps of blended Layer 4-7 application traffic. In this article you can read and see how the Juniper SRX5800 achieved 100 Gbps of stateful traffic, 150 Gbps of stateless traffic and 30 Gbps of intrusion prevention. Read how this test was conducted using a single configuration of four BreakingPoint Elite chassis.

Unified Computing Begets Unified Testing?

Cisco's Unified Computing announcement has been covered throughout the blogosphere and mainstream media, the latest in several that unveil the shift in network infrastructure. In this realm we've seen Juniper's announcement with IBM, the Cisco and VMware announcement and rumors yesterday about IBM and Sun. The basic premise; network equipment is becoming more evolved, automated and content-aware while applications and the data center are becoming more virtualized and network-aware. When once you had disparate players serving different markets you now see these markets converging and the players turning towards each other in order to compete and/or partner. This convergence will only speed up rapidly throughout 2009, evaporating the once static network infrastructure into a dynamic entity aligned appropriately with enterprise IT needs. Greg Ness wrote a nice piece that reviews this evolutionary shift quite well over at SeekingAlpha and helped spark this post.

Reading all of this coverage I started to think how or if this alters the network equipment testing tools industry. The need for realistic testing is something we talk about a lot on this blog and that has come about due to the push towards next-generation network devices which are content-aware. This has been happening for a long time, even the push to "unify computing' is not new, Cisco has just made the latest in-roads. Will the notion of a unified computing fabric mean a need to look at a more unified testing approach? Or have we already moved in that direction and we refer to it in a different manner?

One example comes to mind and there are plenty more obviously. Cisco is trying to provide consolidated access to both SANs and NAS, this support for a "unified fabric" will mean an ability to access storage over Ethernet, Fibre Channel, Fibre Channel over Ethernet or iSCSI. In order to make this a reality there are a lot of moving parts, bound both by the network infrastructure, the IT infrastructure, the application infrastructure, the virtual infrastructure and more. The term "unified" makes it all seem simple, but there are a lot of moving parts, not to mention protocols, packets and devices (although that would be reduced). As the Enterprise shifts their network infrastructure towards this vision, whether it be from Cisco, IBM or another player, it continues to be critical that testing is done with this unified and realistic approach in mind. Unified computing begets unified testing.

OK, but what does unified testing mean? Let's go back to the Cisco announcement.  The success of unified computing means adhering to transparency. In the case of Cisco, partnerships are being made with once competing interests, those partnerships will live or die on the level of transparency and cooperation provided. In the testing world the same holds true, transparency or truth in testing helps create better and more secure equipment. We now find ourselves back to the  need to provide realistic testing scenarios, even if the numbers aren't exactly what you wanted to see. Truth in testing is critical in making sure that all network equipment and application servers are ready, whether they are deployed in a traditional manner or as part of a unified fabric. In fact, I would argue as equipment and applications begin to rely on each other more and more that the idea of unified and truthful testing becomes paramount.

What do you think of the Cisco Unified Computing push? How do you see this movement altering the testing tools market and the way in which you test your network equipment and application servers?