Jump to content

Blog

Shield

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


The Unknown Threat in Sweden – KPMG Study

During recent years, we have observed an increase of severe cyber attacks targeting classified financial information, legal acts, business communication, and military or other governmental highly sensitive information.

In order to investigate the “unknown threat” in Sweden, KPMG, together with FireEye, conducted a study of the Swedish threat landscape and to ascertain what the real risk is to businesses in Sweden.

Each organisation participating in the study were provided a FireEye NX 7400 appliance. The appliance was strategically placed on the edge of the organisations infrastructure, between the actual network security layers and the client hosts. The appliance was either positioned inline with the firewall or in mirror mode in order for the appliance to receive an integral copy of the traffic passing through the firewall and/or proxy. Both incoming and outgoing traffic were monitored.

The study shows that all the organisations were exposed to infection attempts, where malware had successfully passed through the organisations’ perimeter defence and had reached internal hosts. 93% of the organisations were actually found to be infected as we observed communication attempts towards callback servers and in 79% we were able to observe attempts to exfiltrate data from the organisations.

According to the study:

  • An average organization generates 43 security incidents a day, with an average of 2 new infected hosts a day
  • 93% of Organizations were breached
  • 79% were exfiltrating data
  • 49% of the detected malware was unknown
  • 52% of the identified malware was unknown to anti-virus vendors
  • 83% of the callbacks were related to data exfiltration
  • Call back destinations according to verticals:
    • Government exfilterates to USA, France and Asia
    • Manufacturing organizations to USA and China
    • Industrial companies to US, Ukraine, Russia, Germany and UK
    • Retail towards USA

Despite best efforts to maintain a tight security posture across networks and systems; cyber attacks do, and more importantly will occur. Security is a process and not a solution, and as such safeguarding IT networks and sensitive data from electronic attack and exposure, both from the internet and internally at an organisation is a constant effort.

The slightest lapse in security processes could prove detrimental to an organisation, resulting in critical system down-time or exposure of sensitive corporate and customer information with severe consequences of financial and reputational loss, and potential legal implications.

Advanced Persistent Threats (APTs) to organisations are ever increasing with nefarious individuals or organisations devoting significant time and effort in gaining unauthorised and persistent  access to networks and systems. APT actors will most likely not be discouraged if an occurrence of their targeted attacks was once successfully contained.

The inevitability of cyber attacks whether small isolated events or large-scale network compromise, outage or data exfiltration therefore presents a strong business case for developing an effective response capability.

A comprehensive cyber response capacity should cover all facets of proactive and reactive cyber response, consisting of Prepare & Train, Detect & Initiate, Contain & Investigate, Recover and Report & Improve.

To see the full study visit: http://www.kpmg.com/SE/sv/kunskap-utbildning/nyheter-publikationer/Publikationer-2014/Sidor/UnknownthreatsinSweden.aspx

 

 

NB: This study included 14 organisations, from which we selected a representative amount of client hosts to monitor during the month of June 2014. The incoming and outgoing internet traffic was monitored for a period of four weeks, between June 2 and June 27.

The average number of employees in these organisations is approximately 5 000. Due to the large variety of organisations participating to this study, in terms of vertical and size, we are confident to consider those organisations as a representative sample of the Swedish business landscape.  For the purpose of the study, and in order to preserve the anonymity of the participating organisations, we have grouped organisations into six verticals: Finance, Government, Manufacturing, Retail, Industry and Service.

The study focused on gathering information related to malicious traffic. We only logged communications triggering security alerts. Since legitimate traffic was not logged we cannot track the exact amount of endpoints that were actually communicating through the FireEye appliances. However, we estimate the total number of unique internal hosts within participating organisations to approximately 70 000. During the measurement period, we recorded a total of 15 586 security alerts.

 

Why Bringing Your Network Security “Inline” Lines Up With Your Goals

An attacker can compromise a network and successfully exfiltrate data in less time than you might think.

The 2011 security breach of EMC’s RSA Security Division showed us that it only takes a few days, if not minutes, for cyber criminals to compromise a well-protected corporate network and launch an attack that would eventually cost at least $66M to remedy. Today’s cyber attacks are fast and hard hitting, sometimes happening so swiftly that qualified security personnel can’t triage the breach before it causes serious damage. In fact, as identified in our 2014 MTrends report, it takes organizations on average 229 days to detect a breach – and that detection is primarily done by third-parties!

Organizations can best protect themselves by leveraging real-time technology that can stop attackers in their tracks before they penetrate their targeted networks.

Getting In Line

Inline security solutions effectively defend against today’s fast-paced, evasive attacks on company networks. In the past, security professionals have weighed the risks of compromise from delayed detection and technology gaps versus the risks of potential traffic bottlenecks that were perceived with inline solutions.

Customers typically voice two issues with deploying inline technology, and they both stem from the concern that business needs to continue securely and uninterrupted.

The first of these issues is making sure the network remains functional and accessible, even if devices fail. Customers can’t afford a point of failure on a mission-critical network. But appropriate network design, internal or external fail-open kits, and associated software features significantly lessen the potential for network failure with inline solutions.

False positives have been another concern. Customers worry that filtering tools used to secure the network will cause significant extraneous noise, which potentially could keep them from detecting a true alert.

Most security administrators further fine-tune the signatures before deploying these products inline to adapt them to their environments. While this ensures that the security solutions do not impede business traffic (and this should be the first goal of any organization – run the business!), it lessens the impact of true, inline security.

Today’s evolving threat landscape of sophisticated, targeted attacks has emphasized a critical need for a scalable, secure solution to prevent the staggering outcomes of a successful breach.

The right type of solution balances the blocking power of true inline security with near-zero false positives. The FireEye Multi-Vector Virtual Execution (MVX) engine was designed to do just that. The FireEye MVX was the first technology to provide true multi-flow, multi-vector correlation of today’s advanced cyber threats. It does this by leveraging a virtual execution engine that mimics the end-user behavior to identify true threats and limit false alerts. The MVX is so accurate that across the FireEye customer base, a typical FireEye appliance gives customers 10 alerts/day instead of the hundreds or even thousands of alerts from other vendors that are made up almost entirely of false positives. With this accuracy, the time to investigate alerts and the associated costs are greatly reduced.

FireEye’s inline technology quickly has earned its customers’ trust. In May 2010, fewer than 15% of FireEye customers were using inline deployment mode. Since then, FireEye’s technology has proven itself as a trusted protection partner against advanced threats. As a result, nearly 50% of customers were inline deployment by the end of 2013, as seen in Figure 1.

inline1

Figure 1: The Percentage of FireEye Customers who Deploy FireEye Products Inline

This trend confirms what we’ve been hearing anecdotally from customers, and the numbers speak for themselves. Customers are confident about FireEye products’ ability to detect advanced attacks in real time with near-zero false positives. More and more of them are choosing to move beyond a detection-only solution to protecting against today’s advanced cyber attacks. Today, these customers are active proponents of inline FireEye deployments, not just as a must in their security framework, but also as a no-brainer in ensuring true, scalable inline security.

Going Public About Privacy: A Six Part Series

This is the first of a six-article series by FireEye’s Chief Privacy Officer, Shane McGee.  In this series, Shane will explore six fundamental steps to building an effective privacy program.  There are many important topics that won’t be discussed here, e.g., setting objectives, assembling a team, third party assessments, performance metrics, and vendor interactions.  For purposes of this blog, however, we limited Shane to the six most important steps to creating a privacy program.  He chose the following:

  1. Give Privacy a Voice
  2. Follow the Information
  3. Communicate Clearly, Carefully and Candidly
  4. Become Part of the Process
  5. Build a Culture of Privacy
  6. Rinse and Repeat

Give Privacy a Voice

Everyone’s talking about privacy again. I say ‘again’ because there was a long stretch where, here in the U.S., privacy wasn’t the issue it had been a decade ago. Back then, consumer privacy issues rocketed into the headlines as people learned about things like targeted advertising and the consequences of posting personal information online. The attention caused the Federal Trade Commission (FTC) and State Attorneys General to launch high-profile investigations and enter into settlements with several companies for deceptive, privacy-related conduct. This enforcement activity seemingly satisfied U.S. consumers, effectively hitting the sleep button on privacy issues for the next several years.

Now privacy is back. And while people are still concerned about topics like online tracking and who sees their Facebook posts, the list of important privacy-related issues has grown significantly. Now there’s data localization, cyber-security intelligence sharing, the right to be forgotten, and Snowden. And that’s just a small sampling.

One of the important things about the ‘new’ world of privacy is that it no longer involves only consumer information and the companies that touch it. Now, companies without consumer data are also beholden to regulators and vulnerable to legal action. Employee privacy is a major focus, especially in countries like Germany and France, and companies that sell products that touch corporate networks suddenly find themselves fielding new privacy-related questions.

The increasing complexity and internationalization of privacy issues results in more questions for executives who aren’t necessarily prepared to answer appropriately. In companies that don’t have a dedicated privacy function, these questions usually get directed to one of several different people depending on the circumstances. This inconsistency gives rise to several types of risk, not the least of which is that a potential plaintiff can cherry-pick between responses and use the one most likely to support a privacy-related claim.  At best, it makes the company’s message appear uncoordinated and amateurish.

And that brings me to my point: companies need a single voice when it comes to privacy.  According to the FTC, statements about privacy represent promises, and promises can’t be broken without consequence. For that reason, privacy-related statements require forethought and consistency, and must reflect actual practices.  Back when privacy issues were less complex, you could boil best practices down to one phrase: “say what you do and do what you say.”  That is, create a privacy policy that communicates your privacy practices and make sure you comply with that policy.  Privacy has become a lot more complex since then, but the basic message is still the same.  Just make sure your company is speaking clearly and with a single voice.

 

 

Searching for the Cure: Targeted Threat Actors Pursuing the Pharmaceutical Industry

If you visit an unsafe area, you’re probably more careful about locking your doors, right? But what if it’s well publicized that you have valuables in your possession? You’d likely not only lock doors, but maybe also use a strongbox and have security in place. Knowing that you have something of value makes you a visible – and likely – mark.

It’s no different when thieves are targeting a company’s network.

That’s exactly what the pharmaceutical industry faces. And it’s a prescription for disaster.

Advanced Persistent Threat (APT) groups are targeting the pharmaceutical realm, compromising systems and stealing vital information – and perhaps putting lives at risk.

Recent reports of threat actors swiping personal data of healthcare providers’ patients reinforces what FireEye Labs researchers have been warning our customers about: the healthcare and pharmaceutical industries are data-rich goldmines for APT actors.

When we talk to our customers about targeted threats – especially threat actors backed by nation states – we urge them to consider which information assets are beneficial to targeted actors in the long haul. Nations that use cyber threat actors to achieve their objectives often have strategic healthcare initiatives that are a key indicator of compromises to come. The pharmaceutical industry falls squarely in the crosshairs: threat actors looking to improve their country’s ability to address domestic health concerns will set their sights on stealing IP related to technologies, processes and expertise.

The Symptoms

We’ve previously worked pharmaceutical company cases where we assessed that suspected nation state threat groups targeted the victims for economic espionage. In one incident we determined two China-based APT groups gained access to the environment as long as three years prior to our involvement. The threat groups accessed or compromised more than 100 of the company’s systems and installed backdoors to facilitate continued access to the victim’s network. One of the APT groups stole IP and business data from the victim, including information on bio cultures, products, cost reports and other details pertaining to the company’s operations abroad.

It’s highly probable the stolen IP and business information ultimately assisted beneficiary pharmaceutical industry companies in gaining a competitive advantage.[1] Information on cell cultures and products could allow a company to manufacture its own versions of products, or work from the victim’s findings to advance its research into a particular area while minimizing R&D outlay. Also, an organization might use information on another company’s operational costs and prices to undercut that company’s market share by offering cheaper products.

Countries could also use targeted cyber threat activity to steal data that could help with domestic health concerns. For example, during one week late last year, we saw a China-based APT group target three different companies that provide oncology treatments and services. This activity could have dovetailed with government initiatives to deal with China’s increasing cancer rates. (According to an article in the Guardian, “Cancer mortality rates in China have increased by 80% over the last thirty years, making [cancer] the nation’s leading cause of death.”[2])

Detection

The long-term strategic view – that is, identifying, analyzing and predicting targeted threat actors’ behavior – is only part of the threat intelligence picture. From an operational standpoint, our healthcare and pharmaceutical sector customers experience much of the same targeted threat activity as other industries.

We looked at the use of malware activity directed at clients in the pharmaceutical and healthcare sectors in July and saw quite a bit of consistency across tools used by targeted threat actors.  Overall that month, APT web/file/email detections for the pharmaceutical industry slightly increased compared to the prior month. We saw over 30,000 callbacks to existing command and control infrastructure, and the sector was hit by hard various RATs. Most detections came from njRAT and XtremeRAT, on which we wrote a Feburary blog post which included technical analysis. Because RATs can be publicly available, we noted that a wide range of threat actors use them, including targeted threat actors seeking to blend in with traditional cybercrime activity.

Prognosis

We suspect nation-state backed threat actors will continue to target companies in the pharmaceutical and healthcare industries for the foreseeable future, especially given the industries’ importance in both economic growth and domestic healthcare. Certainly, non-state threat actors motivated by financial gain also pose a risk. Financially motivated cybercriminals might target IP relating to drug formulation processes to facilitate the trade of counterfeit drugs, a global market that the National Association of Boards of Pharmacy estimates cost $75 billion USD in 2010.[3] Actors could breach an environment and steal information to compromise the integrity of a clinical trial. Beyond the potentially exorbitant costs to the company, there are the potential violations of privacy laws and other compliance regulations to consider. While we have not seen such a situation occur, it’s worth considering, especially as a greater understanding of potential risks is key to improving security.


[1] A recently unsealed FBI criminal complaint alleged that a Chinese national named Su Bin, along with two unnamed conspirators, colluded to conduct computer intrusions and steal data related to US military projects. The complaint gave an unusual glimpse into the mechanisms behind nation state sponsored espionage and detailed how an individual operator received targeting instructions and subsequently used those instructions to steal information. Several of the email conversations detailed in the complaint suggest that the final beneficiaries of the intrusions were Chinese state-owned companies. The FBI complaint concludes that Su and an unnamed conspirator conspired to sell the stolen aircraft information to multiple buyers, including Chinese aerospace companies, and that they sought to “match” stolen data with the most suitable buyer. We have no reason to believe that what occurred in the industry relevant to the FBI complaint is any different than the data theft flow in other industries, such as the pharmaceutical industry.

[2] Kaiman, Jonathan. “Inside China’s ‘Cancer Villages.’” The Guardian. 4 June 2013. Web. 9 July 2014.

[3] Gillette, Felix. “Inside Pfizer’s Fight Against Counterfeit Drugs.” Bloomberg LP. 17 January 2013. Web. 9 July 2014.

Android SSL Vulnerabilities: Lessons for CISOs

We recently published a blog reporting a variety of issues with a set of security capabilities found in commonly used Android applications in the Google Play store. These capabilities frequently come from security configurations baked into the ad libraries that developers use to display ads in their apps and don’t want to develop themselves. This is a laudable practice (implementing things like encryption protocols is hard and should be avoided by most software engineers), but it means that a flaw in a single library can impact thousands of apps downloaded by billions of users.
 
So what? Well, for starters, the most common flaws we found expose users of vulnerable applications to man-in-the-middle attacks.  Basically, that boils down to this: if you’re using a vulnerable application on a network where someone can intercept your communications (use the wireless at your favorite coffee shop recently?) you could be exposed. If you want the gory details you can get them in this post http://www.fireeye.com/blog/technical/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html.
The exec-level view boils down to the below:
  • Any data you receive or send via these vulnerable applications could be intercepted, such as usernames, passwords or other data you might want to keep private.
  • An attacker could use their ability to intercept these communications to exploit other vulnerabilities and potentially attempt to steal *other* data from you or gain control of the device.
  • We did a random sampling and found a plethora of these vulnerabilities – vulnerabilities that would be fairly trivial to exploit. In some cases fundamentally simple aspects of security protocols designed to protect data in transit have been ignored. The likelihood someone can…and is…using these vulnerabilities to attack mobile users is high. That means the likelihood your corporate IT users have devices that are exposed is also high.
