Category Archives: remote code execution

YARA DDE rules: DDE Command Execution observed in-the-wild

The MS Office DDE YARA rules that we published yesterday detected several malicious documents samples since 10/10/2017.

Remark: the malicious samples we mention were detected with our DDEAUTO rule (Office_DDEAUTO_field); as we feared, the second rule (Office_DDE_field) is generating some false positives and we will update it.

The first sample uses PowerShell to download an executable and run it. With zipdump.py and our YARA rules we can extract the command, and with sed command “s/<[^>]*>//g” we can remove the XML tags to reveal the command:

The second sample is using PowerShell with a second stage DLL (we were not able to recover the DLL):

As could be expected, we also observed many samples that are not truly malicious, but just the samples of persons experimenting with DDE code execution starting 10/10/2017. This could also be the case for the “DLL sample”.

Finally, we observed a malicious campaign spoofing emails from the U.S. Securities and Exchange Commission (SEC)’s EDGAR filing system with .docx attachments abusing DDE code execution.

This campaign used compromised government servers to serve a PowerShell second stage script:

Leveraging compromised government servers increases the success of such campaigns, because of the implied trust associated with government servers.

Talos published an extensive analysis for this campaign. We observed the same samples, and also a sample (email attachment) from the same campaign that uses pastebin to host the second stage:

Should you have to analyze the next stages, know that they are PowerShell scripts that have been compressed and BASE64 encoded. Here is one method to extract these scripts:

New IOCs:

  • bf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb
  • 316f0552684bd09310fc8a004991c9b7ac200fb2a9a0d34e59b8bbd30b6dc8ea

Detecting DDE in MS Office documents

Dynamic Data Exchange is an old Microsoft technology that can be (ab)used to execute code from within MS Office documents. Etienne Stalmans and Saif El-Sherei from Sensepost published a blog post in which they describe how to weaponize MS Office documents.

We wrote 2 YARA rules to detect this in Office Open XML files (like .docx):

Update 1: our YARA rules detected several malicious documents in-the-wild.

Update 2: we added rules for OLE files (like .doc) and updated our OOXML rules based on your feedback.

// YARA rules Office DDE
// NVISO 2017/10/10 - 2017/10/12
// https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/
 
rule Office_DDEAUTO_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee][Aa][Uu][Tt][Oo]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}
 
rule Office_DDE_field {
  strings:
    $a = /<w:fldChar\s+?w:fldCharType="begin"\/>.+?\b[Dd][Dd][Ee]\b.+?<w:fldChar\s+?w:fldCharType="end"\/>/
  condition:
    $a
}

rule Office_OLE_DDEAUTO {
  strings:
    $a = /\x13\s*DDEAUTO\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

rule Office_OLE_DDE {
  strings:
    $a = /\x13\s*DDE\b[^\x14]+/ nocase
  condition:
    uint32be(0) == 0xD0CF11E0 and $a
}

These rules can be used in combination with a tool like zipdump.py to scan XML files inside the ZIP container with the YARA engine:

The detection is based on regular expressions designed to detect fields containing the word DDEAUTO or DDE. By dumping the detected YARA strings with option –yarastringsraw, one can view the actual command:

Here is an example of the DDE rule firing:

You can also look for MS Office files containing DDE using this YARA rule in combination with ClamAV as described in this blog post.

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.

rtfdump.py 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 oledump.py: 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.

Detection

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 {
 strings:
 $header = "{\\rtf1"
 $objdata = "objdata 0105000002000000" nocase
 $urlmoniker = "E0C9EA79F9BACE118C8200AA004BA90B" nocase
 $http = "68007400740070003a002f002f00" nocase
 condition:
 $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.

 

References: