A 30-minute sweep of Industrial Control Systems in Belgium

TLDR; We found several ICS systems in Belgium that were exposed to the internet without requiring any authentication. Screenshots below.

Update 19/12: We’ve also had some coverage in the media about this research. ‘De Standaard‘ did an article about it and so did ‘Datanews’ (in Dutch and in French).

Industrial Control Systems (ICS) is the general term for electronic control systems used in industrial production. The term encompasses everything from supervisory control and data acquisition (SCADA) to Programmable Logic Controllers (PLC) – often found in industrial and critical infrastructures.

These systems were once state-of-the-art controllers for heavy industry, but nowadays they are included in many HVAC (Heating, Ventilation and Air Conditioning), home automation and even industrial livestock feeding systems. These systems are installed in many corporations – big and small – but also at home.

ICS Security

ICS Security has been a big issue since Stuxnet[1]. Stuxnet was one of the first – and very advanced – malware specifically targeting ICS appliances. Since then, we’ve seen a steady flow of ICS targeted malware, simple and advanced alike[2]. One of the reasons ICS is being heavily targeted, is because of the criticality of the appliances that it controls, but also because most ICS systems have not been designed for security. To make matters worse, many ICS installations are poorly incorporated into existing networks. Today, still many ICS appliances are connected to the internet without any proper authentication. This means that actors with bad intentions could gain access to these critical systems with little to no effort.

Since NVISO is a Belgian company (and thus most of our clients are Belgian or have a Belgian office), we decided to take a quick peek into the security of Belgian ICS systems.

“How many of those systems would we be able to find in Belgium with little effort”, we thought…

Shodan

In comes Shodan[3]. Shodan is the first search engine for internet-connected devices. It allows you to easily search throughout the internet for specific appliances and protocols. We only used Shodan in throughout this research and have only used simple search syntax.

ics-10

30 minutes later

Using our knowledge about ICS systems (some vendors, some protocols), we started investigating the Belgian internet-space. The results were worrisome. Within only 30 minutes, we managed to find at least 9 instances of Belgian ICS systems that were connected to the open internet, without requiring authentication. We found heating systems, ventilation systems, building control systems, delivery acceptance systems, home automation systems, camera systems and even an automatic feeding system of a farm.

Next to these ICS systems, we also found a big volume of Belgian Point-of-Sale (PoS) systems. Luckily, almost no Belgian PoS is equipped with a card reader – and thus no credit card details would be retrieved upon compromise – but there’s still a risk here concerning customer’s data. Next to that it could be used as an entry point into the corporate network. Probably not a good idea to have those directly connected to the internet.

All the ICS systems that we found using Shodan, used a VNC server for remote access. TCP/5900 was in open state and authentication was disabled. We have stopped seen these horrible things in corporate environments, but apparently they still exist in the ICS world…

Remediation

If your ICS system needs to be remotely controlled, we would recommend to use a secure connection towards it (VPN, white listing IP’s, etc.) and enforcing a decent authentication (long and complex password/passphrase, no anonymous login). Since many ICS systems still don’t give you decent authentication out-of-the-box, make sure to put it behind a managed network and enforce decent authentication (and logging!), e.g. by using a jump server.

We will contact all identified companies with our findings and will offer them help with any potential remediation. In Belgium, this sort of ‘notification’ is still in a gray zone, legally speaking. Luckily, the Centre for Cybersecurity Belgium (CCB) is looking into proposing a ‘responsible disclosure’ law[4].

Raise Awareness

With this 30-minute research, we wanted to raise awareness about the criticality of ICS and other internet-attached systems and their lack of security. While companies are slowly but steadily investing more and more into information security, they often overlook ICS systems. Next to the end-user responsibility, we want to stress that a part of the responsibility is to be shared with the vendors and installation companies. We often see that they make no effort to secure these systems or offer no guidelines towards secure installation.

The loot

Disclaimer: We have removed all Personal Identifying Information from the screenshots below. We have not accessed any system; the screenshots were taken by Shodan. All screenshots listed below have been identified as originating from a system located in Belgium.

 

ics-1

The interface of a Tolsma storage technology climate control system

ics-2

The logon screen of a PoS system. While this system requires authentication, these versions of windows embedded often contain multiple vulnerabilities and should not be exposed unfiltered to the internet.

ics-3

The interface of a building heater system.

ics-4

The interface of a camera module for the Tolsma Storage Technology appliance.

ics-5

Again, an interface of a building heater system.

ics-6

The interface of an intercom system.

ics-7

The interface of a home automation system.

ics-8

The interface of a feeding machine for livestock.

ics-9

The interface of a Tritone Automatic Feeding System.

[1] https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/

[2] https://www.fireeye.com/blog/threat-research/2016/06/irongate_ics_malware.html

[3] https://www.shodan.io

[4] http://datanews.knack.be/ict/nieuws/ethisch-hacken-bijna-legaal-in-belgie-want-alles-zit-vol-lekken/article-normal-787153.html

