I’ve been focused on conducting research into the mobile spyware arena these last few months and the results have been very interesting. As I’m sure you are aware, I released a fully functional piece of Blackberry Spyware called txsBBSpy at the Shmoocon security conference in February 2010 and have done a number of interviews and podcasts on the topic. While my research is interesting, other high profile attacks just this week could really make this type of spyware/trojan a lot more dangerous.
At CanSecWest security conference this week, iPhone, Firefox, Safari, and other mobile operating systems and browsers were proven vulnerable to zero day exploitation. (The Register Article). Many people have expressed to me that txsBBSpy doesn’t actually have an infection vector and that mobile devices are secure from attack. I think the results of Pwn2Own clearly demonstrate otherwise. Mobile devices are just as insecure, if not more so than the standard desktop system. What makes it even more dangerous is that researchers who sell their exploits can get between 10K$ and 115K$ depending on the specifics of the flaw. That’s no longer chump change! Why would any researcher have any incentive at all to disclose the flaw responsibly given the big dollars that can be made by selling to a broker.
The only thing really limiting researchers from selling their flaws on the open market is the threat of incarceration. Jeremy Jethro was sentenced this week to three years probation and 10K$ in fines for selling exploit code to hacker Albert Gonzalez who in turn used the code in hacking companies and stealing 90 million credit card and debit card numbers. Gonzalez paid Jethro 60$K for the exploit while Jethro had no indication that Gonzalez intended to use the exploit code in any illegitimate way. Had this gone to court, the precedent that could have been set here is astonishing. Luckily this case was a plea bargain, otherwise the selling of exploit code would essentially be criminalized and we wouldn’t be sure to what degree this really impacts the researcher. If a researcher were to sell his exploit code to ZDI and then ZDI somehow accidentally leaks the code that is then used in an attack, who is to blame and who pays the fines/jail time? If a researcher sells his code to an independent broker who then resells the code to a criminal, who is left holding the legal bag? We do know this much.. it’s dangerous and potentially illegal to sell exploit code that is then used in a crime regardless of your knowledge of the crime. Everything else is still shades of grey.
What does this mean for mobile based Spyware? It means that those vulnerable phone operating systems and browsers are likely to get exploited with previously unknown vulnerabilities and spyware like mine is likely to be the resulting payload. Welcome to the era of malicious mobile attacks.
There have been a lot of great articles written in the wake of my presentation on Mobile Spyware at Shmoocon 2010. Many of them show wonderful insight into the problems that mobile carriers and owners of the mobile applications stores are facing. However, for every handful of great articles, we occasionally come across a technical expert that presents a different viewpoint. Usually it’s best to let the articles stand on their own merit and let the readers decide for themselves, but in this instance I think it might be best to use a recent article to demonstrate how incorrect statements create confusion about the issues.
The article I’m referring to is Mobile security: Hackers kept at bay by lack of a standard platform. The article does not directly reference my presentation, but it does make some points that just don’t make sense. The first half of the article has some expert commentary that is cause for concern, while the second half raises interesting questions that bolster my arguments.
In the first half of the article, the author turned to Candid Wueest, senior threat researcher at Symantec, for comments on monocultures in the arena of mobile malware, ease of malware creation, and the safety of downloading applications from the device manufacturers application marketplace.
As long as smartphone users download applications only through authorised, moderated channels, he argues, they can be confident their mobile platform will limit the actions these applications can perform.
This is absolutely not true. I showed in my presentation examples of spyware that has already been discovered sourcing from so called “authorized, moderated channels” such as the Google Android Marketplace and the Apple iTunes store. This is exactly the type of false sense of security that is coming from the “authorized” marketplaces and trickling down to the consumer. In this instance we see the level of trust that even a subject matter expert is giving to the mobile application stores to provide only secure and trusted applications. Until the application store operators become transparent with their procedures and policies regarding the security of applications they make available, the above statement only makes the problem worse.
“At the same time, he adds, relatively few hackers have the in-depth skills and understanding necessary to create viruses capable of targeting a specific mobile platform.”
Programming, specifically Java, is not my daily job. It’s not what I do day in and day out. I am far from an expert with in-depth skills when it comes to writing mobile malware, yet it didn’t take me all that long to figure it out. I went from zero blackberry knowledge to programming a fully functional piece of spyware within a month or two. I’d say that it doesn’t really take “in-depth skills and understanding” to create malware capable of targeting a specific mobile platform.
“A monoculture is far more helpful to virus writers, so while we’ve seen 4m viruses, worms and trojans attack Windows, we’ve seen only 400 kinds of malware aimed at mobile platforms,” he says.
While I agree that a monoculture is far more helpful to virus writers, it’s not like we are dealing with a culture that has 100+ different options. If you target iPhone and Blackberry alone you would get a huge percentage of the US market, and if you throw in Symbian you cover a good chunk of Europe as well. We also have to consider the amount of time that people have kept sensitive data on Windows systems and how long they have kept that same data on their smartphones. Smartphones have really come into vogue as miniature computing systems in the last year or two, while full service computing systems have been around for ages.
I’m not suggesting that the mobile apocalypse is coming in 2010. What I am suggesting is that 2010 will see a notable increase in the amount of malware created and propagated via the mobile application store fronts such as iTunes, Blackberry App Center, and the Google Android Marketplace. The data is migrating to the hand held, so will the cyberattacks.
Some of the media coverage to date has described Tyler Shields’ proof-of-concept spyware as a “BlackBerry hack”, much to our chagrin. In this blog post, we’d like to clarify some of the misconceptions that have surfaced both in the media and in the BlackBerry user community. Feel free to post additional questions in the comments section and we’ll do our best to respond.
Q: This isn’t a real hack, is it? Tyler’s program is similar to many applications already on the market.
We’ve tried to make it clear from the beginning that txsBBSpy is a demonstration of public, documented APIs and should not be considered a hack, an exploit, or a vulnerability in the BlackBerry OS or infrastructure. There are many commercial apps, including FlexiSpy, SmrtGuard, Mobile Spy, and others, all of which utilize the same BlackBerry APIs. But these apps must be purchased, and they’re only available in compiled form.
What’s notable about txsBBSpy is that we’ve released source code to demonstrate how the application works. This serves as an educational resource as well as an eye-opener showing how simple it is to implement malicious functionality.
Q: Is the spyware risk unique to BlackBerry?
Not at all, it’s just the platform we decided to research. Similar work has been done on other mobile platforms such as iPhone, including this presentation from Nicolas Seriot delivered at BlackHat 2010 in Washington, DC last week. His proof-of-concept application, SpyPhone, takes the same approach as txsBBSpy by demonstrating what can be accomplished using public APIs. Any mobile platforms that can run third-party applications have similar risks.
Q: Wouldn’t you still have to trick a human into installing the spyware?
Yes, but this doesn’t negate the risk. Consider the parallel in the PC world. People inadvertently install spyware on their computers because they wanted a cool toolbar or because some message told them they were supposed to. Users make bad choices. If they didn’t, we wouldn’t have a multi-billion dollar anti-virus industry.
The same risks apply to mobile devices. People will install applications. It’s fair enough to say that most users wouldn’t install an app called txsBBSpy, but many would happily download a game featuring dancing bears. All joking aside, there is nothing to prevent an otherwise legitimate program from including unadvertised, malicious functionality. What assurances do you have that the Twitter client, RSS aggregator, or video game that you installed on your BlackBerry isn’t also stealing your emails or intercepting your text messages? Case in point, the Etisalat spyware would have gone completely unnoticed had it not been for a poorly architected “phone home” routine.
Q: RIM requires all apps to be signed. Doesn’t that protect against the spyware risk?
Not at all. It’s a minor hurdle at best. Anyone with $20 and a name (doesn’t have to be your actual name) can get a code signing key. There are plenty of ways to obtain a key anonymously, if you think hard enough; Tyler alluded to a couple during his ShmooCon presentation.
Once a developer has a key, he simply submits a SHA-1 hash of the .cod file to RIM, who will respond back with a RIM signature which gives the application permission to use the requested controlled APIs at runtime. RIM never receives the source code or the compiled application, so they have no way of inspecting its functionality. Further, there is no revocation list for malicious applications. If a developer releases a malicious application, RIM can refuse to sign his apps in the future, but they can’t prevent an app from running once it’s been signed, nor can they prevent the developer from obtaining another anonymous key and creating additional code any time he wants.
Q: Isn’t this whole thing overblown, since BlackBerry users can set permissions for each app they install?
The BlackBerry OS does provide granular controls for application permissions that are configurable by the user. Access to connections, interactions, and user data are split into about 20 categories, each of which can be set to Allow, Deny, or Prompt. The problem is that most users don’t take advantage of these features. According to a Trend Micro survey of 1,016 U.S. smartphone users in June 2009, only 23% of smartphone owners use the security software installed on the devices. During a webinar we held earlier today, we posed this question to attendees: “Do you enable application level security for each application on your BlackBerry device?” Only 15% of attendees answered yes, and that’s for a technical audience. I’d assume the number would be well below 15% across a representative sampling of BlackBerry users.
The other misconception around application permissions is that you’ll always be prompted before the application can access any user data. In reality, the DEFAULT application permissions in both the 4.x and 5.0 BlackBerry OS allow third-party applications to access emails, organizer data (contacts, etc.), files, device settings, media, and many other categories without prompting. Tyler’s slide deck provides a complete listing of default permissions for third-party apps.
Now, the defaults are already pretty loose, but the OS is even more permissive for applications that have been granted “trusted” status. At installation time, the user is asked “Is this a trusted application?” and if they answer “Yes”, the application is given even greater freedom to access phone connections, location data, the Internet, and more, without further prompting. Users don’t think twice about granting trusted access because they hate being inconvenienced by prompts every time the app wants to do something. How does a user know whether or not it’s safe to give an application trusted status?
Q: Aren’t enterprise users immune to spyware, due to BES features that prevent unwanted applications from being installed?
IT Policies on the BlackBerry Enterprise Server (BES) can be configured to restrict which third-party apps employees can install, but this raises a similar question: how does the IT staff know whether or not to whitelist an application? They have no way to objectively assess whether they should trust the application.
Q: Don’t the mobile app stores already screen applications for spyware before making them available for download?
The app stores have a unique opportunity to screen submitted applications for malicious behavior, but none of them have come out publicly saying that they do so. There are several references in Tyler’s presentation of malicious apps that have been accepted into various mobile app stores, so we know that the screening processes are not rigorous. Anecdotally, we know that RIM is concerned mostly with ensuring that third-party applications do not crash the operating system. From media reports, we know that the iTunes App Store is concerned with profanity, supposed “misuse” of Apple trademarks, and apparently even mentioning the names of other handsets (but harvesting phone numbers is fine).
The intersection of bad user behavior and app store inaction creates a target rich environment for malicious mobile applications.
[UPDATE, 2/10/2010: We've written a follow-up blog post to address some of the questions and misconceptions we've been seeing.]
Tyler Shields gave a presentation earlier today at ShmooCon 2010 on the threats of mobile spyware, particularly as it relates to data privacy. Smart phones and mobile applications have grown tremendously popular over the past couple of years, and it seemed like an appropriate time to raise awareness of what these applications are capable of.
Our goal was to demonstrate how BlackBerry applications can access and leak sensitive information, using only RIM-provided APIs and no trickery or exploits of any sort. We make no assumptions about how the malicious application will be installed on the phone, and we haven’t attempted to sneak a malicious application into BlackBerry App World. BlackBerry apps can be installed from any location, plus, there are so many examples of malware slipping through the screening processes of the various app stores (Apple, Symbian, Android, etc.) that we didn’t find it necessary to prove the point again. To some degree, official app stores give users a false sense of security because people will assume that everything in the store must be trustworthy.
Here’s a video that demonstrates the features of Tyler’s proof-of-concept spyware. We show how it can be used to dump contacts and messages, intercept text messages, eavesdrop on the room, report on phone usage, and monitor GPS data. To view this in HD resolution, click through to Vimeo and use full screen mode for best results.
We’re also releasing source code. As far as we know, this is the first public release of source code that demonstrates such a broad range of malicious functionality on a BlackBerry device. Code reviewers and security practitioners can use it as an educational resource to help them recognize malicious behavior and understand the specific risks introduced. This is an important educational asset for those of us working to create more secure software. As for the bad guys, it would be naive to think that they don’t already know how to do this stuff. The code doesn’t go out of its way to be stealthy; in fact, it’s quite the opposite (by design).
So how can users protect themselves? There are a few places to defend against malware of this nature.
Users can configure their default application permissions to be more restrictive. This way, if an application tries to use an API that accesses the user’s email or contact list, the OS will ask for permission. Avoid granting applications “trusted application” status, which grants untrusted applications additional privileges. Tyler’s slide deck shows the default and trusted permission sets in more detail.
Corporations using a BlackBerry Enterprise Server can configure their IT policies to restrict their users from installing third-party applications, or whitelist certain approved applications (but brace yourself for the backlash)
BlackBerry App World could introduce a rigorous security screening process that submitted applications must pass in order to be listed in the store.
If app stores don’t provide any security testing, the risk reduction responsibility falls to the enterprise. We recommend creating an approved list of applications that have undergone security testing.
Finally, it should be noted that while we chose BlackBerry for our proof-of-concept, this is not just a BlackBerry problem. All mobile platforms provide similar mechanisms for writing applications that have access to the user’s personal, potentially sensitive information. As consumers become increasingly dependent on their mobile devices, we are certain to see an uptick in the volume and sophistication of mobile malware.
I couldn’t agree more that we may be missing an opportunity to bring whitelisting to these new important mobile platforms. We need to leave the “detect and revoke” mentality of the PC world behind as we move to new platforms. Attackers are able to game the PC antivirus model by continuously flooding the software ecosystem with new unknown malware. The attackers will win in the mobile world too if we don’t change it. The mobile app store is a form of whitelisting that can assure the security of an entire platform if the whitelisting means something. That is if the apps are tested for security before being published.
Veracode is being asked by large financial organizations to build security testing into internal mobile app stores. There is obviously a desire for security screened applications in the corporate and government world. Why not just scan once at the platform provider’s app store and give the benefits to all?
Veracode researcher Tyler Shields is presenting 2/7/2010 at Shmoocon on Blackberry malicious mobile code. The presentation and sample code will be available here.
Yesterday it was reported by variousmedia outlets that a recent BlackBerry software update from Etisalat (a UAE-based carrier) contained spyware that would intercept emails and text messages and send copies to a central Etisalat server. We decided to take a look to find out more.
We’re not sure why the software was delivered in both .jar and .cod form. The .cod file is a RIM proprietary format that contains the compiled Java classes along with a signature. Therefore it’s not even necessary to send the .jar, but they did, completely unobfuscated. Arrogance or incompetence? Here’s what’s inside:
$ jar tvf Registration.jar
0 Sat Jul 04 18:52:00 EDT 2009 META-INF/
447 Sat Jul 04 18:52:00 EDT 2009 META-INF/MANIFEST.MF
18732 Sat Jul 04 18:52:00 EDT 2009 Registration.cod
91 Sat Jul 04 18:52:00 EDT 2009 Registration.csl
183 Sat Jul 04 18:52:00 EDT 2009 Registration.cso
0 Sat Jul 04 18:52:00 EDT 2009 com/
0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/
0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/
0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/
10857 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Commands.class
2388 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Constants.class
1056 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Log.class
935 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Main$1.class
3479 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Main.class
4137 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/MsgOut.class
5975 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Recv.class
16133 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Send.class
2988 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/StatusChange.class
6462 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/app/Transmit.class
0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/
3465 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/HTTPDeliver.class
0 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/
7370 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/SMTP.class
3285 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/smtp/SMTPHeader.class
3871 Sat Jul 04 18:52:00 EDT 2009 com/ss8/interceptor/tcp/SocketBase.class
1273 Sat Jul 04 18:52:00 EDT 2009 Interceptor.class
These classes implement the various hooks:
The Recv class implements net.rim.blackberry.api.mail.event.FolderListener and net.rim.blackberry.api.mail.event.StoreListener, allowing it to hook folder and message store updates. It’s installed using addFolderListener().
The Send class implements net.rim.blackberry.api.mail.event.FolderListener and net.rim.blackberry.api.mail.SendListener, allowing it to hook folder updates and outbound messages. It’s not installed as a listener via addSendListener(), though it’s used explicitly to forward messages later on.
The StatusChange class implements net.rim.device.api.system.RadioStatusListener and net.rim.device.api.system.GlobalEventListener, allowing it to hook radio events such as a change of network. It’s installed using addRadioListener() and addGlobalEventListener(), and all it really does is remove and re-register the Recv listener when certain network events occur.
Whenever a message is received on the device, the Recv class first inspects it to determine if it contains an embedded command — more on this later. If not, it UTF-8 encodes the message, GZIPs it, AES encrypts it using a static key (“EtisalatIsAProviderForBlackBerry”), and Base64 encodes the result. It then adds this bundle to a transmit queue. The main app polls this queue every five seconds using a Timer, and when there are items in the queue to transmit, it calls this function to forward the message to a hardcoded server via HTTP (see below). The call to http.sendData() simply constructs the POST request and sends it over the wire with the proper headers.
Let's get back to that part about embedded commands. The first thing that the Recv class does is check to see if there's an embedded command in the received message. The first check is actually inactive due to a conditional that will always evaluate to false. If I had to guess I would say that conditional was originally used to check the origin of the message against two BlackBerry device PINs -- that's a guess based on the fact that the strings look similar to the device PIN format. If this code path were enabled, any message with a subject containing "cmd_mail" would be passed off to a command handling routine. If the subject also contained "XXX", it meant the body was encrypted.
Since that section will never run, we move on to the else clause. Here, we see that if the sender name and address match "Customer Service" and the message was PIN-based (as opposed to email based) the body of the message will be treated as an encrypted command packet and the message will be instantly discarded. It's unclear if it will momentarily appear in the user's Inbox, but even if it does, it won't be there for long.
The encryptedCmd() function parses the body of the command packet by extracting anything that looks like a PGP signature block, that is, the chunk of text delimited by the strings "-----BEGIN PGP SIGNATURE-----" and "-----END PGP SIGNATURE-----". It then Base64 decodes the body and AES decrypts it using an AES key based on the device PIN. It then parses the command packet, which is an XML-like structure. It doesn't seem to execute arbitrary commands, just packages up device information such as IMEI, IMSI, phone number, etc. and sends it back to the central server, the same way it does for received messages. It also provides a way to remotely enable/disable the spyware itself using the commands "start" and "stop". Just for fun, here's the key generation routine used to encrypt these command packets to a specific device. The keyString variable is the hex-encoded form of whatever is returned by the RIM API call DeviceInfo.getDeviceId():
public static byte[] generateKey(String keyString, int keylen)
{
byte buf[] = new byte[keylen];
Arrays.fill(buf, (byte)0);
byte key[] = keyString.getBytes();
int srcbytes = key.length;
int n = srcbytes;
if(n < keylen)
n = keylen;
int keyoffset = 0;
int i = 0;
int j = 0;
for(; i < n; i++)
{
int pos = i % srcbytes;
buf[j++] ^= key[pos] + keyoffset;
if(pos == srcbytes - 1)
keyoffset += 23;
if(j % keylen == 0)
j = 0;
}
return buf;
}
The most alarming part about this whole situation is that people only noticed the malware because it was draining their batteries. The server receiving the initial registration packets (i.e. "Here I am, software is installed!") got overloaded. Devices kept trying to connect every five seconds to empty the outbound message queue, thereby causing a battery drain. Some people were reporting on official BlackBerry forums that their batteries were being depleted from full charge in as little as half an hour.
The final thing to mention is that the spyware does appear to be installed in a non-running state by default, where it's not actually exfiltrating data once the initial registration packet has gone out. However, using the command and control mechanism we described earlier, the carrier can remotely start/stop the service at will on a per-device basis.
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.
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-prefixattacks 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.
