More recently (in March), App Store review teams began to reject applications that used this method. Although you’re free to use it during development and in applications distributed using ad-hoc or in-house distribution (e.g. pushed from a Mobile Device Management server), this call is no longer allowed in the App Store. There is now no way for applications to retrieve an ID that is both globally available to all applications and guaranteed to be unique across all iOS devices. (The MAC address of the primary wireless device comes close, but isn’t guaranteed; see below). Undoubtedly this made some privacy advocates and device users happy, as there will no longer be an immutable key for application publishers and mobile ad/analytics networks to track. However, those unique-ID users promptly went to work in creating replacement ID schemes that they could use to track a device across multiple, not-necessarily-related applications. This is a gap that needed to be filled quickly for many businesses in the mobile space; if you’re interested in the details of how these IDs are used, a good writeup of one use case recently appeared in this post on the MoPub blog. The short version: they use(d) UDIDs to correlate new application installations or in-app purchases with previous ad clicks. This is worth pointing out, because it’s at the heart of their business, and other companies like it: the need to track devices in a persistent way did not disappear along with the API call.

This post is about ongoing developments in the device-wide ID space, with a special focus on two dueling schemes and codebases that have gained users and attention: OpenUDID and SecureUDID. If you’re an iOS developer, this could (hopefully) serve as a quick introduction to the details of these systems, including their limitations and potential for information leakage.

Problem statement: The challenges of creating a new unique ID

Developing an alternative to the UDID isn’t as straightforward as it might seem to someone unfamiliar with modern mobile-app environments. Although there’s anecdotal evidence that some ad networks are moving towards fingerprinting/time-correlation/IP collection techniques to track events, others are merely choosing a new scheme to generate an ID and using their existing backend infrastructure. We can place these new schemes into two general categories: those that try to derive an ID value from unique data that is already globally accessible on the device; and those that generate a new ID and publish it to other applications using a particular scheme-specific storage protocol.

The former approach was a natural leap for developers. Article comments, blog posts, and Stack Overflow answer suggested forms of this soon after the uniqueIdentifier deprecation. In fact, the ODIN working group’s approach is quite simple: it is merely a SHA-1 hash of the raw MAC address of en0, which is present on every iDevice. (Specfically, their ID is the uppercase-hex-string format of the SHA1 hash. See http://code.google.com/p/odinmobile/source/browse/Sample%20Code/iOS/trunk/ODIN.m.) Others SHA1 over a message containing the MAC address and an app-specific ID — generally the application’s bundle ID. Here’s an example of that approach. These solutions, while clever, often do a poor job of protecting the MAC itself; if an attacker can capture MAC addresses from a network on which mobile devices are joined, he or she can correlate those with UDIDs stored and saved elsewhere. Even if the schemes involved hashes more computationally expensive than a single round of SHA1, the space for a dictionary attack against all Apple OUI prefixes is quite small. The current OUI list, as of 4/25/2012, includes 147 prefixes assigned to “Apple Inc” or “Apple Computer” (or some variation thereof). Each of those allows for a maximum of 2^24 = 16777216 MAC addresses, or ~2.47 * 10^9 addresses overall. Furthermore, this scheme doesn’t afford users control over their IDs — the ability to reset them entirely, as is possible with cookies, browser local storage, and Flash cookies. (As research like Evercookie shows, battling persistent fingerprinting on a mobile device is child’s play compared to trying to stop a modern desktop browser from being tracked by a determined attacker/ad network with sufficient reach.)

The second approach that UDID replacement schemes use — generating an ID and publishing it to other applications — isn’t perfect either. These schemes work like this:

1. Look for an ID published by any other application. If one exists, use it.
2. Otherwise, generate a new ID. Publish the new ID, then use it.
3. (optional) Cache the ID being used to app-local storage (filesystem, NSUserDefaults, keychain, etc.)

All that’s left to work out is the publishing mechanism. Effective sandboxing allows for very few reliable ways for iOS applications to exchange data on a device, particularly when the applications aren’t running at the same time. The two primary supported mechanisms for persistent, bidirectional information exchange that don’t involve external services are keychain items and the pasteboard. The kSecAttrAccessGroup keychain query option requires applications to share a common publisher and application-ID prefix; because of this, keychain sharing isn’t a general solution for storing a global ID. Custom URL schemes, used by many applications as a go-to for unidirectional IPC, wouldn’t work here either — there’s no way to get data back from a call to UIApplication -openURL:.

All that’s left is custom pasteboards. On iOS, UIPasteboards are used not only for sharing cut-and-paste data between applications, but also as a general key-value store accessible by all applications. They’re even persistent across phone reboots, and the application that created a pasteboard doesn’t need to be running for it to be accessible to other applications on a device. However, when the application that created a UIPasteboard item is removed from a device, so is the pasteboard. Because users install and remove applications fairly regularly, using a single location to store your ID isn’t wise: as soon as the user deletes the application that created the ID, the pasteboard disappears. This means that schemes can’t use a single, global UIPasteboard to store their ID; they must diversify.

Before the examples, a quick note on the above. Although the documentation does say that pasteboards created by an application are to be removed on application uninstallation, we’ve failed to observe this after trying multiple applications on a real device. In all cases, a UIPasteboard marked as persistent persists even after its creator is removed and a system reboot occurs (iPhone 4S, iOS 5.0.1). If you’re an iOS developer, keep this in mind. It looks like we’re not the only ones to observe this, either. And in any case, UIPasteboard entries are globally mutable, with exceptions for the special system pasteboards. Any other application may read, write, or remove any other entry at will.

Now, let’s take a look at some real-world examples.

OpenUDID (https://github.com/ylechelle/OpenUDID)

OpenUDID is designed as a drop-in replacement for UIDevice -uniqueIdentifier — a small API that provides a device-wide unique ID, that is shared across all applications that use the OpenUDID scheme. OpenUDID uses a 160-bit ID. The first 128 bits are the result of a single round of MD5 on the return value of NSProcessInfo -globallyUniqueString, which is derived from the device’s hostname (typically based off of the owner’s name), the pid of the running app, and a timestamp (docs here). The latter 32 bits are the output of arc4random(). Like the original UDID, this is retrieved by the OpenUDID API as an NSString in lowercase-hex format.

OpenUDID’s persistence is achieved using the UIPasteboard, as discussed above. To ensure persistence past application removal, OpenUDID doesn’t use a single custom pasteboard item, but many custom pasteboard items — 100, to be exact — named “org.OpenUDID.slot.N”, where N is [0, 99]. Each application that uses OpenUDID chooses one of these “slots” (saving its choice locally in NSUserDefaults), and saves a copy of its idea of the current OpenUDID inside it. These slots are all public, so if there’s no cached OpenUDID, the code goes through all 100 slots and chooses the UDID that is represented most frequently. If and only if all slots are empty (or corrupted), a new OpenUDID is generated by the scheme listed above.

OpenUDID’s optout functionality works by setting a value in the NSDictionary stored inside the pasteboard slot for a given application. This value is not propagated from other applications’ slots, like the UDID is. For this reason, there’s no global opt-out functionality respected by OpenUDID. However, since UIPasteboard objects are mutable, and the data in the slots are unencrypted, it’s possible for another application to rewrite all populated UIPasteboard slots with values that include opt-out functionality.

SecureUDID (http://secureudid.com)

SecureUDID’s design goals are a bit different from OpenUDID and the original UIDevice UDID. Instead of providing a common ID shared across all applications, SecureUDID shares an ID across multiple applications that share a secret. The ID is encrypted using the secret as the key; the secret is then embedded in the binary, and ostensibly shared across all other users of your ID. This is intended to limit the spread of tracking applications to those authorized by a specific subset of SecureUDID users.

Persistence: Like OpenUDID, SecureUDID uses UIPasteboard “slots” (64 of them) to store copies of an ID along with some metadata. Unlike OpenUDID, it doesn’t claim one slot per application — instead, it’s one application per secret. This potentially has implications for persistence: if the application that created the UIPasteboard entry is removed, the UIPasteboard documentation says that the slot will be removed as well. (As noted above, in practice this doesn’t happen, but it might in the future.)

SecureUDID’s IDs are generated by CFUUIDCreate() which results in a 128-bit value that is derived from hardware values (including, likely, the MAC address, according to the documentation) but guaranteed to be unique. It also features opt-out functionality, but SecureUDID honors opt-out flags from all other SecureUDID slots, even those which aren’t using an ID encrypted with the (domain,key) pair used by the checking application. For users, this means that if you opt out of SecureUDID in one location, this will propagate to other applications that use SecureUDID as well.

SecureUDID’s secret (the crypto key) is a SHA1 hash of the concatenation of two values, both passed to SecureUDID’s +UDIDForDomain:usingKey: method. Although the documentation implies that one of these is intended to be public knowledge (bundle ID) and the other is a private key, the effective secrecy of these values is identical if they’re both embedded in the binary. If this is the case, then they are visible to anyone with a copy of the application’s binary or a running device. As such, there are no technical barriers preventing unauthorized applications from using these secrets to decrypt and read SecureUDIDs created by from existing, published applications.

Another interesting feature of SecureUDID is that its pasteboard slots (“org.secureudid-N”, where N is [0, 63]) store an unencrypted NSDate value that contains the last time a given key was accessed. All applications that use a given SecureUDID secret update this value; it’s used to evict an existing UIPasteboard slots when all 64 are full. Since this value is global, it means that unscrupulous developers could write applications that can use this value to nefarious purposes — effectively getting information on how often applications that share a common secret are used– even without knowing the key or decrypting the SecureUDID.

End

It’s worth pointing out that these schemes are still very much in development. In particular, opt-out functionality is still being ironed out, particularly with respect to UI options. Even though versions of these schemes are in shipping code today, this may change in the future. However, the fundamental challenges remain, as will analytics/advertising networks’ need for tracking.

Still, it’s difficult to say whether there’s any net change here. Although an easy-to-use (and much-berated) unique ID mechanism is now gone, some companies’ need to track users across multiple applications has not changed. It’s relatively easy for ad or analytics networks to get their users to incorporate new schemes like those dissected here — in fact, it’s standard operating procedure to hand users a bundle of code that’s fairly easy to integrate. Users can expect to see variations on these tracking schemes for the foreseeable future. Technical changes (such as Apple’s decision to remove the call) can only go so far without breaking much-desired features — at some point, the responsibility lies with individual application publishers to decide exactly what kind of tracking/identification technology they decide to use. These publishers are ultimately the ones that decide what goes in applications that people use, and how much control users have over their personal usage data. As for savvy users, they’re left with limited options: in some cases, learning about these schemes opens up avenues for interference (e.g. write an application that deletes or rewrites all tracking-related UIPasteboard items); in others, the only option is to either accept some amount of usage tracking or not use certain applications at all.

81% of attacks utilized some sort of Hacking. Within hacking there is a stark difference between large and small organizations. SQL injection comes in 3rd after use of stolen login credentials and exploitation of backdoor or command and control channel. It is tied with dictionary attacks. This data shows large organizations have much more application security risk than small organizations.

Source: Verizon DBIR Report

SQL Injection comes in 8th overall for threat action when malware, physical, and social engineering are included.

Source: Verizon DBIR Report

This breakdown by larger organizations in this year’s DBIR helps highlight our target customer pain much better. 10% of all hacking breaches were web application related for all orgs but 54% for large organizations! How can a large organization not have a web application security program after seeing this data?

Source: Verizon DBIR Report

And finally SQL Injection makes the top list of risk reduction recommendations.

Our recommendations will be driven off of Table 8, which is in the Threat Action Overview section, and shows the top ten threat actions against larger organizations. Rather than repeat the whole list here, we’ll summarize the points we think represent the largest opportunities to reduce our collective exposure to loss:

• Keyloggers and the use of stolen credentials
• Backdoors and command control
• Tampering
• Pretexting
• Phishing
• Brute force
• SQL Injection

The slide to my presentation are here http://www.cs.tufts.edu/comp/116/lectures/static-binary-analysis-wysopal-tufts-comp-116.pdf

There does seem to be some mystery still to static binary analysis even though Veracode has been delivering this application security testing process to hundreds of customers with tens of thousands of applications for almost 5 years now. One of my goals in this presentation is to make it clear that there is nothing source code analysis can do that binary analysis can’t. Binary analysis even has benefits over source code analysis. It may seem counter-intuitive so you will want to see the presentation.

The students at Tufts asked about 20 questions after my presentation. They were the best questions I have ever gotten from a group. There were only a couple that I hadn’t fielded before but I had never had so much coverage of interesting questions that I had received before from one group. There was one I struggled with about our control flow optimization. I almost deferred to Sam Guyer, a Tufts professor who also works for Veracode who was in the audience but I think I answered it well enough. The question was apt as there is always a depth of analysis tradeoff when dealing with large programs.

It was a very pleasurable talk and I was impressed by the students at Tufts. I hope you go into app sec. We can use you!

Conference Presentations

• Chris Wysopal, Monday 9:30-10:20am. PANEL: National and International Security Standards — The Viability of Cross-Jurisdictional Solutions, (Cloud Security Alliance Summit), Gateway Room 102/103
• Chris Eng, Monday 2:00-3:10pm. Security Testing (SEM-002), Room 305
• Chris Eng, Monday 3:30-4:30pm. PANEL: Data Mining for Enterprise Security, (Mini-Metricon 6.5), SFSU @ 835 Market Street, Rooms 626-627
• Chris Wysopal, Wednesday 3:50-5:00pm. Defending Behind the Device: Mobile Application Risks (HT2-108), Room 104
• Tyler Shields, Thursday 8:00-9:10am. PANEL: Mobile Device Security: Is the Enterprise Up for the Challenge? (MBS-301), Room 305

Veracode Booth (#1853 in the Expo Hall)

• Chris Eng, Monday 6-8pm, Tuesday 11am-1pm, Wednesday 2-4pm
• Tyler Shields, Tuesday 11am-2pm, Wednesday 4-6pm
• Christien Rioux, Tuesday 1-4pm, Wednesday 11am-2pm, Thursday 1-3pm
• Chris Wysopal, Wednesday 11am-2pm

Booth Mini-Presentations

These are short 10-minute talks that we’ll be doing in the booth. Our product management and marketing teams will be doing short presentations too (complete schedule).

• Chris Eng, Monday 7pm. State of Software Security (Technical Findings)
• Tyler Shields, Tuesday 12pm. Mobile AppSec Threat Landscape
• Christien Rioux, Tuesday 2pm. Why Binary is Better
• Chris Wysopal, Wednesday 12pm. People and Apps are the New Perimeter (APT & Spearphising)
• Tyler Shields, Wednesday 4pm. Mobile AppSec Threat Landscape

Over the past week there have been a few big stories on iOS apps transmitting users’ address books as a convenience feature. Apple has even found themselves on the congressional hot seat this week about their device’s address book privacy. AllThingsD reports that Apple, faced with growing criticism that they have given iOS developers far too much access to private data without requiring a user prompt, has pledged that apps dumping address book data will soon require explicit user permission to do so.

Dieter Bohn at The Verge states the problem best: “Any iOS app has complete access to a large amount of data stored on your iPhone, including your address book and calendar. Any iOS app can, without asking for your permission, upload all of the information stored in your address book to its servers. From there, the app developer can either use it to help find your friends, store it in perpetuity, or do any number of other things with it.”

Introducing AdiOS

To find out how many of my iPhone apps were dumping the address book, I put together a utility called AdiOS (Addressbook Detector for iOS) that lets Mac users scan the iOS apps in your iTunes directory to see if they have the potential to dump your phone book externally. AdiOS detects apps that access your entire address book, by using a binary grep to look for use of the ABAddressBookCopyArrayOfAllPeople API call. AdiOS quickly and easily finds all the apps that have the potential to violate your privacy. It could also be used to see if your apps are complying with the new policies Apple is rolling out around protection of Address book information.

Using AdiOS to Audit Your Privacy

AdiOS allows Mac users to see what apps have potential privacy problems. Using AdiOS is easy. Just download AdiOS, unzip, double click on AdiOS.app, and let it run. If you have a few hundred apps, it’ll take a couple minutes to complete.

Output will look something like this:

What We Discovered

A few of us in Veracode just tested AdiOS on our own machines. Of the roughly 450 iOS apps on my Mac, 50 of them appear to call ABAddressBookCopyArrayOfAllPeople. That by itself doesn’t mean the app is transmitting any data, or doing so behind your back, but it does raise questions. Angry Birds does it. Citibank does it. Several Google apps do it. A number of lesser-known games do it, too. Why do all of these apps need to dump my entire address book? The quantity of apps with this ability really caught us off guard.

Most apps that have email functionality (e.g. “send this to a friend”) wouldn’t ever need to use ABAddressBookCopyArrayOfAllPeople. They could just use the standard view controller for contact info, the ABPeoplePickerNavigationController. If they wanted a custom UI for the picker, then they have no choice but to dump the address book.

In order to check whether the app is actually transmitting the address book information, you’d need to perform a full static analysis, or a manual test using a tool such as mitmproxy.

Don’t Panic!

Lots of apps access your whole contact list for legitimate reasons! Social networking apps do it so you can make connections. Maps/directions/GPS apps do it for convenient access to all of your friends’ addresses. Many games do it so that you can “share your highscores”, etc. But still, it’s interesting to see which apps have the potential to do what with your personal address book data.

Should We Really Be Surprised?

Talking to the Veracode Research team about this iOS address book madness, the consensus was that none of this should come to a surprise to anyone who’s been following mobile development or security research for mobile platforms.

At Veracode, we’ve already detected this issue in some of the mobile applications that we’ve scanned for our customers. More importantly, we can automatically determine if the app is actually transmitting the address book information once it has been retrieved. Obviously that requires much deeper analysis than this quick binary grep tool can provide! The deep static binary analysis service that we offer our customers uses data flow graphs to connect the output of ABAddressBookCopyArrayOfAllPeople with downstream network APIs in order to confirm a privacy leak.

Along with running AdiOS, consumers of mobile apps should ask their providers to perform binary static analysis on the apps they offer.

Excerpts in italics from Hackers Intercept FBI Call With U.K.

The Federal Bureau of Investigation said cybercriminals hacked into a cybercrime conference call between its agents and law enforcement officials overseas.

The 16-minute call was posted on the Internet on Friday. The hacker collective Anonymous claimed responsibility, though the FBI didn’t name the group and said a criminal investigation was under way.

As a security person I am not content to know what happened. I need to know how it happened. Without understanding the how, we can’t prevent it in the future. In reading the news stories it has become clear how this happened.

The FBI said the breach wasn’t made on the agency’s secure email or other computer systems. Instead it appeared to be result of a law enforcement officer overseas who was invited to be on the FBI call and who forwarded the information to his private email account, which was compromised by hackers.

Anonymous had been working to compromise the personal email accounts (gmail, yahoo, hotmail, etc) of federal agents from multiple countries. Personal accounts are MUCH easier to compromise than corporate/internal mail accounts:

• The authentication and password reset forms can be reached by any attacker over the internet
• There is typically no password strength enforcement
• Users reuse passwords and the password associated with this email account may have been compromised in another breach
• There are automated password reset mechanisms.

Anonymous successfully compromised at least one agent’s personal email account. When you have a large group as a target all you need is one weak account.

An international law enforcement conference call was scheduled to discuss the Anonymous investigation. A few dozen agents from 5 countries were sent meeting invitations over secure email channels to their internal official accounts. These invitations contained the dial in number and passcode to a conference bridge.

At least one of the agents forwarded the invitation to their personal email account. At least one of the agent’s personal email account had already been compromised by Anonymous. Now Anonymous had the conference bridge information. They dialed into the conference call. The agents running the call did not audit individuals joining the call. Anonymous was able to eavesdrop on the call and deal an embarrassing setback to the investigation.

There are a few lessons we can learn from this besides not forwarding confidential mail to personal email accounts. You need a strong password on personal email, and ideally use 2 factor authentication (like Google supports) if available. Make sure you are using the strongest password reset mechanism if there are multiple offered. Don’t use a secret question where the answer is public information or easily guesable. Paris Hilton used “What is the name of your dog?” on her T-Mobile account. Not a good choice. Finally, if sensitive information is discussed on a conference bridge, audit the people joining the call. There is a reason the service beeps when people join.

As you can see the attackers are crafty and unrelenting. You need to stick to secure operating procedures or you will be easily compromised.

What’s interesting to me about this breach is that Zappos is renowned for their customer service, so watching how they communicate in the coming days and weeks should be an interesting case study. A few notable points so far:

• Tony Hsieh, the CEO, posted a copy of the internal email that they had sent to all their employees. And tweeted about it. The only difference from the customer-facing email was that it stated the number of records affected. But it’s unusual for a company to share internal communication like this.
• Zappos expired everybody’s password, forcing customers to follow the password reset workflow before regaining access to their account. Usually a company will urge you to change your password but won’t force you to do so. This was a good move on their part. The servers seemed very overloaded though; around 9pm last night it took me a few minutes (and a couple of server timeouts) to successfully reset my password.
• Around the same time, Zappos disabled international access to their website, meaning that anybody outside the US couldn’t reset their password as instructed in the email. This seemed a bit odd. As I am writing this post, the site is still unavailable to international customers. This has understandably frustrated some customers.
• In the customer-facing email, Zappos notes that credit card numbers were not affected, but “cryptographically scrambled” passwords were. This is where I believe they ought to be more forthcoming. What does “cryptographically scrambled” entail? An unsalted MD5 hash, Stratfor style? Salted hashes? Symmetric encryption? A homegrown algorithm? Something stronger like bcrypt or scrypt? This detail is critical, because it indicates how easy it will be for attackers to recover the original passwords from the affected customers and try to use them on other sites like Gmail, Facebook, Twitter, and others. Customers might be more likely to change their password on other websites if they understood the relative risk.
• The email does not disclose how long customer data was exposed prior to the breach notification. This is an important detail that was omitted.
• Zappos has been actively engaging with customers on their @Zappos_Service Twitter account. In fact, last night when I posed a question to the CEO’s Twitter alias, @Zappos_Service responded 4 minutes later. They didn’t have an answer, but they responded.
• They turned off their phone system because they felt responding via email would be more efficient (and their phone system couldn’t handle the volume anyway). Still, can you imagine a “typical” company doing this? It seems simultaneously crazy and brilliant.
• It takes a long time to send 24+ million emails. I received mine last night at 8:34pm and 9:03pm, but a colleague here at Veracode mentioned he didn’t get his until this morning. So assuming they’re going out alphabetically by e-mail address, that’s how long it took to get from “c” to “r”.
• Since both Zappos.com and 6pm.com were affected, it’s possible that they shared a single database. There are a bunch of scenarios though. It could be a vulnerability in application code shared by both sites. It could have also been an insider attack, but the fact that credit card numbers were not compromised suggests to me that the attack was external.

For me, the two things to watch for now are how quickly they restore international access and whether or not they disclose how passwords were stored and what “cryptographically scrambled” means in that context. Security breaches happen to the best of companies and these days what differentiates you is how you respond. So far I believe Zappos is on the right track.

(Incidentally, Tony Hsieh’s book, Delivering Happiness, is a fantastic read. I have a lot of respect for how this company operates, and not just because my shoes arrive overnight.)

Veracode Security Guides

Data Security Resources

Just before the holidays, we detected a cross-site scripting (XSS) vulnerability while running a web application scan for one of our customers. Nothing special about that; we detect thousands of these things every week. But as we discussed this particular finding, we noticed that the layout of the website looked… familiar. As it turned out, the discussion forum where we found the XSS was a SaaS-based product called Lithium.

From Lithium’s website: “The world’s most innovative companies such as AT&T, Barnes & Noble, Best Buy, Sephora, Univision, Home Depot, and HP use Lithium to engage their customers in breathtaking new ways (literally, breathtaking).” Run this Google search and you’ll find a bunch of Fortune 500 companies using their software.

So now, instead of one XSS, we have hundreds. It’s not just our customer who is impacted. Suddenly it’s kind of a big deal.

Here’s how everything played out. We’ll do this timeline CORE Security style (all times EST).

• 2011-12-15 5:29 PM. We fire off a quick email to the address listed on Lithium’s Security page.
• 2011-12-15 6:12 PM. We receive a response from Misha Logvinov, Lithium’s CIO.
• 2011-12-15 6:23 PM. We encrypt and send over the vulnerability details to Lithium.
• 2011-12-15 11:40 PM. Lithium reports they have a patch ready to go and will update in the morning.
• 2011-12-16 2:30 PM. We do a little poking around and it seems the vulnerability is patched for some domains but not others. We email for a status check.
• 2011-12-16 2:37 PM. Lithium confirms that the patch is in the process of being rolled out and will be completed by close of business.
• 2011-12-16 COB-ish. We’re not seeing any more vulnerable instances.

Anybody who has reported vulnerabilities before can appreciate how unusual it is for a vendor to respond this quickly. Everything was accomplished in under 24 hours! That is practically unheard of.

From a “big picture” perspective, this whole situation illustrates some important application security themes:

• It’s a canonical example of software supply chain risk. A single XSS vulnerability simultaneously affected hundreds, maybe thousands of customers. No matter how securely these companies developed software internally, they were still exposed to vulnerabilities in third-party software.
• It emphasizes the ecosystem effect of vendor security assessments. One Lithium customer did an analysis of third-party code they were operating. A defect was found, and the vendor fixed it. Now all Lithium customers benefit, without having to lift a finger! Imagine if all companies assessed their third-party code and insisted on fixes from their suppliers.
• It shows that SaaS can have huge security benefits. Imagine if Lithium had been deployed as an on-premise product at each customer sites, requiring each customer to download and install a fix themselves. Some companies would probably never get around to patching their servers. The flip side is if the SaaS company dragged their feet — or simply refused — to patch the software, leaving the customer without a viable mitigation.
• It demonstrates that application security response can be done right. Lithium engaged quickly, took the vulnerability report seriously, and wasted no time in fixing the problem. It’s not uncommon for some vendors to take months.

Increasingly, we’re seeing our customers rethink how they vet the software they purchase or license from third-party suppliers. I hope success stories like these become commonplace as we start holding software suppliers — both SaaS and on-premise — accountable for security, not just functionality.

Veracode Security Guides

Data Security Resources

Backdoors in industrial control systems

These backdoor revelations in industrial control equipment are becoming frequent. Earlier this year Dillion Beresford found similar backdoor vulnerabilities in Siemens equipment.

We find these types vulnerabilities fairly often when we scan vendor code on behalf of our customers at Veracode. Our recent State of Software Security Report vol. 4 detailed the findings. We didn’t find these backdoors in internally developed, outsourced, or open source applications. We did find backdoors in 3% of software vendor developed code.

This chart above is the result of our static and dynamic analysis of thousands of different applications over the preceding 18 month period.

Vendors add this backdoor code because it lowers their support costs. Unfortunately it is at the expense of the customer’s risk. It is easier for a vendor support technician to remotely diagnose a problem if they know a “support” password to your system or if there is a debugging interface exposed to the network. No need to fly on site or communicate time consuming “remote hands” commands to a local IT employee.

We have seen an uptick in customers performing 3rd party scans on the software they are purchasing. A few years ago it was only our financial services customers that were concerned about backdoors and vulnerabilities in the code they were purchasing. Now we are seeing a much broader range of industry verticals.

The chart above shows we have 8 different industry types including: aerospace & defense and oil & gas, scanning 3rd party code. We are still not seeing industrial control equipment but with the news this year I think it is only a matter of time. 3rd party analysis will grow as operators of code continue the trend to hold vendors accountable.

Backdoor testing should always include static code scanning. How can you find a static password or cryptography key without it? Ideally this is done on the product binary. Vendors are loath to give up source code, even to a 3rd party, and even if they do they might not give you the exact source code or all of the source code. Binary scanning and backdoor testing go hand in hand so Veracode has done research on the subject of backdoor and implemented as much as was practical in our binary static analysis. For further reading on testing apps for backdoors see our “Static Detection of Application Backdoors” paper which was presented at Black Hat Las Vegas.