Analyzing an Office Maldoc with a VBA Emulator

Today we were informed of another maldoc sample. After a quick look, we were convinced that this sample would be a good candidate for Philippe Lagadec’s VBA emulator ViperMonkey.

The maldoc in a nutshell: when the spreadsheet is opened, the VBA code builds a long JScript script and then executes it. This script contains base64 code for an executable (ransomware Petya GoldenEye version), which is written to disk and executed. The building of the script is done with heavily obfuscated VBA code, so we thought it would be a good idea to try ViperMonkey. ViperMonkey is a free, open-source VBA emulator engine written in Python. You can use it to emulate VBA code on different platforms without MS Office.

Taking a look with oledump.py at this sample (md5 b231884cf0e4f33d84912e7a452d3a10), we see it contains a large VBA macro stream:

20161207-140153

 

Here is the end of the VBA code:

20161207-140222

Let’s analyze this with ViperMonkey:

vmonkey.py sample.vir

Since there are a lot of VBA statements, it will take ViperMonkey some time (couple of minutes) to parse this:

20161207-134559

In the end we get this result:

20161207-135220

ViperMonkey doesn’t identify any suspicious actions, but we see that the ActiveX object to be created is “MSScriptControl.ScriptControl”. This string was obfuscated with Chr concatenations, and ViperMonkey was able to parse it. To parse all obfuscated expressions like this, we provide option -e to ViperMonkey:

vmonkey.py -e sample.vir

20161207-140124

 

We this information, we can understand what subroutine Workbook_Open does: it executes a JScript script stored in variable LQ3.

How to we get the value of LQ3? We can set ViperMonkey’s log level to debug, and log the emulation of all statements. This will produce a lot of output, so it’s beter to redirect this to file.

vmonkey.py -l debug sample.vir > output.log 2> debug.log

Searching for the last occurrence of string “setting LQ3” in debug.log, we find the JScript script:

20161207-141806

This script decodes a BASE64 payload, writes it to disk and then executes it: it’s a new variant of Petya ransomware, GoldenEye.

 

PDF URIs

I was handed an interesting PDF document. It doesn’t contain malicious code, yet it generates network traffic. Let me explain how this is achieved.

Creating a PDF that makes a HTTP(S) connection to a website is easy. There’s no need to use an exploit, not even JavaScript. You just have to use a URI object:

20161128-103231

On its own, this object will do nothing. An action is needed to have this URI requested. If you want this URI to be requested when the PDF document is opened, you could add an /OpenAction:

20161128-103504

Adobe Reader will not let this connection happen silently. The user will be prompted before the TCP connection (to subdomain.nviso.be in our example) is established:

screen-shot-2016-11-28-at-10-44-35

But even before the user clicks one of the buttons, Adobe Reader will do a DNS request for this domain (nviso.be):

screen-shot-2016-11-28-at-10-43-43

If the domain does not resolve to an IP address, Adobe Reader will do another DNS request for the subdomain (subdomain.nxdomains.be in this example, where nxdomains.be does not resolve to an IP address):

screen-shot-2016-11-28-at-10-46-50

In this case, the warning presented to the user is slightly different:

screen-shot-2016-11-28-at-10-47-05

This type of PDF document can be used to track users: when the document is opened, a DNS request is performed. If the request is a FQDN unique to the PDF document, then such a DNS request logged by the DNS server is a sure indicator that the PDF document has been opened. Remark that this DNS request will have a source IP address from a DNS server, not from the user’s machine.

If the user allows a connection to be made, then a TCP connection will be established between the user’s machine and the web server.

In a corporate environment with HTTP(S) proxies, the DNS requests can be prevented from going to the Internet.

Malicious Document Targets Belgian Users

In this blog post I want to show how a malicious document (maldoc) behaves and how it can be analyzed with free tools.

A couple of weeks ago many users in Belgium received an e-mail, supposedly from a courier company, informing them that a package was waiting for them (article in Dutch).

This is an example of the e-mail:

20161114-142948

This e-mail contains a link to a Word document:

20161114-142226

The Word document contains VBA macro code to download and execute malware (downloader behavior). But MS Word contains protection features that prevent the code from running when the document is opened in Word.

First of all, since the Word document was downloaded from the Internet, it will be marked as such, and MS Word will open the document in Protected View:

20161114-143404

The user is social-engineered into clicking the Enable Editing button. Because the Word document contains VBA macros, another protection kicks in:

20161114-143421

By default, MS Word disables macros for documents of untrusted sources. Only after the user clicks on the Enable Content button, will the VBA macros run.

The user is presented with an empty document, but meanwhile malware was downloaded and executed invisibly to the user:

20161114-143442

The VBA macro code can be extracted with a free open-source tool: oledump.py.

20161114-153022

When looking at the VBA code (streams 8 and 9), we find subroutine Document_Open in stream 9:

20161114-153526

