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:



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.


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)

Speaking @BSidesDE This Friday on Android Privacy Bugs (CVE-2018-9489, CVE-2018-9581 and CVE-2018-15835)

We will be giving a talk this Friday (11/09/2018) at 10:30 am at BSides Delaware conference in Newark, Delaware. The talk will be given in Room A112 (Track 2). The talk is titled “A Tale of Three Brothers: Three Android Privacy Bugs”, and will cover three bugs in Android OS listed below. Two of them will be disclosed publicly for the first time during the talk. Slides, videos and full advisories should be posted next week.

Bugs covered:

UPDATED: Slides and video added:

Gmail for Android Allows Screenshots in Confidential Mode

Google recently added confidential mode for Gmail that allows the sender to restrict how their email gets by the recipients including forbidding printing, etc. However, it looks like that Gmail for android still allows screenshots to be taken for such emails. To replicate, try the following:

  1. Send a confidential email to another Gmail user.
  2. Open the email, press Power + Volume Down. A screenshot will be taken.

The underlying reason is because the Gmail 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. For example, Chrome for Android prohibits screenshots when browsing in anonymous mode on Android.

We did file a bug report with Google and here is their response:

We can not prevent someone from taking a photograph of their phone, using a second camera for example. Preventing taking photos of the content is not part of the feature.

Google bug report # 112838515

Five Tools for Starting Security Analysis of Android Apps

Here are five, easy to use, tools to start security analysis of a Android apps. While they are basic, they allow to do the initial checking for things like lack of SSL, sensitive files, broadcast issues and secrets in code. We also highly recommend buying a cheap Android device for testing instead of/in addition to an emulator.

As always, please obey all relevant laws and do not use these tools for illegal activity.

On-device MITM proxy – PacketCapture

An MITM proxy is used to inspect network traffic going from/to a particular mobile device, or perhaps a specific application on the device. Normally, an MITM proxy requires setting up a separate test machine with the proxy and then pointing traffic from the test device to that machine. However, PacketCapture, is a free and easy to use MITM proxy that runs on the Android device itself, can optionally inspect SSL traffic and can also be selectively applied to a specific app. It lacks the bells and whistles of other proxies, but it is very easy to use. Behind the scenes it works by creating a VPN connection to itself on the device.

One thing to keep in mind: the next version of Android (Android P) will enable TLS by default. Apps can still opt out via a network security policy (see here). Once that changes takes place, you are advised to check the network security policy first before trying this tool.

On-device Broadcasts Monitor – Android Broadcasts Monitor

One of the common pitfalls in Android development is using global broadcasts when exchanging data between different components of the application. Because global broadcasts can be seen by other apps, they can leak sensitive data. An easy way to look for these is to install the Android Broadcasts Monitor app (Google Play link here) which will show you all global broadcasts as they happen.

On-device File Manager

Another useful tool in your toolbox is an on-device file manager. This can be used to check if a particular application leaves any sensitive data on the SD card where it can be accessed by other apps. In particular, you should inspect the “/Android/” directory. We are fans of the Amaze File Manager (source at GitHub) but you can use any other as well.

If you do end up using Amaze, it has a nice feature where you can backup an installed app to the SD card, which allows you to get an APK of an app for further analysis with tools like JADX.

On-device Video Recorder – Telecine

Recording on-device videos comes really useful when making demos or doing bug bounties. One useful tool we use is Telecine by Jake Wharton which can record all screen activity (except FLAG_SECURE). One useful tip is to use “ffmpeg” or a similar tool to downscale the resolution like this example:

ffmpeg -i Telecine_video.mp4 -crf 40 -an final.mp4

Android Decompiler – JADX

JADX is a Java decompiler which can take an Android APK and decompile it back to Java source code. One useful thing this can be used for is to analyze possible secrets that are included in the Android resources (not code). Often, there may be sensitive data that is easier to find instead of searching through source code. The “/strings” and “/raw” folders are usually the best place to start.

Keep in mind that Android uses a custom JVM which is not the same one as normal Java. Therefore things relevant to security like cryptography, SSL connections, etc. do not necessarily behave the same way as in regular JVMs.

Research: Auto-detection of Compressed Files in Apple’s macOS


Compressed files on macOS are autodetected by the operating system even if they are renamed to certain other extensions. This can be used to fool users and antivirus software that relies on file extensions by packaging malicious code inside compressed files with different extensions. The vendor (Apple) does not consider this to be a security issue. Most anti-virus vendors for macOS are not affected by this issue. This was originally discovered in macOS v10.11 (El Capitan) and v10.12 (Sierra), but the latest version of macOS v10.13 (High Sierra) was not tested.


[NOTE: This bug was originally discovered as a result of a different set of bugs in Google’s Chrome browser. While the impact of this particular issue isn’t high, it was interesting enough for us to pursue a coordinated disclosure process. Because of the large number of parties involved, the disclosure coordination process took a long time which is why this article took almost two years to publish.]

On Microsoft Windows, files are identified by their extensions, which appears after the “.” in the filename. On macOS metadata about the file maybe available separately and either a creator code, a type code or a Uniform Type Identifier is used. However, on the Internet (in browsers and email clients) instead of filenames, MIME media types are used with a registry maintained by IANA on behalf of the IETF. Linux systems use a mix of extensions and media types, with some auto-detection / “sniffing” of media types based on file content. Some mappings do exists across the various systems as well.

For example, a ZIP archive would be identified as follows:

  • Windows – .zip extension
  • Internet/Linux – application/zip media type
  • macOS UTI –

Additionally, on most desktop OSes, an association exists between a file type and an application that will open it by default. Those associations are maintained differently from OS to OS, but at their core they associate a particular identifier about a file type such as an extension (Windows) or a media type (browsers), and a program assigned to open it by default. Users are used to this arrangement and many security utilities such as antivirus programs will only look inside files that maybe dangerous. For example, a ZIP file on Windows if renamed to a different extension may not necessarily be scanned by default because double clicking on it will not open it.

Another important point is that malware authors may sometimes try to disguise malicious code by compressing it inside an archive such as a ZIP file. The expectation is that when a user downloads it, they will double click and open it using the default program on that platform, and then will execute the malicious code. This is another reason why this functionality deserves a closer look.


The following two things were discovered:

  1. The compression utility that is part of macOS will open any file extension associated with that program and will try to “sniff” / auto-detect the original file type used. The following file extensions were tested:
    • ZIP Files when renamed as:
      • .AS
      • .CPGZ
      • .PAX
      • .XIP (a Gatekeeper warning will be shown for non-signed files)
    • DMG files when renamed as:
      • .CDR
      • .DART
      • .DC42
      • .DISKCOPY42
      • .DMG
      • .DMGPART
      • .DVDR
      • .IMG
      • .IMGPART
      • .ISO
      • .NDIF
      • .SMI
      • .TOAST
      • .UDIF
  2. The OS itself (macOS) itself will open and execute some file formats even when renamed to a different extension. Gatekeeper protection is not bypassed. The following extensions are affected:
    • PKG
    • MPKG

To duplicate the first issue, create a ZIP file containing any content (we used the EICAR test file) and rename to include a file extension as any of the compression formats above for ZIP. (AS, CPGZ, PAX or XIP). Send this file to a macOS computer via USB or email or a link; download and double click. The ZIP file will open correctly. You can also do the same thing but with a DMG file for any of the DMG file formats listed above (DC42, ISO, etc).

To duplicate the second issue, create a PKG file containing some code or take an existing one, rename as .MPKG and transfer to a macOS computer. Double click to execute.

All testing was done in May 2016 on a MacBook Pro running MacOS v10.11.3 (El Capitan), and re-tested again in April 2017 on a MacBook running MacOS v10.12.04 (Sierra). It is unclear whether later versions of MacOS are affected since we did not perform testing on versions past v10.12.04 (Sierra).


There are two issues:

  1. Human users and anti-malware software are not aware that macOS supports a large number of legacy compression file types and may not be properly looking out for them or scanning them.
  2. Because of the “sniffing” behavior, it would be trivial for an attacker to package malware inside a well known format like ZIP or DMG rename it to one of these extensions. Anti-virus software may fail to scan such archives because they do not expect a ZIP file to be packaged that way.

The information in this article was originally discovered while analyzing Google’s Chrome browser (details here).

