Back in 2016, a coworker of mine was using CERT BFF, and he asked how he could turn a seemingly exploitable crash in Microsoft Office into a proof-of-concept exploit that runs calc.exe. Given Address Space Layout Randomization (ASLR) on modern Windows platforms, this isn't as easy as it used to be. One strategy to bypass ASLR that is possible in some cases is to leverage a memory leak to disclose memory addresses. Another strategy that is sometimes possible is to brute-force attack the vulnerability to make ASLR irrelevant. In this case, however, the path of least resistance was to simply use Rich Text Format (RTF) content to leverage Object Linking and Embedding (OLE) to load a library that doesn't opt in to using ASLR.

As I started pulling the thread of RTF and OLE, I uncovered a weakness that is much more severe than an ASLR bypass. Continue reading to follow my path of investigation, which leads to crashed Windows systems and stolen passwords.

Before getting into the details of my analysis, let's cover some of the basics involved:

OLE is a technology that Microsoft released in 1990 that allows content from one program to be embedded into a document handled by another program. For example, in Windows 3.x Microsoft Write provides the ability to embed a "Paintbrush Picture" object, as well as a "Sound" or a "Package." These are the three available OLE objects that can be inserted into a Write document:

Once inserted, we now have a Write document that has embedded Paintbrush content. Neat!

SMB is a protocol that extends the DOS API (Interrupt 21h) for local file access to include network capabilities. That is, a file on a remote server can be accessed in much the same way that a file on a local drive can be accessed. Microsoft included SMB capabilities in Windows for Workgroups 3.1, which was released in 1992.

Microsoft Outlook is an email client that comes with Microsoft Office. Outlook includes the ability to send rich text (RTF) email messages. These messages can include OLE objects in them.

When viewed with the Microsoft Outlook client, these rich text email messages are displayed in all of their rich-text glory.

You may already have an idea of where I am going. If it's not clear, let's summarize what we know so far:

1. Microsoft Outlook can create and render RTF email messages.
2. RTF documents (including email messages) can include OLE objects.
3. Due to SMB, OLE objects can live on remote servers.

HTML email messages on the Internet are much more common than rich text email, so let's first look at the behavior of Microsoft Outlook when viewing an HTML message that has a remote image on a web server:

Here we can see that the remote image is not loaded automatically. Why is this the case? The reason is because if Outlook allowed remote images to load automatically, it could leak the client system's IP address and other metadata such as the time that an email is viewed. This restriction helps to protect against a web bug being used in email messages.

Now let's try the same sort of message, except in rich text format. And rather than a remote image file, it's an OLE document that is loaded from a remote SMB server:

Well this is unexpected. Outlook blocks remote web content due to the privacy risk of web bugs. But with a rich text email, the OLE object is loaded with no user interaction. Let's look at the traffic in Wireshark to see what exactly is being leaked as the result of this automatic remote object loading:

Here we can see than an SMB connection is being automatically negotiated. The only action that triggers this negotiation is Outlook previewing an email that is sent to it. In the screenshot above, I can see that the following things are being leaked:

1. IP address
2. Domain name
3. User name
4. Host name
5. SMB session key

A remote OLE object in a rich text email messages functions like a web bug on steroids! At this point in my analysis in late 2016, I notified Microsoft about the issue.

This bug results in two main problems, described below.

We know at this point that we can trigger Outlook to initiate an SMB connection to an arbitrary host. On February 1, 2017, a Windows SMB client vulnerability (VU#867968) was disclosed. Upon connecting to a malicious SMB server, Windows would crash. What if we created a rich text email in Outlook, but point to an SMB server that exploits this vulnerability?

Once Outlook previews such an email message, Windows will crash with a Blue Screen of Death (BSOD) such as the above. And beyond that, every time Outlook is launched after encountering such a scenario, Windows will BSOD crash again because Outlook remembers the last email message that was open. This is quite a denial of service attack. At this point I shared the attack details with Microsoft. Eventually Microsoft fixed this SMB vulnerability, and luckily we did not hear about any mass email-based exploitation of it.

SMB vulnerabilities aside, I decided to dig deeper into the risks of a client attempting to initiate an SMB connection to an attacker's server. Based on what I saw in Wireshark, I already knew that it leaked much more than just the IP address of the victim. This time I used both Responder and John the Ripper.

First I sent an RTF email that has a remote OLE object that points to a system running Responder. On the Responder system I saw the following as soon as the email was previewed in Outlook:

Here we have an NTLMv2 hash that we can hand off to John the Ripper. As shown below, I copied and pasted the hash into a file called test_user.john:

In approximately 1 second, I was able to determine that the password for the user "test_user" who opened my RTF email was test. The hash for a stronger password (longer and more types of characters) will take longer to crack. I've performed some basic testing on how long it takes to bruteforce the entire solution space of an 8-character password on a single mid-range GPU (NVIDIA GTX 960):

• Lowercase letters - 16 minutes
• Mixed-case letters - 3 days
• Mixed-case letters and digits - 12 days
• Mixed-case letters, digits, and symbols - 1 year

The statistics above are the worst-case scenarios for bruteforce cracking randomly-generated passwords. Any passwords that are words (like "test") or patterns (like "asdf") are much easier to crack than randomly-generated passwords, since most cracking tools have rules to check for such things.

Also, an attacker may have access to systems with multiple high-end GPUs that can cut their times into fractions of the above numbers. Each character that is added to the password length has an exponential effect on the time it takes to bruteforce the password, though. For example, while my mid-range GPU takes 1 year to exhaust the entire solution space of an 8-character password (with mixed case letters, digits, and symbols), increasing the password length to 9 characters also increases the time it takes to exhaust the solution space to 84 years!

Microsoft released a fix for the issue of Outlook automatically loading remote OLE content (CVE-2018-0950). Once this fix is installed, previewed email messages will no longer automatically connect to remote SMB servers. This fix helps to prevent the attacks outlined above. It is important to realize that even with this patch, a user is still a single click away from falling victim to the types of attacks described above. For example, if an email message has a UNC-style link that begins with "\\", clicking the link initiates an SMB connection to the specified server.

Additional details are available in CERT Vulnerability note VU#974272.

On the Windows platform, there are several ways to cause the client to initiate an SMB connection. Any time an SMB connection is initiated, the client's IP address, domain name, user name, host name, and password hash may be leaked. To help protect against attacks that involve causing a victim's machine to initiate an SMB connection, please consider the following mitigations:

• Install Microsoft update CVE-2018-0950. This update prevents automatic retrieval of remote OLE objects in Microsoft Outlook when rich text email messages are previewed. If a user clicks on an SMB link, however, this behavior will still cause a password hash to be leaked.
• Block inbound and outbound SMB connections at your network border. This can be accomplished by blocking ports 445/tcp, 137/tcp, 139/tcp, as well as 137/udp and 139/udp.
• Block NTLM Single Sign-on (SSO) authentication, as specified in Microsoft Security Advisory ADV170014. Starting with Windows 10 and Server 2016, if the EnterpriseAccountSSO registry value is created and set to 0, SSO authentication will be disabled for external and unspecified network resources. With this registry change, accessing SMB resources is still allowed, but external and unspecified SMB resources will require the user to enter credentials as opposed to automatically attempting to use the hash of the currently logged-on user.
• Assume that at some point your client system will attempt to make an SMB connection to an attacker's server. For this reason, make sure that any Windows login has a sufficiently complex password so that it is resistant to cracking. The following two strategies can help achieve this goal: