Category Archives: remote code execution

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

Analysis of a CVE-2017-0199 Malicious RTF Document

There is a new exploit (CVE-2017-0199) going around for which a patch was released by Microsoft on 11/04/2017. In this post, we analyze an RTF document exploiting this vulnerability and provide a YARA rule for detection. is a Python tool to analyze RTF documents. Running it on our sample produces a list with all “entities” in the RTF document (text enclosed between {}):

This is often a huge list with a lot of information. But here, we are interested in OLE 1.0 objects embedded within this RTF file. We can use the filter with option -f O for such objects:

There are 2 entities (objdata and datastore) with indices 153 and 249 (this is a number generated by rtfdump, it is not part of the RTF code). The content of an object is encoded with hexadecimal characters in an RTF file,  entity 153 contains 5448 hexademical characters. So let’s take a look by selecting this entity for deeper analysis with option -s 153:

In this hex/ascii dump, we can see that the text starts with 01050000 02000000, indicating an OLE 1.0 object. As the second line starts with d0cf11e0, we can guess it contains an OLE file.

With option -H, we can convert the hexadecimal characters to binary:

Now we can see the string OLE2Link, which has often been referred to when talking about this zero-day. With option -i, we can get more information about the embedded object:

So it is clearly an embedded OLE file, and the name OLE2Link followed by a zero byte was chosen to identify this embedded OLE file. With option -E, we can extract the embedded object:

Since this is an OLE file, we can analyze it with we dump the file with option -d and pipe it into oledump:

The OLE file contains 2 streams. Let’s take a look at the first stream:

We can recognize a URL, let’s extract it with strings:

Because of vulnerability CVE-2017-0199, this URL will automatically be downloaded. The web server serving this document, will identify it as an HTA file via a Content-Type header:

Because this download is performed by the URL Moniker, this moniker will recognize the content-type and open the downloaded file with Microsoft’s HTA engine. The downloaded HTA file might look to us like an RTF file, but the HTA parser will find the VBS script and execute it:

This VBS script performs several actions, ultimately downloading and executing a malicious executable.


Let’s take a second look at the first stream in the OLE file (the stream with the malicious URL):

The byte sequence that we selected here (E0 C9 EA 79 F9 BA CE 11 8C 82 00 AA 00 4B A9 0B), is the binary representation of the URL Moniker GUID: {79EAC9E0-BAF9-11CE-8C82-00AA004BA90B}. Notice that the binary byte sequence and the text representation of the GUID is partially reversed, this is typical for GUIDs.

After the URL Moniker GUID, there is a length field, followed by the malicious URL (and then followed by a file closing sequence, …).

We use the following YARA rule to hunt for these RTF documents:

rule rtf_objdata_urlmoniker_http {
 $header = "{\\rtf1"
 $objdata = "objdata 0105000002000000" nocase
 $urlmoniker = "E0C9EA79F9BACE118C8200AA004BA90B" nocase
 $http = "68007400740070003a002f002f00" nocase
 $header at 0 and $objdata and $urlmoniker and $http

Remark 1: we do not search for string OLE2Link

Remark 2: with a bit of knowledge of the RTF language, it is trivial to modify documents to bypass detection by this rule

Remark 3: the search for http:// (string $http) is case sensitive, and if you want, you can omit it (for example, it will not trigger on https).

Remark 4: there is no test for the order in which these strings appear

Happy hunting!

The GHOST vulnerability

A serious problem in the Linux glibc library went unnoticed for almost 15 years. A simple coding mistake introduced into the code in November 2000 leaves servers including e-mail servers vulnerable to remote code execution. A buffer overflow in the GNU C Library function __nss_hostname_digits_dots(), which is called by the well used gethostbyname*() functions makes it possible to take over any type of server. In the case of e-mail servers — to take only one example — it is possible to take over a server remotely by sending a well-crafted e-mail exploiting the vulnerability.


Yesterday, Qualys announced that a serious problem in the Linux glibc library exposes servers to remote code execution. While the problem was already found in May 2013, the security implications of the bug only came to light when Qualys security researchers dived deeper into the issue. The issue was handled as a regular bug and updates were made available in 2013. As this bug was not qualified as a security issue, most systems were not updated.

However, there are clearly security implications to the bug that was found. As illustrated in the picture, taking over an unpatched e-mail server is rather simple as it does not require special credentials whatsoever. It requires detailed knowledge of the bug itself (and as Glibc is open source, the code can be inspected) and a malicious person with exploit writing capabilities to craft an attack vector in order to exploit this vulnerability. It requires the malicious person to send the e-mail to the mail server, which then calls one of the gethostbyname*() functions which will in turn call the problematic __nss_hostname_digits_dots(). If the attack is correctly designed, the attacker will get a shell on (and control over) the machine.


If you want to know if your systems are affected by this problem, you can use the code made available here to find out if your system is vulnerable. In any case, we would like to encourage administrators to update affected systems as soon as possible. NVISO customers have been sent an advisory note with detailed information regarding this vulnerability and what they can do right now to protect themselves.

What we’ve learned from this vulnerability is that once again security issues can go unnoticed for a very long time. We often come across web-facing applications that feature code written years ago, sometimes over a decade old. A clear lesson is that these may no longer be considered safe, for the simple reason that new security issues have since emerged. Many organizations are addressing this issue by reviewing older code on critical and web-facing applications. We can only encourage everyone to do the same.