Zimperium zLabs is Raising the Volume: New Vulnerability Processing MP3/MP4 Media.

Following our discovery of vulnerabilities in the Stagefright library in April, Zimperium Mobile Threat Protection, zLabs VP of Research Joshua J. Drake continued researching media processing in Android. His continued research, which focused on remote attacks against current devices, led to the discovery of yet another security issue.

Meet Stagefright 2.0, a set of two vulnerabilities that manifest when processing specially crafted MP3 audio or MP4 video files. The first vulnerability (in libutils) impacts almost every Android device since version 1.0 released in 2008. We found methods to trigger that vulnerability in devices running version 5.0 and up using the second vulnerability (in libstagefright). Google assigned CVE-2015-6602 to vulnerability in libutils. We plan to share CVE information for the second vulnerability as soon as it is available.

What is the impact of this issue?

  • Confirmed remote code execution (RCE) impact via libstagefright on Android 5.0 and later.
  • Older devices may be impacted if the vulnerable function in libutils is used (using third party apps, vendor or carrier functionality pre-loaded to the phone).

What is the vulnerability ?
Processing specially crafted MP3 or MP4 files can lead to arbitrary code execution.

How the attack can be triggered ?

The vulnerability lies in the processing of metadata within the files, so merely previewing the song or video would trigger the issue. Since the primary attack vector of MMS has been removed in newer versions of Google’s Hangouts and Messenger apps, the likely attack vector would be via the Web browser.

  1. An attacker would try to convince an unsuspecting user to visit a URL pointing at an attacker controlled Web site (e.g., mobile spear-phishing or malicious ad campaign)
  2. An attacker on the same network could inject the exploit using common traffic interception techniques (MITM) to unencrypted network traffic destined for the browser.
  3. 3rd party apps (Media Players, Instant Messengers, etc.) that are using the vulnerable library.

How is Zimperium responding to these issues?

We notified the Android Security Team of this issue on August 15th. Per usual, they responded quickly and moved to remediate. They assigned CVE-2015-6602 to the libutils issue but have yet to provide us with a CVE number to track the second issue. We would like to thank Google for their cooperation for promptly including the fix in the upcoming Nexus Security Bulletin scheduled to be released next week.

Empowering end users and ZHA partners

At this point, we do not plan to share a proof-of-concept exploit for this new vulnerability with the general public. Once a patch is available, we will update our Stagefright Detector app to detect this vulnerability.

After reporting this vulnerability to Google we sent an update to our Zimperium Handset Alliance (ZHA) partners. We are planning to share proof-of-concept code with verified ZHA members  later this month. We encourage vendors to update their Android devices to incorporate the fix as soon as possible.

Impacting the ecosystem

As more and more researchers have explored various vulnerabilities that exist within the Stagefright library and associated libraries, we expect to see more vulnerabilities in the same area. Many researchers in the community have said Google has replied to their reported bugs saying that they were duplicate or already discovered internally.

The research provided by Zimperium in this area has been a catalyst for change. Following our initial Stagefright announcement, industry-leading vendors made a clear statement that security updates will be provided on a monthly basis. So far, two monthly Nexus Security Bulletins have already posted. Next week will be the third.

Detecting attacks with z9

At the heart of all Zimperium technology is our z9 engine, which has been trained with the capability to detect media processing attacks through all attack vectors. No additional update is required to detect this new pair of vulnerabilities. We are diligently monitoring sources for in-the-wild attacks.

You can read more information on vulnerabilities in Stagefright library below:

Follow us on twitter for other breaking announcements:

Follow Us

Attribution: OPM vs Sony

I read Top U.S. spy skeptical about U.S.-China cyber agreement based on today’s Senate Armed Services Committee hearing titled United States Cybersecurity Policy and Threats. It contained this statement:

U.S. officials have linked the OPM breach to China, but have not said whether they believe its government was responsible.

[Director of National Intelligence] Clapper said no definite statement had been made about the origin of the OPM hack since officials were not fully confident about the three types of evidence that were needed to link an attack to a given country: the geographic point of origin, the identity of the “actual perpetrator doing the keystrokes,” and who was responsible for directing the act.

