January 3rd, 2014

Snapchat Snafu!

Snapchat Logo

When the folks at Snapchat recently turned down an acquisition offer of three billion dollars, I have to admit I was shocked by their incredibly high estimation of their own importance. After all, half of their “secret sauce” is an easily-reproducible photo sharing app; the other half is the fact that their users’ parents haven’t discovered it yet. I’ll admit a bit of jealousy and the fact that my age starting with “3” makes me demographically incapable of understanding the app’s appeal. However, what I do understand is that a frightening disregard for API security might have jeopardized the entire company’s value. Loss of user trust is a fate worse than being co-opted by grandparents sharing cat pictures.

While Snapchat does not expose its API publicly, this API can easily be reverse engineered, documented and exploited. Such exploits were recently published by three students at Gibson Security and used by at least one hacker organization that collected the usernames and phone numbers of 4.6 million Snapchat users. Worse, the company has been aware of these weaknesses since August and has taken only cursory measures to curtail malicious activity.

Before we talk about what went wrong, let me first state that the actual security employed by Snapchat could be worse. Some basic security requirements have clearly been considered and simple measures such as SSL, token hashing and elementary encryption have been used to protect against the laziest of hackers. However, this security posture is incomplete at best and irresponsible at worst because it provides a veneer of safety while still exposing user data to major breaches.

There are a few obvious problems with the security on Snapchat’s API. Its “find friends” operation allows unlimited bulk calls tying phone numbers to account information; when combined with a simple number sequencer, every possible phone number can be looked up and compromised. Snapchat’s account registration can also be called in bulk, presenting the opportunity for user fraud, spam etc. And finally, the encryption that Snapchat uses for the most personal information it processes – your pictures – is weak enough to be called obfuscation rather than true encryption, especially since its shared secret key was hard-coded as a simple string constant in the app itself.

These vulnerabilities could be minimized or eliminated with some incredibly basic API Management functionality: rate limiting, better encryption, more dynamic hashing mechanisms etc. However, APIs are always going to be a potential attack vector and you can’t just focus on weaknesses discovered and reported by white hat hackers. No security – especially reactive (instead of proactive) security – is foolproof but your customer’s personal data should be sacrosanct. You need the ability to protect this personally-identifiable information, to detect when someone is trying to access or “exfiltrate” that data and to enable developers to write standards-based application code in order to implement the required security without undermining it at the same time. You need a comprehensive end-to-end solution that can protect both the edge and the data itself – and which has the intelligence to guard against unanticipated misuse.

While our enterprise customers often look to the startup world for lessons on what to do around developer experience and dynamic development, these environments sometimes also provide lessons in what not to do when it comes to security. The exploits in question happened to divulge only user telephone and username data but large-scale breaches of Snapchat images might not be far behind. When talking about an API exposed by an enterprise or governmental agency, the affected data might be detailed financial information, personal health records or classified intelligence information. The potential loss of Snapchat’s $3 billion payday is serious to its founders but lax enterprise API security could be worse for everyone else.

CA’s line of API security products – centered around the Layer 7 API Management & Security Suite for runtime enforcement of identity management, data protection, threat prevention and access control policies – can help you confidently expose enterprise-class APIs to enable your business while preventing the type of breach experienced by Snapchat, among others.

November 5th, 2013

Thoughts on Trends in IoT & Mobile Security

Written by
 

IoT and Mobile SecurityRecently, I read an article about predicted growth in the Internet of Things (IoT). Extrapolating a previous estimation from Cisco, Morgan Stanley is predicting there will be 75 billion connected devices by 2020. This sort of math exercise is entertaining and has a real “wow” factor but the real question here is: What does this mean for consumers and enterprises?

In recent years, consumer electronics manufactures have started to see the usefulness of building Internet connectivity into their appliances. This enables the post-sales delivery of service upgrades and enhanced features. It also allows mobile apps to control home appliances remotely. This is nothing radical per se, a decade ago I observed a sauna in the Nokia Research Center’s lab being controlled by voice and WML. But this was still a simple one-off integration. As the number of device form factors increases, the complexity of integrating devices grows. The term “anytime, anywhere computing” is usually used to describe this scenario but it isn’t entirely adequate. As a consumer I don’t only want device-independent access to a service – I want the various devices and appliances to work with each other so that smarter interactions can be achieved.

