• Distrustful Third Party SDKs
  • Felix Krause
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: CACppuccino
  • Proofread by hanliuxin5

Trust issues with third-party SDKS

Third-party SDKS are often easily modified when you download them! Using a simple man-in-the-middle attack, anyone on the same network can insert the virus code into the code base, which then enters your app and runs on your users’ phones.

Of the most popular closed source iOS SDKS, 31% of the SDKS and 623 libraries in CocoaPods are defenseless to this attack. As part of the study, I notified the affected organizations and submitted patches to CocoaPods to alert developers and SDK providers.

What are the potential consequences of an SDK being modified?

If someone modifies an SDK before you install it, the situation becomes very dangerous. Because you’re sending your app along with all that dangerous code. It runs on thousands of devices over a few days. It also has the same permissions as your app.

This means that any SDK you reference in your app has:

  • Any keychain that your app can access
  • Any files or folders that your app has access to
  • Any permissions your app has, such as location info, album permissions, etc
  • Your app’s iCloud stores content
  • All the data your app exchanges with the Web server, such as user login information, personal information, etc

There’s a good reason Why Apple mandates iOS apps to sandbox, so don’t forget that any SDK included with your app runs in your app’s sandbox and has access to everything your app has access to.

What’s the worst that a virus-containing SDK can do?

  • Stealing sensitive user information usually involves adding a keylogger to your app and recording every click
  • Steal keys and user credentials
  • Take the user’s location history and sell it to a third party
  • Display the iCloud phishing pop-up, or other login credentials
  • Get photos in the background without telling the user

The attack method described here shows how an attacker can use your mobile app to steal sensitive user data.

Network Security 101

To help you understand how the virus code can bind to your app without your permission or attention, I will provide the necessary background to understand how the MITM attack works and how to avoid it.

The following information has been simplified so that a mobile developer can understand how these work and how they protect themselves without much knowledge of network communications.

HTTPs vs HTTP

HTTP: Unencrypted transmission, anyone on the same network (WiFi or Ethernet) can easily listen to network packets. While this method of listening on an unsecured WiFi network is straightforward, it’s actually just as simple on a protected WiFi or Ethernet network. Your computer does not validate the network packet of the host for which you are requesting data; Other computers can receive packages before you do, open and modify them, and then send you the changed version.

HTTPs: In HTTPs transport, other hosts on the network can still listen for your packages but cannot open them. They can still get some basic metadata, such as the host name, but not detailed data (such as the body part of the data, the full URL, etc.). . In addition, your client verifies that your packet is from the original host and that no one has modified the content. HTTPs technology is based on TLS.

How do browsers switch from HTTP to HTTPs

Type “google.com” into your browser (please type “HTTP”, not “HTTPS”). You will see how the browser automatically switches from the “HTTP” port to “HTTPS”.

This switch doesn’t happen in your browser, but on a remote server (google.com), because your client (now the browser) doesn’t know which port the host supports. (Except for hosts using HSTS)

The initial request is made through HTTP, so the server can only tell the client to switch to the secure “HTTPS” port in plain text. The response code is “301 Moved Permanently”.

You can already see the problem here: since the first response is in plaintext, an attacker can change the specific network packet to replace the redirected URL and keep the “HTTP” unencrypted. This is called SSL stripping, and we’ll talk more about it later.

How do network requests work

Simply put, network requests work on a multi-tier model. Different layers have different messages telling the network how to route packets:

  • The lowest layer (data link layer) uses MAC addresses to locate hosts on the network
  • The upper layer (network layer) uses IP addresses to locate hosts on the network
  • The layer above adds port information and the actual message content to be delivered

If you are interested, you can learn how OSI model works, especially in the realization of TCP/IP protocol (for example microchipdeveloper.com/tcpip:tcp-i…). .

So, if your computer sends a network packet to a router, how does it know how to route the network packet based on layer 1 (MAC Address)? To solve this problem, routers use a port called ARP.

How does ARP work and how can it be abused

Simply put, devices on a network use ARP mapping to remember where to send network packets with a specific MAC address. ARP works simply: If a device knows the IP address that a network packet should be sent to, it asks everyone in the network, “Which IP address should this MAC address correspond to?” The device with that IP address responds with the message ✋

Unfortunately, the device was unable to verify the identity of the ARP message sender. So an attacker can quickly respond to another device’s ARP declaration: “Please send all network packets at IP X to this MAC address.” The router remembers this information and later applies it to all relevant requests. This is known as ARP spoofing.

See how all network packets are routed to your computer by the attacker instead of directly from the host?

As long as a network packet passes through an attacker’s machine, there is some risk. It’s the same risk you take with your ISP or VPN service you trust: if the service you use is properly encrypted, they can’t know what you’re doing or modify your network package without your clients (like your browser) noticing. As mentioned earlier, some information such as specific meta-information is still visible (such as host names).

If there is an unencrypted network packet (such as HTTP), the attacker can not only read its contents, but also rewrite any information at will without being detected.

Note: The techniques described above are not the same as the public WiFi security issues you may have read about. The problem with public WiFi is that anyone can read the packets that are being sent, and if those packets are HTTP without encryption, it’s easy to read what’s going on. ARP contamination affects all networks, whether public or not, WiFi or Ethernet.

Let’s see how it works in practice, okay

Let’s take a look at some SDKS, how they publish their files, and then we’ll see what we can find.

CocoaPods

Open-source Pods: CocoaPods uses Git underneath to download code from services like GitHub. Git :// Uses SSH :// for ports, similar to HTTPs encryption. In general, if you install the open source SDK from GitHub using CocoaPods, you’re pretty safe.

Closed source Pods: While preparing this article, I noticed that Pods can define an HTTP URL to point to the binary SDK, so I submitted a pull Request (1 and 2), This is merged and published as CocoaPods 1.4.0 to generate warnings when aPod uses unencrypted HTTP.

Crashlytics SDK

Crashlytics uses CocoaPods as the default distribution, but there are 2 optional installation methods: Fabric Mac App or manual installation, both of which are HTTPS encrypted, so there’s not much we can do here.

Localytics

Let’s take a look at a sample SDK where a document page is transmitted over unencrypted HTTP (see address bar)

So you might think, “Oh, I’m just looking at a document here, and I don’t care if it’s not encrypted.” The problem is that the download link here (in blue) is also part of the site, meaning an attacker could easily replace the https:// link with http://, making the actual file download insecure.

Alternatively, an attacker can choose to simply replace the https:// link with a link from an attacker that looks similar.

  • S3.amazonaws.com/localytics-…
  • S3.amazonaws.com/localytics-…

Also, there is no good way for users to verify the identity of a particular host, URL, or S3 bucket of SDK authors.

To verify this, I set up my Raspberry PI to hijack traffic and implement various SSL spoofing (demoting HTTPs links to HTTP), from JavaScript files, image files, to download links.

Once the download link is demoted to HTTP, it is easy to replace the contents of the ZIP file:

It’s easy to replace HTML text in transit, but how does an attacker replace a ZIP file or binary?

  1. The attacker downloads the original SDK
  2. The attacker inserts the virus code into the SDK
  3. The attacker compresses the changed SDK
  4. The attacker waits for incoming network packets and replaces all files that have specific characteristics with zip files prepared by the attacker

(This is the same method used in the image replacement technique: each image transmitted over HTTP is replaced with an expression.)

As a result, the downloaded SDK may contain additional files or code that has been modified:

For this attack to work, all you need is:

  • The attacker is on the same network as you
  • The document web page is unencrypted and all links are capable of SSL spoofing

Localytics fixed the problem after it was revealed, so document pages and downloads are now HTTPs encrypted.

AskingPoint

Looking at the next SDK, its documentation pages are HTTPs encrypted, and from the screenshots, it looks secure:

However, this HTTPs based site link points to an unencrypted HTTP file, and browsers do not warn users in this case (some browsers already warn when JS/CSS files are downloaded over HTTP). It’s hard for users to see what’s going on here unless they compare the hashes provided manually. As part of this project, I wrote a security report for Google Chrome (794830) and Safari (rDAR ://36039748) to warn users who download unencrypted files from HTTPs sites.

AWS SDK

At the time of my research, the DOWNLOAD page for the AWS iOS SDK was encrypted using HTTPs, but linked to an unencrypted ZIP download, similar to the SDK mentioned earlier. After the problem was disclosed, Amazon fixed it.

In a nutshell

Recalling the aforementioned iOS privacy bug (iCloud phishing, location via image, camera in the background), what if we weren’t talking about malicious developers targeting users, but attackers targeting you, an iOS developer, in order to reach millions of users in a short time?

Attacking developers

What if an SDK was modified while you were downloading using a man-in-the-middle attack and inserted virus code that broke your trust? Take the iCloud phishing pop-up. How hard would it be to use another developer’s app to steal a user’s password and send it to your remote server?

In the video below, you can see a sample iOS app with maps. After downloading and adding the AWS SDK to the project, you can see how the virus code is executed, in this case iCloud popup phishing shows up, and then the plaintext password for iCloud is read and sent to a remote server.

YouTube video please see: https://youtu.be/Mx2oFCyWg2A

This attack can only be launched if the attacker is on the same network as you (e.g. in the same conference hotel). Or the attack could be done through the ISP or VPN service you use. My Mac uses the default macOS configuration, which means no proxy, custom DNS or VPN Settings.

Setting up such an attack is surprisingly simple because it can be automated using tools designed for SSL spoofing, ARP contamination, and replacing multiple requests. If you’ve done this before, it takes less than an hour to set up on any other computer, including raspberry PI, like the one I used for this study. So the entire attack cost less than $50.

I have decided not to disclose the names of the tools I use and the code I write. You can check out some well-known tools like SSLStrip, MitmProxy, and Wireshark

Running arbitrary code on the developer’s machine

In the previous example, the attacker inserted the virus code into the iOS app by hijacking the SDK. Another line of attack is the developer’s Mac. Once an attacker can run code on your machine, or even have remote SSH access, the damage can be huge:

  • Example Activate the remote SSH permission of the administrator account
  • Install the keylogger to get the administrator password
  • Decrypt the keychain using the password and send all login credentials to the remote server
  • Get local secrets such as AWS credentials, CocoaPods and RubyGems’ upload tokens and: * If the developer has a popular CocoaPod, you can spread the virus code across more SDKS
  • Access almost all files and databases on your Mac, including iMessage conversations, emails and source code
  • Recording screens without the user’s knowledge
  • Install a new ROOT SSL certificate that allows an attacker to listen to most of your encrypted network requests

To prove that this can happen, I looked up how to insert virus code into the shell text that the developer runs locally, in the BuddyBuild case:

  • As before, the attacker needs to be on the same network
  • The BuddyBuild document tells the user to gocurlAn unencrypted URL to pass throughshTo operate means anycurlAny code returned from the command is executed
  • The modifiedUpdateSDKProvided by the attacker (Raspberry PI) and asks for the administrator password (usually BuddyBuild update scripts don’t ask for this)
  • In a second, the virus script can:
    • Enable remote SSH permission for the current account
    • Install and configure keyloggers for automatic logging of your login operations

Once an attacker has the root password and SSH permissions, they can do any of these things.

YouTube video please see: https://youtu.be/N1Wj6ipc-HU

BuddyBuild fixes the problem after feedback.

How realistic is such an attack?

** is very realistic! ** Open your Mac’s Network Settings and view a list of WiFi connections your Mac has made. For me, my MacBook has been connected to over 200 hotspots. And how much of it can you trust completely? Even in trusted networks, other machines may have been compromised before, enabling remote control attacks (see above).

SDKS and developer tools are increasingly being targeted by attackers. Here are some examples from the past few years:

  • Xcode GhostAffecting nearly 4,000 iOS apps, including wechat:
    • The attacker has remote login access to any machine using these apps
    • Show the fishing popover
    • Have permission to read and change the stickboard (this can be dangerous when using a password manager)
  • The NSA is committed to finding iOS vulnerabilities
  • Pegasus: Malware targeting non-jailbroken iphones, used by governments
  • KeyRaider: Only affects jailbroken iphones, but still steals user credentials from over 200,000 end users
  • Just a few weeks ago, there were a lot of blog posts about how this affected the site project (e.g. 1, 2).

And more like it. Another option is to get permission to download the server (for example, S3 buckets use permission keys) and replace the binaries. This has happened a lot in the past few years, such as the Mac App transfer incident. This opens up another layer of attack territory that I haven’t covered in this blog post.

Convention center, hotel, coffee shop

Whenever you connect to WiFi in a conference center, hotel or coffee shop, you are an easy target. An attacker knows there are a large number of developers at the conference and can easily take advantage of this.

How can SDK providers protect their users?

That’s beyond the scope of this blog post. It’s a good idea for Mozilla to provide a security guide. Mozilla also provides a tool called Observatory that automatically checks the server’s configuration and certificates.

How many popular SDKS are affected by this vulnerability?

I’ve been working on it since November 23, 2017, and according to AppSight (which counts all Facebook and Google SDKS as one because they all use the same installation method — skipping all the open source SDKS on GitHub), The 41 most popular mobile SDKS were surveyed.

  • 41Check the SDK
    • 23 are closed source and you can only download binary files
    • 18 are open source (they’re all on GitHub)
  • 13Is an easy target for a man-in-the-middle attack without the user knowing anything
    • 10 are closed source SDKS
    • Three are open source SDKS, which means users can download the source code securely from GitHub, as well as from the unencrypted HTTP channel on the official website
  • The five SDKS don’t have any secure download methods, which means they or their corresponding services (like GitHub) don’t support HTTPs at all
  • Thirty-one percent of SDKS are vulnerable to this type of attack
  • Five additional SDKS require accounts to download (do they have something to hide?).

I notified all potential targets of the attack in November and December 2017, giving them two months to resolve the issue before speaking publicly about it. Of the 13 affected SDKS:

  • One solved the problem within three business days
  • Five solved the problem within a month
  • Seven SDKS still had vulnerabilities when this blog post was posted

SDK providers still affected by the bug haven’t responded to my email or simply replied “we’ll take a look at it” — they’re all in the top 50 most used SDKS.

From CocoaPods, a total of 4,800 releases were affected from 623 CocoaPods. I got this data from the Specs directory locally by grep -l -r ‘” HTTP “: “http://’ *.

Open source vs. closed source

Judging from the numbers above, if you are using a closed source SDK, you are likely to be affected by the attack. What’s more, when the SDK is a closed source, it’s hard to verify the integrity of the dependent libraries. As you know, you should always check the Pods directory with version control to detect changes and audit updates to your dependent libraries. 100% of the open source SDKS I examined are available directly from GitHub, meaning that if you use GitHub’s version instead of the provider’s version, you won’t be affected even if you use the three affected SDKS mentioned above.

Based on the numbers above, it is clear that in addition to not being able to penetrate the source code of the closed source SDK, you are at a higher risk of being attacked. Not just man-in-the-middle attacks, but also:

  • The attacker has obtained the permission of the SDK download server
  • The company providing the SDK was infiltrated
  • Local governments force companies to include backdoors
  • The company that provides the SDK has bad intentions and includes tracking and code that you don’t want

You are responsible for the code you send! You should ensure that you have not breached the trust placed in you, violated the EU’s Data Protection Law (GDPR), or stolen users’ credentials through a virus SDK.

conclusion

As developers, we have a responsibility to only pass code that we trust to the customer. Now one of the simplest attacks is implemented through SDK viruses. If an SDK is open source on GitHub and installed through CocoaPods, you’re pretty safe. Pay special attention to bound binary closed source code or SDKS that you don’t fully trust.

Since this attack leaves such a small footprint, it is hard to detect that your code has been changed. With open source, we as developers can best protect ourselves, and our customers.

Refer to my other privacy and security-related literature.

thanks

Special thanks to Manu Wallner for the recording of the video.

Special thanks to my friends for their feedback on this article: Jasdev Singh, Dave Schukin, Manu Wallner, Dominik Weber, Gilad, Nicolas Haunold and Neel Rao.

Unless otherwise mentioned in the article, these projects are part-time projects that I do on weekends and evenings, and have nothing to do with my job or employer.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.