Our recommendations are as follows:

  • Apple should consider deprecating or adding a warning for these extensions and removing the “sniffing” support.
  • Anti-malware software for macOS should support all of these formats, as well as accounting for the possibility of one format being renamed as another

Vendor Responses

The vendor (Apple) does not consider this to be a security issue as follows:

After examining your report we do not see any actual security implications. All of the extensions provided in your report are supported disk image formats and will be treated equally.

After examining your report we do not see any actual security implications. Archive Utility opens archive files and the extensions you provided are archive extensions.

After examining your report we do not see any actual security implications. The Installer app makes it clear when executable code is running even if the file has been renamed.

As per advice of Apple’s security team, we also contacted multiple antivirus vendors that provide AV software for macOS to check if they are affected by this issue. Here is what we got back:

Vendors That Responded:

  • Avast – not affected
  • Avira – not affected
  • AVG – related bug for engine versions prior to 4668 has been fixed earlier (see CVE-2017-9977 and our blog post); other products not affected
  • BitDefender – not affected
  • Cisco – one product impacted, tracked by bug identifier CSCve34034 – no CVE has been issued – Cisco has issued an advisory and is tracking this under CVE-2018-0237:
    • Cisco AMP Virtual Private Cloud Appliance – The Cisco AMP appliance does not rely on the file extension when processing ZIP archives or PKG install packages. However, older versions relied on file extension to detect DMG files and so is susceptible to one of the scan evasion problems described in the advisory. The DMG portion is now fixed in software release 1.4.5.
  • ClamXAV (Canimaan Software) – not affected
  • Comodo – not affected
  • CyberByte – not affected
  • Dr. Web – not affected
  • ESet – not affected
  • F-Secure – not affected
  • Intego – not affected
  • Kaspersky – not affected
  • Malware Bytes – not affected
  • Protect Works – not affected
  • QuickHeal – not affected
  • Sophos – not affected
  • Symantec – not affected
  • Trend Micro – not affected
  • Webroot – not affected

Other Vendors:

  • 360 Total Security – pending
  • BullGuard – no response
  • EScanAV – no response
  • GData – pending
  • Google Chrome – safe browsing affected prior to M51 and M52 (see our blog post here)
  • MacKeeper – no response
  • McAfee – no response
  • Panda – no response
  • QuikAV – pending
  • Total Defense – pending


Apple Product Security Followup Numbers: 638059697,  640528823 and 640528841

Cisco Bug # CSCve34034 / CVE # CVE-2018-0237


Advisory written by Yakov Shafranovich.

Timeline Summary

2016-03-21: Report # 638059697 submitted
2016-05-04: Reports # 640528823 and 640528841 submitted
2016-05-21: Report # 640528823 rejected
2016-06-22: Report # 638059697 rejected
2016-06-23: Report # 640528841 rejected

2017-03-15: Advisory provided to the vendor for comment
2017-04-23: Retested on macOS Sierra, updated and resent to vendor for comment
2017-04-28: Reply from vendor received
2017-05-01: Retested on a fresh install of macOS Sierra, revised advisory sent to vendor for comment
2017-05-01: Notifications go out to AV vendors

2018-01-24: Second time that notifications go out to AV vendors
2018-02-10: Third and final time that notifications go out to AV vendors
2018-02-10: Final advisory shared with the vendor (Apple) for comment
2018-02-25: Public disclosure

2018-04-23: Updated with the new Cisco advisory and CVE

Experimental Tool: Public Cloud Storage Search

This was done as an experiment using Google’s Custom Search Engine. This tool provides access to publicly available content that Google indexes from major cloud providers such as AWS, Azure, DropBox, Google Cloud, etc.

More information here:

Source here:

Live example here:



The Dangers of Plain HTTP Links in Mobile Apps

When dealing with browser security, there is a concept called “the line of death“. This concept means that a user can only trust content that appears within the browser’s address bar or above, and nothing below that line (there is an excellent article from Eric Lawrence who is a Chrome developer explaining this in detail). What that means is that users can click on content above that line safely, but not below since the content appearing below the line may be fake or modified by the attacker. However, it is clear that the rest of the browser UI including menus, settings sections, about box, etc. are static and should be static and safe (unless modified by extensions).