Again, so what? Perhaps you’re using an MDM (or other security solution) that implements containers for your enterprise sensitive data for exactly this reason. You understand the mobile ecosystem and anticipated this exposure – particularly if your enterprise lets employees bring their own mobile device. A few parting thoughts on why you should still care:
  • Critical apps you use for your enterprise *may also be vulnerable.* You want to know if that’s the case. If they are vulnerable a ‘containerization’ solution won’t prevent an attack.
  • While you may have applications that are ‘blessed’ as mobile enterprise apps, the reality is your users are probably using other non-enterprise apps to get work functions done (Evernote anyone? How about Dropbox?). If one of those applications has issues you similarly are going to want to know. Having risks is a reality…it’s the unknown risks that kill you. Oh – a quick note, I am *not* implying we found Evernote or Dropbox issues…I’m just making the point that ‘Shadow IT’ is out there and likely here to stay. You need to manage this exposure.
  • Lastly, if you are using a mobile enterprise ‘container’ solution, there is the possibility that given sufficient access to a device, an attacker could exploit some vulnerability in the container to get at critical enterprise data. You are increasing this risk if you have other non-enterprise applications that are vulnerable to main-in-the-middle attacks on your users’ devices.
My recommendation is simple: via a process, technology, or both, identify mechanisms to rate this risk so you *at least* have awareness, if not a complete remediation plan.

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 exfiltrates 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 walkthrough 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 Javascript 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.

The History of XXShenqi and the Future of SMS Phishing

On Aug 3rd, Chinese social media websites reported on the latest and largest SMS phishing (smishing for short) attack in China. The public security authorities of multiple cities in Guangdong, Jiangxi, and Jiangsu provinces have posted on their blogs warning Android users of this latest phishing attempt. As shown in Fig. 1, by the time the exploitation attempts were identified, over 100,000 Android users were infected and over 20 Million SMS were sent by the phishing malware. On average, each user was charged ¥30 (RMB) or about US$5.

android1

Fig. 1. Timeline of the XXShenqi malware infecting over 100,000 Android users

The package name of this new SMS phishing malware is com.example.xxshenqi and the app name appears as XX神器 (XX Powerful Equipment). As shown in Fig. 2, the icon and the title of the malware give the impression of a video player to attract common Android users.

According to QQ WeChat news, the malware was written out of boredom by a 19 year old freshman student of Central South University on Jul 24th and sent out from his cell phone on Jul 28th. By Aug 3rd, the malware had drawn attention from public media; nine hours later, police authorities had identified and detained the hacker.

Not only is the Android software being distributed a costly nuisance, but it also contains another embedded, malicious apk file that intercepts and sends SMS messages to the hacker’s email address. The behavior has been detected by FireEye Mobile Threat Protection platform in Fig. 8 and will be explained in detail later. Both the main malware and the embedded malware are not publicly well known according to VirusTotal until very recently:

The detection of the main malware is just 5 out of 53 anti-virus vendors:

android2

Fig. (a)

Out of 53 different anti-virus vendors, only two were able to detect it the embedded Trogoggle malware:

android3

Fig. (b)

Prequel – Known SMS Phishing Malware:

SMS phishing is a well-known type of malware in the Android world. It collects personal information through SMS while masquerading as a trustworthy app.

For example in 2012, a Russian smishing malware – neobook.rubakov.strah (version 1.8), sent premium SMS text message with hashed contents to a predefined number that would enable in-app purchases. Based on FireEye Dynamic Threat Intelligence, that app was downloaded thousands of times before it was taken down from Google Play.

Another Spanish smishing malware popular in 2013 was com.ikangoo.whatssex (version 1.7). It mimicked the Whatsapp icon with title Wassapp del Sexo, or Sex Wassapp in English. It has been removed from Google Play but is still available from the developer’s website. This malware would send SMS with user’s device ID for payment purposes at least in one of the older versions.

There have been many smiting malwares to appear in the last few years and the XXShenqi is not as novel as it seems to be.

New SMS Regulation in Android:

Due to the historical prevalence of SMS phishing, the Android platform began to tighten the reading and writing rights of SMS for Android developers.

In Android 4.4 (KitKat), the concept of the default SMS app was introduced, allowing users to choose their default SMS app. Only the default SMS app would be allowed receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Furthermore, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.

However in Android 4.4, non-default SMS apps can still send SMS if it has the SEND_SMS permission.  In the Android developer’s page of sendMultipartTextMessage method, it reads: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).

As shown in Fig. 3 and Fig. 8, the XXShenqi SMS phishing malware can still operate in Android 4.4 however because it has the SEND_SMS permission.

Technical Analysis of XXShenqi:

After installation, the icon of the malware appears as the following:

android4

Fig. 2. The icon of the “XX神器“ (XXShenqi) malware

Most Android applications use MainActivity class as an entry point, however, according to the AndroidManifest.xml configuration file in the malicious application, XXShenqi calls WelcomeActivity class to evade signature-based anti-virus detection. The WelcomeActivity class is then used to send SMS phishing to contacts located in the Android user’s contact list.

android5

As shown in the source code above, the ReadCONTACTS()method is called to send the link to the malicious apk file to all contacts. Below is a detailed analysis of the ReadCONTACTS()method:

android6

WelcomeActivity.this.phoneString is the phone number of the entry in the contact list, and WelcomeActivity.this.nameString is the contact name of the entry.

android7

Fig. 3. The abnormal SMS traffic detected by the FireEye MTP platform

Individuals who are a member of the victim’s contact list will then receive a copy of the link to the malicious apk. Assuming the individual receives the text, downloads the file, opens the file and side loads the APK file into the phone, the individual will then spread the malware to other individuals who are in the their contact list. It’s important to note that these methods for downloading apps are common in many regions where Google Play is not the dominant Android app market.

While sending the SMS, the malware starts the MainActivity, popping up a window to install the trojan SMS uploader embedded in the XXShenqi app – com.example.com.android.trogoogle . The message reads: Please install the installation package which has been included into the app. The installation can be done by clicking the install button.  After the install button is clicked, the trojan SMS sender will be installed on the device and run in the background because it kills its processes once the job is done.

android8

Fig. 4. The pop up window asking for permission to install the embedded malware

The malware then shows the two pages depicted in Fig. 5: the login page and the registration page. The login page asks for the username and password and has two buttons: login and register.

If the user clicks register, a registration page opens, as shown in the right picture of Fig. 5, requesting a username, password, citizen ID number, and their real name. The bottom button is the register button.

android9

Fig. 5. The login page (Left) and the registration page (Right) of XXShenqi

Usernames for either of the pages are not connected to any real services. The registration page does however verify the citizen ID number by checking the format, the length, and the inherent coding of the number. A random number of “1234567890” will trigger a pop up of Please input the correct citizen ID number, as shown on the bottom right of Fig. 5.

After inputting an acceptable citizen ID number, as shown in the left picture of Fig. 6, and clicking the register button, a pop up of Successful registration! is displayed at the bottom, as shown on the right picture of Fig. 6.

android10

Fig. 6. The malware checks the format, the length and the inherent coding of the 18-digit citizen ID number in the registration page (Left) before showing successful registration! (Right)

As demonstrated in the code snippet below, the credentials do not attempt to log into any accounts.

android11

In the code, if the log in is successful, it just shows being verified; please wait… and wrong password, or username doesn’t exist. The two toasts are shown at the bottom of both screenshots in Fig. 7:

android12

Fig. 7. The fake pages of verification (Left) and the error message of wrong password or the account doesn’t exist. (Right)

While the Android user is distracted by the login and registration pages, in the MainActivity class, a subclass of BroadcastReceiver called MyReceiver is started. The MyReceiver class is to start the com.example.com.android.trogoogle to send SMS messages to the hacker.

As shown in the source code below, it sends the SMS to an email address and kills its process after completing so that neither thread is seen from the Android system setting tab, nor is the icon shown in the home screen of the phone.

android13

 

android14

Fig. 8. More abnormal SMS traffic in the embedded malware as detected by the FireEye MTP platform

Even when the hacker was finally identified and detained, the only way that authorities could stop the exponential expansion of infected users was by removing the app from its web hosting service. Yet the malware can easily be resurrected when repackaged and hosted in numerous cloud storage services. As few security mechanisms and detection capabilities exist for mobile malware, it’s easy to see why 20 million SMS were sent and 100,000 users were infected in only a few days.

