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

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

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

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

That patch is available here.

 

Issue Summary:

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

 

Technical information:

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

Exploitation:

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

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

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

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

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

 

 

Credit:  Fermin J. Serna and Kevin Stadmeyer

Advertisements

Another Door to Windows | Hot Potato exploit

Microsoft Windows versions 7, 8, 10, Server 2008 and Server 2012 vulnerable to Hot Potato exploit which gives total control of PC/laptop to hackers

Security researchers from Foxglove Security have discovered that almost all recent versions of Microsoft’s Windows operating system are vulnerable to a privilege escalation exploit. By chaining together a series of known Windows security flaws, researchers from Foxglove Security have discovered a way to break into PCs/systems/laptops running on Windows 7/8/8.1/10 and Windows Server 2008/2010.

The Foxglove researchers have named the exploit as Hot Potato. Hot Potato relies on three different types of attacks, some of which were discovered back at the start of the new millennium, in 2000. By chaining these together, hackers can remotely gain complete access to the PCs/laptops running on above versions of Windows.

Surprisingly, some of the exploits were found way back in 2000 but have still not been patched by Microsoft, with the explanation that by patching them, the company would effectively break compatibility between the different versions of their operating system.

Hot Potato

Hot Potato is a sum of three different security issues with Windows operating system. One of the flaw lies in local NBNS (NetBIOS Name Service) spoofing technique that’s 100% effective. Potential hackers can use this flaw to set up fake WPAD (Web Proxy Auto-Discovery Protocol) proxy servers, and an attack against the Windows NTLM (NT LAN Manager) authentication protocol.

Exploiting these exploits in a chained manner allows the hackers to gain access to the PC/laptop by elevating an application’s permissions from the lowest rank to system-level privileges, the Windows analog for a Linux/Android root user’s permissions.

Foxglove researchers created their exploit on top of a proof-of-concept code released by Google’s Project Zero team in 2014 and have presented their findings at the ShmooCon security conference over the past weekend.

They have also posted proof-of-concept videos on YouTube in which the researchers break Windows versions such as 7, 8, 10, Server 2008 and Server 2012.

You can also access the proof of concept on Foxglove’s GitHub page here.

Mitigation

The researchers said that using SMB (Server Message Block) signing may theoretically block the attack. Other method to stop the NTNL relay attack is by enabling “Extended Protection for Authentication” in Windows.

 

 

Credit:  Vijay Prabhu, techworm

Industrial Control Systems (ICS/SCADA) and Cyber Security

It’s a cyber war out there! Is your company ready for battle?

Industry is slowly waking up to the fact that its facilities are in the crosshairs, the targets of cyber attacks by bad actors trying to exploit vulnerabilities in industrial control systems (ICSs) to steal intellectual property or damage critical equipment.

Whether caused by sophisticated hacking teams assembled by nation states, cyber criminal organizations, potential competitors, disgruntled or careless employees, or just bored teenagers in their bedrooms, cyber intrusions into industrial facilities now number in the hundreds of thousands every year. Even unintentional cyber incidents can cause damage.

The result can be more dangerous than stolen credit card numbers or government personnel information, because it can cause real physical damage like a destroyed or damaged power plant, water system, chemical plant, or oil and gas facility. Attacks like these could bring a region or even an entire nation to its knees. But even smaller-scale events, such as hackers taking over control of cars on a busy interstate, or manipulating the recipe controls at a food processing plant, could wreak havoc.

In exploring this issue, one fact stands out: industrial control systems were never designed to be secure. Many have also been in place for 20 or 30 years, long before cybersecurity became an issue. It’s no wonder that retrofitting this massive installed base to overcome 21st century cyber vulnerabilities can seem like an insurmountable task.

Digital threats, physical dangers

“Everyone’s concerned about viruses and worms, but Stuxnet never killed anyone,” says Joe Weiss of Applied Control Solutions, who has amassed a database of more than 750 actual control system cyber incidents. “Compromised industrial control systems, on the other hand, have caused significant electrical outages, environmental and equipment damage, and even killed people.”

Weiss is managing director of the ISA99 committee, which helped develop the ISA/IEC 62443 series of standards on industrial automation and control systems security. “IT people are focused on vulnerabilities from information loss, but it’s the impact of ICS failures on equipment, people and the environment that matters to industrial control professionals,” he says. “Not every ICS cyber vulnerability is critical. We need to focus on what can affect control system operation so that end users can prioritize threats to system reliability and safety.”

Weiss sees his role as waking industry up to the real dangers it faces from compromised control systems. “Industry is a backwater when it comes to cybersecurity,” he says. “We don’t have the systems, the training or the technologies to address it because too many people still don’t believe it’s real.”

He takes a broader view of cybersecurity than many people, citing the emissions fraud at Volkswagen, where software was intentionally manipulated to falsify test results. “Industrial control lies more and more within the digital world,” he says. “Anything that changes the intent of the control system function, whether or not it’s with malicious intent, is a cyber issue.”

The enemy is often us

Companies may think they’re safe if their manufacturing systems are not connected to the Internet, but it turns out the biggest threat comes from their own employees.

“There’s no such thing as an air gap,” says Ben Orchard, applications engineer at Opto 22, referring to control systems that aren’t connected to the Internet. “Malicious software (malware) is chiefly introduced into control systems by employees, vendors or contractors who plug devices like an infected smartphone into a computer’s USB port to charge it or bring in a corrupted thumb drive.”

Since people are the biggest weakness in any security system, Orchard recommends disabling or even filling in non-essential USB ports with epoxy. Other basics include only executing software that’s been cryptographically signed by a trusted source, locking down the operating system so that no email or web browsing is allowed, and constant monitoring of control network traffic.

