BUILDING SECURITY IN. Analyzing Mobile Single Sign-On Implementations

Transcription

1 BUILDING SECURITY IN Analyzing Mobile Single Sign-On Implementations

2 Analyzing Mobile Single Sign-On Implementations 1 Introduction Single sign-on, (SSO) is a common requirement for business-to-employee (B2E) application user authentication. As more and more organizations develop mobile applications for their employees, the need to leverage existing SSO technologies by mobile applications has arisen. This paper will focus on the architectures currently used for native mobile applications to leverage existing SSO infrastructures. These architectures cover three distinct use cases: a single identity provider, single shared identity provider session, and single sign-on with a manager. Each use case has unique characteristics and security concerns. For the purposes of this paper, SSO means an end-user authenticates once and that authentication is used by more than one application. For example, an enduser provides a valid username and password to one application and later when that end-user wants to use a second application, the second application does not force the end-user to re-enter his/her username and password. Using this strict definition, the first use case, Single Identity, is not SSO. It lets an end-user use the username and password for two applications, but not the authentication. At first glance, this approach seems undesirable as our applications are not realizing single sign-on; however, merely sharing identity may be the most desirable approach from a security and usability prospective. 2 Use Case One: Single Identity One of the predominant methods for mobile SSO integration is to authenticate end-users in each application using their enterprise username and password. As this technique has frequently been referred to as mobile SSO and is used in many application environments, it is included in this discussion. However, because the end-user must authenticate separately in each application, this architecture is properly called single identity provider, rather than single signon. The distinction is each application authenticates with the identity provider separately rather than sharing a single authentication decision. This approach provides several benefits to both security and even the end-user s experience. For an end-user, this approach gives up the convenience of a not having to reenter their username and password, but replaces it with consistent behavior across applications. End-users will know they are granting access to their data when they start an application and know the access is terminated when the application terminates. From a security perspective, true SSO use cases cannot securely share the authentication token on the mobile device. Analyzing Mobile Single Sign-On Implementations 2

3 2.1 Examining the Control Flow in a Threat Model Figure 1: Single Identity Threat Model T : SSO Token : User Credentials : Protected Resource T T : SSO Token : User Credentials : Protected Resource : Process Separation : File System Sandbox : Certificate Pinning C04 : SSL : SSO Token App One App Two : Process Separation : File System Sandbox : Certificate Pinning C04 : Application Whitelisting : SSL : SSO Token T : Malicious App T : Malicious App with Root Access T : Unauthorized Physical User TZ - 01: Mobile Device TZ - 02: App One Sandbox C04 C04 C04 C04 TA04 TZ - 03: App One Sandbox TA05 T : Malicious App T : Malicious App with Root Access T : Unauthorized Physical User C0 TZ - 01: Mobile Dev App One Web SSO Identity App Two Web App One W Service TZ - 04: Organizational Domain TZ - 04: Organizatio First examine the parts of the threat model present in all mobile SSO threat models. There are three main assets, which are parts of the system Figure 1 that need to be protected. The first asset is the SSO token,. The SSO token represents the authentication decision. Applications use the SSO token to authenticate to individual service providers. The second asset is a user s credentials,, which are only exposed to the identity provider s web page and backend. The last identified set of assets is the protected resources the service providers require user authentication to deliver,. There are five main controls, which are protections for the identified assets. The first identified control is process separation,. Operating systems implement this control to prevent running processes from accessing the memory space of other processes. The second common control is the file system sandbox,. All mobile operating systems have a form of sandboxing, which prevents applications from directly accessing other applications files. The third control present in all of our use cases is certificate pinning,. In certificate pinning, a client application verifies the server s certificate against a hard coded value. The final control is SSL, C04, which protects the assets in transit. There are five identified threat agents with a goal to compromise the identified assets. The first threat agent is a malicious app installed on the mobile device, T. The second threat agent, a malicious app with root access, is identical to the first threat agent except this application has root access on the device, T. The third threat agent is an attacker with physical access to the device (Unauthorized Physical User), T. For the purpose of this paper, the attacker is assumed to have access to the phone past the lock screen. The fourth threat agent is an attacker on a local or adjacent network (Unauthorized Network User), TA04. The final threat agent is a compromised service provider inside of the organization domain, TA05. Analyzing Mobile Single Sign-On Implementations 3