Another reason for the spread is the social engineering aspect of smartphones where individuals tend to trust the links sent by someone on their contact lists. This is particularly true as we do share links containing pictures or even executable files over the SMS to groups from time to time.

Finally, many individuals believe that they cannot get malware on their devices still. This lowers the guard for the individual using the phone, making them more likely to click on a random link. Individuals should be educated that unexpected links such as bargain recommendation or prize information may be not only harmless tricks but also malicious phishing attempts. Even if the device in question is just smart phone or tablet, the same precautions that are taken on a PC should be the same as those on a mobile device.

Prediction of Further SMS Phishing Attacks:

FireEye analysis of this series of SMS phishing and sending malware that infected over 100,000 users in China and charged $500,000 SMS fees in a few days could continue to expand exponentially even though the hacker has been detained.

The growth rate of this SMS phishing malware reveals the fact that such app can be developed easily and spread epidemically in the future. Although the Android OS has received certain fixes to its wide open permissions for reading and sending SMS in KitKat, malware can still send out SMS in those versions, meaning the newer versions of Android can’t prevent the prevalence of such malware.

Black Hat USA Talks: Investigating PowerShell Attacks

Threat actors are always eager to adopt new tools, tactics, and procedures that can help them evade detection and conduct their mission. Incident responders from Mandiant have observed increasing use of PowerShell by targeted attackers to conduct command-and-control in compromised Windows networks. As a trusted administration tool built-in to all modern versions of Windows, PowerShell provides the ability to access remote systems, execute commands, transfer files, load malicious code, and interact with underlying components of the operating system – all tasks for which attackers must otherwise rely on malware. This has created a whole new playground of intrusion techniques for intruders that have already established a foothold on systems in a corporate network.

Ryan Kazanciyan and Matt Hastings will talk about the use of PowerShell throughout the attack lifecycle and the sources of evidence it leaves behind in memory, on disk, in logs, and elsewhere. They will demonstrate how to collect and interpret these forensic artifacts, both on individual systems and at scale. Throughout the presentation, they will include examples from real-world incidents.

Attend this presentation on August 7 at 4:05pm PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Black Hat USA Talks: Sidewinder Targeted Attack Against Android in The Golden Age of Ad Libs

While Google Play has little malware, many vulnerabilities exist in the apps as well as the Android system itself, and aggressive ad libs leak a lot of user privacy information. When they are combined together, more powerful targeted attacks can be conducted.

In this presentation, FireEye’s Yulong Zhang and Tao Wei will present one practical case of such attacks called “Sidewinder Targeted Attack.” It targets victims by intercepting location information reported from ad libs, which can be used to locate targeted areas such as a CEO’s office or some specific conference rooms. When the target is identified, “Sidewinder Targeted Attack” exploits popular vulnerabilities in ad libs, such as Javascript-binding-over-HTTP or dynamic-loading-over-HTTP, etc.

During the exploit, it is a well-known challenge to call Android services from injected native code due to the lack of Android application context. So they will also demonstrate how attackers can invoke Android services such as taking photos, calling phone numbers, sending SMS, reading/writing the clipboard, etc. Once intruding into the target, the attackers can exploit several Android vulnerabilities to get valuable privacy information or initiate more advanced attacks. We will reveal how to exploit new vulnerabilities we discovered in this phase.

In addition, they will show demos using real-world apps downloaded from Google Play.

Although they notified Google, ad vendors and app developers about related issues half a year ago, there are still millions of users under the threat of “Sidewinder Targeted Attacks” due to the slow patching/upgrading/fragmentation of the Android ecosystem.

Attend this presentation on August 7 at 10:15am PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Black Hat USA Talks – Leviathan: Command And Control Communications On Planet Earth

Every day, computer network attackers leverage a Leviathan of compromised infrastructure, based in every corner of the globe, to play hide-and-seek with network security, law enforcement, and counterintelligence personnel.

This presentation draws a new map of Planet Earth, based not on traditional parameters, but on hacker command and control (C2) communications. The primary data points used in this worldwide cyber survey are more than 30 million malware callbacks to over 200 countries and territories over an 18-month period, from January 2013 to June 2014.

First, this talk covers the techniques that hackers use to communicate with compromised infrastructure across the globe. The authors analyze the domains, protocols, ports, and websites used for malicious C2. They explain how covert C2 works, and how attackers keep their communications hidden from network security personnel.

Second, this talk looks at strategic impact. The authors examine relationships between the targeted industries and countries and the first-stage malware servers communicating with them. Traffic analysis is used to deduce important relationships, patterns, and trends in the data. This section correlates C2 communications to traditional geopolitical conflicts and considers whether computer network activity can be used to predict real world events.

In conclusion, the authors consider the future of this Leviathan, including whether governments can subdue it – and whether they would even want to.

Attend this presentation on August 7 at 10:15am PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Threat Research

Filter by Category:


The Unknown Threat in Sweden – KPMG Study

During recent years, we have observed an increase of severe cyber attacks targeting classified financial information, legal acts, business communication, and military or other governmental highly sensitive information.

In order to investigate the “unknown threat” in Sweden, KPMG, together with FireEye, conducted a study of the Swedish threat landscape and to ascertain what the real risk is to businesses in Sweden.

Each organisation participating in the study were provided a FireEye NX 7400 appliance. The appliance was strategically placed on the edge of the organisations infrastructure, between the actual network security layers and the client hosts. The appliance was either positioned inline with the firewall or in mirror mode in order for the appliance to receive an integral copy of the traffic passing through the firewall and/or proxy. Both incoming and outgoing traffic were monitored.

The study shows that all the organisations were exposed to infection attempts, where malware had successfully passed through the organisations’ perimeter defence and had reached internal hosts. 93% of the organisations were actually found to be infected as we observed communication attempts towards callback servers and in 79% we were able to observe attempts to exfiltrate data from the organisations.

According to the study:

  • An average organization generates 43 security incidents a day, with an average of 2 new infected hosts a day
  • 93% of Organizations were breached
  • 79% were exfiltrating data
  • 49% of the detected malware was unknown
  • 52% of the identified malware was unknown to anti-virus vendors
  • 83% of the callbacks were related to data exfiltration
  • Call back destinations according to verticals:
    • Government exfilterates to USA, France and Asia
    • Manufacturing organizations to USA and China
    • Industrial companies to US, Ukraine, Russia, Germany and UK
    • Retail towards USA

Despite best efforts to maintain a tight security posture across networks and systems; cyber attacks do, and more importantly will occur. Security is a process and not a solution, and as such safeguarding IT networks and sensitive data from electronic attack and exposure, both from the internet and internally at an organisation is a constant effort.

The slightest lapse in security processes could prove detrimental to an organisation, resulting in critical system down-time or exposure of sensitive corporate and customer information with severe consequences of financial and reputational loss, and potential legal implications.

Advanced Persistent Threats (APTs) to organisations are ever increasing with nefarious individuals or organisations devoting significant time and effort in gaining unauthorised and persistent  access to networks and systems. APT actors will most likely not be discouraged if an occurrence of their targeted attacks was once successfully contained.

The inevitability of cyber attacks whether small isolated events or large-scale network compromise, outage or data exfiltration therefore presents a strong business case for developing an effective response capability.

A comprehensive cyber response capacity should cover all facets of proactive and reactive cyber response, consisting of Prepare & Train, Detect & Initiate, Contain & Investigate, Recover and Report & Improve.

To see the full study visit: http://www.kpmg.com/SE/sv/kunskap-utbildning/nyheter-publikationer/Publikationer-2014/Sidor/UnknownthreatsinSweden.aspx

 

 

NB: This study included 14 organisations, from which we selected a representative amount of client hosts to monitor during the month of June 2014. The incoming and outgoing internet traffic was monitored for a period of four weeks, between June 2 and June 27.

The average number of employees in these organisations is approximately 5 000. Due to the large variety of organisations participating to this study, in terms of vertical and size, we are confident to consider those organisations as a representative sample of the Swedish business landscape.  For the purpose of the study, and in order to preserve the anonymity of the participating organisations, we have grouped organisations into six verticals: Finance, Government, Manufacturing, Retail, Industry and Service.