Today, we already see a plethora of connected devices with more-or-less crude connectivity and integration options. Smartphones can sync and connect with tablets, TVs and laptops. Mostly, these are very basic integrations, such as your various devices “knowing” about the last page you read in an eBook, regardless of which device you used. But the number and complexity of these integrations will increase greatly in the coming years.

The Coming Age of Connectivity
One of the main reasons the iPhone revolutionized mobile computing was Apple’s focus on user experience. Since then, mobile vendors have battled to see who could provide the best experience within the device. The next battle will be over cross-device experiences within the broader ecosystem, as users roam from device to device. And in the battle, the big players will keep adding their own proprietary components (software and hardware). The sheer size of these ecosystems will make the opportunity large enough to attract even more mindshare. If you make money – who cares about proprietary protocols and connectors?

But how does this relate to IoT, you may ask – isn’t this just a subset of IoT’s promise? The answer is “yes” but that is how this revolution will work – closer to an evolution where the consumer-driven use cases will be implemented first. Yes, there are other enterprise use cases and we can see many protocols and frameworks that claim to address these requirements. In the end though, I believe most of these platforms will struggle with developer uptake as most of the developer mindshare is found in the big mobile ecosystems. As with mobile, the successful approaches will be the platforms that can offer developers familiar tools and a roadmap to revenue.

It’s clear the big players in mobile, like Samsung and Apple, see a huge opportunity in connected devices. As we move on, we will see more devices get included in each of the mobile ecosystems’ spheres. Increased integration between mobile devices and cars is already in the works. Similarly, among the many notable events at last week’s Samsung DevCon (an excellent show, by the way), several SDKs were launched with the aim of solving specific consumer needs around media consumption in the home. But the impact of increasing connectivity will go beyond these relatively well-understood use cases to encompass home automation, smart grid, healthcare and much more.

Alternative Authentication Methods for the Connected World
In this multi-device, multi-service world, conventional username/password login methods will not be convenient. Advances in the biometric space (such as Nymi or Apple Touch ID) will be relevant here. I suspect that, just as we have seen a bring-your-own-device trend grow in enterprise mobile, we will see a bring-your-own-authentication paradigm develop. As a larger set of authentication methods develops in the consumer space, enterprise IT systems will need to support these methods and often be required to adopt a multi-layered approach.

Ensuring Big Data Privacy in the Age of IoT
Another set of challenges will be created by the enormous amounts of data generated by IoT. Increasingly, connected devices are able to collect and transmit contextual data on users. This information can be highly useful for vendors and users alike. But what happens if data is used for purposes other than those first intended or agreed to? Who owns the raw data and the generated insights? And how is the rightful owner in control of this? Today, there is no general standard available nor are the mobile ecosystems providing adequate privacy protection. Sometimes one gets the feeling that users don’t care but they will probably start caring if and when data leakage starts to make an impact on their wallets.

Meanwhile, Layer 7 will continue to innovate and work on solutions that address the challenges created by IoT, multi-device authentication and Big Data. Oh and by the way, I believe Morgan Stanley underestimated the number, I think it will be double that. You heard it here first…

September 26th, 2013

Common OAuth Security Mistakes & Threat Mitigations

OAuth SecurityI just found out we had record attendance for Wednesday’s API Tech Talk. Clearly, there’s an appetite for the topic of OAuth risk mitigation.

With our digital lives scattered across so many services, there is great value in technology that lets us control how these service providers interact on our behalf. For providers, making sure this happens in a secure way is critical. Recent hacks associated with improperly-secured OAuth implementations show that OAuth-related security risks need be taken seriously.

When in doubt, take a second look at the security considerations of the spec. There is also useful information in RFC6819 – OAuth 2.0 Treat Model & Security Considerations.

The Obvious Stuff
Let’s get a few obvious things out of the way:

  1. Use SSL (HTTPS)
  2. Shared secrets are confidential (if you can’t hide it, it doesn’t count as a secret)
  3. Sanitize all inputs
  4. Limit session lifespan
  5. Limit scope associated with sessions

None of these are specific to OAuth. They apply to just about any scheme involving sessions and secrets. For example, form login and cookie-based sessions in Web applications.

OAuth’s Main Attack Vector
Some of the grant types defined by the OAuth protocol involve the end-user being redirected from an application to a service provider’s authorization server where the user is authenticated and expresses consent for the application to call the service provider’s API on its behalf. Once this is done, the user is redirected back to the client application at a callback address provided by the client application at the beginning of the handshake. In the implicit grant type, the redirection back to the application includes the resulting access token issued by the OAuth provider.