4 2.2 Concerns in a Single Identity System With the assets, threats, and controls enumerated in the previous section, one can use the threat model to generate possible attack scenarios. One attack malicious apps will attempt is to gain access to the user s SSO token and user credentials. If the client applications store this information to disk, the operating system will attempt to protect them via sandboxing. Malicious apps with root access will still be able to view these files, bypassing the file system sandbox control. Additionally with root access, a malicious app can still access the memory space of these applications, obtaining any information that has not been cleared from memory and bypassing the process separation control. A particularly dangerous attack scenario is an attacker with physical access to the device compromising the security of the application. With access to the device, an attacker would be able to view any file stored on the device. While there is no perfect solution to securing sensitive information on mobile devices where applications and users have root access, some basic steps should be taken: a. Never store user credentials to disk. b. Once an end-user has authenticated to the application, clear the user credentials from memory. c. Do not store SSO tokens to disk. Maintain SSO tokens inside of memory. The last two threat agents to address are unauthorized network users and compromised service providers. Both of these actors sit outside of the mobile device and only communicate with the device via the network interface. In most situations, these threat agents will not generate requests to the device, instead they rely on the device placing certain calls, listening, and reacting. The biggest concern from a network attacker is man in the middle attacks. To combat a majority of these attacks, systems should use web application best practices such as enforcing strict SSL. The final threat agent is a compromised service provider. If an attacker is able to compromise a service provider, users may unknowingly give this service provider their SSO token. In order to prevent network attackers and compromised service providers from impersonating application services, mobile applications should enforce certificate pinning. 3 Use Case Two: Single Shared Identity Session Another scenario to consider is broadcast native SSO, in which applications share an identity provider session bypassing the SSO token amongst themselves. In order to obtain the authentication decision, each application asks all other applications using the same identity provider if they have an SSO token from the identity provider. If no applications have established an SSO token, then the requesting application will connect to the identity provider and ask the identity provider to authenticate the user s username and password. When a second application needs an SSO token, the application will call out to the same set of applications requesting an SSO token. Since the first application has a token, the first application will send the SSO token. Unlike the previous use case, this is true SSO because the end-user does not need to enter their credentials a second time. Analyzing Mobile Single Sign-On Implementations 4

5 3.1 Examining the Control Flow in a Threat Model Figure 2: Broadcast Native SSO Threat Model T T : SSO Token : User Credentials : Protected Resource T T T : SSO Token : User Credentials : Protected Resource : Process Separation : File System Sandbox : Certificate Pinning C04 : Application Whitelisting : SSL : SSO Token App One IPC C04 App Two : Process Isolation : File System Sandbox : Certificate Pinning C04 : Application Whitelisting : SSL : SSO Token App Clie T : Malicious App T : Malicious App with Root Access T : Unauthorized Physical User TZ - 01: Mobile Device TZ - 02: App One Sandbox TA04 TZ - 03: App One Sandbox TA05 T : Malicious App T : Malicious App with Root Access T : Unauthorized Physical User TZ - 02: App On TZ - 01: Mobile Device HT App One Web SSO Identity App Two Web App Serv Prov TZ - 04: Organizational Domain TZ - 05: Organizational Dom The change between the current and previous threat model is the inclusion of inter-process communication (IPC) between the two mobile Figure applications. 2 An additional control is application whitelisting, C04. Application whitelisting is the generic term for the ability of applications to specify which applications they are willing to communicate with via IPC. 3.2 Concerns in a Broadcast Native SSO System All of the concerns and mitigations outlined in the previous use case also apply to the broadcast native SSO environment. The addition of IPC between the components increases the attack surface of the application, resulting in the need to secure the session identifier in-transit on the device. This change opens the possibility of a malicious application that sniffs and/or injects malicious IPC requests. By sniffing IPC traffic between the various components, a malicious app may provide requesting applications with an illegitimate token, preventing them from accessing the protected resource. In addition to sniffing IPC, a malicious application may also impersonate a legitimate application by directly requesting an SSO token from previously authenticated applications. Both of these cases boil down to an issue in authentication within app-to-app communication on the device. Currently, the best platform level protection against impersonation is to use IPC whitelisting. Both Android and ios (added in ios version 5.0) implement protections allowing applications to specify which application they are communicating with. Whitelisting can work for environments with a small and stable set of applications; however, maintaining whitelists becomes very difficult when the list of applications is dynamic. Unfortunately, whitelisting is not a perfect solution and can still be bypassed on both major platforms. Analyzing Mobile Single Sign-On Implementations 5