If you’re looking for proven practices to improve the cybersecurity of your facilities or production systems, Orchard recommends the ones developed by the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) at the Department of Homeland Security. The guidelines address best practices like defense-in-depth, security zoning and encryption.

“They’ve done an astoundingly good job of assembling logical, practical, real-world advice,” he emphasizes. In particular, Orchard recommends downloading the first document in the series, “Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies” (see “More Sources for Security Guidance,”).

Help is a call away

Automation suppliers are actively engaged in the cyber battle. Vendors are continually adding new levels of security to their products and providing a range of customer education and support services.

Honeywell Process Solutions has fielded a team of more than 85 experts who can provide vendor-agnostic risk analysis, perform forensics, and help customers establish security policies, says Mike Baldi, cybersecurity architect for the company. Honeywell has also created a lab in Georgia to demonstrate and validate security solutions for customers, as well as train its own engineers.

Honeywell’s industrial cybersecurity risk manager software for continuous monitoring provides real-time, continuous monitoring of threats, vulnerabilities and risks specific to a control system, providing immediate notification of weaknesses in security.

“We’ll always be chasing evildoers,” Baldi says, “so advanced analytics are crucial, not just to analyze the latest attack but to identify patterns in these attacks that can guide us to the best solutions. It’s essential that companies analyze threat risk, test solutions at installation and maintain security over the life of a system.”

Turning control security on its head

Bedrock Automation is a company that’s making waves in the world of industrial control with a revolutionary platform that integrates an inside-out, bottom-up approach to cybersecurity.

“The cybersecurity issue was the catalyst for the creation of our new control platform. It’s software-defined automation,” says Albert Rooyakkers, CTO and engineering vice president for Bedrock.

Cybersecurity concerns were the catalyst for Bedrock Automation’s new control platform.

The company says the Bedrock system—created by a team of engineering experts from the automation and semiconductor industries—can function as a PLC, DCS, RTU or safety system. Bedrock is using independent system integrators and high-tech distributors as its channels to the market.

“This platform unification was the big breakthrough, something the major automation suppliers have never been able to achieve,” Rooyakkers says. “The incremental security improvements they’ve been doing for years are not likely to work because there are too many gaps to patch. It’s like taking a stick to a gunfight.”

According to research firm Frost & Sullivan, which cited the company’s work with its 2015 Best Practices Award for Industrial Control System Innovation, “Bedrock Automation has designed a control system with layered and embedded cybersecurity features, starting at the transistor level using secure microcontroller technology that includes secure memory, hardware accelerators and true random number generators.”

Rooyakkers adds, “ICS security in the cyber age will require a complete rethinking of control system design. Standards and best practices are being developed, but it will take a generation at the current pace of progress to achieve the level of security industry needs today.”

Hardening hardware and software

Given that most companies can’t afford a wholesale replacement of their existing control systems, many automation vendors are focused on making incremental improvements to harden their software and hardware.

Among the latest cybersecurity introductions by Emerson Process Management for its DeltaV control platform is a suite of cybersecurity software products from Intel Security’s McAfee Labs, including traditional antivirus, centralized whitelisting of applications allowed to run, security information and event management (SIEM) to perform analytics on events on everything from firewalls to operator stations, and network monitoring to identify unusual network communications.

“We’ve been hardening the control system with every DeltaV release,” says Neil Peterson, DeltaV product marketing director. “With the addition of SIEM, for example, you now have a tool that can manage the cybersecurity health of the control system as a whole, alerting you to unusual circumstances that need to be checked out. These include unauthorized communication attempts on your firewall and failed log-on attempts.”

There’s no silver bullet for cybersecurity, says Rick Gorskie, manager of Emerson’s asset strategy and management program. “Security requires a multilayered approach that combines technology, practices and people,” he says. “That furnace meltdown at a German steel mill purportedly started when someone clicked on a phishing email infected with malware, which allowed hackers to make their way down the network to attack the blast furnace.”

Gorskie says incidents like that are why he’s received more customer questions about security in the past year than in the previous 20 years. “We’re getting more board-level interest than ever before, and they’re starting to fund some serious projects because they want to avoid shutdowns,” Peterson adds. “Security is very hard and it requires shared responsibility. We develop systems with locks, but it requires ongoing vigilance to keep them secure. You can’t set it and forget it.”

More than networks

“Security is more than a network issue,” says Clark Case, security platform leader for Rockwell Automation. “Content (intellectual property) protection, tamper detection, user authentication and access control are just as important.”

While user concerns vary by industry and customer, Case says, “machine builders who ship their equipment offshore are particularly concerned about IP protection, so we’re releasing software licensing technology so they can control access to their source code.”

Rockwell has introduced a number of products and services to help customers design, deploy and maintain more secure control systems, according to Case. The company’s FactoryTalk AssetCentre software, for example, lets users see who is making changes to the control system and what changes have been made, including which machine the changes were made on and who was logged on at the time.

“We’re also making our controllers more secure in the design and manufacturing process so that they’re resilient to standard attacks,” Case adds. In addition to fielding a security incident response team for its products, Rockwell works closely with security groups like ICS-CERT.

“Companies need to step back and take a broader look at system risks—what bad things can be done, and how best to address them,” Case says. “Companies doing the best at mitigating cybersecurity risks have people on staff who are responsible for control system security. Fortunately, there are a growing number of operations technology people with the required skillsets.”

Different worlds

