reviving android's hear t

libStageFright

Project Goals'Stage-fright' is the moniker given to a potential exploit that lives genuinely in the heart of Android framework itself. The significance is that any video sent by means of MMS could be utilized as a road of assault through the libStageFright library, which offers Android assistance with processing video files. Numerous messaging applications including Google's Hangouts automatically processes the video files so it's prepared for viewing as soon as one open's the message, thus the assault could happen without the user knowing about it.

As of today, only the applications on latest version of Android i.e. Marshmallow 6.0 stands immune to stage-fright, thereby leaving numerous applications on previous versions vulnerable. This puts more than a billion users who have devices with earlier versions of Android on a severe risk. Hence as a part of my OSS assessment, I have:

- Analyzed libstagefright in detail and exposed its vulnerabilities.- Came up with numerous attack vectors.- Conducted a survey and uncovered OSS Android applications still

vulnerable to stage-fright by probing them with nominated attack vectors. 

- Proposed mitigation techniques and patches to prevail over stage-fright.

libStageFrightAndroid gives a media playback engine in form of a local level library called libStagefright that comes worked in with software based codecs for a few mainstream media formats. libStagefright features for audio and video playback includes integrity with Open-MAX codecs, session administration, transport control, time-synchronized rendering, and DRM.

MEDIA ARCHITECTURE

The figure shows the media applications interact ing with the Android native multimedia framework.

- Application Framework: At the application system level is the application's code, which uses the android.media APIs to interface with the hardware.

- Binder IPC: The Binder IPC intermediaries encourage communication over process boundary. They are situated in the systems/av/media/libmedia registry and start with the letter "I".

- Local Multimedia Framework: At the local level, Android gives a multimedia system that uses the Stagefright engine for audio and video recording and playback. Stagefright accompanies a default rundown of bolstered software codecs

- Open-MAX Integration Layer (IL): The Open-MAX IL gives an institutionalized approach to Stagefright to perceive and utilize custom equipment based multimedia codecs. You should give an An Open-MAX module must be provided as a common library named libstagefrighthw.so. This module interfaces the custom codec segments to Stagefright. And these custom codecs must be actualized by Open-MAX IL part standard.

Vulnerabilities

Vulnerability: Heap OverflowTargets: Media Server

Impact: Critical

Vulnerability: Elevation of PrivilegeTargets: Haptic driver, Media Server

Impact: High

Vulnerability: Information DisclosureTargets: Exchange ActiveSync, Media Server

Impact: Moderate

Media Server becomes an easy target !

Media ServerThe Android's media server component processes the audio and video streams. Exploiting a vulnerability in media server, an attacker can run his code with the same permissions and privileges that the media server component already have as part of its normal routines. Lets try to look into the architecture of media server by means of the following screenshots.

The media server process runs in the background. It's a native service that's started at boot from /init.rc: As such, the process automatically restarts when it crashes.

Process Privileges: The last part of the service definition in /init.rc shows the privileges that the service runs with:

This service is highly privileged. Normal android apps cannot request/receive permissions like audio, camera, drmrpc, and mediadrm.

Below set of access to media server - can give almost unlimited access. This is nothing but privilege escalation in action.

- inet: can create AF_INET and AF_INET6 sockets (attacker can use this to connect to any hosts on internet)

- net_bt and net_bt_admin: Attacker can access and configure blue-tooth on victim device. - camera: An attacker can leverage this to control victims camera devices (front and back cam)- audio: An attacker can leverage this to record, playback and monitor audio.

An attacker can also control storage on victims phone, can reboot adb and get shell access. An

Attack Vector- MP4To understand how vulnerabilities in libStageFright can be exploited using MP4 video file, it is important to understand structure of an MP4 file. Is a collection of TLV (TypeLengthValue) chunks. This encoding method means there's a value called 'type' specifying the chunk type, a 'length' value of the data length and a 'chunk' value of the data itself.For MP4, the encoding 'length' comes first, then comes 'type' and in the 'chunk' value at the last. The following pseudo-C describes the MP4 chunk format:

When the length is 0, data reaches to end of the file. The atom field is a short string (also called FourCC) which describes the type of chunk. MP4 chunk which have more information than 2^32 bytes have different structure compared to above TLV

So how does this all happen?AwesomePlayer.cpp is a program written in C++, which executes when the malicious MP4 media file is played on the victims phone. Let's jump into code and see how it works.

It calls setDataSource_l (sp<MediaExtractor>).

setDataSource_l:

It will call MPEG4Extractor::countTracks:

Above code calls readMetaData, whereas the following code calls MPEG4Extractor.

This is where the attack takes place - when the MP4 file is parsed. The code from MPEG4Extactor.cpp - will collect all chunks and appends them into one singular buffer. The problem here is that there is no check on size and chunk_size (they are unchecked). The attacker in stagefright exploits an integer overflow.

Above code snippet, the output in size byte from data will be written to buffer irrespective of the actual allocated size of buffer. When heap is carefully shaped, the exploitation can be done very easily. It's a python program exploit, which does the integer overflow and makes a heap overflow. The python exploit will generate a malicious mp4 file, with chunks, size which will make mediaplayer crash and it will reboot again as root. The mp4 file payload also has Attacker's IP address and port on which it will listen on reverse TCP connection.

Defining arguments is a vital part here that establishes a back connection to the host on a pre-decided port number. This will be used to establish a reverse_tcp connection from the victims phone to the attacker machine.

Exploiting Heap OverflowSo, in this section we'll how to leverage the heap over flow exploit. I have followed the undergiven steps in order to accomplish this attack.

- Set up attacker machine - Generate malicious MP4 file- Start a listener (reverse_tcp) on attacker machine- Send the file using attack vectors.- Keep playing after attacker has got the connection.

STEP 1- Setting up attacker machine: We first shall check the IP address of the attacker machine. I have used Kali Linux as attacker machine to compromise victim's android phone.

Kali linux : 192.168.1.245 | Port to listen : 4444

STEP 2- Generating a malicious MP4 file: The generated MP4 file can be seen in below screen shot - funny.mp4

STEP 3- Start a listener on attacker machine: There are many alternatives to use be it netcat or metasploit. In this project I have used metasploit to to listen on to reverse TCP and perform numerous operations. Metasploit gives it more functionality in contrast to other utilities, we can get a meterpreter session and perform numerous tasks from accessing cameras, to mic, to get shell access, list process etc.

Let's choose the exploit which we are going to use. Here I'm just using handler which can receive a connection back from victim phone.

