Monthly Archives: June 2017

Dvmap: the first Android malware with code injection capabilities

25 June 2017

In the train back from Berlin last week I had the opportunity to go through my reading list. The news about Dvmap, an Android malware which code injection capabilities, caught my attention.

Kaspersky’s Roman Unuchek published a great post in the Kaspersky Lab Securelist blog on 8 June 2017 about Dvmap. Dvmap is hidden in the app colourblock which was downloaded more than 50.000 times from the Google Play Store. Google removed the app from the Play Store by now.

Dvmap injects malicious code into the Android system libraries at runtime and deactivates security features of the OS. It is capable to downloading extensions from a C&C Server. In addition, the attackers used some clever method to bypass the security features of the Play Store.

To inject code in system libraries at runtime on Linux-based operating systems root privileges are required. And this is what Dvmap tries at first. Since the standard user does not work as root, the trojan must use existing, unpatched vulnerabilities to gain root rights.

Support Codename Android Version Linux Kernel Distribution
No Gingerbread 2.3.x 2.6.35 0,80%
No Ice Cream Sandwich 4.0.x 3.0.1 0,80%
No Jelly Bean 4.1.x 3.0.31 3,10%
No Jelly Bean 4.2.x 3.4.0 4,40%
No Jelly Bean 4.3 3.4.39 1,30%
Yes KitKat 4.4 3.10 18,10%
Yes Lollipop 5.0 3.16.1 8,20%
Yes Lollipop 5.1 3.16.1 22,60%
Yes Marshmallow 6.0 3.10 31,20%
Yes Nougat 7.0 4.4.1 8,90%
Yes Nougat 7.1 4.4.1 0,60%

(Data collected during a 7-day period ending on June 5, 2017. Any versions with less than 0.1% distribution are not shown. Source: Android Dashboards at Android Developers.com)

The above table shows that 89.6 percent of the Android devices which downloaded software from the Google Play Store run Android versions which are supported by Google. Sounds good.

Unfortunately, Google delivers patches to their partners for further distribution to the consumers. And this is where the trouble begins.

In post ‘Diverse protections for a diverse ecosystem: Android Security 2016 Year in Review’ published on 22 March 2017 in the Google Security Blog one reads:

We provided monthly security updates for all supported Pixel and Nexus devices throughout 2016, and we’re thrilled to see our partners invest significantly in regular updates as well. There’s still a lot of room for improvement, however. About half of devices in use at the end of 2016 had not received a platform security update in the previous year.

With this, about 55% of the devices which downloaded software from the Google Play Store in June 2017 were vulnerable e.g. against Dirty Cow (CVE-2016-5195), a nine-year-old bug in the Linux kernel that was detected in October 2016. Since all Linux kernel from 2.x through 4.x before 4.8.3 were affected, nearly all Android version are affected as well.

From the Android Security Review 2016 we learn that “More than 735 million devices from 200+ manufacturers received a platform security update in 2016”. With this, about 360 million devices are vulnerable to Dirty Cow and Dvmap today.

Google’s partners “invested significantly in regular security updates in the past years”, but sadly not enough. Enterprise customers with an MDM solution like Airwatch in place can take this risk. The consumers foot the bill. Who cares?

Have a great week!

Some thoughts on “Ransomware a real risk for SCADA networks”

5 June 2017

“By now the ‘Air gapping’ myth should be expunged from every ICS/SCADA manager on earth.” I really like this statement from Daniel Cohen-Sason, published on 23 May 2017 in the CYBERBIT blog.

From my point of view, the ‘Air Gap’ era ended with the introduction of portable engineering stations about 30 years ago.

Modern OT networks are often designed on the basis of the ISA 95 Standard with network zones and security devices, e.g. firewalls, to control the communications flow between the process control and SCADA systems across the zones. Modern production requires a lot of Machine-to-Machine (M2M) communication between the production networks zones and between the production network and the business network. Besides this M2M communication Human-to-Machine (H2M) communication is required, e.g. for operator access from the business network and for remote maintenance.

For M2M and H2M interaction communication channels must be opened on the firewalls. With this, there is always a chance that malware can spread across such required connections. Furthermore, cyber attackers can gain access, e.g. through remotely exploitable vulnerabilities, after they hijacked a M2M communications endpoint in the business network. We dealt with this very effectively in the past 20 years.

Many of the required connections use the SMB protocol for exchange of data. That’s no problem per se. The problem is, that we still use Windows 7 and Windows Server 2008 in the manufacturing industry which cannot work with the latest versions of the SMB protocol for data exchange.

Since WannaCry exploited a vulnerability in SMB version 1.0, it was only a matter of time before WannaCry would find its way across a required connection from the business network to the production network.

How to deal with the problem?

  • Priority patching.

The systems at the border between the business network and the production network must me patched with highest priority. Although this is somewhat tricky to achieve in WSUS, it’s worth to deal with this WSUS feature. In addition to the operating system components, all application components must be patched as well. The same applies to Linux based systems.

  • Deactivating SMB.

Is a great means in the case of an emergency, and part of a long-term data exchange strategy.

  • Set up asset and vulnerability management.

At least all systems at the endpoints of required M2M and H2M connections must be included. This enables you to evaluate the scale of the problem in the case of a new vulnerability.

  • Faster innovation cycles.

At least for the systems at the perimeter of the production network we must allow for shorter innovation cycles. With Windows 8, Windows 10, and Windows Server 2012, new versions of the SMB protocol are used which are not affected by WannaCry. Don’t forget to deactivate the SMB V1.0 compatibility in the this versions.

This includes the technology used for data exchange. For example, the widely used Robocopy fosters the spreading of WannaCry because it is based on the SMB protocol.

  • Increase the level of isolation.

Start with challenging the required M2M and H2M connections. Eliminate every connection without a business purpose. For the remaining, check whether the best available security technology is used.

Take care!