The study focused on gathering information related to malicious traffic. We only logged communications triggering security alerts. Since legitimate traffic was not logged we cannot track the exact amount of endpoints that were actually communicating through the FireEye appliances. However, we estimate the total number of unique internal hosts within participating organisations to approximately 70 000. During the measurement period, we recorded a total of 15 586 security alerts.

 

Searching for the Cure: Targeted Threat Actors Pursuing the Pharmaceutical Industry

If you visit an unsafe area, you’re probably more careful about locking your doors, right? But what if it’s well publicized that you have valuables in your possession? You’d likely not only lock doors, but maybe also use a strongbox and have security in place. Knowing that you have something of value makes you a visible – and likely – mark.

It’s no different when thieves are targeting a company’s network.

That’s exactly what the pharmaceutical industry faces. And it’s a prescription for disaster.

Advanced Persistent Threat (APT) groups are targeting the pharmaceutical realm, compromising systems and stealing vital information – and perhaps putting lives at risk.

Recent reports of threat actors swiping personal data of healthcare providers’ patients reinforces what FireEye Labs researchers have been warning our customers about: the healthcare and pharmaceutical industries are data-rich goldmines for APT actors.

When we talk to our customers about targeted threats – especially threat actors backed by nation states – we urge them to consider which information assets are beneficial to targeted actors in the long haul. Nations that use cyber threat actors to achieve their objectives often have strategic healthcare initiatives that are a key indicator of compromises to come. The pharmaceutical industry falls squarely in the crosshairs: threat actors looking to improve their country’s ability to address domestic health concerns will set their sights on stealing IP related to technologies, processes and expertise.

The Symptoms

We’ve previously worked pharmaceutical company cases where we assessed that suspected nation state threat groups targeted the victims for economic espionage. In one incident we determined two China-based APT groups gained access to the environment as long as three years prior to our involvement. The threat groups accessed or compromised more than 100 of the company’s systems and installed backdoors to facilitate continued access to the victim’s network. One of the APT groups stole IP and business data from the victim, including information on bio cultures, products, cost reports and other details pertaining to the company’s operations abroad.

It’s highly probable the stolen IP and business information ultimately assisted beneficiary pharmaceutical industry companies in gaining a competitive advantage.[1] Information on cell cultures and products could allow a company to manufacture its own versions of products, or work from the victim’s findings to advance its research into a particular area while minimizing R&D outlay. Also, an organization might use information on another company’s operational costs and prices to undercut that company’s market share by offering cheaper products.

Countries could also use targeted cyber threat activity to steal data that could help with domestic health concerns. For example, during one week late last year, we saw a China-based APT group target three different companies that provide oncology treatments and services. This activity could have dovetailed with government initiatives to deal with China’s increasing cancer rates. (According to an article in the Guardian, “Cancer mortality rates in China have increased by 80% over the last thirty years, making [cancer] the nation’s leading cause of death.”[2])

Detection

The long-term strategic view – that is, identifying, analyzing and predicting targeted threat actors’ behavior – is only part of the threat intelligence picture. From an operational standpoint, our healthcare and pharmaceutical sector customers experience much of the same targeted threat activity as other industries.

We looked at the use of malware activity directed at clients in the pharmaceutical and healthcare sectors in July and saw quite a bit of consistency across tools used by targeted threat actors.  Overall that month, APT web/file/email detections for the pharmaceutical industry slightly increased compared to the prior month. We saw over 30,000 callbacks to existing command and control infrastructure, and the sector was hit by hard various RATs. Most detections came from njRAT and XtremeRAT, on which we wrote a Feburary blog post which included technical analysis. Because RATs can be publicly available, we noted that a wide range of threat actors use them, including targeted threat actors seeking to blend in with traditional cybercrime activity.

Prognosis

We suspect nation-state backed threat actors will continue to target companies in the pharmaceutical and healthcare industries for the foreseeable future, especially given the industries’ importance in both economic growth and domestic healthcare. Certainly, non-state threat actors motivated by financial gain also pose a risk. Financially motivated cybercriminals might target IP relating to drug formulation processes to facilitate the trade of counterfeit drugs, a global market that the National Association of Boards of Pharmacy estimates cost $75 billion USD in 2010.[3] Actors could breach an environment and steal information to compromise the integrity of a clinical trial. Beyond the potentially exorbitant costs to the company, there are the potential violations of privacy laws and other compliance regulations to consider. While we have not seen such a situation occur, it’s worth considering, especially as a greater understanding of potential risks is key to improving security.


[1] A recently unsealed FBI criminal complaint alleged that a Chinese national named Su Bin, along with two unnamed conspirators, colluded to conduct computer intrusions and steal data related to US military projects. The complaint gave an unusual glimpse into the mechanisms behind nation state sponsored espionage and detailed how an individual operator received targeting instructions and subsequently used those instructions to steal information. Several of the email conversations detailed in the complaint suggest that the final beneficiaries of the intrusions were Chinese state-owned companies. The FBI complaint concludes that Su and an unnamed conspirator conspired to sell the stolen aircraft information to multiple buyers, including Chinese aerospace companies, and that they sought to “match” stolen data with the most suitable buyer. We have no reason to believe that what occurred in the industry relevant to the FBI complaint is any different than the data theft flow in other industries, such as the pharmaceutical industry.

[2] Kaiman, Jonathan. “Inside China’s ‘Cancer Villages.’” The Guardian. 4 June 2013. Web. 9 July 2014.

[3] Gillette, Felix. “Inside Pfizer’s Fight Against Counterfeit Drugs.” Bloomberg LP. 17 January 2013. Web. 9 July 2014.

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 exfiltrates 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 walkthrough 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 Javascript 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.

The History of XXShenqi and the Future of SMS Phishing

On Aug 3rd, Chinese social media websites reported on the latest and largest SMS phishing (smishing for short) attack in China. The public security authorities of multiple cities in Guangdong, Jiangxi, and Jiangsu provinces have posted on their blogs warning Android users of this latest phishing attempt. As shown in Fig. 1, by the time the exploitation attempts were identified, over 100,000 Android users were infected and over 20 Million SMS were sent by the phishing malware. On average, each user was charged ¥30 (RMB) or about US$5.

android1

Fig. 1. Timeline of the XXShenqi malware infecting over 100,000 Android users

The package name of this new SMS phishing malware is com.example.xxshenqi and the app name appears as XX神器 (XX Powerful Equipment). As shown in Fig. 2, the icon and the title of the malware give the impression of a video player to attract common Android users.

According to QQ WeChat news, the malware was written out of boredom by a 19 year old freshman student of Central South University on Jul 24th and sent out from his cell phone on Jul 28th. By Aug 3rd, the malware had drawn attention from public media; nine hours later, police authorities had identified and detained the hacker.

Not only is the Android software being distributed a costly nuisance, but it also contains another embedded, malicious apk file that intercepts and sends SMS messages to the hacker’s email address. The behavior has been detected by FireEye Mobile Threat Protection platform in Fig. 8 and will be explained in detail later. Both the main malware and the embedded malware are not publicly well known according to VirusTotal until very recently:

The detection of the main malware is just 5 out of 53 anti-virus vendors:

android2

Fig. (a)

Out of 53 different anti-virus vendors, only two were able to detect it the embedded Trogoggle malware:

android3

Fig. (b)

Prequel – Known SMS Phishing Malware:

SMS phishing is a well-known type of malware in the Android world. It collects personal information through SMS while masquerading as a trustworthy app.

For example in 2012, a Russian smishing malware – neobook.rubakov.strah (version 1.8), sent premium SMS text message with hashed contents to a predefined number that would enable in-app purchases. Based on FireEye Dynamic Threat Intelligence, that app was downloaded thousands of times before it was taken down from Google Play.

Another Spanish smishing malware popular in 2013 was com.ikangoo.whatssex (version 1.7). It mimicked the Whatsapp icon with title Wassapp del Sexo, or Sex Wassapp in English. It has been removed from Google Play but is still available from the developer’s website. This malware would send SMS with user’s device ID for payment purposes at least in one of the older versions.

There have been many smiting malwares to appear in the last few years and the XXShenqi is not as novel as it seems to be.

