Android Stagefright multimedia viewer prone to remote exploitation

Published: 2015-07-28
Last Updated: 2015-07-28 20:32:12 UTC
by Rick Wanner (Version: 3)
2 comment(s)
Joshua J. Drake from Zimperium zLabs has reported a number of vulnerabilities in the Stagefright media playback system deployed in Android operating system devices. These vulnerabilities permit remote code execution when a specially crafted multimedia message (MMS) is sent to an Android device which can result in the device being compromised and Trojaned often exposing all data stored on the device. On some devices it appears that the MMS exploit can be executed with no intervention from the user and in some cases can be exploited completely invisible to the user.  
It looks like the issue affects all versions of Android 2.2 (Froyo, released 2010) and newer although there is some speculation that exploit mitigation controls in the Android Jelly Bean OS (version 4.1+) and newer may thwart some exploits, but the usefulness of these controls is unclear at this time..  It is also unclear from the information available today if patches are available.  Google has released patched code to the smartphone vendors, but it appears most device vendors have not yet released updated firmware to the public at this time. 

The CVE's for these vulnerabilities are:

CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828, CVE-2015-3829

​It should be assumed that almost all Android devices are vulnerable, so please keep an eye out for updated firmware for your device and apply the firmware as soon as available.


Update: Ugo sent a link to a blog post by Greg Bauges which describes some configuration changes which can be made on the Android device which will disable the automatic loading of MMS messages. While these changes do not stop the vulnerability from being exploited it at least makes it so the device user is aware the malicious MMS was received and run.

Update: I have been having discussions about the potential of these vulnerabilities for weaponization into a worm. Bruce Schneier has waded in with a similar idea.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - - Twitter:namedeplume (Protected)

Keywords: android stagefright
2 comment(s)
CVE-2015-5477 - Bind: Error handling TKEY queries can lead to Bind DDOS
Bind 9.9.7-P2 and Bind 9.10.2-P3 now available -

Guest Diary: Xavier Mertens - Integrating VirusTotal within ELK

Published: 2015-07-28
Last Updated: 2015-07-28 16:01:26 UTC
by Alex Stanford (Version: 1)
2 comment(s)

[Guest Diary: Xavier Mertens] [Integrating VirusTotal within ELK]

Visualisation is a key when you need to keep control of what’s happening on networks which carry daily tons of malicious files. is a key player in fighting malwares on a daily basis. Not only, you can submit and search for samples on their website but they also provide an API to integrate in your software or scripts. A few days ago, Didiers Stevens posted some SANS ISC diaries about the Integration of VirusTotal into Microsoft sysinternal tools (here, here and here). The most common API call is to query the database for a hash. If the file was already submitted by someone else and successfilly scanned, you’ll get back interesting results, the most known being the file score in the form “x/y”. The goal of my setup is to integrate within my ELK setup. To feed virustotal, hashes of interesting files must be computed. I’m getting interesting hashes via my Suricata IDS which inspect all the Internet traffic passing through my network.

The first step is to configure the MD5 hashes support in Suricata. The steps are described here. Suricata logs are processed by a Logstash forwarder and MD5 hashes are stored and indexed via the field ‘fileinfo.md5‘:

(Click to enlarge)

Note: It is mandatory to configure Suricata properly to extract files from network flows. Otherwise, the MD5 hashes won’t be correct. It’s like using a snaplen of ‘0’ with tcpdump. In Suricata, have a look at the inspected response body size for HTTP requests and the stream reassembly depth. This could also have an impact on performances, fine tune them to match your network behavior.

To integrate VirusTotal within ELK, a Logstash filter already exists, developed by Jason Kendall. The code is available on To install it, follow this procedure:

# cd /data/src
# git clone
# cd logstash-filter-virustotal
# gem2.0 build logstash-filter-awesome.gemspec
# cd /opt/logstash
# bin/plugin install /data/src/logstash-filter-virustotal/logstash-filter-virustotal-0.1.1.gem

Now, create a new filter which will call the plugin and restart Logstash.

filter {
    if ( [event_type] == "fileinfo" and
         [fileinfo][filename] =~ /(?i)\.(doc|pdf|zip|exe|dll|ps1|xls|ppt)/ ) {
        virustotal {
            apikey => '
            field => '[fileinfo][md5]'
            lookup_type => 'hash'
            target => 'virustotal'

The filter above will query for the MD5 hash stored in ‘fileinfo.md5‘ to virustotal;com if the event contains file information generated by Suricata and if the filename contains an interesting extension. Of course, you can adapt the filter to your own environment and match only specific file format using ‘fileinfo.magic‘ or a minimum file size using ‘fileinfo.size‘. If conditions match a file, a query will be performed using the API and results stored into a new ‘virustotal‘ field:

(Click to enlarge)

Now, it’s up to you to build your ElasticSearch queries and dashboard to detect suspicious activities in your network. During the implementation, I detected that too many requests sent in parallel to might freeze my Logstash (mine is 1.5.1). Also, keep an eye on your API key consumption to not break your request rate or daily/monthly quota.

2 comment(s)
ISC StormCast for Tuesday, July 28th 2015


Diary Archives