Microsoft decides not to fix whitelisting controls error

News by Jay Jay

Attackers can infiltrate organisations even if the latter employ advanced application whitelisting controls due to a vulnerability that Microsoft has declined to patch, says Carbon Black.

Security researchers have come across a feature in the most recent version of Microsoft Windows that allows an attacker to bypass application whitelisting controls deployed by organisations to distribute malicious content embedded within signed MSI files.

A large number of organisations, especially those that have completely digitised their records and rely on databases or the cloud to store or process data, use JAR files (Java Archive files) to aggregate all files that form part of their applications.

By using JAR files, an organisation can store hundreds of data files, images, sound clips, source codes, security certificates and other files within a secure application or library that can easily be accessed using a standard decompression tool. In other words, organisations can use JAR files as .zip folders because both use the standard decompression algorithm.

Most JAR files contain a file named MANIFEST.MF within a folder named META-INF that contains detailed information about a code such as the primary author of the code, the code version and the organisation that maintains the code. Before running an application within Java Runtime Environment (JRE), application whitelisting controls check out the manifest file to determine a JAR file's authenticity and also scan the "End of Central Directory Record" before allowing the JAR file to run.

According to a report from Carbon Black, even though this whitelisting technique helps organisations prevent attackers from injecting malicious content into their IT systems, an existing feature in Microsoft Windows offers attackers a window to bypass such whitelisting controls.

According to researchers, Microsoft publishes a large number of trusted installers called MSI files which are used for installation, storage and removal of programmes, including JAR folders. They are usually stored in .EXE formats and are used widely by programmers, developers and end users.

However, what Microsoft does is that even after an MSI file is appended with additional content by a third party, the company retains the file's valid authenticode, thereby allowing malicious attackers to inject malicious content into databases using the "Microsoft-signed MSI files" to bypass application whitelisting.

Carbon Black added that Microsoft is aware of this issue but has decided "not to address this issue in the current versions of Windows", which means that attackers have a splendid opportunity to infiltrate targeted organisations even if the latter employ advanced application whitelisting controls.

"Many application whitelisting and endpoint security products automatically trust Microsoft signed MSI files since Microsoft normally publishes a wide variety of installers for various technologies and is considered trusted and safe.

"Attackers can abuse this trust to deliver malicious code and even if the environment has additional layers of protection like AV and EDR on top of the application whitelisting, this exploit is hard to detect," Mark Trinidad, senior technical evangelist at Varonis, told SC Media UK.

"Until a patch is released, organisations will have to monitor their environments closely, specifically looking at process trees of Microsoft signed MSI files spawning Java processes and then detecting if the JAR files are malicious.

"Most organisations use application whitelisting on legacy and fixed-function systems, like POS terminal or a server that operates something in a factory. Organisations should strictly monitor access to these systems and abnormal behaviour to any service accounts linked to these systems," he added.

Travis Smith, principal security researcher at Tripwire, said that when looking specifically at AppLocker, validating an incoming file is most effective when an organisation validates it via the file hash instead of signatures.

"With signatures, you are relying on the operating system to validate the signature of an element to approve it. Similar to the file paths, you rarely would need to update the database of approved signatures until a new one was introduced. However, with AppLocker, only the name of the signature was looked at for approval. So a malicious actor could create a piece of malware which was signed by ‘Microsoft’, and get their malware to run.

"Validating via the file hash is the most secure way to identify an element, as it’s incredibly difficult to cause a collision with a strong hashing algorithm (having two identical file hashes). The problem with this method though, is that administrators would need to update their hash databases each time an executable changes, or scripts are updated. This increases the amount of administrator overhead for those who have a regular amount of change on their endpoints," he added.

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming event