The Effects of Overhyped Usability

When Apps Get Out of (Privacy) Control

Slow but steady, the everlasting trade-off between usability and security appears to reach a considerable peak within the mobile app ecosystem. Since “ease of use” has been one of the key drivers for designing mobile apps in the recent past, it’s about time to pause for a moment and to rethink whether our strong expectations towards app usability may have gone too far. To demonstrate how our strong usability expectations are going to intensify the mobile privacy crisis, this blog entry describes one of my latest cases in which I noticed an app that automagically retrieves a user’s login credentials from its backend. For convenience.

The Case of the Deutsche Telekom HotSpot Login App

According to the official App Store description, the HotSpot Login App by Deutsche Telekom assists users to connect to one of the public Telekom hotspots. It says “Telekom mobile customers can set up their credentials automatically with the app.

Automatic retrieval of login credentials by pushing the Automatic setup button. The username is based on a user's phone number.

In practice, users just have to push the “Automatic setup” button within the account settings dialog. A few seconds later, the login form is magically filled with the corresponding hotspot credentials (see Figure 1). Noticeably, the username is based on a user’s phone number, which actually shouldn’t be accessible from an app at all due to iOS sandbox restrictions. So how did Telekom manage this? Using private API? In that case, how was it possible to bypass Apple’s vetting process? Special treatment for mobile service providers? Far from it, as the following analysis will show.

By intercepting the cellular network traffic it could be easily determined that whenever the automatic setup button is pushed, the following HTTP request is issued to the system

GET /getCredentials?x-Hash=ad5af2d1ef8aead398cd132aa4d1479e07f43ac60cbeea3f73e45c9f96650f4e HTTP/1.1
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: de-de
Connection: keep-alive
x-Hash: ad5af2d1ef8aead398cd132aa4d1479e07f43ac60cbeea3f73e45c9f96650f4e
User-Agent: HotSpot%20Login/2.4.0 CFNetwork/672.0.8 Darwin/14.0.0

It should be noted that the only remarkable part about that request is an ominous hash value, which is placed in its parameter and header values. Obviously, that hash is meant to prevent fraudulent use of this web service.

This request resulted in the following server response:

HTTP/1.1 200 OK
x-Username: <PHONE_NUMBER>
Content-Length: 0
Content-Type: text/plain; charset=ISO-8859-1

It turned out that a user’s credentials are disclosed within the two HTTP headers x-Password and x-Username, which, in turn, are used to fill the app’s login form. This means that the initial assumption of private API usage to determine a user’s phone number has proved to be false. Instead, a web service provided by Deutsche Telekom provides all the relevant data. In fact, this is not surprising as it should be easy for a mobile carrier to match a requester’s IP address to their account information.

So far, the one and only requirement to query that web service is a single hash value, which is actually calculated inside the app. In more detail, the hash is calculated within the method getStringMax provided by the UserCredentialManager class. This method uses the device’s current public IP address and appends a static “shared secret” value (ae2454ca2df8c8c3) to it. Finally, a SHA-256 hash value is computed of that assembled string (IP + shared secret) to legitimize the web service request.

Exploitation Scenarios

So, what does it all mean? When talking about risks, the good news is that the wlanauthenticate sytem is only accessible from the Deutsche Telekom cellular network. Moreover, the requester’s IP address is used along with the hash value to finally authorize a request. Therefore, crawling user hotspot credentials on a large scale is not an option. However, the bad news is that any app can make use of that service to query the phone numbers of their users or, even worse, their hotspot password (limited to customers of Deutsche Telekom of course). For this, an app only needs to issue a single HTTP request as demonstrated above using the following Objective-C function to calculate the required hash value. In no time, any requesting app will be provided with the user’s phone number and the hotspot password.

- (NSString*) calculateHash:(NSString *)ip
    NSString *sharedSecret = @"ae2454ca2df8c8c3";
    ip = [ip stringByAppendingString:sharedSecret];
    NSData *dataIn = [ip dataUsingEncoding:NSASCIIStringEncoding];
    uint8_t dataOut[CC_SHA256_DIGEST_LENGTH]={0};
    CC_SHA256(dataIn.bytes, dataIn.length,  dataOut);
    NSData *out=[NSData dataWithBytes:dataOut length:CC_SHA256_DIGEST_LENGTH];
    NSString *hash=[out description];
    hash = [hash stringByReplacingOccurrencesOfString:@" " withString:@""];
    hash = [hash stringByReplacingOccurrencesOfString:@"<" withString:@""];
    hash = [hash stringByReplacingOccurrencesOfString:@">" withString:@""];
    return hash;

This seems to be a great opportunity for the advertising industry as it allows not only to reliably track users based on their phone numbers, but also to extend spam activities to other channels like text messaging services. This could be the beginning of “Customers Who Frequently Used This App Also Used…” messages flooding mobile messenger networks. Or the other way round: Apps might harvest hotspot credentials to sell them on the black market. I’m not quite sure, which of these scenarios is worse…

Notwithstanding the above, such a precarious practice is questionable insofar as Apple has significantly ramped up efforts in recent years to restrict apps’ overall capabilities to harm users’ privacy. Removal of the Unique Device ID (UDID) or the WiFi MAC address, introducing loads of new entitlements to restrict access to private API within iOS 7, just to name a few. However, it just seems like a waste of efforts when a mobile service provider circumvents those restrictions by utilizing their exposed network position.

Reactions from the Deutsche Telekom CERT

For this reason, I contacted the Deutsche Telekom CERT at the beginning of November 2013 and responsibly disclosed my findings. I also sketched all the related privacy implications. They informed me at the end of November that the issues were still under investigation and provided me with a final reply at the end of December. Within that e-mail they stated that they weighed up the potential risk of abusing the web service against its enormous usability boost and decided to keep that function up running. Otherwise, the overall app usability would suffer significantly. They also pointed out that users would be at risk only when installing “malicious” apps from third-party marketplaces and it would be the users fault when not sticking to official App Store apps. On a side note, I was wondering since when Apple evaluates individual web service requests within their vetting process? Anyhow, they finally stated that “exploitation of this vulnerability would (at least) require special expertise and criminal energy”. Duh!

PS: Within the last update of the HotSpot Login App the hash calculation method was renamed from the former name “getSecureHashForIP” to a more meaningless value of “getStringMax”. Well enough.


At the very beginning of this analysis it turned out that the automatic setup procedure would require a cellular data connection (to enable the backend to match a requesters cellular IP address to their account information). This is ensured by the app class ReachabilityARC that will display an error message whenever setup is invoked from within a WiFi network. Clearly, this renders all well-known WiFi based network capture approaches useless. Thus, in order to inspect the app’s traffic the cellular data connection has to be intercepted. This can be easily accomplished within iOS by setting up a specific APN (Access Point Name) payload that defines a reverse proxy (see Figure 2). Although those settings are not directly accessible from the iOS user interface, the Apple Configurator Application allows creation of so called mobile configuration profiles, which in turn provide access to hidden settings like APN proxy configurations etc. It should be noted that, in practice, it is recommended to redirect the intercepted proxy traffic back to the iOS device in order to deliver it to the backend systems. This ensures that all requests are in fact issued via the cellular network, which might prevent app malfunctions. For more information on how to easily proxy back to the device, please refer to my recent blog post “The Proxy Fight” .

Intercepting celluar network connections using an iOS mobile configuration profile.