Waze | Another way to track your moves

Millions of drivers use Waze, a Google-owned navigation app, to find the best, fastest route from point A to point B. And according to a new study, all of those people run the risk of having their movements tracked by hackers.

Researchers at the University of California-Santa Barbara recently discovered a Waze vulnerability that allowed them to create thousands of “ghost drivers” that can monitor the drivers around them—an exploit that could be used to track Waze users in real-time. They proved it to me by tracking my own movements around San Francisco and Las Vegas over a three-day period.

“It’s such a massive privacy problem,” said Ben Zhao, professor of computer science at UC-Santa Barbara, who led the research team.

Here’s how the exploit works. Waze’s servers communicate with phones using an SSL encrypted connection, a security precaution meant to ensure that Waze’s computers are really talking to a Waze app on someone’s smartphone. Zhao and his graduate students discovered they could intercept that communication by getting the phone to accept their own computer as a go-between in the connection. Once in between the phone and the Waze servers, they could reverse-engineer the Waze protocol, learning the language that the Waze app uses to talk to Waze’s back-end app servers. With that knowledge in hand, the team was able to write a program that issued commands directly to Waze servers, allowing the researchers to populate the Waze system with thousands of “ghost cars”—cars that could cause a fake traffic jam or, because Waze is a social app where drivers broadcast their locations, monitor all the drivers around them.

 

The attack is similar to one conducted by Israeli university students two years ago, who used emulators to send traffic bots into Waze and create the appearance of a traffic jam. But an emulator, which pretends to be a phone, can only create the appearance of a few vehicles in the Waze system. The UC-Santa Barbara team, on the other hand, could run scripts on a laptop that created thousands of virtual vehicles in the Waze system that can be sent into multiple grids on a map for complete surveillance of a given area.

In a test of the discovery, Zhao and his graduate students tried the hack on a member of their team (with his permission).

“He drove 20 to 30 miles and we were able to track his location almost the whole time,” Zhao told me. “He stopped at gas stations and a hotel.”

 

Last week, I tested the Waze vulnerability myself, to see how successfully the UC-Santa Barbara team could track me over a three-day period. I told them I’d be in Las Vegas and San Francisco, and where I was staying—the kind of information a snoopy stalker might know about someone he or she wanted to track. Then, their ghost army tried to keep tabs on where I went.

Users could be tracked right now and never know it.

– Ben Zhao, UC-Santa Barbara computer science professor
 

The researchers caught my movements on three occasions, including when I took a taxi to downtown Las Vegas for dinner:

And they caught me commuting to work on the bus in San Francisco. (Though they lost me when I went underground to take the subway.)

The security researchers were only able to track me while I was in a vehicle with Waze running in the foreground of my smartphone. Previously, they could track someone even if Waze was just running in the background of the phone. Waze, an Israeli start-up, was purchased by Google in 2013 for $1.1 billion. Zhao informed the security team at Google about the problem and made a version of the paper about their findings public last year. An update to the app in January of this year prevents it from broadcasting your location when the app is running in the background, an update that Waze described as an energy-saving feature. (So update your Waze app if you haven’t done so recently!)

“Waze constantly improves its mechanisms and tools to prevent abuse and misuse. To that end, Waze is regularly in contact with the security and privacy research community—we appreciate their help protecting our users,” said a Waze spokesperson in an emailed statement. “This group of researchers connected with us in 2014, and we have already addressed some of their claims, implementing safeguards in our system to protect the privacy of our users.”

The spokesperson said that “the concept of Waze is that we all work together to share information and impact the world around us” and that “users expect to offer certain information about their route in exchange for unparalleled navigation assistance.” Among the safeguards deployed by Waze is a “system of cloaking” so that a user’s location as displayed “from time to time within the Waze application does not represent such user’s actual, real time location.”


But those safeguards did not prevent real-time tracking in my case. The researchers sent me their tracking minutes after my trips, with accurate time stamps for each of my locations, meaning this cloaking system doesn’t seem to work very well.

“Anyone could be doing this [tracking of Waze users] right now,” said Zhao. “It’s really hard to detect.”

