Finally getting around to posting our materials from the talk that Chris Wysopal and I gave at BlackHat this year entitled “Static Detection of Application Backdoors.” Here are the slide deck and the accompanying whitepaper:

Also, as a proof-of-concept, we had demonstrated using IDA Pro’s scripting framework to detect one of the backdoor examples that we discussed — suspicious cryptographic API calls. Specifically, it flags calls to known encryption, decryption, and/or key management functions where a constant value is passed to a specific argument position. This can help identify situations such as an application encrypting data with a hard-coded key. We had numerous requests to post the code, so here it is:

Veracode’s binary analysis technology uses similar (but more sophisticated) techniques. We build our own intermediate representation of the binary’s data flows, control flows, and range propagation which is not based on IDA Pro. We then scan that representation for backdoors in ways similar to the cryptoconst script. However, at BlackHat you’re not allowed to promote your own products/services, so it wasn’t appropriate for us to use it for demonstration purposes.

RSnake blogged on this first but I can’t help but comment on it. Essentially, Cenzic managed to get a patent issued on the technique of fault injection, and now they’re getting litigious. The abstract from the patent reads as follows:

A method of testing a target in a network by fault injection, includes: defining a transaction baseline; modifying at least one of an order and a structure of the transaction baseline to obtain a modified transaction with malformed grammar; and transmitting the modified transaction to a target. The method may further include, receiving a feedback from the target to determine fault occurrence. An apparatus for testing a target in a network by fault injection, includes: a driver configured to generate patterns, where a pattern can generate a plurality of packets for transmission to the target, the pattern being represented by an expression with a literal string and a wild character class; and a network interface coupled to the driver and configured to transmit and receive network traffic.

Late last month, they filed suit for patent infringement against SPI Dynamics, who makes WebInspect, one of the leading web application scanners on the market. Conveniently, they waited until after SPI was acquired by HP, which clearly has much deeper pockets than the previously privately-held SPI.

Why do patents keep getting issued for techniques and methods that have been common practice for years? If you were doing application security consulting in the late 90s or early 2000s chances are you were using fault injection. Back at @stake, I know of two tools that we released in the 2000-01 timeframe specifically around fault injection — one was Dave Aitel’s sharefuzz tool (still available from Immunity) and another was Frank Swiderski’s feszer. And those were just the tools that were publicly released. Other security consultancies at the time were certainly using similar techniques. There’s no way the Cenzic patent has any merit, there’s too much prior art out there.

Remember the Watchfire patent on web application scanning?

A method for detecting security vulnerabilities in a web application includes analyzing the client requests and server responses resulting therefrom in order to discover pre-defined elements of the application’s interface with external clients and the attributes of these elements. The client requests are then mutated based on a pre-defined set of mutation rules to thereby generate exploits unique to the application. The web application is attacked using the exploits and the results of the attack are evaluated for anomalous application activity.

Yes, plenty of people were doing that before the patent was issued in 2001. There weren’t a lot of automated web application scanners at the time, but methodology-wise, that’s how people did manual penetration testing. Now that Watchfire (actually IBM) holds a patent on it, all of the other vendors, Cenzic and SPI/HP included, have to pay significant royalties to stay in business. What this also does is discourages new and better tools from entering the market. Creativity is stifled for fear of IBM knocking on the door and demanding their cut.

There will be a lot of eyes on the Cenzic vs. SPI case as it clearly has far-reaching implications for the security industry. Chances are it’ll get settled out of court and a licensing agreement reached, since it’d be a drop in the bucket for HP. Hopefully HP chooses to fight it, though, because they can win this one.

There’s been a lot of blogging over the weekend about the 36-hour Skype outage that occurred starting last Thursday. From Skype’s official explanation, it wasn’t a security-related event — in other words, Skype wasn’t hacked. We have no reason to believe otherwise. However, security and availability are often discussed in the same breath, and lots of people will be speculating about the chain of events that led to this outage.

It’s worth understanding a little bit about the Skype network. I remembered reading this paper a few years back, in which some Columbia University researchers analyzed Skype network traffic to derive information about the Skype infrastructure. Things may have changed slightly since then, but for now, let’s assume it’s accurate.

The primary takeaway from this analysis is that Skype relies heavily on hosts called Super Nodes to help direct traffic on the P2P network. Super Nodes are what allow Skype clients to communicate on the network from behind firewalls and NAT. Any Skype client can become a Super Node, and though the mechanism by which that happens is not well-documented, you’re more likely to become a Super Node if you’re on a publicly routable IP address and have adequate bandwidth.

Logging into the Skype network is a two-step process. First, the client has to establish a connection to a Super Node. If and only if this is successful, the client contacts Skype’s central login server to authenticate to the network. Failure at either of these steps would prevent users from logging on, which is the scenario in Skype’s blog:

The disruption was triggered by a massive restart of our users’ computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update.

The high number of restarts affected Skype’s network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact.

So why hasn’t this happened before? Both Skype and patch Tuesday have been around for a long time. It depends on whether the issue was primarily due to overloading the login server or a lack of available Super Nodes. It’s a reasonable assumption that Skype closely monitors the load on its login servers and would have seen that load inching closer and closer to capacity over the past few patch Tuesdays. Unless the Skype user base grew exponentially over the past month, it’s likely they would have been prepared for the spike in traffic. Also, I’m unclear on how the lack of Super Nodes and the load on the login servers combine to create an amplification effect, since they are serial dependencies — that is, the login server isn’t even contacted unless a Super Node is available.

Perhaps there has been a significant shift in the number of Super Nodes relative to the number of Skype clients. More people are sitting behind home firewalls or NAT routers these days. However, if this were the case, the network would probably be struggling to operate under normal conditions, not just on patch Tuesday.

Did Microsoft change the mechanism by which patches are rolled out? It doesn’t seem like there should ever be a “massive restart” of computers across the globe. On my systems, I let the Windows Updater download updates automatically, and I’m usually not prompted that they’re ready for installing until Wednesday. It takes a while for the patches to propagate to systems across the globe, and as they are applied, the systems reboot in a rolling fashion. What would have caused significantly more systems than normal to reboot at the same time? And why didn’t it happen until Thursday?

It will be interesting to see if Skype releases any more technical details. Without a doubt, it is difficult to build and maintain a reliable network of this size, and I’m sure there are some good lessons learned from this event that anybody working on large-scale systems would appreciate hearing about.

[Update, 8/21/2007: MSRC weighs in on the role of Windows Update]

Veracode president and CEO, Matt Moynahan, was featured yesterday in a podcast interview with IT security expert Dan Sullivan on automated vulnerability analysis as a service.

In the podcast, Matt answers questions on automated application vulnerability analysis – offered as an outsourced service. And he discusses why companies are looking for solutions that use multiple testing techniques, including Web application scanning and static binary analysis, to provide more comprehensive security reviews.

Here’s the description from the site:

Automated vulnerability assessment can complement manual efforts to find and correct vulnerabilities in application code. In this podcast, Matt Moynahan, CEO of Veracode, discusses key issues in vulnerability testing, including:

• What is the process of automated application vulnerability analysis? What are the pros and cons?
• What types of application vulnerabilities can be detected with automated analysis as a service?
• When analyzing application vulnerabilities, is static analysis sufficient to detect vulnerabilities or are behavior-based techniques required as well?
• Many developers are familiar with cross-site scripting and injection attacks, are there others you commonly see when you conduct security reviews?

Listen to it or download it here.