Why bother setting up dedicated websites to host malicious content when you can just infect trusted sites like BusinessWeek? This is becoming something of a trend, as evidenced by the mass SQL Injection attacks from a few months ago.

The idea is simple — find SQL Injection vulnerabilities in high-traffic, trusted websites where the site’s content is dynamically fetched from a database (i.e. just about any content-rich site). Then use an automated tool to prepend or append malicious content to that content in the database. When the unsuspecting user visits the page to read an article, they will be treated to a barrage of <script> or other tags fetching content from sites in .ru, .cn, or who knows where else.

The guidance you give to mom and dad, “don’t visit sketchy looking sites in other countries,” is no longer good enough. If BusinessWeek can be compromised, it’s a given that USA Today, CNN, the New York Times, and other establishments are being targeted as well.

For this and similar examples, NoScript would have thwarted the attack because it wouldn’t permit the .js file to be loaded from an off-domain location. But what happens when the attackers start injecting the entire .js payload into the database instead of just a <script> tag? Now the malicious code is coming from the trusted domain, and if I’ve configured NoScript to allow scripts from businessweek.com, I’m out of luck. In fact, I have no idea why the attackers aren’t using this tactic already. Any ideas?

I spent the weekend in Berlin attending a conference called PH-Neutral, run primarily by the Phenoelit crew. This was the first European security conference I’ve attended and I found it quite different from any North American security gathering I’ve been to, such as BlackHat, CanSecWest, SOURCE Boston, BlueHat, or RSA. Everything was far more casual and laid back, which is something I had heard about European conferences but hadn’t experienced until now (even EUSecWest is held in a club whereas CanSecWest is in a Marriott).

The event was held at Die Insel, on a tiny island a few kilometers outside of Berlin’s city center, near Treptower Park. The venue is mostly used for live music so basically it feels like a dark, somewhat dingy club (certainly the bathrooms are reminiscent of a club). The presentations were on the 3rd floor in a room that probably held about 60 people in close quarters; to handle overflow, a closed-circuit feed was being simulcast on the 4th floor, which was a bit less crowded and, more importantly, opened out onto a rooftop deck which meant better ventilation. The bottom floor led out to a Biergarten with tables, beach chairs, and a stage which was used for DJing. The layout was actually pretty efficient for allowing around 200 people to mill about and socialize/network while not having to stray too far from where the talks were presented.

As far as the event itself, when I said “laid back” earlier, don’t interpret that to mean disorganized or watered down in any way. It was run with stereotypical German efficiency, from badging to presentations to the after-hours parties. The presentations were just as technical and relevant as any of the more “corporate” conferences. Unfortunately for me, I don’t know that many people in European security circles, and most of the ones I do know weren’t in attendance. Those I did meet, however, were impressively smart and well-versed. Nobody was trying to conduct business transactions or slip away for meetings, which is inevitably what happens when only technical folks are present!

For me, a few talks stood out. Fukami and BeF’s talk on SWF and the Malware Tragedy discussed methods for automated static detection of malware in Flash movies. Much of it centered on heuristics related to inconsistencies in the file format or tag structure, abnormal concentrations of strings in the constant pool, or the existence of various obfuscation techniques. Ultimately, there are false positive issues to be addressed but that is just a fact of life with static analysis, and it will be an iterative process to refine those heuristics as the attack vectors evolve. I thought this talk was particularly timely given the increasing prevalence of Flash as a conduit for exploits/malware, such as the most recent Flash 0day that made the news (granted, this was an exploit against Flash itself, not just using Flash as a delivery mechanism, but close enough).

I also enjoyed pierre’s talk on counterintelligence, basically a mélange of wiretapping and other bugging devices discovered in the wild. War stories are always interesting, particularly when it comes to the realm of physical security. One of the x-ray images he showed of a bugged pen was identical to a pen that I own (minus the bugging device of course… I hope). The feel of the talk reminded me a bit of James Atkinson’s talk at SOURCE, “Telephone Defenses Against the Dark Arts” (video: Part 1 and Part 2), which also got rave reviews.