Cybersecurity is that much more important in manufacturing. “When there’s a breach in the IT world, you can take the system down and fix it,” explains Jeff Caldwell, chief architect for cybersecurity at Belden. “But in the industrial world, you have to continue to operate when there’s a problem. You can’t have power plants shutting down or planes falling from the sky. Industry’s primary concerns are resilience, uptime and safety. Cybersecurity is just a segment of that.”

Belden promotes a safe networking architecture that includes every device connected to those networks. “Consequently, we’ve developed cybersecurity solutions for all seven layers of the ISO stack,” Caldwell says.

Key elements of this architecture include security zoning; system change management; intrusion radiation protection to identify, halt and report invalid and anomalous traffic; security sentinels at every network juncture; layer 2 deep packet inspection in front of PLCs and RTUs as well as between security zones; authentication for user and administrator access; encryption of VPN traffic information; and secure wireless.

Belden recently acquired TripWire, a company that specializes in system change management, as part of a cybersecurity product portfolio that includes Tofino layer 2 firewalls with industrial protocol deep packet inspection.

Being knowledgeable about industrial protocols is essential to any control system security solution, Caldwell says. “IT uses gigantic signature files to identify patterns that indicate security problems, but that doesn’t work in the industrial world where communications often flow over serial cables that can’t carry large files,” he says. “Let’s face it: The IT world has failed at control system security. You just can’t jam IT solutions onto control systems and make them work. Only 20 percent of industrial cyber incidents are intentional, and disgruntled employees cause half of those. Just 10 percent come from hackers. That’s why it’s critical to protect against everything.”

This is not a test

“Most manufacturers have some degree of security preparedness in place, but it’s unknown whether these steps are enough to repel a full-scale targeted assault on a facility,” cautions Richard Clark, technical marketing specialist for SCADA cybersecurity at Schneider Electric Software, which includes InduSoft and Wonderware. “It seems more likely, as has been demonstrated in several modeling and public test sessions by ICS-CERT at Idaho National Lab, that such an attack would be successful because most engineers and IT personnel would not know how to react properly to such an event.”

Manufacturers need to ask themselves what damage could be caused at their facility if a targeted attack succeeded and their production system was shut down for weeks, Clark says. “These are the type of what-if scenarios that are frequently never explored. Few security managers or engineering teams have performed a single-point failure analysis of their facility, and even fewer have ever done a formal risk assessment using the results of the analysis,” he says. “This is especially irresponsible since there are excellent tools to help them find answers to these questions and determine if they are dedicating enough resources to safeguarding their facilities from a breach or control system malfunction.”

Clark says forward-looking security engineers and IT personnel have begun using automation to assist them in preventing attacks, combining security solutions to create what is known as defense-in-depth. These layers of disparate security measures can virtually surround critical assets and infrastructure.

“Once customers make the effort to begin to understand the nature of these threats to their facilities, products and employees, the safer and more operationally efficient they will become,” he says.


More Sources for Security Guidance

ICS-CERT Guidelines >>https://ics-cert.us-cert.gov/Recommended-Practices

Belden Security Blogs >>http://www.belden.com/blog/industrialsecurity/index.cfm

Schneider Electric/InduSoft Security eBooks >>https://www.smashwords.com/books/view/509999

NIST Cybersecurity Framework Gap Analysis Tool >>https://www.us-cert.gov/forms/csetiso

PBS Nova Program on Cybersecurity >>http://video.pbs.org/video/2365582515/

ISA 99/ISA/IEC 62443 Guidelines >>http://isa99.isa.org/ISA99%20Wiki/Home.aspx

 

 

 

Credit:  , automationworld

BlackEnergy Attacking Ukraine’s Critical Infrastructures

The cybercriminal group behind BlackEnergy, the malware family that has been around since 2007 and has made a comeback in 2014 (see our previous blog posts on Back in BlackEnergy *: 2014 Targeted Attacks in Ukraine and Poland and BlackEnergy PowerPoint Campaigns, as well as ourVirus Bulletin talk on the subject), was also active in the year 2015.

ESET has recently discovered that the BlackEnergy trojan was recently used as a backdoor to deliver a destructive KillDisk component in attacks against Ukrainian news media companies and against the electrical power industry. In this blog, we provide details on the BlackEnergy samples ESET has detected in 2015, as well as the KillDisk components used in the attacks. Furthermore, we examine a previously unknown SSH backdoor that was also used as another channel of accessing the infected systems, in addition to BlackEnergy.

BlackEnergy evolution in 2015

Once activated, variants of BlackEnergy Lite allow a malware operator to check specific criteria in order to assess whether the infected computer truly belongs to the intended target. If that is the case, the dropper of a regular BlackEnergy variant is pushed to the system.

The BlackEnergy malware stores XML configuration data embedded in the binary of DLL payload.

Figure 1 – The BlackEnergy configuration example used in 2015

Figure 1 – The BlackEnergy configuration example used in 2015

Apart from a list of C&C servers, the BlackEnergy config contains a value called build_id. This value is a unique text string used to identify individual infections or infection attempts by the BlackEnergy malware operators. The combinations of letters and numbers used can sometimes reveal information about the campaign and targets.

Here is the list of Build ID values that we identified in 2015:

  • 2015en
  • khm10
  • khelm
  • 2015telsmi
  • 2015ts
  • 2015stb
  • kiev_o
  • brd2015
  • 11131526kbp
  • 02260517ee
  • 03150618aaa
  • 11131526trk

We can speculate that some of them have a special meaning. For example 2015telsmi could contain the Russian acronym SMI – Sredstva Massovoj Informacii, 2015en could mean Energy, and there’s also the obvious “Kiev”.

KillDisk component

In 2014 some variants of the BlackEnergy trojan contained a plugin designed for the destruction of the infected system, named dstr.

In 2015 the BlackEnergy group started to use a new destructive BlackEnergy component detected by ESET products as Win32/KillDisk.NBB, Win32/KillDisk.NBC and Win32/KillDisk.NBD trojan variants.

The main purpose of this component is to do damage to data stored on the computer: it overwrites documents with random data and makes the OS unbootable.

The first known case where the KillDisk component of BlackEnergy was used was documented by CERT-UA in November 2015. In that instance, a number of news media companies were attacked at the time of the 2015 Ukrainian local elections. The report claims that a large number of video materials and various documents were destroyed as a result of the attack.

It should be noted that the Win32/KillDisk.NBB variant used against media companies is more focused on destroying various types of files and documents. It has a long list of file extensions that it tries to overwrite and delete. The complete list contains more than 4000 file extensions.

 

Figure 2 – A partial list of file extensions targeted for destruction by KillDisk.NBB

Figure 2 – A partial list of file extensions targeted for destruction by KillDisk.NBB

The KillDisk component used in attacks against energy companies in Ukraine was slightly different. Our analysis of the samples shows that the main changes made in the newest version are:

  • Now it accepts a command line argument, to set a specific time delay when the destructive payload should activate.
  • It also deletes Windows Event Logs : Application, Security, Setup, System.
  • It is less focused on deleting documents. Only 35 file extensions are targeted.
Figure 3 – A list of file extensions targeted for destruction by new variant of KillDisk component

Figure 3 – A list of file extensions targeted for destruction by new variant of KillDisk component

As well as being able to delete system files to make the system unbootable – functionality typical for such destructive trojans – the KillDisk variant detected in the electricity distribution companies also appears to contain some additional functionality specifically intended to sabotage industrial systems.

Once activated, this variant of the KillDisk component looks for and terminates two non-standard processes with the following names:

  • komut.exe
  • sec_service.exe

We didn’t manage to find any information regarding the name of the first process (komut.exe).

The second process name may belong to software called ASEM Ubiquity, a software platform that is often used in Industrial control systems (ICS), or to ELTIMA Serial to Ethernet Connector. In case the process is found, the malware does not just terminate it, but also overwrites the executable file with random data.

Backdoored SSH server

In addition to the malware families already mentioned, we have discovered an interesting sample used by the BlackEnergy group. During our investigation of one of the compromised servers we found an application that, at first glance, appeared to be a legitimate SSH server called Dropbear SSH.

In the order to run the SSH server, the attackers created a VBS file with the following content:

Set WshShell = CreateObject(“WScript.Shell”)
WshShell.CurrentDirectory = “C:\WINDOWS\TEMP\Dropbear\”
WshShell.Run “dropbear.exe -r rsa -d dss -a -p 6789″, 0, false

As is evident here, the SSH server will accept connections on port number 6789. By running SSH on the server in a compromised network, attackers can come back to the network whenever they want.

However, for some reason this was not enough for them. After detailed analysis we discovered that the binary of the SSH server actually contains a backdoor.

Figure 4 – Backdoored authentication function in SSH server

Figure 4 – Backdoored authentication function in SSH server

As you can see in Figure 4, this version of Dropbear SSH will authenticate the user if the password passDs5Bu9Te7 was entered. The same situation applies to authentication by key pair – the server contains a pre-defined constant public key and it allows authentication only if a particular private key is used.

Figure 5 – The embedded RSA public key in SSH server

Figure 5 – The embedded RSA public key in SSH server

ESET security solutions detect this threat as Win32/SSHBearDoor.A trojan.

Indicators of Compromise (IoC)

IP addresses of BlackEnergy C2-servers:
5.149.254.114
5.9.32.230
31.210.111.154
88.198.25.92
146.0.74.7
188.40.8.72

XLS document with malicious macro SHA-1:
AA67CA4FB712374F5301D1D2BAB0AC66107A4DF1

BlackEnergy Lite dropper SHA-1:
4C424D5C8CFEDF8D2164B9F833F7C631F94C5A4C

BlackEnergy Big dropper SHA-1:
896FCACFF6310BBE5335677E99E4C3D370F73D96

BlackEnergy drivers SHA-1:
069163E1FB606C6178E23066E0AC7B7F0E18506B
0B4BE96ADA3B54453BD37130087618EA90168D72
1A716BF5532C13FA0DC407D00ACDC4A457FA87CD
1A86F7EF10849DA7D36CA27D0C9B1D686768E177
1CBE4E22B034EE8EA8567E3F8EB9426B30D4AFFE
20901CC767055F29CA3B676550164A66F85E2A42
2C1260FD5CEAEF3B5CB11D702EDC4CDD1610C2ED
2D805BCA41AA0EB1FC7EC3BD944EFD7DBA686AE1
4BC2BBD1809C8B66EECD7C28AC319B948577DE7B
502BD7662A553397BBDCFA27B585D740A20C49FC
672F5F332A6303080D807200A7F258C8155C54AF
84248BC0AC1F2F42A41CFFFA70B21B347DDC70E9
A427B264C1BD2712D1178912753BAC051A7A2F6C
A9ACA6F541555619159640D3EBC570CDCDCE0A0D
B05E577E002C510E7AB11B996A1CD8FE8FDADA0C
BD87CF5B66E36506F1D6774FD40C2C92A196E278
BE319672A87D0DD1F055AD1221B6FFD8C226A6E2
C7E919622D6D8EA2491ED392A0F8457E4483EAE9
CD07036416B3A344A34F4571CE6A1DF3CBB5783F
D91E6BB091551E773B3933BE5985F91711D6AC3B
E1C2B28E6A35AEADB508C60A9D09AB7B1041AFB8
E40F0D402FDCBA6DD7467C1366D040B02A44628C
E5A2204F085C07250DA07D71CB4E48769328D7DC

KillDisk-components SHA-1:
16F44FAC7E8BC94ECCD7AD9692E6665EF540EEC4
8AD6F88C5813C2B4CD7ABAB1D6C056D95D6AC569
6D6BA221DA5B1AE1E910BBEAA07BD44AFF26A7C0
F3E41EB94C4D72A98CD743BBB02D248F510AD925

VBS/Agent.AD trojan SHA-1:
72D0B326410E1D0705281FDE83CB7C33C67BC8CA

Win32/SSHBearDoor.A trojan SHA-1:
166D71C63D0EB609C4F77499112965DB7D9A51BB

Credit: welivesecurity

Malware Found Inside Downed Ukrainian Grid Management Points to Cyber-attack

The Burshtyn TES power plant in Ivano-Frankivsk Oblast, Ukraine. It’s not clear if Burshtyn was affected, but power outages did affect the grid in the Ivano-Frankivsk Oblast region. Image: Raimond Spekking/Wikimedia Commons

Overview

On December 23, a Ukrainian power company announced that a section of the country had gone dark. This temporary outage was not the result of purely physical sabotage—like the case a month earlier where explosives had knocked out power lines to Crimea—but instead, according to Ukrainian officials, was due to a cyberattack.

The country’s SBU security service immediately castigated Russia for the outage, according to Reuters, and Ukraine started an official investigation into what exactly happened.

Over the past few days, more details around the attack have emerged, including an apparent sample of malware found in a network of the regional control center. If that malware was indeed responsible for causing a blackout throughout parts of Ukraine, it would be a signal that industrial control systems (ICS), and in particular electric grids, really are under threat from cyberattacks, something that researchers have been warning for years.

“It was easily recoverable, but obviously it’s a bad thing for the power to go out”

Around a week after the attack announcement, Robert M. Lee, a former US Air Force cyber warfare operations officer as well as the founder and CEO of Dragos Security, wrote on the SANS ICS Security Blog that his team had obtained a sample of the malware found within the affected network.

“The fact that malware was recovered from the network at all, and the fact that it’s newer, gives a high confidence assessment that the cyberattack on Ukraine was legitimate,” Lee told Motherboard in a phone interview. Lee said the malware was “unique,” implying that it likely wasn’t something that just happened be on the grid network during the outage.

“The malware is a 32 bit Windows executable and is modular in nature indicating that this is a module of a more complex piece of malware,” Lee wrote in his blog post, who passed the sample over to Kyle Wilhoit, a senior threat researcher at cybersecurity company Trend Micro. Wilhoit said that the malware had a wiping function that would impact the targeted system.

“The resolution of APIs that are not used elsewhere in the code probably means that some of the code was borrowed from another program,” wrote Jake Williams, founder of Rendition Security and a SANS instructor, to whom Lee also provided the malware. Williams added that the malware appears to have a code “base,” on which modules are then added.

Other pieces of malware have targeted industrial systems in the past: “Havex” has infected technology commonly used in process control systems, such as water pumps and turbines; and “BlackEnergy,” which has been used in straight-up cybercriminal campaigns, has also been used to hit energy engineering facilities.

An Associated Press investigation published in December last year found that “sophisticated foreign hackers” had gained enough access to control power plant networks around a dozen times in the last decade. More broadly, the Wall Street Journal recently revealed that Iranian hackers had breached a New York dam in 2013. At the latest Chaos Communication Congress, a security, politics and art conference in Hamburg, Germany, researchers warned of the serious vulnerabilities in automated railroad systems. All of those require varying degrees of sophistication, with some of them needing expert knowledge of the target network’s protocols and idiosyncrasies.

After Lee’s post, more researchers published their own findings. Analysts from ESET claimed that the malware found in Ukraine was actually the BlackEnergy malware. Others went a step further, and wrote that BlackEnergy has been found within other Ukrainian power companies during the week of Christmas last year.

One group that has made heavy use of the BlackEnergy malware, and has previously targeted power facilities and other ICS, is alleged Russian hacking group Sandworm. It would be easy to assume that, because of the target and presence of supposed BlackEnergy malware, that Sandworm was behind the attack.

But that’s a logical leap too far, at least with the currently available evidence.

“The BlackEnergy malware has been in existence since 2007 and lots of different actors have used it,” Lee told Motherboard.

“People are saying that this piece of malware is linked to BlackEnergy. I can buy that, and there is some good analysis to say that is likely true,” he added. “But just because the BlackEnergy malware was used, does not mean that it’s linked at all” to Sandworm.

Irrespective of who committed the attack, what appears to have happened is that hackers “caused a power outage that was temporary in nature. It was easily recoverable, but obviously it’s a bad thing for the power to go out,” Lee said. “It’s not trivial—it still takes getting on the system and exploiting all that—but it’s not hard.”

One possible explanation is that the attackers may have remotely accessed a digital control panel located within the control center’s system. Other researchers have pointed towards the data wiping feature of the malware; presumably, wiping out vital data could have a negative impact on the electric grid’s systems. At this point, both of those theories are largely speculative.

But while either of those approaches are relatively easy for a hacker to carry out, attacks that would cause much more impact—that lasted for say, weeks or months—are much less likely to occur.

“Taking down the power grid, or cascading failures, or weeks of impact: that is incredibly hard. People have oversold how easy that is to achieve,” Lee added.