Part of what allowed the researchers to track me so closely is the social nature of Waze and the fact that the app is designed to share users’ geolocation information with each other. The app shows you other Waze drivers on the road around you, along with their usernames and how fast they’re going. (Users can opt of this by going invisible.) When I was in Vegas, the researchers simply populated ghost cars around the hotel I was staying at that were programmed to follow me once I was spotted.

“You could scale up to real-time tracking of millions of users with just a handful of servers,” Zhao told me. “If I wanted to, I could easily crawl all of the U.S. in real time. I have 50-100 servers, and could get more from [Amazon Web Services] and then I could track all of the drivers.”

Theoretically, a hacker could use this technique to go into the Waze system and download the activity of all the drivers using it. If they made the data public like the Ashley Madison hackers did, the public would suddenly have the opportunity to follow the movements of the over 50 million people who use Waze. If you know where someone lives, you would have a good idea of where to start tracking them.

Like the Israeli researchers, Zhao’s team was also able to easily create fake traffic jams. They were wary of interfering with real Waze users so they ran their experiments from 2 a.m. to 5 a.m. every night for two weeks, creating the appearance of heavy traffic and an accident on a remote road outside of Baird, Texas.

“No real humans were harmed or even interacted with,” said Zhao. They aborted the experiment twice after spotting real world drivers within 10 miles of their ghost traffic jam.

 

While Zhao defended the team’s decision to run the experiment live on Waze’s system, he admitted they were “very nervous” about initially making their paper about their findings public. They had approval from their IRB, a university ethics board; took precautions not to interfere with any real users; and notified Google’s security team about their findings They are presenting their paper at a conference called MobiSys, which focuses on mobile systems, at the end of June in Singapore.

 

“We needed to get this information out there,” said Zhao. “Sitting around and not telling the public and the users isn’t an option. They could be tracked right now and never know it.”

“This is bigger than Waze,” continued Zhao. The attack could work against any app, said Zhao, turning their servers into an open system that an attacker can mine and manipulate. With Waze, it’s a particularly sensitive attack because users’ location information is being broadcast and can be downloaded, but the attack on another app would allow hackers to download any information that users broadcast to other users or allow them to flood the app with fake traffic.

“With a [dating app], you could flood an area with your own profile or robot profiles and basically ruin it for your area,” said Zhao. “We looked at a bunch of different apps and nearly all of them had this near-catastrophic vulnerability.”

The scary part, said Zhao, is that “we don’t know how to stop this.” He said that servers that interact with apps in general are not as robust against attack as those that are web-facing.

“Not being able to separate a real device from a program is a larger problem,” said Zhao. “It’s not cheap and it’s not easy to solve. Even if Google wanted to do something, it’s not trivial for them to solve. But I want them to get this on the radar screen and help try to solve the problem. If they lead and they help, this collective problem will be solved much faster than if they don’t.”

“Waze is building their platform to be social so that you can track people around you. By definition this is going to be possible,” said Jonathan Zdziarski, a smartphone forensic scientist, who reviewed the paper at my request. “The crowd sourced tools that are being used in these types of services definitely have these types of data vulnerabilities.”

Zdziarski said there are ways to prevent this kind of abuse, by for example, rate-limiting data requests. Zhao told me his team has been running its experiments since the spring of 2014, and Waze hasn’t blocked them, even though they have created the appearance of thousands of Waze users in a short period of time coming from just a few IP addresses.

Waze’s spokesperson said the company is “examining the new issue raised by the researchers and will continue to take the necessary steps to protect the privacy of our users.”

In the meantime, if you need to use Waze to get around but are wary of being tracked, you do have one option: set your app to invisible mode. But beware, Waze turns off invisible mode every time you restart the app.

Full paper here.

Credit:

[CRITICAL] CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting. Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn’t immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.

That patch is available here.

 

Issue Summary:

Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack. The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack. Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

 

Technical information:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query. Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated. Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow. The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

Exploitation:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact. As you can see in the below debugging session we are able to reliably control EIP/RIP.

