Exploiting CVE-2017–0199: HTA Handler Vulnerability
Last updated
Last updated
Note: this was posted in April 2017 and was the first public post describing how to weaponise the vulnerability in contrast to the many posts at the time detailing its discovery from a defense perspective
This post was originally published on https://www.mdsec.co.uk/blog/ when I was under employment of MDSec Consulting Limited in the United Kingdom. This is mirrored on my own blog for archiving reasons.
FireEye recently documented attacks of a 0-day vulnerability in the Windows HTA handler being exploited in the wild using Office RTF documents. The vulnerability later became referenced as CVE-2017–0199 and addressed in the April 2017 Microsoft Update. Neither the sample or any specific information were released on how to reproduce the vulnerability, however it was particularly interesting to the team because it was capable of bypassing known exploit mitigations such as EMET.
This blog post describes how to exploit this issue without user interaction based on our research; the technique discussed may differ from that used by the threat actors. It is also important to stress that the issue is not just restricted to RTF documents, we have successfully exploited this using other Office document types also.
While the technical steps to reproduce the issue as described by FireEye are sparse, the article contains several hints; firstly that the issue occurs using an OLE2 embedded link object, secondly while handling a HTA file.
To embed an OLE2 link object in to a document, open Microsoft Word and click on the insert object button as shown in the screenshot below:
Select Create From File, insert the URL to the HTA file and tick both Link to file and Display as Icon.
Save the document as a DOCX, DOC or RTF file; all of which handle OLE2 link objects.
At this point, some social engineering is required to get the user to run the payload as they must double click the icon for the OLE object. However, no warnings or run prompts are displayed should the user do this, as can be seen below:
However, the icon and text may look somewhat suspicious to the educated user; it is therefore possible to improve the campaign by replacing the icon and filename and rendering the object in Word. This can be achieved by not selecting the “Display as Icon” check box and serve the document content-type as application/rtf or application/doc:
This causes the HTA to be rendered as follows:
However, user interaction is still required and the user must double click on the “hello” text this time or save the file to force the document to perform the connection to update the content and display it.
However, FireEye’s description does not explicitly state that user interaction is required and hints that the payload should automatically run when the document is opened. Research by the ActiveBreach team discovered how this can be achieved. Delving further in to the RTF RFC the “\objupdate” control was discovered:
The description for this control is particularly interesting as it implies the object will update before displaying itself:
As such, it should be possible to create a document containing an \objupdate control that will ultimately force it to update on start up. This can be achieved by taking the previously created document and modifying it in a text editor:
Original:
Document with injected \objupdate control:
Opening the RTF file now causes the hosted HTA file to run without user interaction:
GIF: https://www.mdsec.co.uk/wp-content/uploads/2017/04/sploit.gif
It’s also worth noting that our research shows that if the user does not have Microsoft Office installed, the issue can still be exploited in WordPad however interaction is required.
A number of Yara rules have been released by the response community to detect this issue. In many cases these are somewhat inaccurate and may generate false positives as they rely on detection based on an RTF document containing an OLE2Link object. This does not necessarily imply malicious behaviour and may be a legitimately embedded object.
To effectively detect CVE-2017–0199, Yara rules should add a condition to identify the \objupdate control.
This blog post was written by Vincent Yiu.
We would also like to thank Etienne Stalmans for providing guidance on this issue.