I thought this was interesting for several reasons. First, does DNI Clapper mean that the US government has not made an official statement regarding attribution for China and OPM because all “three types of evidence” are missing, or do we have one, or perhaps two? If that is the case, which elements do we have, and not have?

Second, how specific is the “actual perpetrator doing the keystrokes”? Did DNI Clapper mean he requires the Intelligence Community to identify a named person, such that the IC knows the responsible team?

Third, and perhaps most importantly, contrast the OPM case with the DPRK hack against Sony Pictures Entertainment. Assuming that DNI Clapper and the IC applied these “three types of evidence” for SPE, that means the attribution included the geographic point of origin, the identity of the “actual perpetrator doing the keystrokes,” and the identity of the party directing the attack, which was the DPRK. The DNI mentioned “broad consensus across the IC regarding attribution,” which enabled the administration to apply sanctions in response.

For those wondering if the DNI is signalling a degradation in attribution capabilities, I direct you to his statement, which says in the attribution section:

Although cyber operations can infiltrate or disrupt targeted ICT networks, most can no longer assume their activities will remain undetected indefinitely. Nor can they assume that if detected, they will be able to conceal their identities. Governmental and private sector security professionals have made significant advances in detecting and attributing cyber intrusions.

I was pleased to see the DNI refer to the revolution in private sector and security intelligence capabilities.

How Do They Stack Up? The Mobile Web vs. Native Apps

Every day we’re faced with choices. Chocolate or vanilla? Cats or dogs? Ketchup or mustard? Pizza or salad? Pizza, always choose pizza. These everyday choices are all about personal preference, but they have a big impact on the way we live and even the way the world around us runs. If consumers only preferred ketchup, the condiment food industry would change. Production of ketchup would increase, marketing would focus only on ketchup-related advertising and restaurants would only order mass amounts of ketchup – sayonara, mustard.

The choices we make as consumers have a huge impact on the technology industry, which is why the mobile Web versus the native app story has been so prevalent in the changing business world.

Before diving deeper, it’s important to understand differences between a native app and the mobile Web. A native app is an application developed specifically for a mobile device; it is what a user downloads from an app store and installs on a smart phone. The mobile Web refers to a site optimized for mobile use, accessed on a mobile device. Think the Facebook app, versus accessing Facebook on a device through a mobile browser.

In an Opera Mediaworks Q2 state of mobile advertising report, it was found that while the U.S. relies heavily on native apps, the rest of the world has a preference for the mobile Web. This is an interesting find since most would assume that the native app would be preferred in the fast pace, need to know, gotta-have-it-now society we live in. Even mature markets like Europe and Japan have a higher usage of the mobile Web, making experts wonder where the U.S. stands on the developmental curve.

You may be wondering how this all comes into play. Why does it matter if I use a native app or the mobile Web? Who cares? Hackers, that’s who.

Cyber criminals are relentless; they will do whatever it takes to hack your phone and use your mobile habits to their advantage. If a hacker knows that U.S. mobile phone users are more prone to using native apps, then their strategy for hacking U.S. mobile users will be different than how they would attack other countries who prefer the native Web. Feeling vulnerable? Don’t stress just yet. Whether you prefer a native app or a mobile phone, we’ve compiled a helpful list of measures you can take to protect your mobile security.

  • Be conscious of the information you send through your mobile device. Banking details and social security numbers should always be communicated offline and in the most secure manner possible.
  • Take advantage of security tools that help prevent mobile hacks. Equip your mobile device with comprehensive security software. McAfee® Mobile Security is free for Android and protects you from potentially malicious mobile Websites as well as known bad apps.
  • Change your passwords frequently and always make them complex. Changing your passwords regularly will lessen your chances of a potential hack.

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


“ASP.NET MVC: Secure Data Transmission”

Guest Editor: Today’s post is from Taras Kholopkin. Taras is a Solutions Architect at SoftServe, Inc. In this post, Taras will review secure data transmission in the ASP.NET MVC framework.

