Thoughts on the MSI/JAR Authenticode Bypass

Earlier today, Google’s VirusTotal published a blog post about a new way to bypass code signing in Windows via JAR files:

Microsoft Windows keeps the Authenticode signature valid after appending any content to the end of Windows Installer (.MSI) files signed by any software developer. This behaviour can be exploited by attackers to bypass some security solutions that rely on Microsoft Windows code signing to decide if files are trusted. The scenario is especially dangerous when the appended code is a malicious JAR because the resulting file has a valid signature according to Microsoft Windows and the malware can be directly executed by Java.

In short, an attacker can append a malicious JAR to a MSI file signed by a trusted software developer (like Microsoft Corporation, Google Inc. or any other well-known developer), and the resulting file can be renamed with the .jar extension and will have a valid signature according Microsoft Windows. For example, via the command “copy /b signed.msi + malicious.jar signed_malicious.jar”. The victim can be infected with just a double-click in such a file.

Here are some quick thoughts from our research team – note that we were not involved in this effort and have no insider knowledge. This is entirely based on public sources.

How can ZIP and EXE files be combined?

First of all, how is it possible that the same exact file can be executable both by Windows and Java? The trick lies in how Windows executable files work – as described in Microsoft’s documentation. Basically, the OS reads the file from the beginning, looking at the magic value of “MZ” followed by headers, then followed by the file content. We are going to assume that there is a table in the file that tells the reader how long each segment is, and therefore it is possible to append arbitrary data to the end of the file without it breaking.

A JAR file, however, is essentially a ZIP file. ZIP files have their index or central directory in the end of the file, and it is possible to prepend data in the beginning of the file and that file still being valid. That means that you can combine a Windows executable that is read from the beginning and rely on its headers and tables to tell the reader where to stop, and do the same for the ZIP content in the end of the file. Both files remain valid, while combined together. Also, while the example provided by VirusTotal is a JAR file, the same trick would work for other ZIP-based formats like Microsoft Office (DOCX/XSLX/etc), OpenOffice (ODT/ODS/etc), etc. Of course, this assumes that the software reading these files goes to the central directory of the ZIP and doesn’t check the magic value in the beginning.

Here is an modified example of PE files from Wikipedia, and a ZIP file example from OASIS, showing the direction in which file content is read:

revengpefile                  zip

Combined together:

revengpefile

zip

What is Microsoft Code Signing / Authenticode?

As per the original blog post and other technical documentation from Microsoft, the code signing in question is Authenticode which is used by Microsoft for Windows executables, drivers, and other files. The purpose it to make sure the file originated from a trusted publisher. There is also a command line tool included in Windows called “SignTool” which is used for signing and verifying files.

The way code signing works is described in a Microsoft technical document here. It is essentially a digital signature using PCKS7 and special X.509 certificates (code signing certificates issued by CAs). It is connected to the same PKI infrastructure as SSL certificates with some additional checks by CAs when issuing the certificate (not at sign time). Like all other digital signatures, it is essentially some sort of a hash signed by a private key of the holder of the certificate which is then verified by the public key in the X.509 certificate. The certificate itself is verified against public PKI infrastructure just like SSL.

Example appears below (from Microsoft documentation):screen shot 2019-01-16 at 8.00.15 pm

Bypassing Code Signing

In a standard digital signature scenario such as PGP or S/MIME, the entire content of the message is hashed to produce a message digest using a function like SHA. That hash is then digitally signed using the sender’s private key. Note that the entire message is hashed – this allowing the receiver to check if it was modified or not, not just bits and pieces.

One of the common refrains in security is “never roll your own crypto”, which in this case includes choosing what to hash. In the case of Authenticate, it appears that the file hash does not cover the entire file. As described in this document, information in the end of the file (after the second “remaining content” above) ARE NOT included in the hash (emphasis added):

Information past of the end of the last section. The area past the last section (defined by highest offset) is not hashed. This area commonly contains debug information. Debug information can generally be considered advisory to debuggers; it does not affect the actual integrity of the executable program. It is quite literally possible to remove debug information from an image after a product has been delivered and not affect the functionality of the program. In fact, this is sometimes done as a disk-saving measure. It is worth noting that debug information contained within the specified sections of the PE Image cannot be removed without invaliding the Authenticode signature.

Implications

This means that it is trivial to simply append another file like a JAR to the end of another digitally signed file, then rename it a JAR and have the resulting file look valid in Windows since the digital signature check will stop before reading the content of the JAR file. At the same time, the file will be executable by Java since it will read from the end ignoring any of the signed content appearing in the beginning. The same would apply for other ZIP based formats like Microsoft Word and this may allow an attacker to send a malicious document while masquerading it as a legit one. Additionally it appears from the blog post that some A/V and security products use the Authenticode signature as a shortcut to validate files so they don’t need to scan them.

Another possible use of this technique is to make attribution murky since some analysts may take the Authenticode signature at face value and not realize that the malware inside may not be from the publisher that signed the file.

An additional idea would be to use this trick to exfiltrate data out of an organization by putting the extra data in the end of the file. This assumes that the DLP and similar tools monitoring outbound traffic rely on the Authenticode signature as well.

Microsoft’s code signing method isn’t the only one that exists. Similar methods exists for Java, Adobe AIR, Android, MacOS, Debian, etc. Further research is needed to see if similar issues exist in other code signing schemes.

(Written by Yakov Shafranovich)

Microsoft Authenticator for Android Allows Screen Capture

Microsoft offers an application for Android called “Microsoft Authenticator” which is used to setup two-factor authentication (2FA). This application operates in two modes – one allows to generate standard OTP codes like many other apps (Google Authenticator, Authy, etc). The second mode allows a user to register with Azure’s Multi-Factor Authentication (MFA) service, and allows users to authenticate by tapping a prompt on their phone instead of entering an OTP code (similar to Google Prompt).

However, it looks like that the application still allows screenshots to be taken. This is true for setting up the OTP with a manual seed, viewing generated OTP codes, and entering a username + password when setting up Azure MFA. The implication is that if a user’s device ends up running a rogue app, that app can capture the initial OTP seed (if entered manually), the initial username and password for MFA, as well as all generated OTP codes as they are shown by the app, and thus break two factor authentication.

To replicate, try the following:

  1. Open the application.
  2. Setup a new OTP code by adding “other account” + a random seed, and view codes. Alternative, try to sign-up for MFA with a personal account.
  3. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response

We filed a bug report with the vendor (Microsoft) and here is their response:

Our team assessed the issue, and this does not meet the bar for servicing. We have informed the product team about this issue. MSRC is closing the case.

As for CVE, since there is no fix going for this, we will not be assigning any CVE for this issue.

References:

  • Azure Multi-Factor Authentication – see docs here
  • Google Play Link to the app – see here
  • Google Prompt for Android – see here
  • MSRC Case # 46793
  • Our earlier blogpost about FLAG_SECURE on Android – see here

 

Advisory: Insufficient Parameter Sanitization in login.live.com

Overview

Web widgets hosted by Microsoft’s online login portal, login.live.com, do not perform sufficient parameter sanitization allowing an attacker to inject arbitrary text.

Background

Microsoft offers several legacy Javascript widgets that are used to display and customize sign-in link and buttons using Windows Live ID. They are hosted on login.live.com at the following URLs:

https://login.live.com/controls/WebAuth.htm
https://login.live.com/controls/WebAuthButton.htm
https://login.live.com/controls/WebAuthLogo.htm

They are documented by Microsoft here and accept several parameters that are used to customize the resulting widget.

Details

One of the parameters, style, is used to pass in CSS styling commands for the Javascript widgets described above. However, this parameter is not sanitized, and reflects back the information passed to to it via Javascript’s alert() method. It can be coerced to reflect arbitrary text of the attacker’s choosing, making it seemingly appear on a legit Microsoft website. While this does not result in script execution, it can be used as part of a social engineering campaign to attack users.

Example URL with malicious content:

https://login.live.com/controls/WebAuth.htm?appid=test&style=Please_call_Microsoft_Support_at_1-800-BAD-GUYS_and_provide_your_username_and_password:t

Screenshot

(note the SSL icon in the browser)

msft

References

MSRC Case # 30838 / TRK # 0189016
Microsoft Sign-in Link API: https://msdn.microsoft.com/en-us/library/bb676638.aspx

Microsoft Security Researcher Acknowledgements (September 2015): https://technet.microsoft.com/en-us/security/cc308575

Credits

Thank you to Grier Forensics for providing advice. Discovered by Yakov Shafranovich in collaboration with the Shaftek Enterprises Security Research Team.

Bounty Information

This discovery qualified for a security bounty under the terms of Microsoft’s Online Services Bug Bounty program.

Timeline

2015–08–06: Vendor notified
2015–08–06: Initial vendor response
2015–08–11: Vendor replicated the issue
2015–08–31: Fix deployed by vendor
2015–09–17: Bounty received
2015–09–21: Public disclosure

2016–03–15: Updated

Microsoft June Security Update Breaks Copy/Paste of Files in Windows

Overview

We recently looked at a problem on a Windows computer that was peculiar. The computer had Windows v8.1 installed and as of last week everything was working fine. Over the weekend Microsoft updates for June got applied and now the system cannot copy/paste files. Copy/paste works fine between regular programs, just not for files. The symptoms are:

  1. Selecting files, doing Ctrl-C, and then Ctrl-V in a different folder does not do anything.
  2. Right clicking with your mouse on the files, and selecting “Copy”, then right clicking in another folder and selecting “Paste” does not work.

“Send To” still works fine, but some users are also reporting issues with copy/paste not just with files but also Microsoft Office programs including Outlook.

Further digging led me to the fact that a specific update for Windows breaks copy/paste. I have verified this issue by un-installing and re-installing the update, and checking Copy/Paste of files in between. This update is:

“Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Elevation of Privilege” — MS-061 and KB3057839

The interesting question is why this is happening?

Several possibilities:

1. This maybe related specifically to SpectorSoft and its suite of surveillance programs (eBlaster, SpectorPro, etc.).

It is possible that SpectorSoft hooked onto some Windows API that potentially can cause a security issue, and Microsoft closed that hole. It is also plausible that other spyware-like programs have been using this hole. According to some comments on Reddit, this maybe directly related to Duqu-like spyware that recently infected Kaspersky.

THIS MEANS THAT IF YOUR WINDOWS COMPUTER CANNOT COPY/PASTE FILES AFTER JUNE 9, 2015, YOU PROBABLY HAVE SURVEILLANCE SOFTWARE OR SPYWARE INSTALLED!!!

2. The security patch is for the clipboard.

The vulnerabilities disclosed by Microsoft seem to revolve around memory management. Perhaps Microsoft was concerned with people trying to hack their way in via the placing items in the clipboard and then moving the code into a different place in memory?