(gdb) x/i $rip => 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req (gdb) x/a $rsp 0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril! Failed exploit indicators, due to ASLR, can range from:

  • Crash on free(ptr) where ptr is controlled by the attacker.
  • Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.
  • Crash reading from memory pointed by a local overwritten variable.
  • Crash writing to memory on an attacker-controlled pointer.

We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.

 

 

Credit:  Fermin J. Serna and Kevin Stadmeyer

FBI Links Chinese Government to DDoS Attacks on US Websites

 

The FBI says it has credible evidence to link the Chinese government to attackers who leveraged two Chinese telecom companies and the Baidu search engine to carry out recent distributed denial of service (DDoS) attacks targeting unnamed U.S. websites.

The FBI issued a confidential Flash Alert to U.S. companies alleging that the Chinese government sanctioned activities in which Internet traffic was “manipulated to create cyber attacks directed at U.S.-based websites” using man-in-the-middle (MitM) techniques.

“Analysis by the U.S. government indicated that Internet traffic which originated outside China, was intercepted and modified to make unsuspecting users send repeated requests to U.S.-based websites,” the Flash Alert reportedly said.

“The malicious activity occurred on China’s backbone Internet infrastructure, and temporarily disrupted all operations on the U.S.-based websites.”

Analysis of the attacks revealed that malware was injected into the browsers of users when web traffic reached China Unicom or China Telecom networks – both state-owned telecommunications companies – “at the same points in these routes that censor traffic for the Chinese government.”

“The location of the [man-in-the-middle] system on backbone networks operating censorship equipment indicates that the [man-in-the-middle] attack could not have occurred without some level of cooperation by the administrators of these systems,” the Alert said.

“The malicious Javascript would direct the unsuspecting user’s browsers to make repeated requests to targeted U.S.-based websites.”

While the FBI Flash Alert did not specify which company’s websites were attacked, it is likely that the popular web-based software developers collaboration platform GitHub was among those targeted.

Researchers from the University of California at Berkeley, the University of Toronto, and Princeton recently published details of a powerful Chinese MitM tool dubbed the “Great Cannon,” which was used in DDoS attacks targeting websites operated by the anti-censorship project GreatFire.org, and later connected to the attacks on GitHub.

“Specifically, the Cannon manipulates the traffic of ‘bystander’ systems outside China, silently programming their browsers to create a massive DDoS attack,” the researchers said.

“The operational deployment of the Great Cannon represents a significant escalation in state-level information control: the normalization of widespread use of an attack tool to enforce censorship by weaponizing users.”

GitHub was likely targeted because GreatFire.org had begun to mirror some content on the platform. The attacks against GreatFire employed the same techniques as those seen in the GitHub attack, which leveraged hijacked Internet traffic.

“The web browser’s request for the Baidu javascript is detected by the Chinese passive infrastructure as it enters China. A fake response is sent out from within China instead of the actual Baidu Analytics script. This fake response is a malicious javascript that tells the user’s browser to continuously reload two specific pages on GitHub.com,” analysis of the attack revealed.

This analysis aligns with details of the GreatFire.org attacks which was released previously.

“Millions of global internet users, visiting thousands of websites hosted inside and outside China, were randomly receiving malicious code which was used to launch cyber-attacks against GreatFire.org’s websites. Baidu’s Analytics code (h.js) was one of the files replaced by malicious code which triggered the attacks,” officials at GreatFire.org said.

“Baidu Analytics, akin to Google Analytics, is used by thousands of websites. Any visitor to any website using Baidu Analytics or other Baidu resources would have been exposed to the malicious code.”

GreatFire.org said it has conclusive evidence that the Chinese government using the nation’s infrastructure to conduct the attacks, and had previously published a detailed report, which was further backed up by the analysis provided by the university researchers.

“We show that, while the attack infrastructure is co-located with the Great Firewall, the attack was carried out by a separate offensive system, with different capabilities and design, that we term the Great Cannon,” the researchers wrote.

“The Great Cannon is not simply an extension of the Great Firewall, but a distinct attack tool that hijacks traffic to (or presumably from) individual IP addresses, and can arbitrarily replace unencrypted content as a man-in-the-middle.”

 

 

Credit:  Anthony M. Freed

Critical SSL Vulnerability Leaves 25,000 iOS Apps Vulnerable to Hackers

Critical SSL Vulnerability Leaves 25,000 iOS Apps Vulnerable to Hackers
A critical vulnerability resides in AFNetworking could allow an attacker to cripple the HTTPS protection of 25,000 iOS apps available in Apple’s App Store via man-in-the-middle (MITM) attacks.
AFNetworking is a popular open-source code library that lets developers drop networking capabilities into their iOS and OS X products. But, it fails to check the domain name for which the SSL certificate has been issued.
Any Apple iOS application that uses AFNetworking version prior to the latest version 2.5.3 may be vulnerable to the flaw that could allow hackers to steal or tamper data, even if the app protected by the SSL (secure sockets layer) protocol.

 

Use any SSL Certificate to decrypt users’ sensitive data:
An attacker could use any valid SSL certificate for any domain name in order to exploit the vulnerability, as long as the certificate issued by a trusted certificate authority (CA) that’s something you can buy for $50.

This meant that a coffee shop attacker could still eavesdrop on private data or grab control of any SSL session between the app and the Internet,” reports SourceDNA, a startup company that provides code analysis services.

Like, for example, I can pretend to be ‘facebook.com‘ just by presenting a valid SSL certificate for ‘thehackernews.com.
The vulnerability, which is estimated to affect more than 25,000 iOS apps, was discovered and reported by Ivan Leichtling from Yelp.
AFNetworking had fixed the issue in its latest release 2.5.3 before the previous version 2.5.2, which fails to patch another SSL-related vulnerability.

 

Version 2.5.2 Failed to Patch the issue:
Previously it was believed that with the release of AFNetworking 2.5.2, the lack of SSL certificate validation issue had been eliminated that allowed hackers with self-signed certificates to intercept the encrypted traffic from vulnerable iOS apps and view the sensitive data sent to the server.
However, even after the vulnerability was patched, SourceDNA scanned for vulnerable code present in iOS apps and found a number of iOS apps till then vulnerable to the flaw.

 

Therefore, anyone with a man-in-the-middle position, such as a hacker on an unsecured Wi-Fi network, a rogue employee inside a virtual private network, or a state-sponsored hacker, presenting their own CA-issued certificate can monitor or modify the protected communications.

 

Apps from Big Developers found to be vulnerable. SERIOUSLY?
A quick check for iOS products with the domain name validation turned off; the security company found apps from important developers, including Bank of America, Wells Fargo, and JPMorgan Chase, likely to be affected.
SourceDNA also said that the iOS apps from top developers such as Yahoo and Microsoft, meanwhile, remained vulnerable to the HTTPS-crippling bug.
 
Prevention against the flaw:
Just to prevent hackers from exploiting the vulnerability, SourceDNA has not disclosed the list of vulnerable iOS apps.
However, the company advised developers to integrate the latest AFNetworking build (2.5.3) into their products in order to enable domain name validation by default.
SourceDNA is also offering a free check tool that could help developers and end users check their apps for the vulnerability.

 

Meanwhile, iOS users are also advised to check immediately the status of apps they use, especially those apps that use bank account details or any other sensitive information.
And before the developers of vulnerable apps release an update, users should avoid using any vulnerable version of the apps for the time being.

 

ZIMPERIUM discovered “DoubleDirect” MitM Attack

The new network attack vector “DoubleDirect” MitM Attack, Targets Android, iOS and OS X Users

Security researchers have discovered a new type of “Man-in-the-Middle” (MitM) attack in the wild targeting smartphone and tablets users on devices running either iOS or Android around the world.

 

The MitM attack, dubbed DoubleDirect, enables an attacker to redirect a victim’s traffic of major websites such as Google, Facebook and Twitter to a device controlled by the attacker. Once done, cyber crooks can steal victims’ valuable personal data, such as email IDs, login credentials and banking information as well as can deliver malware to the targeted mobile device.

 