OAuth’s main attack vector involves a malicious application pretending to be a legitimate application. When such an attacker attaches its own address as the callback for the authorization server, the user is redirected back to the malicious application instead of the legitimate one. As a result, the malicious application is now in possession of the token that was intended for a legitimate application. This attacking application can now call the API on behalf of the user and wreak havoc.

OAuth 101: Callback Address Validation
The most obvious defense against this type of attack is for the service provider to require that legitimate client applications register their callback addresses. This registration step is essential as it forms the basis of a user being able to assess which application it is granting to act on its behalf. At runtime, the OAuth authorization server compares these registered values against the callback address provided at the beginning of the handshake (redirect_uri parameter). Under no circumstance should an OAuth authorization server ever redirect a user (along with an access token) to an unregistered callback address. The enforcement of these values is a fundamental precaution that should be engrained in any OAuth implementation. Any loophole exploiting a failure to implement such a validation is simply inexcusable.

redirect_uri.startsWith(registered_value) => Not good enough!
Some application developers append client-side state at the end of runtime redirection addresses. To accommodate this, an OAuth provider may be tempted to merely validate that a runtime redirection address starts with the registered value. This is not good enough. An attacker may exploit this by adding a suffix to a redirection address – for example, to point to another domain name. Strict redirection URI trumps anything else, always. See http://tools.ietf.org/html/rfc6819#section-5.2.3.5.

Dealing with Public (Not Confidential) Clients
If you are using the authorization code grant type instead of implicit, a phishing attack yields an authorization code, not the actual access token. Although this is technically more secure, the authorization code is information that could be combined with another vulnerability to be exploited – specifically, another vulnerability caused by improperly securing a shared secret needed to complete the code handshake in the first place.

The difference between the implicit and authorization code grant types is that one deals with public clients and the other deals with confidential ones. Some may be tempted to rely on authorization code rather than implicit in order to add security to their handshakes. If you expose APIs that are meant to be consumed by public clients (such as a mobile app or a JavaScript-based invocation), forcing the application developer to use a shared secret will only lead to these shared secrets being compromised because they cannot be effectively kept confidential on a public platform. It is better to be prepared to deal with public clients and provide handshake patterns that make them secure, rather than obfuscate secrets into public apps and cross your fingers they don’t end up being reverse-engineered.

Remembering Past Consent Increases Risk
Imagine a handshake where a user is redirected to an authorization server (e.g. implicit grant). Imagine this handshake happening for the second or third time. Because the user has an existing session with the service provider, with which the authorization server is associated (via a cookie), the authentication step is not required and is skipped. Some authorization server implementations also choose to “remember” the initial expression of consent and will not prompt the user to express consent again – all in the name of better user experience. The result is that the user is immediately redirected back to the client application without interaction. This typically happens quickly and the user is not even aware that a handshake has just happened.

An “invisible” handshake of this kind may lead to improved user experience in some situations but this also increases the effectiveness of a phishing attack. If the authorization server does not choose to implement this kind of handshake and instead prompts the user to express consent again, the user is now aware that a handshake is at play. Because the user does not expect this action, this “pause” provides an opportunity for the user to question the action which led to this prompt in the first place and helps the user in recognizing that something “phishy” is in progress.

Although bypassing the authentication step provides an improvement in user experience, bypassing consent and allowing redirection handshakes without displaying anything that allows a user to abort the handshake is dangerous and the resulting UX gain is minimal (just skipping an “OK” button).

September 19th, 2013

Did Apple Just Kill the Password?

Written by
 

Password KillerOn the surface, Apple’s recent iPhone 5S announcement seemed just that: all surface, no substance. But as many reviewers have pointed out, the true star of the new model may not be its shimmering gold sheen but instead the finger sensor built into its home button.

Using a fingerprint to prove you are who you claim to be is not new. But building it into a phone is. And as your mobile phone becomes your carrier of content (like photos), currency (like digital wallet) and identity (like keychain) as well as your route to all manner of digital services, proving who you are will become essential for mobile everything.

Before mobile, Web security rooted itself in the username/password paradigm. Your username and password defined the identity you used to authenticate yourself to PayPal, Amazon, Google, Facebook and everything in between. There are stronger ways to secure access to Web sites but written passwords predominate because they are personal and easy to type on a PC, where all Web pursuits took place – until the arrival of the smartphone, that is.

