Dialogic PowerMedia XMS Multiple Vulnerabilities

By | June 24, 2018

I disclosed multiple vulnerabilities to Dialogic in their PowerMedia XMS product (version 3.4), which is a “highly scalable, software-only media server that enables standards-based, real- time multimedia communications solutions for IMS, MRF, Enterprise, and WebRTC applications on premise or in the cloud.”

  • CVE-2018-11634 – Plaintext storage of passwords in a SQLite database.
  • CVE-2018-11635 – Use of a hard-coded cryptographic key used to protect cookie session data allows remote attackers to bypass authentication.
  • CVE-2018-11636 – Cross-site request forgery (CSRF) vulnerability allows remote attackers to execute malicious and unauthorized actions.
  • CVE-2018-11637 – Information leakage vulnerability allows remote attackers to read arbitrary files from the /var/ directory.
  • CVE-2018-11638 – Unrestricted upload of a file with a dangerous type allows authenticated users to upload malicious code to the web root to gain code execution.
  • CVE-2018-11639 – Plaintext storage of passwords within cookies.
  • CVE-2018-11640 – XML External Entity (XXE) vulnerability in a web service (running as the root user) allows unauthenticated remote attackers to read arbitrary files.
  • CVE-2018-11641 – Use of hard-coded credentials.
  • CVE-2018-11642 – Incorrect permission assignment on a shell script run periodically allows the apache user to execute code as the root user.
  • CVE-2018-11643 – SQL injection.

Originally I was just going to use the media server as a testbed to test VoIP client security but I got sidetracked by looking into the media server components. Two installation methods are provided for XMS: ISO or RPM. I was looking at the ISO method which is a complete system installation that includes CentOS and the XMS software stack bundled in, which can be easily installed into a hypervisor.

Continue reading

Maxthon Browser Arbitrary File Write, Login Page UXSS, and SQL Injection

By | November 10, 2016

Maxthon Browser is another popular Android browser that is used instead of the stock browser. I have identified a number of interesting, and severe, vulnerabilities in the Android version of the browser that could result in remote code execution and information leakage.

  • Exposed JavaScript Interface allows for arbitrary file writes – A malicious webpage can force the browser to download a zip file, which the browser will put onto the SD card and unzip, by calling the installWebApp method with the desired URL. Due to a lack of input validation on the zip entry filenames, an attacker could craft a malicious zip file that uses path traversal to overwrite arbitrary files within the browser’s sandbox. This vulnerability can be exploited to achieve remote code execution as I’ll demonstrate later.
  • Exposed JavaScript Interface allows for login page UXSS – A malicious webpage can alter the login page form autofill data associated with other domains by calling the catchform method. The autofill information is injected into login pages using some dynamically built JS code and the browser does not properly output encode the data therefore we can abuse this to launch login page UXSS attacks.
  • Exposed JavaScript Interface allows for SQL Injection into a client-side SQLite database – The code designed to store the form autofill data is also vulnerable to SQL injection. Its possible to corrupt the client-side database or remotely extract out all the information from the autofill table, which includes saved credentials. While I was able to find a number of examples of client-side SQL injection vulnerabilities triggered by IPC in Android applications (like this one from Dominic Chell) and one example of a client-side SQL injection vulnerability triggered remotely by a WAP push from the Baidu X-Team, I couldn’t find published examples about remotely exfiltrating data from a SQLite database associated with an Android application. So this might be the first published example of remote client-side SQL injection against an Android application in which it is feasible to remotely exfiltrate data out of the SQLite database using the login page UXSS exploit as out-of-band communication technique. Ping me if you have other interesting examples.

Update: I also confirmed that the privacy research conducted by Exatel security researchers against the desktop version of Maxthon also pertains to the Android version of the browser. Mainly that the Android application will send the URLs that you type into the address bar to a third party server (g.dcs.maxthon.com) over HTTP in an encrypted form (encrypted using AES/ECB and a hardcoded encryption key).

Continue reading

React Native Development Server Remote OS Command Injection and Remote File Disclosure

By | May 12, 2016

React Native is another cross-platform mobile development framework created by Facebook that developers can use to develop mobile applications on the Android and iOS platforms using JavaScript. From an architectural standpoint the framework is closer to Titanium or Kony than Cordova given that the mobile application uses JavaScriptCore as a standalone JS engine to execute the JS application code and the UI would be composed of native UI components as opposed to a HTML-based UI rendering in a WebView used in Cordova-based applications.

Anyways, I identified a number of vulnerabilities in the development server a couple months ago. During the development process, a Node.js based web server will be running in the background on the developer’s machine. The purpose of the development server is to serve resources such as application JavaScript code and other content, such as images, to the mobile device used during testing. Anytime the developer alters any of the JS code or assets the mobile application pulls down the new files from the development server. This allows for altering the application code without rebuilding the mobile application, which for a real world application might take minutes or hours.

Continue reading

Android Anti-Hooking Techniques in Java

By | December 23, 2015

A recent internal thread about detecting hooking frameworks in native code (C/C++) got me thinking about the different ways that a Java Android application can detect the presence of either Cydia Substrate or the Xposed framework.

Disclaimer: All of these anti-hooking techniques are easy to bypass by any experienced reverse engineer. I’m just exploring how one might go about detecting that their Java application has been hooked using Substrate or the Xposed framework because at some point we will need to be able to bypass these techniques to do our jobs just like how we bypass root detection on a daily basis. The last time I looked at DexGuard and Arxan’s Java protection product (GuardIT) they did not support detection of either hooking framework. I would expect similar anti-hooking techniques will be added to these Java obfuscation/protection products in the future.

Continue reading

Abusing UIWebView baseURL settings in the Cordova ChildBrowser Plug-in

By | April 3, 2015

The ChildBrowser plug-in is a popular third-party plug-in that allows displaying untrusted external websites within a Cordova-based application. It is very similar to the core InAppBrowser plug-in, which is the plug-in that Apache currently recommends using, since they both create a separate WebView instance that does not expose native mobile APIs to the untrusted HTML/JavaScript. Last year I disclosed a vulnerability that allowed the untrusted JavaScript in the InAppBrowser WebView to inject in JavaScript into the trusted Cordova WebView, which allowed for abusing of native mobile APIs remotely. While it doesn’t appear that the ChildBrowser plug-in is vulnerable to a similar JavaScript injection attack, under certain conditions the iOS version of the plug-in can be abused to load untrusted HTML/JavaScript code that executes under the file domain, which allows access to local files and sending those local files to remote servers since the same-origin policy works differently in this context.
Continue reading

Javelin Browser RCE and Password Manager Information Disclosure

By | April 2, 2015

There exists a number of third-party browsers in use on Android devices besides the stock browser and Chrome. PhoneArena provided a feature comparison and performance comparison of the “best” Android browsers in 2014, but I wasn’t familiar with a number of the browsers on the list so decided to take a look at the security of a few of them. The first one that I looked at named Javelin, previously known as Jerky due to its privacy features (not joking), and I identified that it was vulnerable to remote code execution due to improper use of the WebView addJavascriptInterface function on Android devices running a version less than 4.2. On Android devices running 4.2 and above, it shouldn’t be possible to use reflection to instantiate arbitrary classes, and invoke arbitrary functions, but we can still abuse the injected Java objects to acquire the passwords stored in the browser’s password manager remotely.

Continue reading

Cordova LaunchMyApp Plug-in Remote JavaScript Injection

By | December 17, 2014

The Cordova mobile application development framework does not support launching a mobile application via a custom URI scheme, such as someurischeme://pathhere/?param=somedata, out of the box on all of its supported platforms, which is somewhat surprising for a cross-platform mobile framework. Notably missing is support for custom URI schemes in the Android version of the framework, although custom URI schemes are supported by the iOS version of the framework. This has driven developers using the Cordova framework to either develop their own custom Cordova plug-ins to add support for this IPC mechanism or use an open-source 3rd party Cordova plug-in. One of the most popular 3rd party plug-ins with over 30k downloads named LaunchMyApp, or Custom URL Scheme, solves this problem well. I identified that multiple versions of this plug-in suffer from a JavaScript injection vulnerability that is trivial to exploit remotely. The main author of the plug-in quickly remediated the issue in version 3.2.1 by escaping the untrusted input.
Continue reading

Exploitation of Open URL AJAX Requests and DOM-based XSS using CORS

By | December 9, 2014

I noticed a couple somewhat interesting vulnerabilities earlier this year that require the use of cross-origin resource sharing to exploit. Consider the following JavaScript code and assume that the getQueryString function returns the value of the “someUrl” parameter in the query string by parsing the document.location object. In the vulnerable page, the web application asks the user for sensitive data such as their name, credit card, and address, and the client-side JavaScript code submits this information via an AJAX request using the jQuery JavaScript library. The first vulnerability involves the fact that the no input validation existed on the “someUrl” parameter so the attacker could control where the data was submitted. This is similar to open URL redirection vulnerabilities, but given that there exists no redirection, I’ll call this an open URL AJAX request.

someUrl = getQueryParam('someUrl');
jQuery.ajax({url: someUrl, 
				data: jsonString,
				success: handleData,
				contentType : "application/json",
				type: "POST",

Continue reading

Understanding Fragment Injection

By | June 18, 2014

A colleague asked me about an Android vulnerability called fragment injection because of an article he read [1] and I think its worth diving into the details of the vulnerability. Fragment injection is a classic example of using reflection in an unsafe way (CWE-470) [2]. As in untrusted data from an Intent is used to determine which class is instantiated within the target Android application.

In order to understand fragment injection, we have to review Google’s PreferenceActivity class. The PreferenceActivity class pulls out the EXTRA_SHOW_FRAGMENT extra (:android:show_fragment) and the EXTRA_SHOW_FRAGMENT_ARGUMENTS extra (:android:show_fragment_args) from a received Intent [3].

String initialFragment = getIntent().getStringExtra(EXTRA_SHOW_FRAGMENT);
Bundle initialArguments = getIntent().getBundleExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS);

Then later calls the Fragment.instantiate function based on the untrusted input.

Fragment f = Fragment.instantiate(this, fragmentName, args);

The Fragment.instantiate function just loads and returns the desired Fragment class [4].

public static Fragment instantiate(Context context, String fname, Bundle args) {
       try {
              Class clazz = sClassMap.get(fname);
              if (clazz == null) {
                     // Class not found in the cache, see if it's real, and try to add it
                     clazz = context.getClassLoader().loadClass(fname);
                     sClassMap.put(fname, clazz);
              Fragment f = (Fragment)clazz.newInstance();
              if (args != null) {
                     f.mArguments = args;
              return f;

Continue reading