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.
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.
I applaud Google for coming forward and letting the world know about how they were attacked and what the attackers were after. Secrecy only helps the offense. Most of the time we only hear about attacks when there is public evidence such as a defaced web page, screen shots sourced from the attacker, or there is a prosecution. Since the vast majority of attackers are quiet and not prosecuted the public admission of attacks is a great public service which will help organizations understand their own risk. Other organization similar in size and sophistication to Google are clearly at risk from similar attackers and attacks.
This widespread attack on US high tech companies signals that 2010 is the year organizations will wake up that there are sophisticated attackers after their intellectual property such as source code and hardware designs. All the same attacks used to steal CC#’s and online passwords for financial theft are being targeted at intellectual property.
Attackers are well organized and have command & control in place so that the discovery of a zero day vulnerability can be used to maximum advantage by rapidly hitting a large number of high value targets.
The only solution to running software with latent vulnerabilities is to stop running software with latent vulnerabilities. Anti-virus and IDS won’t help when it is a zero day vulnerability where there is no pattern to match. Software acceptance needs to include evidence that rigorous security testing was performed.
It is time for organizations to take a hard look at the set of client software they allow on their employees workstations and determine how trustworthy that software is. In most organizations these client systems have unbounded risk and are receiving data from the untrusted internet. If this doesn’t change, attacks similar to what happened to Google are going to effect every organization with something of value.
A conversation on Twitter this morning started out like this:
@dinozaizovi: Finding vulnerabilities without exploiting them is like putting on a dress when you have nowhere to go.
This clever analogy spurred a discussion about the importance of proving exploitability as a prerequisite to fixing bugs. While I agree that nothing is more convincing than a working exploit, there will always be a greater volume of bugs discovered than there are vulnerability researchers to write exploits. Don’t get me wrong — as a former penetration tester, I agree that it is fun to write exploits, it just shouldn’t be a gating factor. Putting the burden of proof on the researcher to develop an exploit is not scalable, nor does it help create a development culture that improves software security over the long term.
A related topic, and one that hits closer to home for me, is how software developers deal with the results of static analysis. Static analysis is often misunderstood, particularly by people who have only dealt with dynamic analysis (fuzzing, web scanning, etc.) or penetration testing in the past. Because static analysis detects flaws without actually executing the target application, there’s an increased likelihood of finding “noise” (insignificant flaws) or false positives. On the other hand, static analysis provides broader coverage, often detecting flaws in complex code paths that a web scan or human tester would be unlikely to find. So there’s your trade-off.
Here’s a conversation I have all too frequently, paraphrased:
DEVELOPER
I don’t think I should have to fix this SQL injection flaw unless you can prove to me that it’s exploitable.
ME
Static analysis isn’t performed against a running instance of the application. Not all flaws will be exploitable vulnerabilities, but some of them almost certainly are. Here, let me show you all of the code paths where untrusted user input enters the application and eventually gets used in the ad-hoc SQL query we’ve marked as a bug.
DEVELOPER
But what’s the URL that I can click on to exploit it?
ME
Static analysis is different from a penetration test. The output of our analysis is a code path, not a URL. URL construction cannot be derived solely from the application code, because it depends on outside factors such as how the web server and application server are configured. Moreover, we don’t have the necessary context of how this flaw fits into the business logic of the application. Maybe this functionality is only accessible by certain users when their accounts are in a particular status. It might take a couple hours working closely with a developer in a test environment to come up with the attack URL. It might take several more hours to write a script around that attack URL to mine the database. On the other hand, it would take about 10 minutes to replace that ad-hoc query with a parameterized prepared statement.
DEVELOPER
Well, if you can’t demonstrate the vulnerability, then it’s not real.
ME
Demonstrating a working exploit certainly proves a system is vulnerable. But the lack of a working exploit is hardly proof that it’s not vulnerable. You could spend the time to investigate every single flaw to figure out which ones are vulnerable, or you could fix them all in such a way that you’re guaranteed it won’t be vulnerable. In our opinion, the time is better spent on the latter.
DEVELOPER
[more defensiveness]
ME
[bangs head against wall]
Now imagine that conversation stretching out to 30 minutes or more. They could’ve fixed a half-dozen flaws already. And it’s not limited to SQL injection. For example, consider cross-site scripting (XSS):
DEVELOPER
I need you to prove that this XSS flaw is exploitable.
ME
How about just applying the proper output encoding so you know the untrusted input will be rendered safely by the browser?
Buffer overflows:
DEVELOPER
I need you to prove that this buffer overflow is exploitable.
ME
How about just using a bounded copy or putting in a length check, so you know the buffer won’t overflow?
By now you get the picture. Many developers want proof, to the extent that they’ll sacrifice efficiency to get it. If we are to improve software over the long haul, developers must learn to recognize situations where it takes less time to patch a bug than to argue about its exploitability. On a more positive note, from someone who talks to static analysis customers on a daily basis, the tide is starting to turn in the right direction. But it is still an uphill battle.
The size and scope of the RBS Worldpay ATM heist are unprecedented. The perpetrators stole $9M in a matter of hours from 2100 ATMs worldwide. An indictment was handed down on Nov 10, 2009. I am always on the lookout for indictments and trials related to computer crime because this is often the only time the details of the attacker’s techniques and victim’s vulnerabilities are released publically. For instance it wasn’t until an indictment was issued in the Heartland Payment Systems breach that we found out how the attackers breached the perimiter. In that case it was a SQL Injection flaw on an internet facing web application. What can we learn from the RBS Worldpay indictment?
The indictment states that the attackers were able to generate ATM cards and obtain the correct PIN codes to make a withdrawal. PIN codes, like most sensitive secrets, are stored in encrypted form. The indictment states that the attackers were able to reverse engineer the PIN codes. I take this to mean they didn’t sniff them on the network but figured out how to turn the stored encrypted PIN code back into the plain text PIN. If this is the case there is a huge vulnerability in the way banks are storing PINs. There are many different PIN storage algorithms out there and the older ones have weaknesses. As an example, here is a paper on attacking the algoritm used by IBM 3624s which many ATMs are based on. Like password hash storage in Windows, backwards compatibility with older encryption formats can be a grave weakness. I am hoping that the FBI or Secret Service has shared the details of this attack with all US banks.
We know to get to the encrypted PINs the attackers had to breach the perimeter of RBS Worldpay. The indictment states the attackers used a vulnerability in the RBS Worldpay computer network. This is about as vague as it gets. Was it a misconfigured firewall, a web application vulnerability, an unpatched server, or something else? This would be nice to know from an industry viewpoint because if RBS WorldPay isn’t dedicating enough resources to protect from a particular threat then other organizations likely aren’t also.
Finally some nice details. The indictment shows the SQL commands that were executed to manipulate the bank’s database to change limits on certain ATM cards and delete transaction data. It is not clear how the attackers are accessing the SQL server, whether it is a command-line on the server itself, another machine, or perhaps through SQL Injection. It is clear that it is game over once an attacker can modify your database tables.
I hope more details come to light so the industry can be educated from this attack and it isn’t simply a data breach datapoint.
Update:
Several people have asked me about PIN cracking. The papers talk about PIN cracking as an “insider attack”. The truth of the matter is once you breach the perimeter and are in the soft gooey center, for all intents and purposes, you are an insider.
It is well known that when several PIN block formats are available the security
of the whole system degrades to the security of the weakest PIN block
format. The attacks demonstrate that reformatting capability between different
PIN block formats allows an attacker to abuse weaknesses of both formats.
Therefore enabling reformatting is more dangerous than using the weakest format.
We have also shown that the ISO-1 format is extremely weak and thus
should be immediately removed from the list of allowed interchange transaction
formats.
Another interesting insight from the attacks described is that the offset and
the PVV values may reveal as much information as the PIN itself. One possible
remedy is treating the offset and the PVV as secret values.
The changes require worldwide modifications in ATMs, HSMs and other components
implementing the PIN processing API.
In addition to all implementation of this API, systems applying the EMV
standard ([7]) and using online (rather than off-line) PIN verification are also
vulnerable to the attacks.
PIN blocks are 64-bit strings that encode a PIN ready for encryption and secure
transmission in banking networks. These networks employ tamper proof hardware
security modules (HSMs) to perform sensitive cryptographic operations, such as
checking the correctness of a PIN typed by a customer. The use of these HSMs is
controlled by an API designed to enforce security. PIN block attacks are unanticipated
sequences of API commands which allow an attacker to determine the value
of a PIN in an encrypted PIN block. This paper describes a framework for formal
analysis of such attacks. Our analysis is probabilistic, and is automated using
constraint logic programming and probabilistic model checking.
The WASS Project which Veracode contributed data to shows some nice benefits to White box (static) over Black box (dynamic) for many serious vulnerability categories. White box overall detects a higher prevalence of many categories which we can extrapolate to having lower FN rates. Now the sample set of apps is not the same so this can only be used as a trend. Static is better than dynamic in 5 out of 7 categories: credential/session prediction, SQL Injection, Path Traversal, Insufficient Authorization, OS Commandeering. In one category, insufficient authorization, dynamic is better and in one category, brute force attack, my gut feel is this is within the margin of error given the different app samples.
I consider credential/session prediction flaws detected by white box to be typically hard to exploit even though it is a real flaw. White box (static) analysis reports this whenever non-cryptographically strong random number generators are used to generate session identifiers or resource IDs. Usually this means standard rand() is used. The SQL injection, path traversal, and OS commandeering are probably found better by static because these are a good sweet spot for static with its 100% code coverage. All that is required is good data flow modeling from web request to tainted function. In this case, database query, file I/O, or system/process calls. Black box not finding as much is likely do to much less coverage of code paths in the application.
Percent of vulnerabilities out of total number of vulnerabilities (% Vulns BlackBox & WhiteBox)
If we consider the prevalence of high risk level vulnerabilities in detailed web application analysis (P. 9) we’ll see that the most widespread is Credential/Session Prediction errors. SQL Injection, Path Traversal and implementation and configuration errors in authentication and authorization systems are also widespread.
Weld Pond and Cult of the Dead Cow to be Featured on Dateline NBC
9.30.1999
The lack of client side security for internet transactions poses a huge
security risk that online banks and others just seem to ignore. Tools such
as BO2K and even simpler keystroke loggers can cut through the
authentication used for “secure” web transactions to allow an attacker to
authenticate as the hapless consumer.
Dateline explores this problem on Sunday October 3rd at 7pm EST. Watch
Cult of the Dead Cow demonstrate the attack and Weld Pond from the
L0pht talk about whatis really going on.
It is shocking how little has fundementally changed in the way consumers perform high value banking transactions over the web. Looking back with 10 years hindsight I have a slightly different way of describing the situation. Banks assume the network is compromised so they use end to end encryption. Banks don’t assume the endpoint is compromised so there is no security protection. In 2009 what is more likely, that your upstream is compromised or the endpoint is compromised? I would say for the average internet user the endpoint is more likely to be compromised.
Has the endpoint water slowly come to a boil and we are happy frogs slowly getting cooked?
