Anonymous Browsing App Falls Short of Claims

Will Strafach
6 min readMar 3, 2017

--

OpenDoor claims to be an anonymous internet browsing application for iOS devices, created to help fight internet censorship (According to the developers).

The app description of OpenDoor bills it as secure, private, and anonymous. Unfortunately, these claims are all currently false. Much like a few other popular iOS applications, the OpenDoor application allows for any man-in-the-middle attacker to intercept and silently surveil all connections. This includes connections of which the user has prefixed with “https://” (an explicit indication that the user is attempting to make a secure and encrypted connection, under normal circumstances).

I will list below most of my notes regarding this application, formatted in a manner most easily interpretable by a technical audience.

Summary of Findings

  • The OpenDoor app for iOS (Bundle ID: com.backdoorapp.opendoor) accepts any invalid TLS certificate presented, allowing a man-in-the-middle attacker to intercept and/or modify user traffic without detection. This attack can be performed in a close-access situation or performed anywhere along the network path (such as ISP-level).
  • The search functionality uses URL endpoints from the “search.plist” file within the OpenDoor app bundle, all of which contain an “http://” prefix (with the exception of DuckDuckGo). Due to the application opting out of App Transport Security for all connections, these plaintext connections are allowed, causing user search terms to be passively intercept-able (no TLS man-in-the-middle needed!).
  • Many advertising and analytics libraries are compiled into the app binary. However, packet captures show only Google Analytics and AppLovin connections during app operation. Information about the device is sent both providers. Additionally, information regarding websites accessed by the user is transmitted to Google Analytics.
  • The following statement can be found within the application Terms of Service, and could only be fully accurate if the OpenDoor developers are retaining logs of user activity: “In order to cooperate with legitimate governmental requests, subpoenas or court orders, to protect our systems and customers, or to ensure the integrity and operation of our business and systems, we may access and disclose any information we consider necessary or appropriate, including, without limitation, IP addressing and traffic information, and usage history.”
  • Private and prohibited system APIs are utilized in attempt to read a sensitive/unique device identifier (Recent versions of iOS will block this attempt).
  • We can confirm the following versions to be vulnerable: 2.54, 2.53, 2.52
  • Our internal records show the following versions have a high likelihood of vulnerability, although older versions may be vulnerable as well: 2.47, 2.46, 2.45, 2.43, 2.42, 2.41, 2.40.
  • App Store reviews and Facebook comments indicate that the userbase of the OpenDoor application include users in the Middle East, Asia, as well as kids with a desire to bypass school web filters. The application was also popular within China, prior to removal from the Chinese App Store.
  • This application is not suitable for the intended use case, and will cause users to silently experience a major decrease in security.

Cause of TLS Vulnerability

The side-stepping of TLS validation in this application appears to be deliberate. The motivation for this is unclear. One possible reason is an error which would be normally be produced by the TLS certificate presented by open proxy servers utilized by OpenDoor to mask connections. OpenDoor connects to websites using the following format: https://<Proxy IP>/<Target URL>

The “Proxy IP” presents a TLS certificate assigned to an unrelated domain name. Due to this, if the application were to properly validate TLS certificates, a “hostname mismatch” error would occur and block the connection.

Developers for the OpenDoor application may have simply disabled TLS validation due to this error. It is not possible to assess their logic associated with this solution, as it undercuts any form of security which could be provided by the application.

Private API Usage

Pseudocode output from the offending function (via Hopper)

The application dynamically loads the private “IOKit” framework in an obfuscated manner, presumably to bypass checks during the App Review process. Code from this private framework is then used in attempt to retrieve the Serial Number of the user’s iOS device.

On recent iOS versions, the above code should not work at all (This is due to increased security implimented by Apple at the OS level). There is absolutely no danger here for most users. However, it is noteworthy to see this type of code within an app intended to assist in anonimity.

Sensitive Information Access

Data Access justifications, from OpenDoor app metadata (via verify.ly analysis)

Metadata within the application contains the above justifications for access to sensitive bits of data (This is required to be front-and-center in iOS 10, otherwise access to the data will be prohibited).

This is bizarre, as I have not been able to trigger any of the above during application analysis. Static analysis of the code indicates utilization of some of the above-mentioned data within embedded advertising libraries only.

Example of sensitive information access by advertising libraries (via verify.ly analysis)

I was unable to locate any overt use of the above-mentioned sensitive data by the main application code. As such, I would expect the developers to not include these justifications within their app metadata, causing the access attempts to silently fail. It is certainly possible that these are leftovers from previous legitimate code, but even so, this seems concerning and may warrant further investigation.

Advertising and Analytics

Partial list of “Outgoing Network Connections” detected, after scanning a copy of the OpenDoor application IPA file, freshly downloaded from the App Store.

There appears to be 8 recognized third-party advertising and analytics code libraries within the OpenDoor application. During live testing, only connections to Google Analytics and AppLovin could be detected. The following information is trasnmitted to analytics services:

  • Hostnames of visited websites
  • Full URLs and additional parameters for connections which fail to properly load
  • Cellular Carrier Name
  • Locale (ie. “en_US”)
  • Model
  • OS Version

Additional Information

In 2013, Apple was criticized for removing OpenDoor from the iOS App Store in China:

Apple has been accused of kowtowing to the Chinese government by pulling from its China App Store a product enabling users to circumvent firewalls and access restricted sites.

As noted in the linked article, OpenDoor had about 2,000 daily downloads by Chinese users at the time, and Chinese users accounted for one third of the app’s downloads. Incidentally, removal from the App Store in China may have been a very good thing for many users who wished to get around web filtering put in place by the Great Firewall. However, many others are not as fortunate. According to a Facebook post from 2014, they had at least 2,000,000 users. New downloads have slowed down recently; According to Apptopia, they are seeing an average of 23,000 new downloads each month (Average is based on past 12 months).

Conclusion

I prefer to take a neutral tone in technical posts, in order to present concise facts without mixing in personal opinion. I believe an exception must be made in this case.

This application is utterly unsuitable for use by anyone desiring even a whiff of privacy, security, or anonymity. Users residing in regions which censor internet connections should err on the safe side, and consider any data sent during prior use of this application to be potentially compromised.

--

--

Will Strafach

building great things. breaking others. | infosec, cyber, CANEX, mobile phone (iOS) hacking. | e: will@wstraf.me