Tag: android

ADVISORIES | January 17, 2020

Android (AOSP) Download Provider SQL Injection in Query Sort Parameter (CVE-2019-2196)

By Daniel Kachakil

A malicious application with the INTERNET permission granted could retrieve all entries from the Download Provider internal database, bypassing all currently implemented access control mechanisms, by exploiting an SQL injection in the sort parameter (ORDER BY clause) and appending a LIMIT clause, which allows expressions, including subqueries.

The information retrieved from this provider may include potentially sensitive information such as file names, descriptions, titles, paths, URLs (which may contain sensitive parameters in the query strings), cookies, custom HTTP headers, etc., for applications such as Gmail, Google Chrome, the Google Play Store, etc.

ADVISORIES |

Android (AOSP) Download Provider SQL Injection in Query Selection Parameter (CVE-2019-2198)

By Daniel Kachakil

A malicious application with the INTERNET permission granted could retrieve all entries from the Download Provider internal database, bypassing all currently implemented access control mechanisms by exploiting an SQL injection in the selection clause.

The information retrieved from this provider may include potentially sensitive information such as file names, descriptions, titles, paths, URLs (that may contain sensitive parameters in the query strings), cookies, custom HTTP headers, etc., for applications such as Gmail, Google Chrome, the Google Play Store, etc.

ADVISORIES |

Android (AOSP) TV Provider SQL Injection in Query Projection Parameter (CVE-2019-2211)

By Daniel Kachakil

A malicious application without any granted permission could retrieve all entries from the TV Provider internal database, bypassing all currently implemented access control mechanisms by exploiting an SQL injection in the projection parameter.

The information retrieved from this provider may include personal and potentially sensitive information about other installed applications and user preferences, habits, and activity, such as available channels and programs, watched programs, recorded programs, and titles in the “watch next” list.

RESEARCH | April 25, 2019

Internet of Planes: Hacking Millionaires’ Jet Cabins

By Daniel Martinez

The push to incorporate remote management capabilities into products has swept across a number of industries. A good example of this is the famous Internet of Things (IoT), where modern home devices from crockpots to thermostats can be managed remotely from a tablet or smartphone.

One of the biggest problems associated with this new feature is a lack of security. Unfortunately, nobody is surprised when a new, widespread vulnerability appears in the IoT world.

However, the situation becomes a bit more concerning when similar technologies appear in the aviation sector. Nowadays we can find Cabin Management and In-Flight entertainment systems that can be managed from mobile devices owned by crew members and/or passengers.

The systems I’ve analyzed in the research presented here, are deployed in business jets. The discovered vulnerabilities affect passenger and crew devices.

The Cabin Management System is based on a wireless access point installed onboard the aircraft that provides network connectivity from the mobile devices of passengers and crew members to the cabin server. The Android applications (and their iOS equivalents) for both vendors were developed by Rockwell Collins to manage the available cabin capabilities in the aircraft such as cabin temperature, light intensity and much more.

Manufacturer video promo: https://www.youtube.com/watch?v=pRA3AnPU1dE