This subroutine is automatically executed when Word opens the document. Subroutine Document_Open contains a call to subroutine TvoFLxE in Module1:

20161114-155109

Subroutine TvoFLxE removes the content of the document (this causes the document to become blank, see screenshot), saves the document and calls function HuEJcCj.

20161114-155123

In this function we see a call to CreateObject. This is always interesting and requires further analysis. CreateObject takes a string as argument: the name of the object to be created. In this code, the string is returned by function JFZzIeCKcjgPWI which takes 2 arguments: 2 strings that look like gibberish. We see this often in maldocs (malicious documents): strings are obfuscated, e.g. made unreadable. Function JFZzIeCKcjgPWI is a string decoding function, taking strings “MWqSBYcnRrviVpGRtY.ASJhGneqYlVl”and “FYqRnVNvJB1GqMA” and converting them to a meaningful string.

In this maldoc, the string obfuscation method is rather simple. Function JFZzIeCKcjgPWI removes all characters found in string “FYqRnVNvJB1GqMA” from string “MWqSBYcnRrviVpGRtY.ASJhGneqYlVl”. Was is left is string “WScript.Shell”. This Shell object can be used to make Windows execute commands. So we need to deobfus.

20161114-155207

When we deobfuscate these strings, we get this PowerShell command:

20161114-162354

This PowerShell command downloads an executable (malware) to disk and executes it. The downloaded malware seems to be ransomware, we’ll write another blog post if it has interesting features.

To protect yourself from this kind of attacks, never activate the document (Enable Editing and Enable Content). Anti-virus can also protect you by 1) detecting the maldoc and 2) detecting the executable written to disk. When you don’t trust a document, you can always upload it to VirusTotal.

 

Testimonial of Stefaan Truijen

Hi, I’m Stefaan Truijen and in 2014-2015 I did my master thesis at the department of computer science at KULeuven. I assessed the susceptibility of modern web browsers to RAM scrapers in collaboration with NVISO. Security had always been one of my passions, so I was excited to get started.

Writing a thesis is an intensive process. Happily, I was able to rely on both Arne (NVISO) and Raoul (KULeuven) throughout the entire year for advice/brainstorming.

First, I needed to get an overview of prior research on memory scraping. Arne supplied me with a couple of initial research documents and references, and I reviewed any new material I found with Arne and Raoul almost weekly.

After some preliminary tests, I had to determine how I would continue and I wanted to contribute at least a little bit to fighting memory scrapers. I was able to bounce a few ideas off Arne and Raoul. In the end we decided that, since I was unable to find any prior research that had already assessed the size of the problem – i.e. memory scraping web browsers – measuring the degree of susceptibility of each of the three most commonly used web browsers (Chrome, Firefox, IE) was the most interesting angle.

In order to get a sufficient amount of data to form a solid conclusion, I ran thousands of experiments. Of course, running thousands of experiments manually is not very efficient and it affects reproducibility of the results. Therefore I learned how to work with new tools. Most relevant were Selenium’s automated testing framework for web browsers and the Windows API. Whenever I had questions, Arne and Raoul gladly answered them.

Now that the dust has settled, I can say that I have acquired a deeper understanding of low level security, more specifically memory scraping, and the consequences of relatively relaxed memory and API access policies that I did not have before. I am very satisfied with the result of my thesis and NVISO played an important role in realizing it!

Testimonial of Nick Van Haver

Hi, I’m Nick Van Haver and I want to reflect briefly on my master thesis which I have worked out in cooperation with NVISO and the Ghent University. NVISO helped me in many ways while providing me with a lot of freedom to choose the course of my thesis. They showed me a lot of trust and respect, which I truly appreciate.

The topic of my thesis research was “The Detection of Client-side Vulnerabilities in Web Applications through the Browser”. This topic is deeply rooted in the field of web application security, and thus lead me far beyond its basics. At first I had quite some experience with the development of web applications, but far less with relation to their security aspects.

When looking into a new field or topic, it is hard to find the right sources and high quality references. The right resources can turn a week’s worth of work into a single day. NVISO provided me with these resources and handed me tools, enabling me to educate myself in the web application security field and to make the most out of my thesis. Thanks to NVISO, I had contact with some of the big names in the industry such as Google, Minded Security, Portswigger and many others. Furthermore they assisted me with their expertise in security during meetings.

In the end, my research resulted in a fairly high score of 16 out of 20. Because of these grades I graduated magna cum laude as a Civil Engineer in Computer Sciences. At the beginning of my thesis my knowledge on web application security was rather limited. Now I feel accomplished in this field of security and I now know where to find the most correct information when dealing with web application vulnerabilities. I now also feel more confident when contacting external parties.

I can highly recommend working with NVISO. Choosing to work together with them for your master thesis ensures you that the topic will be both challenging and interesting. You will receive the support and resources you need to achieve your goal. It really is a worthwhile experience! Once the results of my thesis are public, they will be shared with the community!