New SMS Regulation in Android:

Due to the historical prevalence of SMS phishing, the Android platform began to tighten the reading and writing rights of SMS for Android developers.

In Android 4.4 (KitKat), the concept of the default SMS app was introduced, allowing users to choose their default SMS app. Only the default SMS app would be allowed receive the new SMS_DELIVER_ACTION intent, which the system broadcasts when a new SMS message arrives. Furthermore, only the default SMS app receives the new WAP_PUSH_DELIVER_ACTION intent when a new MMS arrives.

However in Android 4.4, non-default SMS apps can still send SMS if it has the SEND_SMS permission.  In the Android developer’s page of sendMultipartTextMessage method, it reads: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider).

As shown in Fig. 3 and Fig. 8, the XXShenqi SMS phishing malware can still operate in Android 4.4 however because it has the SEND_SMS permission.

Technical Analysis of XXShenqi:

After installation, the icon of the malware appears as the following:

android4

Fig. 2. The icon of the “XX神器“ (XXShenqi) malware

Most Android applications use MainActivity class as an entry point, however, according to the AndroidManifest.xml configuration file in the malicious application, XXShenqi calls WelcomeActivity class to evade signature-based anti-virus detection. The WelcomeActivity class is then used to send SMS phishing to contacts located in the Android user’s contact list.

android5

As shown in the source code above, the ReadCONTACTS()method is called to send the link to the malicious apk file to all contacts. Below is a detailed analysis of the ReadCONTACTS()method:

android6

WelcomeActivity.this.phoneString is the phone number of the entry in the contact list, and WelcomeActivity.this.nameString is the contact name of the entry.

android7

Fig. 3. The abnormal SMS traffic detected by the FireEye MTP platform

Individuals who are a member of the victim’s contact list will then receive a copy of the link to the malicious apk. Assuming the individual receives the text, downloads the file, opens the file and side loads the APK file into the phone, the individual will then spread the malware to other individuals who are in the their contact list. It’s important to note that these methods for downloading apps are common in many regions where Google Play is not the dominant Android app market.

While sending the SMS, the malware starts the MainActivity, popping up a window to install the trojan SMS uploader embedded in the XXShenqi app – com.example.com.android.trogoogle . The message reads: Please install the installation package which has been included into the app. The installation can be done by clicking the install button.  After the install button is clicked, the trojan SMS sender will be installed on the device and run in the background because it kills its processes once the job is done.

android8

Fig. 4. The pop up window asking for permission to install the embedded malware

The malware then shows the two pages depicted in Fig. 5: the login page and the registration page. The login page asks for the username and password and has two buttons: login and register.

If the user clicks register, a registration page opens, as shown in the right picture of Fig. 5, requesting a username, password, citizen ID number, and their real name. The bottom button is the register button.

android9

Fig. 5. The login page (Left) and the registration page (Right) of XXShenqi

Usernames for either of the pages are not connected to any real services. The registration page does however verify the citizen ID number by checking the format, the length, and the inherent coding of the number. A random number of “1234567890” will trigger a pop up of Please input the correct citizen ID number, as shown on the bottom right of Fig. 5.

After inputting an acceptable citizen ID number, as shown in the left picture of Fig. 6, and clicking the register button, a pop up of Successful registration! is displayed at the bottom, as shown on the right picture of Fig. 6.

android10

Fig. 6. The malware checks the format, the length and the inherent coding of the 18-digit citizen ID number in the registration page (Left) before showing successful registration! (Right)

As demonstrated in the code snippet below, the credentials do not attempt to log into any accounts.

android11

In the code, if the log in is successful, it just shows being verified; please wait… and wrong password, or username doesn’t exist. The two toasts are shown at the bottom of both screenshots in Fig. 7:

android12

Fig. 7. The fake pages of verification (Left) and the error message of wrong password or the account doesn’t exist. (Right)

While the Android user is distracted by the login and registration pages, in the MainActivity class, a subclass of BroadcastReceiver called MyReceiver is started. The MyReceiver class is to start the com.example.com.android.trogoogle to send SMS messages to the hacker.

As shown in the source code below, it sends the SMS to an email address and kills its process after completing so that neither thread is seen from the Android system setting tab, nor is the icon shown in the home screen of the phone.

android13

 

android14

Fig. 8. More abnormal SMS traffic in the embedded malware as detected by the FireEye MTP platform

Even when the hacker was finally identified and detained, the only way that authorities could stop the exponential expansion of infected users was by removing the app from its web hosting service. Yet the malware can easily be resurrected when repackaged and hosted in numerous cloud storage services. As few security mechanisms and detection capabilities exist for mobile malware, it’s easy to see why 20 million SMS were sent and 100,000 users were infected in only a few days.

Another reason for the spread is the social engineering aspect of smartphones where individuals tend to trust the links sent by someone on their contact lists. This is particularly true as we do share links containing pictures or even executable files over the SMS to groups from time to time.

Finally, many individuals believe that they cannot get malware on their devices still. This lowers the guard for the individual using the phone, making them more likely to click on a random link. Individuals should be educated that unexpected links such as bargain recommendation or prize information may be not only harmless tricks but also malicious phishing attempts. Even if the device in question is just smart phone or tablet, the same precautions that are taken on a PC should be the same as those on a mobile device.

Prediction of Further SMS Phishing Attacks:

FireEye analysis of this series of SMS phishing and sending malware that infected over 100,000 users in China and charged $500,000 SMS fees in a few days could continue to expand exponentially even though the hacker has been detained.

The growth rate of this SMS phishing malware reveals the fact that such app can be developed easily and spread epidemically in the future. Although the Android OS has received certain fixes to its wide open permissions for reading and sending SMS in KitKat, malware can still send out SMS in those versions, meaning the newer versions of Android can’t prevent the prevalence of such malware.

Black Hat USA Talks: Investigating PowerShell Attacks

Threat actors are always eager to adopt new tools, tactics, and procedures that can help them evade detection and conduct their mission. Incident responders from Mandiant have observed increasing use of PowerShell by targeted attackers to conduct command-and-control in compromised Windows networks. As a trusted administration tool built-in to all modern versions of Windows, PowerShell provides the ability to access remote systems, execute commands, transfer files, load malicious code, and interact with underlying components of the operating system – all tasks for which attackers must otherwise rely on malware. This has created a whole new playground of intrusion techniques for intruders that have already established a foothold on systems in a corporate network.

Ryan Kazanciyan and Matt Hastings will talk about the use of PowerShell throughout the attack lifecycle and the sources of evidence it leaves behind in memory, on disk, in logs, and elsewhere. They will demonstrate how to collect and interpret these forensic artifacts, both on individual systems and at scale. Throughout the presentation, they will include examples from real-world incidents.

Attend this presentation on August 7 at 4:05pm PT in South Seas GH. Make sure to use #BHUSA and @FireEye if you plan to tweet highlights from the talk.

To view the whitepaper, click here.

Security Perspective

Filter by Category:


Why Bringing Your Network Security “Inline” Lines Up With Your Goals

An attacker can compromise a network and successfully exfiltrate data in less time than you might think.

The 2011 security breach of EMC’s RSA Security Division showed us that it only takes a few days, if not minutes, for cyber criminals to compromise a well-protected corporate network and launch an attack that would eventually cost at least $66M to remedy. Today’s cyber attacks are fast and hard hitting, sometimes happening so swiftly that qualified security personnel can’t triage the breach before it causes serious damage. In fact, as identified in our 2014 MTrends report, it takes organizations on average 229 days to detect a breach – and that detection is primarily done by third-parties!

Organizations can best protect themselves by leveraging real-time technology that can stop attackers in their tracks before they penetrate their targeted networks.

Getting In Line

Inline security solutions effectively defend against today’s fast-paced, evasive attacks on company networks. In the past, security professionals have weighed the risks of compromise from delayed detection and technology gaps versus the risks of potential traffic bottlenecks that were perceived with inline solutions.

Customers typically voice two issues with deploying inline technology, and they both stem from the concern that business needs to continue securely and uninterrupted.

The first of these issues is making sure the network remains functional and accessible, even if devices fail. Customers can’t afford a point of failure on a mission-critical network. But appropriate network design, internal or external fail-open kits, and associated software features significantly lessen the potential for network failure with inline solutions.

False positives have been another concern. Customers worry that filtering tools used to secure the network will cause significant extraneous noise, which potentially could keep them from detecting a true alert.

Most security administrators further fine-tune the signatures before deploying these products inline to adapt them to their environments. While this ensures that the security solutions do not impede business traffic (and this should be the first goal of any organization – run the business!), it lessens the impact of true, inline security.

Today’s evolving threat landscape of sophisticated, targeted attacks has emphasized a critical need for a scalable, secure solution to prevent the staggering outcomes of a successful breach.

The right type of solution balances the blocking power of true inline security with near-zero false positives. The FireEye Multi-Vector Virtual Execution (MVX) engine was designed to do just that. The FireEye MVX was the first technology to provide true multi-flow, multi-vector correlation of today’s advanced cyber threats. It does this by leveraging a virtual execution engine that mimics the end-user behavior to identify true threats and limit false alerts. The MVX is so accurate that across the FireEye customer base, a typical FireEye appliance gives customers 10 alerts/day instead of the hundreds or even thousands of alerts from other vendors that are made up almost entirely of false positives. With this accuracy, the time to investigate alerts and the associated costs are greatly reduced.

FireEye’s inline technology quickly has earned its customers’ trust. In May 2010, fewer than 15% of FireEye customers were using inline deployment mode. Since then, FireEye’s technology has proven itself as a trusted protection partner against advanced threats. As a result, nearly 50% of customers were inline deployment by the end of 2013, as seen in Figure 1.

inline1

Figure 1: The Percentage of FireEye Customers who Deploy FireEye Products Inline

This trend confirms what we’ve been hearing anecdotally from customers, and the numbers speak for themselves. Customers are confident about FireEye products’ ability to detect advanced attacks in real time with near-zero false positives. More and more of them are choosing to move beyond a detection-only solution to protecting against today’s advanced cyber attacks. Today, these customers are active proponents of inline FireEye deployments, not just as a must in their security framework, but also as a no-brainer in ensuring true, scalable inline security.

Going Public About Privacy: A Six Part Series

This is the first of a six-article series by FireEye’s Chief Privacy Officer, Shane McGee.  In this series, Shane will explore six fundamental steps to building an effective privacy program.  There are many important topics that won’t be discussed here, e.g., setting objectives, assembling a team, third party assessments, performance metrics, and vendor interactions.  For purposes of this blog, however, we limited Shane to the six most important steps to creating a privacy program.  He chose the following:

  1. Give Privacy a Voice
  2. Follow the Information
  3. Communicate Clearly, Carefully and Candidly
  4. Become Part of the Process
  5. Build a Culture of Privacy
  6. Rinse and Repeat

Give Privacy a Voice

Everyone’s talking about privacy again. I say ‘again’ because there was a long stretch where, here in the U.S., privacy wasn’t the issue it had been a decade ago. Back then, consumer privacy issues rocketed into the headlines as people learned about things like targeted advertising and the consequences of posting personal information online. The attention caused the Federal Trade Commission (FTC) and State Attorneys General to launch high-profile investigations and enter into settlements with several companies for deceptive, privacy-related conduct. This enforcement activity seemingly satisfied U.S. consumers, effectively hitting the sleep button on privacy issues for the next several years.

Now privacy is back. And while people are still concerned about topics like online tracking and who sees their Facebook posts, the list of important privacy-related issues has grown significantly. Now there’s data localization, cyber-security intelligence sharing, the right to be forgotten, and Snowden. And that’s just a small sampling.

One of the important things about the ‘new’ world of privacy is that it no longer involves only consumer information and the companies that touch it. Now, companies without consumer data are also beholden to regulators and vulnerable to legal action. Employee privacy is a major focus, especially in countries like Germany and France, and companies that sell products that touch corporate networks suddenly find themselves fielding new privacy-related questions.

The increasing complexity and internationalization of privacy issues results in more questions for executives who aren’t necessarily prepared to answer appropriately. In companies that don’t have a dedicated privacy function, these questions usually get directed to one of several different people depending on the circumstances. This inconsistency gives rise to several types of risk, not the least of which is that a potential plaintiff can cherry-pick between responses and use the one most likely to support a privacy-related claim.  At best, it makes the company’s message appear uncoordinated and amateurish.

And that brings me to my point: companies need a single voice when it comes to privacy.  According to the FTC, statements about privacy represent promises, and promises can’t be broken without consequence. For that reason, privacy-related statements require forethought and consistency, and must reflect actual practices.  Back when privacy issues were less complex, you could boil best practices down to one phrase: “say what you do and do what you say.”  That is, create a privacy policy that communicates your privacy practices and make sure you comply with that policy.  Privacy has become a lot more complex since then, but the basic message is still the same.  Just make sure your company is speaking clearly and with a single voice.

 

 

Android SSL Vulnerabilities: Lessons for CISOs

We recently published a blog reporting a variety of issues with a set of security capabilities found in commonly used Android applications in the Google Play store. These capabilities frequently come from security configurations baked into the ad libraries that developers use to display ads in their apps and don’t want to develop themselves. This is a laudable practice (implementing things like encryption protocols is hard and should be avoided by most software engineers), but it means that a flaw in a single library can impact thousands of apps downloaded by billions of users.
 
So what? Well, for starters, the most common flaws we found expose users of vulnerable applications to man-in-the-middle attacks.  Basically, that boils down to this: if you’re using a vulnerable application on a network where someone can intercept your communications (use the wireless at your favorite coffee shop recently?) you could be exposed. If you want the gory details you can get them in this post http://www.fireeye.com/blog/technical/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html.
The exec-level view boils down to the below:
  • Any data you receive or send via these vulnerable applications could be intercepted, such as usernames, passwords or other data you might want to keep private.
  • An attacker could use their ability to intercept these communications to exploit other vulnerabilities and potentially attempt to steal *other* data from you or gain control of the device.
  • We did a random sampling and found a plethora of these vulnerabilities – vulnerabilities that would be fairly trivial to exploit. In some cases fundamentally simple aspects of security protocols designed to protect data in transit have been ignored. The likelihood someone can…and is…using these vulnerabilities to attack mobile users is high. That means the likelihood your corporate IT users have devices that are exposed is also high.
Again, so what? Perhaps you’re using an MDM (or other security solution) that implements containers for your enterprise sensitive data for exactly this reason. You understand the mobile ecosystem and anticipated this exposure – particularly if your enterprise lets employees bring their own mobile device. A few parting thoughts on why you should still care:
  • Critical apps you use for your enterprise *may also be vulnerable.* You want to know if that’s the case. If they are vulnerable a ‘containerization’ solution won’t prevent an attack.
  • While you may have applications that are ‘blessed’ as mobile enterprise apps, the reality is your users are probably using other non-enterprise apps to get work functions done (Evernote anyone? How about Dropbox?). If one of those applications has issues you similarly are going to want to know. Having risks is a reality…it’s the unknown risks that kill you. Oh – a quick note, I am *not* implying we found Evernote or Dropbox issues…I’m just making the point that ‘Shadow IT’ is out there and likely here to stay. You need to manage this exposure.
  • Lastly, if you are using a mobile enterprise ‘container’ solution, there is the possibility that given sufficient access to a device, an attacker could exploit some vulnerability in the container to get at critical enterprise data. You are increasing this risk if you have other non-enterprise applications that are vulnerable to main-in-the-middle attacks on your users’ devices.
My recommendation is simple: via a process, technology, or both, identify mechanisms to rate this risk so you *at least* have awareness, if not a complete remediation plan.

Operation Poisoned Hurricane: Lessons for CISOs

The tactics described in “Operation Poisoned Hurricane” should come as a stark reminder that advanced threat actors do not stand still. They continue to refine their tradecraft, finding new and innovative ways to bypass security controls and evade detection.

The technical details of the evasion techniques are complex, but the lessons for the CISO are clear:

  1. Traffic to a legitimate website is not always legitimate traffic – malware could be hiding command and control communications in traffic to reputable sites.
  2. Don’t allow direct Internet access, ever. The DNS hijacking described in the blog relies on directly sending DNS queries.
  3. File-based malware controls are being successfully evaded in the wild.

