SOURCE Conference Blog

The recent Siemens WinCC SCADA targeted malware packages an zero day application vulnerability with a zero day OS vulnerability. The OS vulnerability in Windows creates a worm capability to get to the target and once on the target the application vulnerability allows compromise of the application’s data. The vulnerabilities are used in stages:

Stage 1: Use a Windows OS vulnerability for wormable spread. This is the zero day .LNK file attack.
Stage 2: If the malware lands on a computer running Siemens WinCC software it uses an application vulnerability to access the database containing sensitive information and exfiltrates the data

Stage 1 is an OS vulnerability. This effects everyone running Windows. Stage 2 is an application vulnerability. This effects only those running Siemens WinCC which the attack is targeted for. Siemens software has a critical severity vulnerability that is also easy to exploit: a hard coded password. Once hard coded passwords are discovered it is trivial for the attacker to access systems using that password, in this case a database.

Hard Coded password (also known as CWE-798: Use of Hard-coded Credentials) is #11 on the CWE/SANS Top 25 Most Dangerous Software Errors, an industry standard list that Veracode contributed to. It is a very common problem and is found in a lot of software that has not undergone proper security testing before shipping to customers. Veracode commonly finds this vulnerability in the software we test for our customers.

This is what the CWE/SANS Top 25 Most Serious Software Errors has to say about hard coded passwords:

“Hard-coding a secret password or cryptograpic key into your program is bad manners, even though it makes it extremely convenient – for skilled reverse engineers. While it might shrink your testing and support budgets, it can reduce the security of your customers to dust. If the password is the same across all your software, then every customer becomes vulnerable if (rather, when) your password becomes known. Because it’s hard-coded, it’s usually a huge pain for sysadmins to fix. And you know how much they love inconvenience at 2 AM when their network’s being hacked – about as much as you’ll love responding to hordes of angry customers and reams of bad press if your little secret should get out. Most of the CWE Top 25 can be explained away as an honest mistake; for this issue, though, customers won’t see it that way. Another way that hard-coded credentials arise is through unencrypted or obfuscated storage in a configuration file, registry key, or other location that is only intended to be accessible to an administrator. While this is much more polite than burying it in a binary program where it can’t be modified, it becomes a Bad Idea to expose this file to outsiders through lax permissions or other means.”

Siemens has put their customers at risk with this egregious vulnerability in their software. Worse, in my book however, is all the customers who purchased the software not knowing of its risk. Software customers that are operating SCADA systems on critical infrastructure or their factories with the WinCC Software had a duty to their customers and shareholders to not purchase this software without proper security testing.

We should ask the question, “Why didn’t Siemens fix the hard coded password vulnerability when it was first publicly disclosed?” They waited 2+ years and started to fix it only after a worm exploited it. We should also ask the question, “Is it negligence when you don’t fix a critical known vulnerability and wait for your customers to get exploited?”

The way to solve the problem of vulnerable software in critical infrastructure is to have independent security tests for at least the vulnerabilities listed in the CWE/SANS Top 25 Most Dangerous Software Errors before the software is deployed. Otherwise, customers are just hoping that someone discovers that someone else’s systems are compromised, and alerts the media, and there is a patch deployed, before their systems are compromised. With the sophistication shown through this multi-stage USB attack, it is clear that hope is not a viable option.

Vulnerability disclosure is in the spotlight again. First it was Tavis Ormandy disclosing a vulnerability in Microsoft Windows before Microsoft had a fix available. Now a group called Goatse Security has disclosed a vulnerability in an AT&T website that affects Apple iPad 3G owners. The Wall Street Journal reports on the repercussions against vulnerability researchers in “Computer Experts Face Backlash”.

The AT&T website vulnerability is part of a growing new trend for vulnerability disclosures. As software and services move from traditional installed software to SaaS and into the cloud, more vulnerabilities are only going to exist in code running on one organization’s web server. This makes the basis for website vulnerability disclosures as beneficial somewhat different from disclosures for software that is installed on many customer devices.

The first issue with vulnerabilities in code running on a website is, to do the research in the first place, the researcher needs to interact with computers that they don’t own. Traditional vulnerability research occurs on the researcher’s equipment or on equipment they have permission to use. Website research has a risk of crossing the line into unauthorized access or exceeding authorized access as defined by the CFAA (Computer Fraud and Abuse Act).

What constitutes exceeding access on a public website is a bit of a gray area. On one hand, sending a large buffer to a web application that causes it to crash and execute the code of your choosing seems like exceeding authorized access. No one would ever think the application was designed to do that and clearly executing your own program is very different than interacting with a web page. But what about a web site which was designed to display the email address associated with an ID when the user enters an ID? Is it exceeding authorized access to put in a random ID and get the email address associated with it back? The website is working as its designers intended.