Secure data transmission is a critical step towards securing our customer information over the web. In fact, many of our SoftServe applications are regulated by HIPAA, which has the following secure data transmission requirements:

  • Client-server communication should be performed via secured channel (TLS/HTTPS)
  • Client (front-end application) should not pass any PHI data in URL parameters when sending requests to the server
  • All data transmission outside of the system should be performed via secure protocol (HTTPS, Direct Protocol, etc.)

To satisfy this requirement, let’s examine how to secure data transmission in an ASP.NET MVC application.

Enable HTTPS Debugging
One of my favorite features introduced in Visual Studio 2013 is the ability to debug applications over HTTPS using IIS Express. This eliminates the need to configure IIS, virtual directories, create self signed certificates, etc.

Let’s begin by modifying our SecureWebApp from the ASP.NET MVC: Audit Logging blog entry to use HTTPS. First, select the SecureWebApp project file in the Solution Explorer. Then, view the Properties window. Notice we have an option called “SSL Enabled”. Flip this to true, and you will see an SSL URL appear:


Now, our SecureWebApp can be accessed at this endpoint: https://localhost:44301/.

RequireHttps Attribute
With HTTPS enabled, we can use the ASP.NET MVC framework to require transport layer encryption for our application. By applying the RequireHttps attribute, our application forces an insecure HTTP request to be redirected to a secure HTTPS connection. This attribute can be applied to an individual action, an entire controller (e.g. AccountController), or across the entire application. In our case, we will apply the RequireHttps attribute globally across the application. To do this, add one line of code to App_StartFilterConfig.cs:

public class FilterConfig { public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new HandleErrorAttribute()); //Apply HTTPS globally filters.Add(new RequireHttpsAttribute()); } }

After applying the require HTTPS filter, the application protects itself from insecure HTTP requests. Notice that browsing to http://localhost:8080/ results in a redirection to a secure https://localhost connection.

Now, it should be noted that the redirect uses the standard HTTPS port number 443. In Visual Studio, you will see a 404 error because the IIS Express instance is using port 44301. Don’t be alarmed, on a production system this will work as long as you are hosting your application on the standard HTTPS port 443.

Secure Cookies
Another important step for secure data transmission is protecting authentication cookies from being transmitted insecurely over HTTP. Because our entire site requires HTTPS, start by setting the requireSSL attribute to true on the httpCookies element in the web.config file:

<system.web> <httpCookies httpOnlyCookies=”true” requireSSL=”true” lockItem=”true”/> </system.web>

If you are using ASP.NET Identity, set the CookieSecure option to Always to ensure the secure flag is set on the .AspNet.Application cookie. This line of code can be added to the Startup.Auth.cs file:

app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, CookieHttpOnly = true, CookieSecure = CookieSecureOption.Always, LoginPath = new PathString(“/Account/Login”), … });

If you are using forms authentication, don’t forget to set requireSSL to true on the forms element to protect the .ASPXAuth cookie.

<authentication mode=”Forms”> <forms loginUrl=”~/Account/Login” timeout=”2880″ requireSSL=”true”/> </authentication>

After making these changes, login to the application and review the set-cookie headers returned by the application. You should see something similar to this:

HTTP/1.1 200 OK … Set-Cookie: ASP.NET_SessionId=ztr4e3; path=/; secure; HttpOnly Set-Cookie: .AspNet.ApplicationCookie=usg7rt; path=/; secure; HttpOnly

HTTP Strict Transport Security
Finally, we need to add HTTP Strict Transport Security (HSTS) protection to the application. This protection instructs the browser to always communicate with a domain over HTTPS, even if the user attempts to downgrade the request to HTTP. The HSTS header also happens to prevent HTTP downgrade attack tools, such as sslstrip, from performing man-in-the-middle attacks. More information on this tool can be found in the references below.

With IE finally adding support for the HSTS header in IE11 and Edge 12, all major browsers now support the Strict-Transport-Security header. Once again, one line of code is added to the Global.asax.cs file:

protected void Application_EndRequest() { Response.AddHeader(“Strict-Transport-Security”, “max-age=31536000; includeSubDomains;”); }

The max-age option specifies the number of seconds the browser should upgrade all requests to HTTPS (31536000 seconds = 1 year), and the includeSubDomains option tells the browser to upgrade all sub-domains as well.

Alternatively, you can preload your web site’s domain into browser installation packages by registering in the Chrome pre-load list: https://hstspreload.appspot.com/

For more information on security-specific response headers for ASP.NET applications, there is an open source tool that you can use to automatically set the HSTS header. The Security Header Injection Module (SHIM) can be downloaded via NuGet. More information can be found in the link below.

Making these minor configuration and code changes will ensure your data is secure in transit! To learn more about securing your .NET applications, sign up for DEV544: Secure Coding in .NET!


About the author
Taras Kholopkin is a Solutions Architect at SoftServe, and a frequent contributor to the SoftServe United blog. Taras has worked more than nine years in the industry, including extensive experience within the US IT Market. He is responsible for software architectural design and development of Enterprise and SaaS Solutions (including Healthcare Solutions).

iOS 9 security: A reality check

By zLabs :: Jimmy Shah

Apple has released iOS 9 with a large number of security fixes. Zimperium recommends that iOS users install the latest iOS update.

There are 60+ vulnerabilities present in iOS 8.x that are fixed in the upgrade to iOS 9. The vulnerabilities include the ones that are exploitable remotely and locally. Impacted devices include the iPhone 4s, 5th Generation iPods, and iPad 2’s and newer.

Local attacks

Local attackers can do significant damage when in possession of an iOS device. Attackers are able to get unlimited attempts to brute force the device lock code by resetting the attempt limit – something that can be achieved restoring from a backup.

A significant amount of sensitive OS and user specific information can be acquired by attackers. These include password information, private keys, and visited websites. Local attackers are also able to execute arbitrary code, some with system level privileges.

Remote Attacks

Attackers without physical control of iOS devices have the ability to steal information and execute code. Remote attacks range from the creation of malicious cookies to leaking sensitive information.

Local vulnerabilities, Remote Vulnerabilities - (Source: zLabs, Zimperium)

Nearly a quarter of the vulnerabilities patched in iOS 9 were exploitable by local attackers.

App User Interface Spooling

A small number of vulnerabilities can allow an attacker to spoof the User Interface of legitimate apps and websites. This could allow the attacker to pose as a legitimate app to fool the user into providing sensitive information(e.g. passwords, usernames, credit card numbers).

Information Leakage

Attackers can gain information on OS structures and memory layout to aid in further exploit development.

Much of the information leakage is only accessible to local attackers, making them a bit harder for an attacker to exploit. This also makes them much more effective when a successful exploit is created.

Privacy Leaks

User privacy is compromised by a group of vulnerabilities. The attacks vary from local attacks to remote or network attacks. Attackers can query Siri for notifications on locked devices. They can also respond to audio messages.

Visiting a malicious website can lead to code execution or simply steal browsing history and network activity.

(Source: zLabs, Zimperium)

The patched vulnerabilities leaked both personal and system information.

Arbitrary code execution with System or Kernel privileges

Attackers have a number of vulnerabilities that can be exploited to execute code on iOS devices. An attacker able to execute code as a regular user on a device is troublesome, more so when they can escalate privileges and gain root level access.

Loading a crafted font or text file can result in a local attacker running arbitrary code. An attacker can also use a crafted app to gain System level privileges. Malicious apps count for some of the successful attacks that lead to attackers getting their code running on iOS devices.
(Source: zLabs, Zimperium)

Attackers can execute arbitrary code on iOS devices, but some vulnerabilities will give system or kernel privileges.

iOS 9 update fixes multiple vulnerabilities

Zimperium highly recommends that iOS users update all potentially affected devices to iOS 9. Numerous vulnerabilities that could lead to arbitrary code execution and/or the leaking of sensitive information have been patched.

Follow @Zimperium, @zLabs 

Follow Us