What can you do to protect your organisation from these threats? My suggestions are:

  1. Make sure you have a well-architected Internet proxy architecture that prevents direct connectivity from your network:
    • Never allow hosts other than your secure external DNS resolver to send DNS queries to the Internet. Period.
    • Record all internal DNS queries, these are a possible sign of a compromised machine.
  2. Put in place a malware detection solution that can identify multi-vector, multi-stage malware execution:
    • These attacks used legitimate, signed binaries from a known security company to load malicious code contained in other files as part of a multi-stage attack. File-oriented security controls do not detect these attacks, you need a full behavioural analytics engine to see the attack.
    • Don’t assume that a signed binary is safe. Automated analysis of code behaviour in an execution environment is critical.
  3. Ensure you can detect and block command & control traffic from compromised users, even if it is to legitimate websites:
    • Sophisticated attackers can use blogs, code repositories, even comments on social media, to send and receive command & control signals.
    • Reputation-based detection is not sufficient, you need detection and protection that can understand new command and control tactics based on automated behavioural analysis.

The attackers are evolving their attacks, are you evolving your defenses fast enough to keep them out?

Your Locker of Information for CryptoLocker Decryption

Ransomware is a particularly nasty piece of malware that takes infected machines hostage. CryptoLocker was successful at garnering  multi-millions in ransom payments the first two months of CryptoLocker’s distribution, according to a recent blog by FireEye regarding the takeover of CryptoLocker infrastructure – Operation Tovar.

Operation Tovar helped tear down the infrastructure used by attackers, but there are still many instances where users are still being infected with ransomware. After the success of Operation Tovar, there were few resources available to help decrypt files that were still encrypted with the attacker’s private key.

While not particularly innovative, CryptoLocker was successful because it encrypts the files of computers it infected and then demanded a ransom for a private key to decrypt those files. The harsh reality of a situation like this is, not many people back up their data. In some cases, the backups would be encrypted if mounted to an infected machine. As a result, many of the victims felt helpless at this point, and paid the ransom – typically around $300. A simple description of the way that CryptoLocker works can be found below:

  1. CryptoLocker arrives on a victim’s machine through a variety of techniques such as spear-phishing emails or watering hole attacks.
  2. CryptoLocker then connects to randomly generated domain (via DGAs) to download a specific RSA public key.
  3. At that point, an AES-256 key is created for each file on the system.
  4. CryptoLocker then encrypts all of the supported files using the generated key from step 3.
  5. The generated key is then encrypted with the downloaded RSA public key from step 2.
  6. And finally, the AES-key is written to the beginning of the encrypted files, thus requiring the private key to decrypt.
crypto1

Figure 1: Screenshot of victim machine infected with CryptoLocker

Not all CryptoLocker variants are created equal. There are several copycats and hybrid versions of Crytpolocker that exist, ranging from programs like CryptoDefense, PowerLocker, TorLocker and CryptorBit, to variants that are not necessarily named but have modified functionality, such as using Yahoo Messenger as a propagation technique.

Decryption Assistance

To help solve the problem of victims’ files still being encrypted, we leveraged our close partnership with Fox-IT. We developed a decryption assistance website and corresponding tool designed to help those afflicted with the original CryptoLocker malware. Through various partnerships and reverse engineering engagements, Fox-IT and FireEye have ascertained many of the private keys associated with CryptoLocker.  Having these private keys allows for decryption of files that are encrypted by CryptoLocker.

FireEye and Fox IT have created a webpage, https://www.decryptcryptolocker.com, where a user can upload an encrypted CryptoLocker file.  Based on this upload, the user will be provided with the option to download a private key that should decrypt their affected files. The site also provides instructions on how to apply this key to the files encrypted by CryptoLocker to decrypt those files.

To use the site, simply upload an encrypted file without any confidential information. (Please keep in mind, we will not permanently store, view, or modify your file in any fashion.) Enter your email address, to ensure the private key associated with the file is sent to the correct individual. Ensure you enter the correct number or phrase in the Captcha entry field.

crypto2

Figure 2: Screenshot of https://www.DecryptCryptoLocker.com

After clicking “Decrypt It!”, you will be presented with instructions to download the Decryptolocker.exe tool from https://www.decryptCryptoLocker.com (Figure 3). In addition, your private key will be sent to the email addresses specified.

crypto32

Figure 3: DecryptCryptoLocker decryption result page

After receiving the email (Figure 4), you will then select the key and utilize it in conjunction with Decryptolocker.exe.

crypto4

Figure 4: Email containing private key

At this point, the user opens a Windows Command Prompt, and browses to the directory of the Decryptolocker.exe tool and the locked file.  (Please note that the directory of the locked file must be specified if the file is not local to the tool’s directory.) The user must enter the command exactly as specified on the successful decryption page. The command structure should be used as the following:

Decryptolocker.exe –key “<key>” <Lockedfile.doc>

Upon successful execution of the tool, the user should be presented with a prompt indicating decryption was successful (Figure 5).

crypto5

Figure 5: Successful decryption of File1-1.doc

Conclusion

Operation Tovar made a clear impact on the distribution of and infection of machines by CryptoLocker. However, there have been no known avenues available designed to help users get their encrypted files back without making significant payments to those responsible for infecting machines in the first place. While the remediation of infected machines can be somewhat difficult, hopefully with the help of https://www.decryptCryptoLocker.com and Decryptolocker.exe, we can help you get back some of the valuable files that may still be encrypted.

As always, to help prevent a threat like this from affecting you and your data, ensure you backup your data. Ideally, this would be done in at least two locations: One would be on premises (such as an external hard drive), and the other would be off premises (such as cloud storage).

View the free, on-demand webinar DeCryptoLocker: Relief for CryptoLocker Victims for additional information.

FAQ

Are all encrypted files afflicted with CryptoLocker decryptable with this tool?

We believe we recovered everything the from the CryptoLocker database. However, we are aware that there could be a limited data chunk that could be missing which is related to either the takedown or interruptions of the CryptoLocker backend infrastructure. As a result, certain files may not be decryptable. Also, new variants of CryptoLocker may be released at any time, and the tools we discuss here or have made available may not be able to decrypt files infected with these more recent variants.

Does this tool work against CryptoLocker variants?

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, this tool may not be successful in all decryption processes because of code and functionality variances.

Does any of our data get stored by FireEye or Fox-IT?

Under no circumstances does personal data get stored, processed or examined by FireEye or Fox-IT when using this tool.

Is this service free?

The Decryptolocker.exe tool is available at no cost via the website to anyone that has been compromised with CryptoLocker.

How can I use the Decryptolocker.exe tool?

The Decryptolocker.exe tool is designed to perform a few different types of functions.  Here are some examples of various prompts you can enter, depending on the result you would like to obtain.

1) If you would like to test a file if it is encrypted with CryptoLocker, you can enter:
Decryptolocker.exe –find File1.doc

2) If you would like to find all files encrypted with CryptoLocker in a directory, you can enter:

Decryptolocker.exe –find -r “C:\FolderName”

Note: Remember to include the “-r”

3) If you would like to decrypt a file encrypted with CryptoLocker, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” File1.doc

4) If you would like to decrypt all files in a folder, you can enter:

Decryptolocker.exe –key “<your private key provided in email>” C:\FolderName\*

Note: Remember to include the “*” at the end

5) If you would like to decrypt all the files in a folder or drive recursively, you can enter:

Decryptolocker.exe –key  “<your private key provided in email>” -r C:\

Note: Decryptolocker.exe creates a backup of all encrypted files in the same directory before writing the decrypted file. If you do not have enough space for these files, then the prompt may not execute, and your computer may run more slowly.  Ensure you have sufficient file space before proceeding.

 

Disclaimers

There are several variants of CryptoLocker, all functioning in different ways. While these variants do appear similar to CryptoLocker, the tools discussed here may not successfully decrypt files encrypted by every variant because of differences in the programs or for other reasons. Also, while we have many unlocking keys, there is a possibility that we will be unable to decrypt your files.

References


http://www.fireeye.com/blog/technical/2014/07/operation-tovar-the-latest-attempt-to-eliminate-key-botnets.html

http://blog.fortinet.com/A-Closer-Look-at-CryptoLocker-s-DGA/

https://www.fox-it.com/en/