The latter case is exactly the vulnerability (now fixed) in the AT&T website that affected iPad 3G users. Anyone who registered on the AT&T website entered their iPad’s ICC-ID and an email address. After they had registered they could return and enter just the ICC-ID and the web page would display their email address. Researchers from Goatse Security noticed this and tried entering random ICC-ID numbers into the website and discovered for valid ICC-IDs they would get the owner’s email in response.

At this point Goatse Security had enough to demonstrate the vulnerability and report it to AT&T. But as is often the case when a tiny organization with little track record is reporting an issue to a huge multinational company, they gathered enough information to make the story newsworthy and got a 3rd party organization to contact the company. In fact, they harvested 114,067 email addresses. So a wrinkle to this “gray area” of exceeding authorized access may how much information is gathered. If AT&T prosecutes, as they have stated they will, we will get to find out whether this behavior exceeded authorized access in the eyes of the court.

There is clearly a benefit to Goatse Security’s work. AT&T had the opportunity to fix their website before any information about the vulnerability was made public. A vulnerability that disclosed information that could have been used by criminals to target iPad owners, both over email and over the GSM network, has been remediated. Furthermore, the iPad owners have been notified and can take corrective action, such as being more vigilant to iPad targeted attacks over email or changing their ICC-ID with a new SIM card. It is hard to see any downside to their actions. They never disclosed the information they obtained to prove the vulnerability to a 3rd party and they say they have destroyed it.

We need a way for researchers that discover vulnerabilities in web applications and report them without being prosecuted. As long as the owners of the web site have the opportunity to make corrections to address the vulnerability before disclosure, this will benefit users in the long run.

The challenge is in determining what is an attack and what is research? When does research become exceeding unauthorized access under CFAA? These questions don’t exist for research into vulnerabilities in traditional software that is installed on a machine the researcher owns. As sensitive information moves from local machines and servers to databases and files on the internet, this information is mediated by potentially vulnerable web applications. If good faith and responsible research can’t continue to follow software as it moves from desktops and servers to the cloud then data security overall will suffer.

But we shouldn’t kid ourselves and think that research alone can make an application more secure. It can point out bugs here and there, but can never make an application secure. To do that, web app developers need to test their software for security vulnerabilities before they deploy the software to the internet. A vulnerability report from a researcher is a wake-up call that security testing was inadequate. Organizations need to demonstrate to their customers that they have conducted adequate testing before they deploy their applications and certainly before they attract the attention of researchers. That is the real solution for security on the web. Unfortunately we are still in a phase where researchers need to keep demonstrating the need for more security testing.

In his blog, Gartner analyst Neil MacDonald asks the question, “Is .NET More Secure Than Java?”. Veracode provided data to help answer this question from our “State of Software Security Report” which contains the static analysis results from 1591 Java, .NET and C/C++ applications. .NET comes out slightly ahead.

…the vulnerability density (average flaws per MB of code scanned) for .NET was 27.2 and for Java the overall density was 30.0.

The question of which platform helps create a more secure application has been debated vigorously for many years. Back in 2003, with Andy Jaquith and other consultants at @stake, I performed a comparison of the security of the .NET vs. J2EE platforms. Our overall results had .NET coming out slightly ahead of J2EE mostly due to better developer defaults and better security guidance for developers. This may be the reason .NET is coming out slightly ahead in this analysis of hundreds of real-world applications.

Lots of people have been asking us for opinions on HTML5 security lately. Chris and I discussed the potential attack vectors with the Veracode research team, most notably Brandon Creighton and Isaac Dawson. Here’s some of what we came up with. Keep in mind that the HTML5 spec and implementations are still evolving, particularly with respect to security concerns, so we shouldn’t assume any of this is set in stone.

Don’t Forget Origin Checks on Cross-Document Messaging

Applications that use cross-document messaging could be unsafe if origin checking is done incorrectly (or not at all) in the message receivers. It’s important that developers writing apps that rely on postMessage() carefully check to ensure that messages originate from their own sites, otherwise malicious code from other sites could spoof rogue messages. The functionality itself isn’t inherently insecure, though; developers have used various DOM/browser capabilities to emulate cross-domain messaging for some time now. The window.name attribute has been abused, as has Javascript-driven injection of HTML and URL rewriting. There’s even a cross-platform JavaScript library called easyXDM that provides a friendly interface to these hacks.

One bright spot with regard to cross-document messaging is that older apps won’t be threatened by these issues, only new apps that are intentionally written to rely on the feature.

Local Storage Isn’t as Problematic as You Think

Local storage doesn’t appear to present major security risks, despite a lot of FUD circulating on the topic. Besides cookies, there have always been numerous ways for web apps to store data client-side through the use of plugins (Java, JWS, Flash, Silverlight, Google Gears, etc.) or browser extensions — WebKit/Safari/Chrome have supported local storage before it was even part of HTML5.

Developers should also be aware that as currently implemented, the HTML5 sessionStorage attribute can be vulnerable to manipulation from foreign sites under certain circumstances. A remote site can get a handle to a window containing a site for which a browser has data in sessionStorage. Then, the remote site can navigate to arbitrary URLs in that window, while the window will still contain its
sessionStorage. Hopefully this implementation bug will be fixed by the time the standard is final.