The Android apps analyzed in this post are:

  1. Venue Cabin Remote by Rockwell Collins – Android Application Version 2.1.12 (Current Version 2.2.2) (https://play.google.com/store/apps/details?id=com.rockwellcollins.venue.cabinremote)
  2. Bombardier Cabin Control – Android Application Version 2.1.12 (Current Version 2.2.1) (https://play.google.com/store/apps/details?id=com.rockwellcollins.venue.cabinremote.bombardier)
Figure 1. Google Play Store: Bombardier Cabin Control Developed by Rockwell Collins
Figure 2. Google Play Store: Venue Cabin Remote developed by Rockwell Collins

The purpose of this post is to:

  • Provide an overview of the operations of these emergent systems, with a focus on the vulnerabilities that affect the Android mobile apps
  • Provide a detailed explanation on how to exploit them

The main vulnerabilities I’ve discovered in the systems are:

  • ZIP Files: Path traversal / Arbitrary File Write
  • Lack of Legitimacy Checking of the Server
    • Rockwell Collins Venue Cabin Remote Version 2.2.2 – Legit Connectivity AP Emulation https://youtu.be/8QRAlTBOatU
    • Unencrypted Communications

Based on the vulnerabilities found during the research, an attacker could create the following situations:

  • Deploy a rogue aircraft access point and write in the devices of the connected clients. This could lead to a full compromise of the device.
  • Deploy a rogue aircraft access point and capture credentials or application secrets used to get access to protected areas in the application managed by the crew members in the real aircraft access point.
  • Connect to a real aircraft access point and interact with the cabin devices using the application. This could lead to full access to the cabin capabilities via the application if the attacker gets the password to access protected application menus and create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.
  • Connect to a real aircraft access point and multicast other server configuration to force the devices that are connected to the network to get a new configuration file, this could lead to some dangerous situations like:
    • A full compromise of the client’s devices connected to the network.
    • Create situations of discomfort onboard an aircraft by altering the temperature to a higher or lower value or modifying light intensity, switching off or blinking.

Research Timeline:

  • 2018 February: IOActive discovers vulnerability
  • 2018 February: IOActive notifies vendor
  • 2019 April: IOActive advisory published

Dani Martinez – @dan1t0 (https://twitter.com/dan1t0)
Security Consultant

The complete research, including: full systems overview and analysis, vulnerability discoveries with the Android apps, and detailed exploit scenarios, can be found on the Technical Advisory Paper.

Get the Technical Advisory Paper
RESEARCH | November 3, 2018

Extracting Bluetooth Metadata in an Object’s Memory Using Frida

By Keith Makan

Here’s a script I wrote to extract information from the Bluetooth metadata in an object’s memory. The script makes use of the Frida instrumentation framework, and I’ll take a little time to explain a simple scripting methodology/thought framework for solving problems with Frida.

What you will need:

  1. Frida Server for your device https://www.frida.re/docs/installation/
  2. Frida script to run https://github.com/IOActive/BlueCrawl
  3. Target Android phone (preferably with root permissions)

Getting Started: Your first Script

Frida forwards APIs that wrap Java objects and introduce means to inspect them, modify them, or replace them. This API is implemented in JavaScript, so you have the advantage of anonymous functions and plenty of hook/callback-style API design.

The first useful call you need is Java.perform(function(){}). Here’s an example usage:
hello-world.js:

1 setTimeout(function(){
2 Java.perform(function(){
3 console.log("hello world!");
4 });
5 });

This is essentially a “hello world” Frida Script. We’re passing the setTimeout method in JavaScript for another function, Java.perform, which itself takes a function as an argument. We’re calling the console objects log method and passing it a string; we need to use the setTimeout method because it enables our actions in the JavaScript runtime. We need the Java.perform call because it enables our actions in the Frida Java runtime which inherits and mirrors from the actual runtime we’re targeting on the Android device.

To get it up and running, just grab the Frida server for your device, pop it on the disk and fire off the script from a non-mobile computer (this is essentially the Frida client, since the server runs on the mobile phone):

bullhead:/data/local/tmp # ./frida-server-12.1.0-android-arm64
_

You should see your terminal spit out a “hello world” string.

Now we can make use of other Java features from within the function to which we pass the Java class in the Frida runtime. We can do stuff like search through loaded classes and pull out an instantiated version of those classes, replace loaded instances with others, and more.

Here’s a quick example showing all of the loaded classes in the current application:

1 setTimeout(function (){
2 Java.perform(function (){
3 console.log("\n[*] enumerating classes...");
4 Java.enumerateLoadedClasses({
5 onMatch: function(_className){
6 console.log("[*] found instance of '"+_className+"'");
7 },
8 onComplete: function(){
9 console.log("[*] class enuemration complete");
10 }
11 });
12 });
13 });

When you run it, it should produce the following output:

In this example, we’re running Frida against the Android media service.

Another cool thing you can do is inspect Bluetooth specific classes. This is where BlueCrawl comes in: it basically searches through all the loaded classes and pulls out those with interesting Bluetooth information. Check out this example, showing all the devices dumped from a Bluetooth scanner app’s memory:

I’ve redacted the MAC addresses since some of these devices might not belong to me. 🙂

BlueCrawl also dumps information about Bluetooth sockets, and can actually show you the type of device and MAC address connected to it:

The current version’s features also include the ability to see:

  • loaded Bluetoothclasses
  • loaded BluetoothSocket and BluetoothServerSocket objects
  • loaded Bluetooth Device objects in memory, as stated above

I kept the features tight and as properly implemented as I could for the first iteration, so while it’s not a swiss army knife just yet, you should try this script for checks to determine whether:

  • Your Bluetooth spoofing tech is working properly
  • Apps are secretly scanning for Bluetooth devices
  • Apps are stealing Bluetooth information

More features are on the way once I get to know Frida a little more and finish some further testing.

Happy Scripting!

 

References and Reading

RESEARCH | September 22, 2015

Is Stegomalware in Google Play a Real Threat?

By Alfonso Muñoz
For several decades, the science of steganography has been used to hide malicious code (useful in intrusions) or to create covert channels (useful in information leakage). Nowadays, steganography can be applied to almost any logical/physical medium (format files, images, audio, video, text, protocols, programming languages, file systems, BIOS, etc.). If the steganographic algorithms are well designed, the hidden information is really difficult to detect. Detecting hidden information, malicious or not, is so complex that the study of steganalytic algorithms (detection) has been growing. You can see the growth in scientific publications (source: Scholar Google) and research investment by governments or institutions.
In fact, since the attacks on September 11, 2001, there has been a lot of discussion on the possibility of terrorists using this technology. See:
 
 
 
 
In this post, I would like to illustrate steganography’s ability to hide data in Android applications. In this experiment, I focus on Android applications published in Google Play, leaving aside alternative markets with lower security measures, where it is easier to introduce malicious code.
 
 
Is it possible to hide information on Google Play or in the Android apps released in it?
 
The answer is easy: YES! Simple techniques have been documented, from hiding malware by renaming the file extension (Android / tr DroidCoupon.A – 2011, Android / tr SmsZombie.A – 2012, Android / tr Gamex.A – 2013) to more sophisticated procedures (AngeCryption – BlackHat Europe October2014).
 
Let me show some examples in more depth:
 
 
Google Play Web (https://play.google.com)
 
Google Play includes a webpage for each app with information such as a title, images, and a text description. Each piece of information could conceal data using steganography (linguistic steganography, image steganography, etc.). In fact, I am going to “work” with digital images and demonstrate how Google “works” when there is hidden information inside of files.
 
To do this, I will use two known steganographic techniques: adding information to the end of file (EOF) and hiding information in the least significant bit (LSB) of each pixel of the image.
–      
 
          PNG Images
 
You can upload PNG images to play.google.com that hide information using EOF or LSB techniques. Google does not remove this information.
 
For example, I created a sample app (automatically generated – https://play.google.com/store/apps/details?id=com.wMyfirstbaskeballgame) and uploaded several images (which you can see on the web) with hidden messages. In one case, I used the OpenStego steganographic tool (http://www.openstego.com/) and in another, I added the information at the end of an image with a hex editor.
 
The results can be seen by performing the following steps (analyzing the current images “released” on the website):
Example 1: PNG with EOF
 
 
Step 2: Loot at the end of the file 🙂
Example 2: PNG with LSB
 
 
Step 2: Recover the hidden information using Openstego (key=alfonso)
 
JPEG Images
If you try to upload a steganographic JPEG image (EOF or LSB) to Google Play, the hidden information will be removed. Google reprocesses the image before publishing it. This does not necessarily mean that it is not possible to hide information in this format. In fact, in social networks such as Facebook, we can “avoid” a similar problem with Secret Book or similar browser extensions. I’m working on it…
 
https://chrome.google.com/webstore/detail/secretbook/plglafijddgpenmohgiemalpcfgjjbph?hl=en-GB
 
In summary, based on the previous proofs, I can say that Google Play allows information to be hidden in the images of each app. Is this useful? It could be used to exchange hidden information (covert channel using the Google Play). The main question is whether an attacker could use information masked for some evil purpose. Perhaps they could use images to encode executable code that “will exploit” when you are visiting the web (using for example polyglots + stego exploits) or another idea. Time will tell…
 
 
 
APK Steganography
 
Applications uploaded toGoogle Play are not modified by the market. That is, an attacker can use any of the existing resources in an APK to hide information, and Google does not remove that information. For example, machine code (DEX), PNG, JPEG, XML, and so on.
 
 
Could it be useful to hide information on those resources?
 
An attacker might want to conceal malicious code on these resources and hinder automatic detection (static and dynamic analysis) that focuses on the code (DEX). A simple example would be an application that hides a specific phone number in an image (APT?).
 
The app verifies the phone number, and after a few clicks in a specific screen on a mobile phone, checks if the number is equal to that stored in the picture. If the numbers match, you can start leaking information (depending on the permissions allowed in the application).
 
I want to demonstrate the potential of Android stegomalware with a PoC. Instead of developing it, I will analyze an active sample that has been on Google Play since June 9, 2014. This stegomalware was developed by researchers at Universidad Carlos III de Madrid, Spain (http://www.uc3m.es). This PoC hides a DEX file (executable code) in an image (resource) of the main app. When the app is running, and the user performs a series of actions, the image recovers the “new” DEX file. This code runs and connects to a URL with a payload (in this case harmless). The “bad” behavior of this application can only be detected if we analyze the resources of the app in detail or simulate the interaction the app used for triggering the connection to the URL.
 
Let me show how this app works (static manual analysis):
Step 1: Download the APK to our local store. This requires a tool, such as an APK downloader extension or a specific web as http://apps.evozi.com/apk-downloader/
Step 2. Unzip the APK (es.uc3m.cosec.likeimage.apk)
Step 3. Using the Stegdetect steganalytic tool (https://github.com/abeluck/stegdetect) we can detect hidden information in the image “likeimage.jpg”. The author used the F5 steganographic tool (https://code.google.com/p/f5-steganography/).
 
es.uc3m.cosec.likeimageresdrawable-hdpilikeimage.jpg
likeimage.jpg : f5(***)
Step 4. To analyze (reverse engineer) what the app is doing with this image, I use the dex2jar and jd tools.
Step 5. Analyzing the code, we can observe the key used to hide information in the image. We can recover the hidden content to a file (bicho.dex).
java -jar f5.jar x -p cosec -e bicho.dex likeimage.jpg
 
Step 6. Analyzing the new file (bicho.dex), we can observe the connection to http://cosec-uc3m.appspot.com/likeimage for downloading a payload.
 
Step 7. Analyzing the code and payload, we can demonstrate that it is inoffensive.
ZGV4CjAzNQDyUt1DKdvkkcxqN4zxwc7ERfT4LxRA695kAgAAcAAAAHhWNBIAAAAAAAAAANwBAAAKAAAAcAAAAAQAAACYAAAAAgAAAKgAAAAAAAAAAAAAAAMAAADAAAAAAQAAANgAAABsAQAA+AAAACgBAAAwAQAAMwEAAD0BAABRAQAAZQEAAKUBAACyAQAAtQEAALsBAAACAAAAAwAAAAQAAAAHAAAAAQAAAAIAAAAAAAAABwAAAAMAAAAAAAAAAAABAAAAAAAAAAAACAAAAAEAAQAAAAAAAAAAAAEAAAABAAAAAAAAAAYAAAAAAAAAywEAAAAAAAABAAEAAQAAAMEBAAAEAAAAcBACAAAADgACAAEAAAAAAMYBAAADAAAAGgAFABEAAAAGPGluaXQ+AAFMAAhMTUNsYXNzOwASTGphdmEvbGFuZy9PYmplY3Q7ABJMamF2YS9sYW5nL1N0cmluZzsAPk1BTElDSU9VUyBQQVlMT0FEIEZST00gVEhFIE5FVDogVGhpcyBpcyBhIHByb29mIG9mIGNvbmNlcHQuLi4gAAtNQ2xhc3MuamF2YQABVgAEZ2V0UAAEdGhpcwACAAcOAAQABw4AAAABAQCBgAT4AQEBkAIAAAALAAAAAAAAAAEAAAAAAAAAAQAAAAoAAABwAAAAAgAAAAQAAACYAAAAAwAAAAIAAACoAAAABQAAAAMAAADAAAAABgAAAAEAAADYAAAAASAAAAIAAAD4AAAAAiAAAAoAAAAoAQAAAyAAAAIAAADBAQAAACAAAAEAAADLAQAAABAAAAEAAADcAQAA
 
The code that runs the payload:
 
Is Google detecting these “stegomalware”?
 
Well, I don’t have the answer. Clearly, steganalysis science has its limitations, but there are other ways to monitor strange behaviors in each app. Does Google do it? It is difficult to know, especially if we focus on “mutant” applications. Mutant applications are applications whose behavior could easily change. Detection would require continuous monitoring by the market. For example, for a few months I have analyzed a special application, including its different versions and the modifications that have been published, to observe if Google does anything with it. I will show the details:
Step 1. The mutant app is “Holy Quran video and MP3” (tr.com.holy.quran.free.apk). Currently at https://play.google.com/store/apps/details?id=tr.com.holy.quran.free

Step 2.  Analyzing the current and previous version of this app, I discover connections to specific URLs (images files). Are these truly images? Not all.

Step 3. Two URLs that the app connects to are very interesting. In fact, they aren’t images but SQLite databases (with messages in Turkish). This is the trivial steganography technique of simply renaming the file extension. The author changed the content of these files:

Step 4. If we analyze these databases, it is possible to find curious messages. For example, recipes with drugs.

Is Google aware of the information exchanged using their applications? This example does not cease to be a mere curiosity, but such procedures might violate the policy of publication of certain applications on the market or more serious things.
 
Figure: Recipes inside the file io.png (SQLite database)

In summary, this small experiment shows that we can hide information on Google Play and Android apps in general. This feature can be used to conceal data or implement specific actions, malicious or not. Only the imagination of an attacker will determine how this feature will be used…


Disclaimer: part of this research is based on a previous research by the author at ElevenPaths