Although experts say it is likely that the power outage in Ukraine was caused by an cyberattack, there are still plenty of questions to be answered. More news is sure to follow in the coming days or weeks, as several research teams now have access to the malware sample.

Correction 1/4/16: This story originally referred to systems being compromised in a power plant or plants on the affected grid. As Michael Toecker pointed out, local sources report it was a regional control center that was affected.

 

Malware Analysis

The SANS ICS team recently gained access to a sample of malware that came from the network of the Ukrainian site targeted in the cyber attack that led to a power outage. I want to offer a few caveats to this blog post up front.

 

  • First, this is all developing and the next few days and weeks will add clarity to the situation.
  • Second, with this type of analysis there’s not much that can be definitively stated in terms of attribution or impact. Take everything here as informative only.
  • Third, SANS ICS is not in the business of releasing highly detailed technical analysis of malware. The purpose of this blog is to focus on lessons learned and education for the community. Therefore, I am not going to be sharing the hash of the sample we have but instead talking about the takeaways. There are at least 3 major cybersecurity and threat intelligence vendors I am aware of that have the sample and will be releasing detailed analyses. I do not want us at SANS ICS to impede that by releasing the sample to the wider community right now. However, to any of the major players and researchers that want a sample feel free to reach out to us via the SANS ICS Alumni email distribution and we will provide it to verified sources.

Here I’ll detail the facts, speculation, and takeaways for the community.

The Facts

The SANS ICS team has been researching the cyber attack on the Ukrainian power grid since the event occurred with a mix of interest and a critical viewpoint. The interest was due to the seriousness of the event and the critical viewpoint was taken because while threats are active against ICS there are often otherwise good case-studies that get spun out of control by the media. The idea of a cyber attack on infrastructure that leads to an impact to operations is very serious in nature and must be handled with care, especially when there is geopolitical tension in an area such as Ukraine.

Through trusted contacts in the communitythe SANS ICS team came across a lot of amplifying information about the attack, how it could have occurred, and the seriousness of this incident to the Ukrainian government and the focus they are putting on the investigation that increases the credibility of their reporting. The SANS ICS team was also passed a sample of malware from trusted sources taken from the impacted network by responders in country.

The hash for the malware can also be found on VirusTotal where a user in Ukraine submitted the sample on the 23rd of December. The timing and unique nature of the sample adds some credibility to the sources that collected and passed us the sample of the malware.

The malware is a 32 bit Windows executable and is modular in nature indicating that this is a module of a more complex piece of malware. I passed the malware sample to Kyle Wilhoit, a Senior Threat Researcher at Trend Micro who has done great work in the ICS community before, who confirmed through static analysis that the malware itself has a wiping routine that would impact the infected system. After that I passed the sample to Jake Williams, founder of Rendition Security and a fellow SANS Instructor, who has been analyzing this incident as well for further support. Below is his analysis:


 

Note that this analysis is based on an extremely limited static analysis of the malware and further analysis may impact these findings. The code appears modular in nature. The attackers take steps to obscure some notable suspicious APIs (e.g. OpenSCManager) from the imports table, but not others (e.g. CreateToolhelp32Snapshot). The string “obfuscation” method is crude and obvious upon manual examination, but effective to thwart string matching. Any of these hyphen separated strings would make an excellent Yara rule.

malware-ukraine

Notably, the malware does not appear to use all of the functions it imports. Specifically, there are no cross references to service related calls. While this may be due to dynamic call targets, there are significant numbers of cross references to other dynamically resolved APIs (e.g. RegDeleteKey).

The resolution of APIs that are not used elsewhere in the code probably means that some of the code was borrowed from another program. This hints at a development shop with a code base from which to piece modules together. Although the string obfuscation was crude, it was sufficient for the task. The crude string obfuscation should not be taken as an indication that the attacks came from a non-state actor.

Another possible interesting note is the compile timestamp of the executable. It is set to January 6, 1999.

timestamp-ukraine

This was likely modified by the attackers, but whether this date is significant in historical context is unknown at this time. It may simply be a random modification.


 

There are at least 3 major cybersecurity vendors working on the piece of malware right now in their own analysis and I will simply state that I’m impressed with the quality of work from them I have seen so far. Additionally, folks at the ICS-CERT and E-ISAC are doing great analysis as well and will likely be pushing out information through government sharing channels soon. Simply put, a lot will be known about this in the community soon to further support the analysis or help move on to a better understanding.

The Speculation

It is not currently possible right now to state that the malware recovered caused the loss of power in Ukraine. Additionally, the wiping functionality of the module recovered is likely for the purposes of cleanup after the attack; it itself does not appear to have been capable of causing the outage. This is important to note as the wiping capability is not similar in nature to the Shamoon attack but instead an anti-forensics technique.

Also, it is possible that the incident caused responders to look at the network where they found the malware. The malware could be new and yet not be related to the incident. At this time I believe the malware is related to the incident though from analysis by the SANS ICS team and others around the community but this should be categorized as a low-confidence assessment currently.

There has also been speculation that the malware is related to, and potentially a module for, BlackEnergy2. The previous statement should not be taken as a standalone soundbite. There is very little to support this conclusion right now. If true though this would add credibility to Ukraine’s SBU who reported that the malware was launched by Russian security services. Because of the sources concluding the BlackEnergy2 connection I feel it is important to share the (potentially overstated) speculation with the community as there were many organizations around the global community who were impacted by that campaign. Just because a campaign is reported on publicly does not mean it is no longer active. Security personnel in ICS organizations should be actively looking for threats — the Ukrainian incident should not be seen as an incident that only impacts one site in a foreign country although no panic or alarm should be taken, only due diligence towards defense.