New Tags Increase Attack Surface

HTML5 will also support new data formats and tags such as the <canvas> and <video> tags. In-browser support for video means browser developers now have to parse historically bug-ridden file formats. This increases the attack surface of HTML5 browsers but otherwise doesn’t affect the typical web app developer. The <canvas> tag is a complex set of functionality mixing Javascript and imaging-related functions, and image parsers have historically been rife with vulnerabilities.

Developers Should Be Wary of Cross-Origin Javascript Requests

Another new feature set that’s not directly part of HTML5, but has recently been introduced, is limited support for cross-origin Javascript requests. Historically, it’s been forbidden for Javascript code to request pages from any host other than the page that served the script itself; this is part of the same-origin policy. However, the W3C’s current draft for Cross-Origin Resource Sharing provides a way to circumvent the same-origin policy using a mechanism similar to the crossdomain.xml file in Flash (i.e. the server decides which domains are allowed to access its resources).

Firefox, Safari, and Chrome currently allow cross-domain requests to be sent using XMLHttpRequest. Before the entire request is allowed to proceed, the browser sends a probe request using the OPTIONS method (instead of, for example, GET or POST) first. If the server responds to this probe with an “Access-Control-Allow-Origin” header that gives the source host permission to make the request, the browser will then resend the full request with the requested HTTP method. This is consistent with the current working draft for W3C Cross-Origin Resource Sharing.

However, IE works differently. Instead of relaxing permissions on XMLHttpRequest, it uses a new object type called XDomainRequest. Also, instead of sending a probe that replaces the normal HTTP method with OPTIONS, its probe includes the original HTTP method as well as the request body (in the other browsers, the request body is omitted).

The cross-domain-request features are actually fairly troublesome, from a security point of view. Malicious code on any site can cause probe requests to be sent to any other site, in every major browser, today. Developers need to be aware of both probe types and ensure that their applications won’t be fooled by probes. Fortunately, cookies aren’t passed in any browser’s probe request. Adding to the confusion, some of the official documentation on the topic contains reference code that is blatantly insecure. For example, in an MSDN page on XDomainRequest, ASP code is provided for setting the “Access-Control-Allow-Origin” header field to “*”. This would allow any remote site to make unauthenticated requests against that page from JavaScript, which is not advisable for most applications. Developers need to be sure they understand the dangers of creating an overly permissive access control list.

Sandbox Attribute Could Make Security Easier

One thing that may help, depending on how the standard is eventually defined and implemented, is the support for a sandbox attribute on IFRAMEs. This attribute will allow a developer to chose how data should be interpreted. Unfortunately, this design, like much of HTML, has a pretty high chance of being misunderstood by developers and may easily be disabled for the sake of convenience. If done properly, it could help protect against malicious third-party ads or anywhere else that accepts untrusted content to be redisplayed.

Always Remember Input Validation

The most important thing that developers can do is to remember basic security tenets, for example, the idea that all user input should be considered untrusted. They should learn how the new HTML5 features actually work in order to understand where they’d be tempted to make erroneous assumptions.

“Zero Day” the album that is. Wired has a review. You can read the full lyrics on Frontalot’s site. Here is a snippet:

Press play, prepare as history is made:
“largest hack in one day,” all the headlines will say.

All out of time, hear the chime from the buzzer.
Found this bug on my own, no need for a fuzzer.

“It’s already too late,” spreading as we planned.
No need for the NO OPs, I know just where to land.

Clearing out the registers, with pointers to my functions,
loaded to your memory and writing new instructions.

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.

Here’s a quick post to let you know all the places to get your Veracode fix at RSA Conference 2010.

• On the Expo floor, we’ll be in booth 729. I’ll be at the booth for a few hours on Tuesday and Wednesday. Stop by if you’d like to talk about our service offerings, get a quick demo, or just say hello.
• On Monday morning at 9:25am, Ashish Larivee will be giving a presentation, Metrics for Insights on the State of Application Security at Mini Metricon.
• On Monday morning at 11:15am, I’ll be on a panel, Securely Getting to Planet SaaS at the Cloud Security Alliance Summit in Green Room 131.
• On Wednesday morning at 9:10am, Chris Wysopal will be on a panel, Whitelist or Trustlist? Should There be an Industry Software Whitelist? in Orange Room 301.
• On Wednesday afternoon at 1:00pm, Chris Wysopal will be giving a presentation, Detecting “Certified Pre-owned” Software and Devices in Blue Room 104.
• On Wednesday evening at 6:00pm, I’ll be participating in a Security Round Table at Ruby Skye, prior to the Rapid7 party.

Looking forward to catching up with everyone!

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).

Here are the goods:

Slides: Blackberry Mobile Spyware — The Monkey Steals the Berries
Source: txsBBSpy.java

So how can users protect themselves? There are a few places to defend against malware of this nature.

1. 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.
2. 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)
3. 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.