San Francisco-based mobile security firm Zimperium detailed the threat in a Thursday blog post, revealing that the DoubleDirect technique is being used by attackers in the wild in attacks against the users of web giants including Google, Facebook, Hotmail, Live.com and Twitter, across 31 countries, including the U.S., the U.K. and Canada.
DoubleDirect makes use of ICMP (Internet Control Message Protocol) redirect packets in order to change the routing tables of a host — used by routers to announce a machine of a better route for a certain destination.

 

In addition to iOS and Android devices, DoubleDirect potentially targets Mac OSX users as well. However, users of Windows and Linux are immune to the attack because their operating systems don’t accept ICMP re-direction packets that carry the malicious traffic.

An attacker can also use ICMP Redirect packets to alter the routing tables on the victim host, causing the traffic to flow via an arbitrary network path for a particular IP,” Zimperium warned. “As a result, the attacker can launch a MitM attack, redirecting the victim’s traffic to his device.

Once redirected, the attacker can compromise the mobile device by chaining the attack with an additional Client Side vulnerability (e.g.: browser vulnerability), and in turn, provide an attack with access to the corporate network.

 

The security firm tested the attack and it works on the latest versions of iOS, including version 8.1.1; most Android devices, including Nexus 5 and Lollipop; and also on OS X Yosemite. The firm also showed users how to manually disable ICMP Redirect on their Macs to remediate the issue.

Zimperium is releasing this information at this time to increase awareness as some operating system vendors have yet to implement protection at this point from ICMP Redirect attacks as there are attacks in-the-wild,” the post reads.

 

The company has provided a complete Proof-of-Concept (PoC) for the DoubleDirect Attack, users can downloaded it from the web. It demonstrates the possibility of a full-duplex ICMP redirect attack by predicting the IP addresses the victim tries to connect to, by sniffing the DNS traffic of the target; the next step consists of sending an ICMP redirect packet to all IP addresses.

 
 

Credit: , thehackernews

 

Apple disabling the SSL3 support in Push Notification Service

Apple are about to disable SSL3 support in Apple Push Notification Service at Wednesday, October 29.

Developers experiencing issues with Provider Communication interface in the development environment consider immediate updating the code. After this date – Push notification using SSL3 will stop working.

Official apple notification is below

The Apple Push Notification service will be updated and changes to your servers may be required to remain compatible.

In order to protect our users against a recently discovered security issue with SSL version 3.0 the Apple Push Notification server will remove support for SSL 3.0 on Wednesday, October 29. Providers using only SSL 3.0 will need to support TLS as soon as possible to ensure the Apple Push Notification service continues to perform as expected. Providers that support both TLS and SSL 3.0 will not be affected and require no changes.

To check for compatibility, we have already disabled SSL 3.0 on the Provider Communication interface in the development environment only. Developers can immediately test in this development environment to make sure push notifications can be sent to applications.

POODLE Vulnerability found in all latest Checkpoint portals

checkpoint

POODLE Vulnerability found in all latest Checkpoint versions portals (Multi-Portal, GAIA WEBUI Portal, IPSO Portal, Secure Platform WEBUI, LoM card WEBUI)

In continuation to SHELLSHOCK bash vulnerability found exploitable in Checkpoint WEBUI the company is currently working on closing SSL 3 in all portals since found vulnerable for CVE-2014-3566 POODLE Bites vulnerability.

The Checkpoint sk102989 explains step by step procedure about disabling SSL 3 in all portals and howto enable IPS and HTTPS inspection protections in order to block the endpoint user browsers from successful SSL 3 negotiation in case the remote WEB site is trying to force it. The SK is being updated in mostly daily basis. There is no full solution for diskless IPSO systems can survive reboot  yet as well as pending solution for SmartPortal and LOM card WEBUI.

Of course all portals without solution provided shouldn’t be normally available from unsecured networks because designed to manage OS and hardware settings only.

All Checkpoint customers should check their publicly available portals and use the SK in order to fix. In addition it is highly recommended to disable the SSL 3 protocol on browser and network inspection gateways (UTM, Antivirus, Proxies).

There are free online tools customers can easely use in order to verify SSL 3 protocol support as well as POODLE vulnerability and configuration issues for their public portals

Most popular Android apps open users to MITM attacks

SSL Vulnerabilities: Who listens when Android applications talk?

Summary

The Android ecosystem is all about communicating, and right now it’s screaming for help. That’s because SSL vulnerabilities and the Man-In-The-Middle (MITM) attacks they enable are wreaking havoc on data security. The scariest part? SSL vulnerabilities are evident in many of today’s most popular applications as we recently uncovered.

The FireEye Mobile Security Team analyzed Google Play’s most downloaded Android applications and found that a significant portion of them are susceptible to MITM attacks. These popular apps allow an attacker to intercept data exchanged between the Android device and a remote server. We notified the developers, who acknowledged the reported vulnerabilities and addressed them in subsequent versions of their applications.

Our researchers also constructed a MITM attack demonstration for each of the case studies in this blog. We did not use the infrastructure to glean any private or personal information of any user, other than that of the synthetic user we created to demonstrate the applications mentioned.

Introduction

Mobile applications often talk to remote servers for their functionality. Applications can communicate using the HTTP protocol, which makes it easy for others to intercept data, or the HTTPS protocol – which makes it harder, if not impossible, to intercept data. The security properties of HTTPS stem from Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS).

The Android platform provides libraries and methods to communicate with a server using these secure network protocols, forming the underpinnings of Public-Key Infrastructure (PKI). But, while the SSL/TLS protocol is designed for enhanced security, incorrect use of the Android platform’s SSL libraries can expose applications to MITM attacks. In these attacks, an MITM attacker intercepts traffic from the application to a server or vice versa and may:

  • be a quiet listener that ex-filtrates data sent either by the application or by the server,
  • intercept data from the server and either modify or replace it with malicious data that gets injected into the application, and
  • redirect traffic to an entirely new destination controlled by the attacker.

For a clearer explanation of MITM attacks, at the end of this blog we included a detailed walk-through of the attack mechanics .

Detecting SSL Vulnerabilities in Android

The following is a subset of the SSL/TLS vulnerabilities that we analyzed using our Mobile Threat Prevention platform:

  • The use of trust managers that do not check certificate chains from remote servers, making it possible for an MITM attack to succeed.
    • Verifying certificates to ensure that they are signed by a known and trusted Certifying Authority (CA) is an integral part of certificate- based, client-server communication.
  • The replacement of platform hostname verifiers by application hostname verifiers that do not verify the hostname of the remote server.
    • Having a trust manager that checks certificates is not sufficient in this case, as the attacker may have a certificate signed by a trusted certifying authority and may present a valid certificate chain. Therefore, to prevent a MITM attack, the hostname of the server extracted from the CA-issued certificate must match the hostname of the server the application intends to connect,
  • Applications ignoring SSL errors when they use WebKit to render server pages in mobile applications.
    • With server communications that use SSL/TLS, any errors generated should be caught. Otherwise we open up the vulnerable applications to MITM attacks that may exploit vulnerabilities such as Java-script Binding Over HTTP (JBOH).

SSL Vulnerabilities in the Google Play 1,000 Most Downloaded Applications

We reviewed the 1,000 most-downloaded free applications in the Google Play store as of July 17, 2014. Of these, 674 (~68%) have at least one of the three SSL vulnerabilities that we studied. In Figure 1, we present the number of vulnerable applications we found in each category:

  • Using trust managers that do not check certificates
    • Of the 614 applications that use SSL/TLS to communicate with a remote server, 448 (~73%) do not check certificates
  • Using hostname verifiers that do nothing
    • 50 (~8%) use their own hostname verifiers that do not check hostnames
  • Ignoring SSL errors in Webkit
    • Of the 285 that use Webkit, 219 (~77%) ignore SSL errors generated in Webkit

androidssl1

Figure 1. SSL vulnerabilities in the Google Play top 1000 applications

SSL Vulnerabilities at Large

We analyzed roughly 10,000 applications from the Google Play store. This was a random sample of free applications. Roughly 4,000 (40%) use trust managers that do not check server certificates, exposing any data they exchange with their servers to potential theft. Furthermore, around 750 (7%) applications use hostname verifiers that do not check hostnames, implying that they are incapable of detecting redirection attacks where the attacker redirects the server request to a malicious webserver controlled by the attacker. Finally, 1,300 (13%) do not check SSL errors when they use Webkit.

Case Studies (Applications rendered vulnerable due to vulnerable libraries)

Applications may use third-party libraries to enable part of their functionality. When these libraries have baked-in vulnerabilities, they are particularly dangerous because they make all applications that use them, and frequently the devices that run them, vulnerable. Furthermore, these vulnerabilities are not weaknesses in the applications themselves, but in the features they rely upon for functionality.

Flurry. Flurry is the number-one ranked ad library in the market used by 9,702 out of 70,000+ Google Play apps with 50,000 or more downloads. These applications have been downloaded over 8.7 billion times. As with many ad libraries, Flurry (prior to version 3.4) uses HTTPS with a vulnerable trust manager to upload information like device IMEI and location.

In a proof of concept for an MITM attack, we successfully used a vulnerable version of Flurry to capture the information sent to the remote server https://data.flurry.com. We successfully matched the location of the simulation device against the data being sent by Flurry. In Figure 2, we show a hexdump of the data we captured during this MITM attack.

Ad libraries enable the delivery of targeted advertisements by transmitting sensitive user information, but it is essential that they use HTTPS to send it in a manner that protects against MITM attacks.  The potential privacy breach is compounded when users are unaware of the ad libraries used and how their personal information can be read by unintended recipients.

androidssl2

Figure 2. Hexdump of the data that is being sent using insecure HTTPS

The presence of this vulnerability was communicated to the Flurry developers. They acknowledged the vulnerability was addressed starting in version 3.4 of the ad library.

Chartboost. Chartboost is an ad library used by 5,170 of 70,000+ Google Play apps with 50,000 or more downloads. The aggregate download count for all these applications is over 4.5 billion. Chartboost also used a trust manager that is vulnerable to MITM attacks. In this experimental setup, we intercepted traffic that contains the device IMEI sent over SSL/TLS sockets. While Chartboost has addressed this vulnerability after version 2.0.1, a number of applications with over 5 million downloads in the Google Play store still use vulnerable versions of Chartboost.

The presence of these vulnerabilities was communicated to the developers of Chartboost. They acknowledged that the vulnerability was addressed in a release subsequent to 2.0.1 of the ad library.

Case Studies (Applications that are inherently vulnerable)

Camera360 Ultimate. This is an application that has more than 250 million downloads worldwide. The following is the description of the application from the Google Play store.

Camera360, loved by more than 250 million users globally, is No.1 camera app in many countries. Together with HelloCamera, Movie360, and Pink360, Camera360 provides a comprehensive suite of professional yet fun mobile photography options.
To make your life even easier, Camera360 has introduced Camera360 Cloud, a cloud platform that can help you manage, edit, store, and share your photos all in one place. Join the millions of users in enjoying these FREE services!

Besides inheriting SSL vulnerabilities from the ad libraries used by the application, none of the application’s trust managers uses check server certificates. In another proof-of-concept for an MITM attack that exploits these vulnerabilities, we intercepted all HTTPS traffic between the application and the remote servers it used, allowing us to potentially:

  1. Steal or inject photos/albums at random;
  2. Steal user’s login “local key” to the Camera360 cloud, and many other local device/user specifications (device model, android version, user nickname, user email account, etc.); and
  3. Intercept user credentials (Facebook, Twitter, Sina, QQ, etc.), or inject fake login pages/malicious Javascript to steal any account credentials.

The app has Javascript Binding Over HTTP (JBOH) together with many powerful permissions (camera, audio recording, video recording, etc.), which opens the door to even more sophisticated attacks.

These vulnerabilities were communicated to the Camera360 developers, who were highly proactive in fixing the reported issues and releasing an update addressing them on July 29, 2014.

Application “X”. This application has over 100M downloads and is one of the fastest-growing applications in the Google Play marketplace. Similar to Camera360, Application “X” does not check server certificates when establishing SSL connections. This app’s core functionality pushes images of interest to users. This functionality can be hijacked using an MITM attack, allowing a hacker to inject malicious images into the application, launch a denial of service attack, or worse yet, hold a user’s data for ransom using a DOS attack.