The Takeaways

  • There is a lot of great analysis going on in the community by a number of companies, government organizations, and individual researchers. Each have been contributing some unique aspects to the analysis. Defenders must always work together like this and build off of each other’s strengths. Information sharing in this manner is critical to security.
  • The Ukrainian power outage is more likely to have been caused by a cyber attack than previously thought. Early reporting was not conclusive but a sample of malware taken from the network bolsters the claims. The unique nature of the malware indicate some level of targeting may be possible but much more information is needed to confirm that targeting of ICS or this specific facility was intended.
    • If the malware does end up being related to the BlackEnergy2 campaign then this adds to the possibility that the facility and ICS was specifically targeted
    • Technical data alone is very rarely enough to conclude the intention of an adversary
  • ICS facilities around the world need to take an active defense approach to monitoring ICS networks and responding to threats. Additionally, each should have an ability, or at least contacts to request help from, to perform basic threat and malware analysis to know when to reach out for help to the larger community (my one plug: the identification of, response to, and analysis of threats is the type of skill set we teach in SANS ICS515 and I would encourage organizations to find this or similar type of training for security personnel onsite. Firewalls and boxes on the network alone will not protect an ICS fully).

This incident is an important case-study for the ICS community. If the analysis and follow on information is validated about the malware and attack then this will also be a significant event for the international community. The precedence that this event sets is far reaching past the security community and will need to be analyzed and understood fully. The response by countries to this type of attack and any attribution obtained will also be significant in establishing the precedence of these types of events moving forward in the international community.

 

 

 

Credit:  sans, motherboard

OmniRAT – the $25 way to hack into Windows, OS X and Android devices

 

Just last week, police forces across Europe arrested individuals who they believed had been using the notorious DroidJack malware to spy on Android users.

Now attention has been turned on to another piece of software that can spy on communications, secretly record conversations, snoop on browsing histories and take complete control of a remote device. But, unlike DroidJack, OmniRAT doesn’t limit itself to Android users – it can also hijack computers running Windows and Mac OS X too.

And that’s not the only difference between DroidJack and OmniRAT. Both of them may be being sold openly online, but OmniRAT retails for as little as $25 compared to DroidJack’s more hefty $210.

Security researchers at the anti-virus company Avast describe OmniRAT as a “Remote Administration Tool.

And it certainly can be used for entirely legitimate purposes, with the permission and consent of the owners of Android, Mac and Windows computers it tries to control.

But, in the wrong hands, it can also be considered a “Remote Access Trojan” – giving malicious hackers an opportunity to sneakily spy on and steal from unsuspecting users duped into installing the code.

OmniRAT

In his blog post, researcher Nikolaos Chrysaidos describes how he believes hackers have infected Androids with OmniRAT after sending an SMS.

Apparently, a German Android user explained on the Techboard-online forum how he had received an SMS telling him that an MMS had not been delivered directly to him due to the StageFright vulnerability.

In order to access the MMS, the user was told to follow a bit.ly link within three days, and enter a PIN code.

However, as Crysaidos explains, visiting the URL would initiate the attempt to install OmniRAT onto the target’s Android device:

Once you enter your number and code, an APK, mms-einst8923, is downloaded onto the Android device. The mms-einst8923.apk, once installed, loads a message onto the phone saying that the MMS settings have been successfully modified and loads an icon, labeled “MMS Retrieve” onto the phone.

Once the icon is opened by the victim, mms-einst8923.apk extracts OmniRat, which is encoded within the mms-einst8923.apk. In the example described on Techboard-online, a customized version of OmniRat is extracted.

Android app icon

Perhaps the long list of permissions requested by the app would make you think twice, if it weren’t so common for so many popular apps in the Google Play store to make similar requests.

App permissions

The problem of course is that through its cunning social engineering, and the target’s keen attempt to view the MMS that they might have been sent, it may be all too likely that the user grants permission for the app to be installed without thinking of the possible consequences.

And, as the app is capable of sending its own SMS messages, it may be that your infected Android device could then send further messages with malicious intent to your friends, family and colleagues, in the hope of hijacking further devices. After all, users are more likely to be tricked into believing a message is legitimate, and letting their guard down, if they receive a message apparently coming from someone they know and trust.

Sadly victims will probably have no clue that their devices are compromised, and even if they uninstall the MMS Retrieve icon, the customised version of OmniRAT remains installed on their Android smartphone, and will be sending data to a command and control (C&C) server seemingly based in Russia:

Russian domain

So, the question to ask is how should you protect yourself?

Well, clearly you should resist the urge to install apps onto your smartphone from anywhere other than the official app stores. Although malware has unfortunately snuck into the Google Play store in the past, you’re much more likely to encounter malicious code from unauthorised sources.

Furthermore, I would recommend running a security product on your Android device to detect malicious code and that – if possible – you keep your Android smartphone patched with the latest version of the operating system.

Finally, always think long and hard before clicking on links from untrusted sources. It could be that you’re just one click away from a hacker trying to take remote control of your Android phone.

 

 

Credit: 

iBackDoor: High-Risk Code Hits iOS Apps

Introduction

FireEye mobile researchers recently discovered potentially “backdoored” versions of an ad library embedded in thousands of iOS apps originally published in the Apple App Store. The affected versions of this library embedded functionality in iOS apps that used the library to display ads, allowing for potential malicious access to sensitive user data and device functionality.