Setting up a reverse_tcp payload, to receive back connection. Now the configuration needs to be defined. such as LHOST,LPORT(attacker's IPand port to listen on)

After the configuration is set, we need to trigger the listener by using exploit keyword. After being triggered, it will wait for any back connection coming from victim phone to attacker machine at port 4444 which we configured in the malicious MP4 file previously.

STEP 4- Sending the malicious file to the victim: In general, number of attack vector is more than 11. MMS: The most dangerous is using MMS, the media file is auto downloaded in victim's phone and parsed thereby victim phone will be compromised without victim knowing it. Web Browser: Attacker can embed malicious MP4 file in a web link, which it could send to victim. If user clicks on the link - the reverse TCP is established. Browser auto download: If browser has capability to auto download a media file. The victim's phone could be compromised. Email: Sending the malicious MP4 file as an email attachment to victim.

Social networks: Chat clients such as hangouts, Whatsapp, Facebook messenger can be used to send the link. if auto download is enabled, then victim's phone is compromised. SD card: If attacker has physical access to victim's SD card, it can load mp4 file in SD card, when mounted, it will compromise victim's phone. There are many such possibilities to deliver the MP4 file to victim. The vulnerable code present in mp4 file is invoked many times in Android system. Whenever a thumbnail is rendered or metadata is needed. Rotating the screen, launching the Messaging app , opening Gallery, sharing malicious mp4/media and many more.For this project I have used, Email as an attack vector. For victim device I have used - a virtual android.

The Media server crashes when playing the video and restarts as root. This sends a back connection to our attacker machine, which is waiting for a connection.STEP 5- Keep playing after getting the back connection: After the victim has received the MP4 file and has either downloaded or auto downloaded. Our metasploit gets a back connection and opens a meterpreter session.

Meterpreter session has been opened, we can check whatever processes are running on victim's phone. The command used is ps.

Let's check IP address and interface details of our victim phone.

Let's see if we can pull out system info of our victim's phone. sysinfo command in meterpreter provides us system details.

An attacker can also get shell access to victim's phone:

Check if the device is rooted.

An attacker can also dump contacts from victim's phone.

An attacker can check folders and files on android file system by giving ls command in shell .

Mounting an attack on a real android device.

Remotely clicking a picture by gaining unauthorized access to front camera

And Hacked!

Frame captured from the front camera of the victims phone.

Attacking Live

Vulnerability AnalysisThe mediaserver segment in the vulnerable Android versions can't accurately handle a malicious MP4 video file. At the point when such a MP4 video file is brought into mediaserver, it might trigger a heap overflow and overwrite data in the heap. This can prompt code execution, which could permit applications to be downloaded onto the device. The underlying driver of this vulnerability is a integer overflow while parsing a MP4 record, making memory be composed out of the buffer. In particular, it happens when mediaserver it parses tx3g-hailed data; this is regularly used to give content subtitles. The influenced code can be found in structures/av/media/libstagefright/MPEG4Extractor.cpp:

Still writes 0x100000 bytes in 1 byte

Fist time:chunk_size == 0x100000Second time: chunk_size == 0xFFF00001. Then,0x100000 + 0xFFF00001 = 1, allocate 1 byte indeed.

Other Attack VectorsI tested two scenarios which can be utilized to target media-server. I used the adb shell top | grep mediaserver command to the process; and that can be seen because media-server?s PID or Process Identification Number changed, and the process got crashed and restarted again. Scenario 1: Attacking from an ApplicationHere, I'll demonstrate how thie heap overflow vulnerability can be exploited from within an application. The specially crafted malicious MP4 file will lead mediaserver?s heap to be destroyed. In this demonstration, the mediaserver only crashes, but an attacker can also construct a specific data block to fill the heap and hence gain control of the execution flow.

Scenario 2: Attacking from a URLI embedded the same malicious MP4 file into an HTML file as shown below, which I then uploaded to a web-server. A victim using the built in Web-View in Android 5.1.0 to access the website, the same problems seen in scenario happen.

Also, even though the mobile Google Chrome browser has disabled pre-loading and auto-play of video files embedded within the <video> tag, the malformed file still causes the media-server heap overflow. Somehow this limitation has been bypassed.

This URL contains malicious MP4 video file.

MitigationThe vulnerabilities in libStageFright are genuinely intense as they can be adequately controlled by the assailant, which implies he can choose when to begin the assault furthermore when to stop. The mediaserver manages video and sound related errands, for example, opening and perusing MP4 files, interpreting/encoding a MPEG4 stream, taking pictures, recording videos and sound, and much more. An aggressor would have the capacity to run their code with the same authorizations that mediaserver as of now has as a component of its normal routines. The accompanying abilities diminish the probability that security vulnerabilities in libStageFright could be effectively misused on Android.

- Misuse for some issues on Android is made more troublesome by improvements in more current variants of the Android versions. I urge all users to overhaul to the most recent version of Android where conceivable.

- The Android Security group is effectively observing for misuse with Verify Apps and SafetyNet, which will caution the client about identified conceivably malicious applications going to be introduced. For example, device rooting tools are restricted inside Google Play. To shield users who introduce applications from outside of Google Play, Verify Apps is empowered naturally and will caution users about known establishing applications. Check Apps endeavors to recognize and square establishment of known vindictive applications that adventure a benefit acceleration vulnerability. In the event that such an application has as of now been introduced, Verify Apps will notify the users and endeavor to remove any such applications.

- As suitable, Google Hangouts and Messenger applications don't naturally pass media to mediaserver.

AuthorParul Sharma

Cybersecurity Graduate StudentNew York University