Repeated attempts to contact the developers of Application “X” went unanswered. We therefore chose to anonymize the name of the application until a fix is put in place.

Best Practices

For a detailed explanation of common SSL pitfalls and ways to alleviate them, please see Android Security-SSL. Any application connecting to a third-party web service is likely automatically able to verify server certificates and hostnames.  These platforms usually have more than 100 CAs, and will validate any third-party server that presents a certificate signed by any of them.

If the server certificate is self-signed or comes from a CA the Android platform doesn’t trust, it requires the attention of the application developer. In these cases, the steps to use a custom trust manager are as follows:

  1. Create a KeyStore and set its certificate entry to the certificate to authenticate against
  2. Initialize a TrustManager instance with the KeyStore
  3. Use this instance of the TrustManager class in SSLContext objects used to establish remote server connections

Mobile device users can protect themselves by not accessing websites that require user login credentials when using public wi-fi networks. This in itself, with general vigilance in opening emails from unknown sources, will go a long way in protecting sensitive information from MITM attacks.

We hope that publications like this encourage application developers to stay current on the versions of third-party libraries they use, and to talk to the developers of third-party libraries to ensure the end users’ privacy is not compromised through backdoors.

Acknowledgments: We would like to thank Tao Wei and Dawn Song for their technical inputs that lead to developing of the SSL vulnerability detection capability, and Rebecca Stroder, Kyrksen Storer and the team behind the FireEye Mobile Threat Prevention Platform for their feedback. We also acknowledge the developers of Camera360 Ultimate, Flurry, and Chartboost for being proactive in fixing all reported issues.

Appendix: MITM Attacker and the Mechanics of an MITM Attack

As shown in Figure 3, a Man-In-The-Middle (MITM) attack works as follows:

  • Alice initiates a conversation with Bob
  • Mallory intercepts the conversation and relays the request to Bob
  • Bob responds, Mallory intercepts the response and forwards it to Alice

Neither Alice nor Bob are aware of Mallory’s presence. In our scenario, Alice is an Android application and Bob is the remote server. Mallory is a Man-In-The-Middle attacker with Internet access. Correct use of the platform SSL/TLS library would prevent Mallory from masquerading as Bob in his communication with Alice, and as Alice in her communication with Bob.

androidssl3

Figure 3. A Man-In-The-Middle attack flow

An MITM attacker has access to the Internet and controls a network proxy to direct all traffic originating from a network, such as a wi-fi network, to the Internet. Setting up an MITM attack is as easy as having access to the network proxy and using an off-the-shelf MITM proxy in place of a standard proxy. A standard proxy is limited to setting up an opaque conduit for all communication with no mechanism to read the data that is actually sent. An MITM proxy, on the other hand, plays the role of Mallory in Figure 3, masquerading as the remote server to mobile clients and as the mobile client to the remote server. Public wi-fi networks such as those in airports, cafes, etc., are open to exploitation by such MITM attackers. These networks use basic configurations without firewalls, VPNs, or intrusion detection systems. Attackers build open networks to snoop data that passes between user devices and remote servers. Sophisticated MITM attackers may use phishing emails to change a user’s device configurations, directing all Internet traffic originating from the device to a proxy server they control.

 

 

 

Credits: Adrian Mettler, Vishwanath Raman and Yulong Zhang

DroidSheep – Android Application for Session Hijacking

DroidSheep – One-click session hijacking using your android smartphone or tablet computer.

DroidSheep

DroidSheep makes it easy to use for everybody. Just start DroidSheep, click the START button and wait until someone uses one of the supported websites. Jumping on his session simply needs one more click. That’s it.

What do you need to run DroidSheep?
– You need an android-powered device, running at least version 2.1 of Android
– You need Root-Access on your phone (link)
– You need DroidSheep

Which websites does DroidSheep support?
– amazon.de
– facebook.com
– flickr.com
– twitter.com
– linkedin.com
– yahoo.com
– live.com
– google.de (only the non-encrypted services like “maps”)

Download: droidsheep-current.apk

Website