These potential backdoors could have been controlled remotely by loading JavaScript code from a remote server to perform the following actions on an iOS device:

  • Capture audio and screenshots
  • Monitor and upload device location
  • Read/delete/create/modify files in the app’s data container
  • Read/write/reset the app’s keychain (e.g., app password storage)
  • Post encrypted data to remote servers
  • Open URL schemes to identify and launch other apps installed on the device
  • “Side-load” non-App Store apps by prompting the user to click an “Install” button

The offending ad library contained identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the potentially backdoored ad library: version codes 5.3.3 to 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2] – version 7.0.5 – the potential backdoors are not present. It is unclear whether the potentially backdoored versions of the ad library were released by adSage or if they were created and/or compromised by a malicious third party.

As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015.

While we have not observed the ad server deliver any malicious commands intended to trigger the most sensitive capabilities such as recording audio or stealing sensitive data, affected apps periodically contact the server to check for new JavaScript code. In the wrong hands, malicious JavaScript code that triggers the potential backdoors could be posted to eventually be downloaded and executed by affected apps.

Technical Details

As shown in Figure 1, the affected mobiSage library included two key components, separately implemented in Objective-C and JavaScript. The Objective-C component, which we refer to as msageCore, implements the underlying functionality of the potential backdoors and exposed interfaces to the JavaScript context through a WebView. The JavaScript component, which we refer to as msageJS, provides high-level execution logic and can trigger the potential backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

Figure 1: Key components of backdoored mobiSage SDK

In the remainder of this section, we reveal internal details of msageCore, including its communication channel and high-risk interfaces. Then we describe how msageJS is launched and updated, and how it can trigger the backdoors.

Backdoors in msageCore

Communication channel

MsageCore implements a general framework to communicate with msageJS via the ad library’s WebView. Commands and parameters are passed via specially crafted URLs in the format adsagejs://cmd&parameter. As shown in the reconstructed code fragment in Figure 2, msageCore fetches the command and parameters from the JavaScript context and inserts them in its command queue.

Figure 2: Communication via URL loading in WebView

To process a command in its queue, msageCore dispatches the command, along with its parameters, to a corresponding Objective-C class and method. Figure 3 shows portions of the reconstructed command dispatching code.

Figure 3: Command dispatch in msageCore

At-risk interfaces

Each dispatched command ultimately arrives at an Objective-C class in msageCore. Table 1 shows a subset of msageCore classes and the corresponding interfaces that they expose.

msageCore Class Name Interfaces
MSageCoreUIManagerPlugin – captureAudio:

– captureImage:

– openMail:

– openSMS:

– openApp:

– openInAppStore:

– openCamera:

– openImagePicker:

– …

MSageCoreLocation – start:

– stop:

– setTimer:

– returnLocationInfo:webViewId:

– …

MSageCorePluginFileModule – createDir

– deleteDir:

– deleteFile:

– createFile:

– getFileContent:

– …

MSageCoreKeyChain – writeKeyValue:

– readValueByKey:

– resetValueByKey:

MSageCorePluginNetWork – sendHttpGet:

– sendHttpPost:

– sendHttpUpload:

– …

MSageCoreEncryptPlugin – MD5Encrypt:

– SHA1Encrypt:

– AESEncrypt:

– AESDecrypt:

– DESEncrypt:

– DESDecrypt:

– XOREncrypt:

– XORDecrypt:

– RC4Encrypt:

– RC4Decrypt

– …

Table 1: Selected interfaces exposed by msageCore

The selected interfaces reveal some of the key capabilities exposed by the potential backdoors in the library. They expose the potential ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

Beyond the selected interfaces, the ad library potentially exposed users to additional risks by including logic to promote and install “enpublic” apps as shown in Figure 4. As we have highlighted in previous blogs [footnotes 3, 4, 5, 6, 7], enpublic apps can introduce additional security risks by using private APIs in certain versions of iOS. These private APIs potentially allow for background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations. Apple has addressed a number of issues related to enpublic apps that we have brought to their attention.

Figure 4: Installing “enpublic” apps to bypass Apple App Store review

We can see how this ad library functions by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

Figure 5: Capturing audio with duration and threshold

Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

Figure 6: Reading the keychain in the kSecClassGenericPassword class

Remote control in msageJS

msageJS contains JavaScript code for communicating with a remote server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

Figure 7: The file layout of msageJS

The command execution interface is constructed as follows:

          adsage.exec(className, methodName, argsList, onSuccess, onFailure);

The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

adsage.exec(“MSageCoreUIManager”, “captureAudio”, [“Hey”, 10, 40],  onSuccess, onFailure);

Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

Figure 8: Base64 encoded JavaScript component in Zip format

When msageJS is launched, it sends a POST request to hxxp://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9.

Figure 9: Server response to msageJS update request via HTTP POST

Enterprise Protection

To ensure the protection of our customers, FireEye has deployed detection rules in its Network Security (NX) and Mobile Threat Prevention (MTP) products to identify the affected apps and their network activities.

For FireEye NX customers, alerts will be generated if an employee uses an infected app while their iOS device is connected to the corporate network. FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users will receive on-device notifications of the risky app and IT administrators receive email alerts.

Conclusion

In this blog, we described an ad library that affected thousands of iOS apps with potential backdoor functionality. We revealed the internals of backdoors which could be used to trigger audio recording, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these potential backdoors in ad libraries could be controlled remotely by JavaScript code should their ad servers fall under malicious actors’ control.

[1] http://www.adsage.com/mobisage
[2] http://www.adsage.cn/
[3] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html
[4] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html
[5] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html
[6] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html
[7] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell

Credit:  Zhaofeng Chen, Adrian Mettler, Peter Gilbert , Yong Kang | Mobile Threats, Threat Research