Mike Eddington’s presentation on the Peach 2 fuzzing framework was also quite interesting. Peach 2 was released several months back but I haven’t really been paying much attention to it or any other fuzzing tool for some time. In fact the last time I really had to implement a protocol fuzzer, I was using SPIKE 2.9, so that gives you some indication of how long it’s been. Peach 2 includes some powerful built-in capabilities such as node relationships (e.g. field 1 represents the length of field 2; field 10 is a CRC-32 of fields 1 through 9), data transforms (those with battle scars from ASN.1 will be happy), state machines (packets 1 and 2 have to be normal in order to fuzz packet 3), monitoring agents (detecting when a crash happens and under what conditions), and much more. I am itching to go fuzz something now just so I can tinker with Peach.

All in all, it was a good trip and I enjoyed the opportunity to see how things are done across the pond, and to do a little sightseeing in a historic and beautiful city.

I took part in the L0pht Reunion Panel at the Source Boston conference in Cambridge, MA last Friday. It was a lot of fun to get back together with the “band” and pontificate with no holds barred about the latest security threats, just like we did in the old days.

One of the questions asked of the panel by moderator Michael Fitzgerald (who did a kick-ass job) was, “What scares you the most these days?”. My answer was the proliferation of of inexpensive digital devices made in China that we plug into our computers. The malware problem is getting tricky to dodge. First you couldn’t open email attachments you weren’t expecting. Then you had to worry about surfing even trusted websites with JavaScript turned on, even with the latest patched browsers. Now you have to worry about plugging in the shiny new digital toy you got as a gift. Perhaps its a digital picture frame, digital camera, music player or silly programmable gizmo. Welcome to the age of factory installed malware –the age of devices coming Certified Pre-0wned.

The Associated Press writes:

Recent cases reviewed by The Associated Press include some of the most widely used tech devices: Apple iPods, digital picture frames sold by Target and Best Buy stores and TomTom navigation gear.

In most cases, Chinese factories — where many companies have turned to keep prices low — are the source.

We all know malware is starting to fly under the radar of black list style detection. Low volume malware is flooding the AV labs’ capability to build detection for it. The digital picture frame sold at Sam’s club was infected with previously unknown malware that stole passwords and turned off AV software.

An additional threat that has been reported is devices have been found infecting the flash memory cards that are often inserted to upload photos. From SANS:

“Recently I found a virus on it called Troj_Agent.SAO, which is what Trend Micro named it. Anytime you plug a removable device into it, it would create two files Autorun.inf and autorun.exe. The exe would place itself in the recycler\recycler folder and the .inf would place itself on the root of the removable drive as a hidden file. At first I thought this virus came in on one of our employee’s pen drive but after further investigation I discovered that the files that the virus uses were created on the kiosk the day it was shipped out to us. Also our vendor is using this kiosk in some of their stores at the moment and there have been reports that the kiosks have given their customers a virus. “

We are back to the days of the floppy or “sneaker net” attack vector. Do you know who has touched your SD card or USB drive? Don’t use it in public. Don’t share it with multiple machines. Dan Geer told me he once tossed a USB drive into an audience with the slides for a presentation he just delivered on it. About 10 people passed it around and copied off the slides. It came back with a virus on it. And this was at a security conference.

So it seems that SquirrelMail 1.4.11 and 1.4.12 were recently backdoored. Similar to some high-profile backdoors in the past, this was done by modifying the distribution tarball on rather than infiltrating the source code repository [1]. In this case, the backdoor was detected when a user noticed that the MD5 published on SquirrelMail’s website didn’t match the calculated MD5 from the SourceForge distribution.

Since the SVN repository remained intact, we can’t go back and examine the backdoor in detail. However, we do have a newsgroup posting that sheds a little light on the situation:

> What diff do you see between the compromised version and
> the one that is there now? I see only a comment diff in one file.

it was a small block of code that checks for a $_SERVER var. If that var was present, it would redefine SM_PATH. Under normal circumstances, this would never be executed, but we have since learned how to make it execute.

In PHP, $_SERVER is an array populated by the web server that contains information such as headers, paths, and script locations. This includes some user-supplied input such as the URL query string and the HTTP headers. SM_PATH is the filesystem path where SquirrelMail is configured to be run from. So once an attacker controls SM_PATH, it’s likely that a subsequent call to include() can be exploited to fetch and execute PHP code from a remote server. This is a typical example of a Remote File Include vulnerability.