6 The second major consideration in a broadcast environment is handling a user s SSO token being invalidated and refreshed. When this occurs, all applications which received the SSO token should be told that the token is invalid and be issued the new SSO token. This means in addition to listening for requests for the current SSO token, applications must also listen for SSO token revocation. If an application does not receive an SSO token revocation message and continues to use the invalid token, the identity provider (IdP) will require the end-user to re-authenticate. This will negatively affect the user s experience because they will have to reauthenticate even though they just authenticated in a separate application. 4 Use Case Three: Single Sign-On with a Manager Organizations have begun implementing a manager application on the mobile device that acts as an intermediary between mobile apps and identity provider. A manager lets applications request an SSO token from a single location on the mobile device, simplifying the authentication logic in other applications and resolving some of the problems identified in the native broadcast SSO use case. From a security prospective, the main benefit to this solution is the addition of a central place to enforce policies. The manager solves two problems with the native broadcast use case: complex whitelists and an inconsistent user interface experience. In the native broadcast use case, each application must have a whitelist containing every other application participating in the SSO. When an application is added or removed, the whitelist of all applications must be updated. In combination with the potential security issues, there is the added usability concern where it is possible for each application to have a dramatically different user experience for authentication. The inclusion of the manager simplifies configuration and creates a consistent end-user authentication experience. End-users always enter their username and password into the manager and not each individual application. The manager handles authentication with the identity provider. When the mobile SSO manager receives an SSO token, it is passed back to the requesting mobile application. For subsequent authentication requests, the manager returns the SSO token without prompting the end-user. The manager simplifies the whitelist because the applications participating in the SSO all talk to the manager. Analyzing Mobile Single Sign-On Implementations 6

7 4.1 Examining the Control Flow in a Threat Model Figure 3: Mobile SSO with a Manager Threat Model T T : SSO Token : User Credentials : Protected Resource T T T : Process Isolation : File System Sandbox : Certificate Pinning C04 : Application Whitelisting : SSL : SSO Token App One IPC C04 Mobile SSO Manager IPC C04 App Two T : Malicious App T : Malicious App with Root Access T : Unauthorized Physical User TZ - 02: App One Sandbox TZ - 03: App One Sandbox TZ - 04: App One Sandbox TZ - 01: Mobile Device TA04 TA05 App One SSO Identity App Two TZ - 05: Organizational Domain This model for this mobile SSO system adds a mobile SSO manager. This increases the attack surface by adding a new application and exposing Figure an 3IPC interface between the mobile SSO manager and applications wishing to perform SSO. However, in this system the user s authentication credentials are only handled by the mobile SSO manager and the SSO identity provider. Individual applications leveraging the SSO infrastructure will not process user credentials, drastically reducing the exposure of the user credentials. 4.2 Concerns in a Native SSO with a Manager In addition to all the previously examined concerns and controls, native SSO will have an additional risk in the native mobile SSO manager client. If the mobile SSO manager is not developed in house, it should be analyzed and tested to ensure it is robust enough to protect against all previously mentioned attack vectors. While not a security issue, switching applications to perform authentication may negatively impact the user experience. Users may find the change to SSO rather jarring, especially on devices with poorer performance ratings. Analyzing Mobile Single Sign-On Implementations 7

8 5 Back to Single Identity Organizations considering a new mobile single sign scheme must address the following questions: How are applications verifying the authenticity of other applications before delivering the SSO token? Is the SSO token being stored and if so is it being stored securely? If the security of one application is compromised is the integrity of all applications compromised? After analyzing each of the current solutions used today for leveraging existing infrastructure, the approach of the single identity provider becomes much more appealing. End-users will know when they are authenticated and when they need to login again when launching an application. Single identity provides a consistent end-user experience as well as significant security benefits. When introducing mobile single sign-on, the SSO token has to be shared on the mobile device. In this scenario IPCs including a secure authentication scheme between multiple applications and the app-to-app communication must be securely locked down. Another factor to consider is while a mobile device is a personal device, threats like mobile malware and device loss means the SSO token is at risk. Single sign-on s goal is to provide a convenient and secure way for end-users to authenticate. For web-based applications, existing SSO infrastructure does a great job. Native mobile applications can have convenience or security. It is one or the other because on a mobile device, the user s account can be accessed if the SSO token is intercepted or captured by malicious code on the device. For mobile applications, convenience and security can be achieved through a combination of long running application sessions with a step-up authentication scheme for sensitive or high value transactions. Analyzing Mobile Single Sign-On Implementations 8

9 About the Author Jacob Ewers is a Senior Security Consultant at Cigital, Inc. working in the mobile space as a mobile security architect and vulnerability assessor. Jacob has worked across many Fortune 500 companies in a vast number of industry verticals helping development organizations build security in their applications. Jacob is also an instructor for Cigital s Defensive Programming for Android class and is the author of numerous training courses including the Foundations of Mobile Security. About Cigital Cigital is one of the world s largest application security firms. We go beyond traditional testing services to help organizations find, fix and prevent vulnerabilities in the applications that power their business. Our holistic approach to application security offers a balance of managed services, professional services and products tailored to fit your specific needs. We don t stop when the test is over. Our experts also provide remediation guidance, program design services, and training that empower you to build and maintain secure applications. Analyzing Mobile Single Sign-On Implementations 9 Cigital Ridgetop Circle Suite 400 Dulles, VA Cigital