The smartphone and its similarly keyboard-deprived cousin, the tablet, increasingly represent the jumping off point for the Internet. Sometimes, it may start with a browser. Many times it begins with an app. In either case, passwords are no fun when you move to a mobile device. They are cumbersome to type and annoying when you have to type them repeatedly across multiple sites, services and apps. So, anything that diminishes the burden of typing passwords on a mobile device is a good thing.

Apple is not alone in identifying that end users want ways to eliminate passwords on mobile. Our company, CA Technologies, has a sizeable franchise in Single Sign-On (SSO) and strong authentication technologies, which – when applied to mobile – can significantly reduce the burden of recalling multiple passwords across different sites, apps and services. In fact, CA Layer 7 hosted a webinar on this very topic this morning. But what Apple has achieved is significant because it substitutes a highly-personalized biometric for a password. This has the power to streamline mobile commerce, mobile payments and every other kind of mobile-centered interaction or transaction.

Many commentators have rightfully pointed out that biometrics do not offer a panacea. If your fingerprint gets hacked, for instance, it’s hacked permanently. But there are easy ways of augmenting biometrics to make them stronger. Biometrics can be combined with over-the-air tokens like one-time password or supplemented with context-aware server-side challenges that increase their requirements based on risk. But it’s what they achieve when compared with the alternative that makes fingerprint readers so powerful.

The 5S simplifies authentication for the average user, which encourages security use and acceptance. It also eliminates bad mobile habits like using short, easily memorable, easy-to-type passwords that scream insecurity. Apple is not the first vendor to realize consumers don’t like passwords on mobile devices. But by bringing an alternative to the mass market, it is helping to draw attention to the need and the opportunity: killing the password may open mobile to a whole host of novel security-dependent Internet services.

August 26th, 2013

Layer 7 Mobile Access Gateway 2.0

Mobile Access Gateway 2.0Today, Layer 7 introduced version 2.0 of the Mobile Access Gateway, the company’s top-of-the-line API Gateway. The Mobile Access Gateway is designed to help enterprises solve the critical mobile-specific identity, security, adaptation, optimization and integration challenges they face while developing mobile apps or opening APIs to app developers. In the new version, we have added enhancements for implementing Single Sign-On (SSO) to native enterprise apps via a Mobile SDK for Android and iOS.

Too many times, we have seen the effect of bad security practices. My colleague Matt McLarty eloquently discusses the gulf between developers on one hand and enterprise security teams on the other in this Wired article on Tumblr’s security woes. Because these two groups have different objectives, it becomes hard to get a common understanding of how you can secure the enterprise while enabling app developers to build new productivity-enhancing apps. While nobody really wants to be the fall guy who lets a flaw take down a business, we can be sure Tumblr isn’t the last stumble we are going to see.

To prevent you being the next Stumblr, we have taken a closer look at the technologies and practices for authentication of users and apps. No one of these seemed to be adequate alone and – while acknowledging the value of leveraging existing technologies –  we realized that a new approach was needed.

For mobile app security, there are three important entities that need to be addressed: users, apps and devices. Devices are the focus of the MDM solutions many enterprises are adopting and although these solutions are good at securing data at rest they fail to address the other two entities adequately.

Because today’s enterprise apps use APIs to consume data and application functionality that is located behind the company firewall or in the cloud, API security is vital to the success of any enterprise-level Mobile Access program. Therefore, APIs must be adequately secured and access to API-based resources must be controlled via fine-grained policies that can be implemented at the user, app or device level. To achieve this, the organization must be able to deal with all three entities.

Based on this, we have proposed a new protocol that leverages existing technologies. We leverage PKI for identifying devices through certificates, OAuth 2.0 is used to grant apps access tokens and finally OpenID Connect is used to grant user tokens. This new approach, described in our white paper Identity in Mobile Security,  provides SSO for native apps and makes sure the handshake is done with a purpose – to set up mutual SSL for secure API consumption.

Furthermore, this framework is adaptable to changing requirements because new modules can replace or add to existing protocols. For example, when an organization has used an MDM solution to provision devices, the protocol could leverage this instead of generating new certificates. Equally, in some high-security environments, the protocol should be able to leverage certificates embedded in third-party hardware.

To simplify the job for app developers, the Mobile Access Gateway now ships with a Mobile SDK featuring libraries that implement the client side of the handshake. The developer will only have to call a single API on the device with a URL path for the resource as its parameter. If the device is not yet registered or there are no valid tokens, the client will do the necessary handshake to get these artifacts in place. This way, app developers can leverage cryptographic security in an easy-to-use manner, giving users and security architects peace of mind.