Note that the attacker backdoored the 1.5.1 distribution as well, with the same type of vulnerability but at a different location in the codebase.

I think what’s most interesting to me about this is that so many open source projects still rely on MD5 hashes for integrity checking. The minute the Xiaoyun Wang paper on MD5 collisions was released, every security practitioner in the world considered MD5 unsafe from that point forward. Even though practical attacks had not yet been formulated, the writing was on the wall. Unfortunately, the rest of the world either didn’t notice or didn’t care.

Cryptographers have since developed increasingly sophisticated attacks stemming from Wang’s original work. Recently, researchers in the Netherlands demonstrated two examples of chosen-prefix attacks which would make it possible for an attacker to take two tarballs (one original, one backdoored) and append a series of bytes to each that result in both files having the same MD5 hash. This proves beyond a shadow of a doubt that MD5 is not an effective method for verifying software integrity. There was hardly any doubt that this attack would surface eventually, so why is MD5 still in such widespread usage?

Cryptographic weaknesses aside, a lot of people completely miss the mark with hashes. MD5 or SHA-1 (or any hash function) are not very effective if the only way a user can verify them is on the same website where the download is hosted. If the download point is compromised, chances are the attacker can modify the hashes printed on the website too. Even when it’s done correctly, hashes only help identify when the distribution point is compromised. It does nothing to protect against source code compromise or vulnerabilities in the development tool chain.

There has been some talk in the press lately about backdoors due to the recent court case where it was disclosed that federal agents planted a keystroke logger on a suspect’s computer using a trojan program. Many of the articles don’t report on the court case but raise the question as Declan McCullagh titles his article, “Will security firms detect police spyware?”

You can see the security cat and mouse game playing out between the police and suspected criminals although the roles here are reversed. The criminals are trying to secure their communications and the police are trying to break it to collect evidence. At first the police could just tap the data as it moved from sender to receiver. In response criminals started using strong end to end encryption. To get around that the police compromised the endpoint system with a backdoor to get at the clear text of the messages or passwords to log into encrypted servers. The criminal’s obvious response to that is to secure his system and try and detect any backdoor code.

Real detection of backdoor code is a challenging computer security problem to solve. This article will discuss different methods of detection and the different classes of backdoors.

Spyware, trojan keystroke loggers, or remote access trojans are what I call system backdoors, since they compromise the integrity of the whole computer system. These are typically in programs that you don’t want on your system. They are often installed via social engineering, a vulnerability, or a combination of both.

There is a different, more subtle and insidious backdoor which I call an application backdoor. This is backdoor code that is planted in an application that you do want on your system such as Wordpress, Borland Interbase, or tcpdump. All of those programs had versions that contained backdoors at one point. An application backdoor allows the attacker to bypass the designed authentication or authorization functions of the application and access its data and transactions. Sometimes an application backdoor is also a system backdoor if it allows functionality such as system commands and the application is running in an environment where the OS doesn’t prevent this.

For both system and application backdoors, once you know the program contains a backdoor you can make a signature for the program and detect instances of the program by computing a signature and looking it up in a signature database. This is how many traditional AV products find backdoor programs. The backdoor is typically detected by someone noticing a program that wasn’t supposed to be running on their computer. Then after inspection they also realize it is performing behavior on their system that they don’t want and report it to an AV vendor.

This approach doesn’t work well for custom or low population backdoors such as those used by sophisticated attackers or the police. It also doesn’t work well for application backdoors which are typically planted in the source code of the application or in the binary at the legitimate distribution site. Remember that applications backdoors are in programs that are supposed to be on the system so they don’t stand out. We need better was to detect backdoors than signatures.

Another way to detect backdoors is by looking for backdoor behavior on the system. Is a program listening on the network that isn’t supposed to? Is a program hooking into system level calls to gather keystrokes? Is a program hooking into system level calls to hide its behavior from the system log and administration tools. This is a big step up from signatures because it can detect a backdoor that hasn’t been seen before.

There are limitations to the behavior detection approach. If a backdoor program has done a good job of hiding its behavior from the system you can’t detect it. If a program is supposed to be listening on the network, detecting that doesn’t help. Some behavior may occur on a timer so the behavior detection would have to catch it in the act perhaps within very small intervals of time. Behavior doesn’t do a very good job at application backdoors at all. How will behavior find a special password that bypasses normal authentication or special processing when a certain client IP address is used?

A better solution to finding backdoors that overcomes many of the behavior approach’s limitations is binary static analysis. Binary static analysis can look at all of the functionality of the program without having to wait for it to get into a particular state which is the bane of dynamic (behavioral) analysis.

Binary static analysis is adept at seeing “baked in” static passwords, keys, or IP addresses. It can detect if there are encrypted or self-modifying blocks of code which may mean someone is hiding something. It can detect functionality such as listing on the network or shimming system calls. It can also do this from a trusted clean computer whereas the behavioral analysis needs to run on the same computer that the program being analyzed is executing.

Veracode’s binary analysis technology has scans that look for backdoors in executables. Chris Eng and I are giving a presentation titled, “Static Detection of Application Backdoors” at Black Hat in Las Vegas on August 2. We will cover detection of 4 classes of application backdoors that have:

1. Special credentials
2. Hidden functionality
3. Unintended network activity
4. Manipulation of security critical parameters

We will be giving a demo of proof of concept detection using IDA Pro and even screening a famous clip from a movie concerning backdoors. I’ll give you a hint, “Backdoors are not secrets!”

Client-side browser vulnerabilities, the ones that require the browser software on your computer to make a request to a web site hosting a malicious web page, are on a sharp rise. Sophos reports:

From January to the end of March, Sophos identified an average of 5,000 new infected webpages every day, indicating that this route to infection is becoming more popular with cybercriminals.

and

Not all of the infected websites were created by the hackers themselves. Sophos has found that the majority, 70 percent, were bonafide websites that were vulnerable to attack because they were unpatched, poorly coded or had not been maintained by their owners.

This means there are 3500 newly infected web pages a day that are on bonafide websites. Couple this with the fact that there are browser vulnerabilities where no patch is available that effect most users and you have to say the bad guys really are winning.

Understanding the attack scenario

It takes two to tango in this devastating exploit scenario. An attacker needs to find a vulnerable website and he needs to craft a browser exploit to plant on it. But the beauty of this attack from the attackers perspective is it is opportunistic and the odds are in his favor. Here are the ingredients:

1. the set of website vulnerabilities that allows modification of content
2. the set of bonafide websites unpatched for the modification vulnerabilities
3. the set of browser flaws that allow attackers to execute code
4. the set of browsers unpatched for the code execution vulnerabilities

The attacker just needs one ingredient from each set, 1-4, and he can compromise a client machine that visits the bonafide websites. Unless one of the ingredients above is completely eliminated the opportunistic nature of this attack makes it clear that there is always going to be a certain percentage of compromised machines.

So which is the best set above to eliminate? Number 1 doesn’t seem like an easy target since there are many web servers and thousands of web applications, including custom web applications. Number 2 isn’t a good plan because attackers could just host their own fake web site, which while not as dangerous is still a significant attack vector. Number 3 looks like a good set to eliminate. Even though browsers are very complex there is still only a handful of them which makes the code that needs to be secure reasonable. Number 4 doesn’t solve the zero day problem or the problem where a patch hasn’t been released by the vendor yet.

Attacking the root cause

We need to get on to solving number 3 in earnest. Vendors who supply browsers or plug-ins that extend browsers such as Apple Quicktime need to do a much better job of software security. You guys are the weak link in the chain for client systems. If client computers can be compromised, the internet security foundation crumbles.

There is some good news. We don’t need to find every browser or browser plug-in vulnerability, just the ones that allow code to be downloaded and executed on the client. This is a big category but it is limited. If you look at MITRE’s CWE there is only a certain set of root causes that have the consequence of remote command execution:

1. CWE ID 77 Command Injection
2. CWE ID 79 Cross-site scripting (XSS)
3. CWE ID 88 Argument Injection or Modification
4. CWE ID 121 Stack Overflow
5. CWE ID 122 Heap overflow
6. CWE ID 123 Write-what-where condition
7. CWE ID 124 Boundary beginning violation (’buffer underwrite’)
8. CWE ID 128 Wrap-around error
9. CWE ID 129 Unchecked array indexing
10. CWE ID 132 Miscalculated null termination
11. CWE ID 134 Format string vulnerability
12. CWE ID 170 Improper Null Termination
13. CWE ID 190 Integer overflow (wrap or wraparound)
14. CWE ID 192 Integer coercion error
15. CWE ID 196 Unsigned to signed conversion error
16. CWE ID 252 Unchecked Return Value
17. CWE ID 364 Signal handler race condition
18. CWE ID 415 Double Free
19. CWE ID 416 Use After Free
20. CWE ID 426 Untrusted Search Path
21. CWE ID 469 Improper pointer subtraction
22. CWE ID 479 Unsafe function call from a signal handler
23. CWE ID 590 Improperly Freeing Heap Memory

There are certainly more vulnerabilities that are specific to the designs of the browsers or plugins but this is a good start. Eliminate these and the bar has been significantly raised.

Apple, Mozilla, Microsoft, Opera and all the plug-in vendors, the client side browser vulnerability crisis is yours to solve. We need significantly less remote code execution vulnerabilities in your code.

Watchfire just released a whitepaper on Overtaking Google Desktop which is a thought-provoking read. It essentially exploits the mechanism by which Google Desktop hooks the browser in order to inject links to the local Google Desktop instance when the user performs a typical online Google search. There are a couple of gating factors to making this attack viable — the initial attack vector requires an exploitable XSS vulnerability in google.com, and the victim must have Google Desktop’s browser integration feature enabled. An added twist is that a successful attack essentially gets cached by Google Desktop (since it is based on an advanced search preference) and could persist indefinitely. Really nice work by the Watchfire research team.

More important than the vulnerability itself is the fact that this further blurs the boundaries between web-based and desktop-based attacks. What other pieces of desktop software might potentially be manipulating browser content to provide some level of seamless browser integration? Any standalone application that wants to introduce functionality that integrates with their website (or others) could fall into this category — RSS readers, news readers, BitTorrent clients, instant messaging applications, etc. Local HTTP servers in desktop applications are not too uncommon and will become more prevalent as the web browser becomes the primary user interface for everyday tasks.

Should web browsers really permit arbitrary desktop applications to manipulate the content of pages, without explicit permission from the user? Providing a way to disable this behavior would be one step toward re-establishing boundaries in the interest of security.

A few weeks ago I was waiting for a flight in the JetBlue terminal of JFK. JetBlue offers free Wi-Fi to its customers, which is a nice touch. I powered up my laptop and this is what I saw:

If I’m your typical non-security-minded traveler, which of these networks am I most likely to connect to? I would guess that the majority of people will select one of the two with Jet Blue in the SSID, or maybe the one called Free Public Wi-Fi. Interestingly enough, the real JetBlue SSID is the one called default. Notice that it’s the only one identified as a wireless network (infrastructure mode) as opposed to a computer-to-computer network (ad-hoc mode). The others are almost certainly would-be attackers attempting to lure unsuspecting travelers. If you’re not paying attention, you could fall victim to a phishing attack or even a man-in-the-middle, since most people tend to ignore warnings about invalid SSL certificates when browsing the web. Good way to pick up some malware in your spare time!

I didn’t bother connecting to any of these rogue networks to see what was behind them. A more sophisticated attacker wouldn’t be so obvious. First, they’d be running their card in infrastructure mode so they’d appear to be an access point rather than an ad-hoc network. They’d also be using the same SSID as the genuine JetBlue network, although in this case some of the fake SSIDs might be more effective than a true “evil twin” attack.

This isn’t a new problem by any means, just something I found amusing in my sleep-deprived state. I’ve been in a lot of airports that offered Wi-Fi, but usually it’s for a fee so most people don’t bother. This is the first time I’ve seen that many obviously rogue networks at a single time. It all boils down to consumer awareness — and possibly the need for JetBlue to improve its Wi-Fi deployment process beyond “buy a wireless access point and plug it in.”

Your best bet for avoiding rogue wi-fi networks in situations like this? Bring your cell phone, hook it up to your laptop, and connect to the Internet via GPRS.