The same concept would apply to mobile apps – part of the UI that are static should be safe as well, although it is harder to tell the static and non static parts apart. This leads add to the issue at hand – what happens when the static parts of the app have hyperlinks that don’t use HTTPS? A user of the app would normally trust those links but if they are on a hostile network, clicking on a plain HTTP link would in fact expose them to a potential MITM attack either via DNS hijacking or MITM interception. That means that if they are using a network where the attacker controls the DNS or the network connection itself, these links can be easily hijacked. You can easily image a scenario, where an attacker blocks WhatsApp or Facebook traffic but redirects users who use the HTTP versions to their own malicious site.

On the other hand, when HTTPS is used for these links, the mobile browser will check if SSL certificates are being served on that link, and whether they are signed by a real CA.


Research: The Dangers of Proxying S3 Content


It is common for organizations to use Amazon’s S3 service as a place to host static assets and other content. The content within Amazon S3 is organized in “buckets”. Amazon also provides ability to point custom domains at S3 buckets through virtual hosting or the static website endpoints. In both cases, a CNAME mapping is created from the custom domain to an Amazon domain name.

However, SSL support is not available via the custom domain name, but SSL is provided if either “<bucket-name>” URL or the “<bucket-name>” domain name is used directly (as long as there are no periods in the bucket name). The reason why SSL doesn’t work when accessing the plain domain names is because Amazon is not able to provide certificates for them because they are not the domain owner and current S3 functionality does not allow custom certificates to be loaded. However, for “” domains, Amazon provides a wildcard certificate which works just fine. If you try to access the domain names directly, you will be served content with the same wild card certificate which of course would not match the domain names.

Possible SSL solution – CloudFront or Another CDN

One possible solution offered by AWS is to use their CDN offering called CloudFront. In that case, you can setup two CloudFront domains that sit in front of the S3 buckets and CNAME your domain names to them. This of course comes at a higher price and a confusing set of options: you can use the subdomains, or a free SNI-enabled SSL certificate not compatible with older browsers or a costly ($600/month/per domain) option to upload your own SSL certificate. The data would then flow as follows:

[S3] >—-internal AWS network—-> [CloudFront] >—–SSL—-> [users]

Another set of solutions is to use a non-AWS CDN like CloudFront, etc. and have the CDN proxy the content with SSL. The setup would be similar to Amazon with SNI and non-SNI SSL options available. The data flow would then look like this (for CloudFlare):

[S3] >—-HTTP—-> [CloudFlare] >—–SSL—-> [users]

What You Should Not Do – Proxy S3 Content Yourself

Of course many developers would immediately react to this particular problem in the same way: I can do it better by myself! The usual solutions is to have a script or a webserver rule that will automatically retrieve the content from S3 and display it to the user. So it would look like this:

Everything after “/static/” would that be retrieved from some S3 bucket, let’s say “marketing.example”. So the following path would be followed:

Of course this only lasts as long as there is only one bucket. Let’s say now another bucket is needed called “support.example”. So the script will become something like with the bucket name in the URL:

What will often happen at this point is that the developer will not realize that the bucket names need to be validated against a whitelist of valid buckets. Because S3 bucket names are not unique to one AWS user but share a global namespace across all S3 users, this script would be able to retrieve data from any other S3 bucket, as long as it is public. This will not happen when using CloudFront or other CDNs because they will be mapped 1-to-1 against a specific S3 bucket.

How will this look like? If an attacker can figure out that the script takes arbitrary bucket names, they can go ahead and create a new bucket called “evil.example” and then use the following URLs to retrieve content from it:

What can this be leveraged for? Some examples:

  • Serving malware since the content will be served under the target domain and the target SSL certificates
  • Facilitating phishing attacks
  • XSS since HTML / JS content will bypass the same origin policy since it is served from the same domain as the target
  • Stealing session cookies since the code will run in the same domain and have access to cookies
  • If the content is retrieved using the S3 APIs, then an attacker could setup a “Requester Pays Bucket” and make money off the target (although Amazon would probably catch this eventually)
  • [insert your exploit here]


  • Don’t re-invent the wheel, use an existing solution like CloudFront, or some other CDN
  • If you must proxy content yourself, make sure you have a whitelist of valid buckets, and use other technologies like subdomains, HTTPOnly cookies, CSP headers, etc. to segregate the S3 content from the rest of the site