Previously we
Surprisingly, Colsec was initially unable to reproduce the attack described and demonstrated by John when he used Internet Explorer running on Windows 7 to download and then open the malicious MHT file. Although his process manager showed that the system.ini, which he planned to steal from himself, was read by the script hidden in the MHT file, but was not sent to the remote server.
“It looked like a classic situation of the so-called “mark for a file received from the network (English mark-of-the-Web),” writes Kolsek. "When a file is received from the Internet, properly functioning Windows applications such as web browsers and email clients add a label to the file in the form
The researcher made sure that IE actually put such a label on the downloaded MHT file. Kolsek then tried to download the same file using Edge and open it in IE, which remains the default application for MHT files. Unexpectedly, the exploit worked.
First, the researcher checked the "mark-of-the-Web", it turned out that Edge saves in an alternative data stream, in addition to the security identifier, the source of the file's origin, which may raise some questions regarding the privacy of this method. Kolsek suggested that the extra lines might confuse IE and prevent it from reading the SID, but as it turns out, the problem was elsewhere. After a long analysis, the security specialist found the cause in two entries in the access control list, adding to some system service the right to read the MHT file that Edge entered there after it was downloaded.
James Foreshaw of the dedicated Zero-Day Vulnerability Team - Google Project Zero -
Next, the researcher wanted to better understand what causes the IE security failure. Deep analysis using the Process Monitor utility and the IDA disassembler ultimately showed that the resolution set by Edge prevented the GetZoneFromAlternateDataStreamEx Win Api function from reading the Zone.Identifier file stream and returned an error. For Internet Explorer, such an error when requesting a file's security label was completely unexpected, and, apparently, the browser considered that the error was equivalent to the fact that the file did not have a "mark-of-the-Web" label, which automatically makes it trusted, after causing IE to allow the script hidden in the MHT file to execute and send the target local file to the remote server.
"Do you see the irony here?" Kolsek asks. "An undocumented security feature used by Edge neutralized an existing, undoubtedly much more important feature (mark-of-the-Web) in Internet Explorer."
Despite the increased severity of the vulnerability allowing malicious script to run as trusted, there is no sign that Microsoft intends to fix the bug anytime soon, if it ever gets fixed. Therefore, we still recommend that you, as in the previous article, change the default program for opening MHT files to any modern browser.
Of course, Kolsek's research did not remain without a little self-promotion. At the end of the article, he demonstrated a small patch written in assembler that can use the 0patch service developed by his company. 0patch automatically detects vulnerable software on the user's computer and applies small patches to it literally on the fly. For example, in our case, 0patch will replace the error message in the GetZoneFromAlternateDataStreamEx function with a value corresponding to an untrusted file received from the network, which prevents IE from executing any hidden scripts in accordance with the built-in security policy.
Source: 3dnews.ru