Search This Blog

Showing posts with label PoC. Show all posts

Microsoft: Provide Code for MacOS App Sandbox Flaw

 


MacOS has a vulnerability that was discovered by  Microsoft, it might allow specially created code to execute freely on the system and get past the App Sandbox. 

The security flaw, identified as CVE-2022-26706 (CVSS rating: 5.5), affects iOS, iPadOS, macOS, tvOS, and watchOS. It was patched by Apple in May 2022. In October 2021, Microsoft notified Apple of the problem via Microsoft Security Vulnerability Research (MSVR) and Coordinated Vulnerability Disclosure (CVD).

Sandbox Objective

A specifically written Office document with malicious macro code that allows for system command execution and sandbox limitation bypass can be used by an attacker to exploit the bug. Although Apple's App Sandbox is intended to strictly control a third-party app's access to system resources and user data, the vulnerability allows for obfuscation of these limitations and penetration of the system.

When a user runs malicious software, the main goal of the sandbox is to prevent damage to the system and the user's data.

Microsoft researchers showed that the sandbox rules may be evaded by utilizing specially written software. The sandbox escape vulnerability could be used by an attacker to take charge of the vulnerable device with elevated privileges or to carry out malicious operations like downloading malicious payloads.

The experts originally developed a proof-of-concept (POC) exploit to produce a macro that starts a shell script using the Terminal app, but it was intercepted by the sandbox since it had been given the extended attribute com.apple.quarantine, which inhibits the execution by the Terminal, automatically. The experts then attempted to use Python scripts, but the Python application had a similar problem running files with the mentioned attribute.

"However, this restriction can be removed by using the -stdin option for the open command in the Python exploit code. Since Python had no way of knowing that the contents of its standard input came from a quarantined file, -stdin was able to get around the 'com.apple.quarantine' extended attribute restriction," according to a report by Jonathan Bar Or of the Microsoft 365 Defender Research Team.


The Log4j Incident Demonstrated Again That Publicly Disclosing 0-day Vulnerabilities Only Aids Intruders

 

On December 9, 2021, a (now-deleted) tweet pointing to a 0-day proof of concept (PoC) exploit for the Log4Shell vulnerability on GitHub set the internet ablaze, sending businesses rushing to mitigate, patch, and patch again as other PoCs surfaced. 

Public vulnerability disclosure – that is, revealing to the world the existence of a bug in a piece of software, a library, an extension, or another piece of software, and releasing a proof-of-concept (PoC) that exploits it – occurs frequently for vulnerabilities in a wide range of software, from the most esoteric to the most mundane (and widely used). 

Threat actors are the only ones who benefit from the public disclosure of 0-day PoCs, as per research and experience, because it puts enterprises in the awkward position of needing to remediate the issue without having anything solid to mitigate it with (i.e., a vendor's patch). 

There are several different types of responsible vulnerability disclosure systems available today. Some companies have an official vulnerability disclosure programme while others arrange and operate it through crowdsourced platforms. Companies typically offer money for information concerning flaws in their products (also known as "bug bounties"). 

Those disclosures usually follow a set of steps, and vendor patches have clearly stated release dates so that users have plenty of time to install them (90 days is the accepted standard for this). 

When the Log4Shell vulnerability was announced publicly, the disclosure procedure was already underway (as evidenced by the pull request on GitHub that appeared on November 30). The following is the timeline of the disclosure, according to information provided by the Apache Software Foundation:
  • November 24: The Log4j maintainers were informed 
  • November 25: The maintainers accepted the report, reserved the CV, and began researching a fix November 26: The maintainers communicated with the vulnerability reporter 
  • November 29: The maintainers communicated with the vulnerability reporter December 4: Changes were committed 
  • December 5: Changes were committed 
  • December 7: First release candidate created 
  • December 8: The maintainers communicated with the vulnerability reporter, made additional fixes, created a second release candidate 
  • December 9: Patch released 
While user comments on the Apache Log4j GitHub project page expressed dissatisfaction with the timeliness of the update, this is to be expected when it comes to patching vulnerabilities - as everyone keeps pointing out, after all, the patch was developed by volunteers. 

Probable reasons for releasing PoC 

There could be valid and logical reasons for releasing a 0-day proof-of-concept. The most prevalent of these is the breakdown of the vulnerability disclosure process: the vendor may not be or cease to be responsive, may judge the vulnerability to be minor enough to warrant a repair, or may take too long to fix it – or any combination of the above. 

In situations like these, security researchers frequently decide to make the PoC public for the "common good," i.e. to force vendors to release a patch quickly. Other factors could include publicity (especially if the researcher is associated with a security vendor) – nothing attracts more press attention than zero-day proof-of-concept exploits for a widely used piece of software, especially if no patch is available. 

However, it should be noted that the evidence against publishing proof-of-concept exploits is now substantial and overwhelming. According to a study conducted by Kenna Security, sharing proof-of-concept attacks mostly assists attackers. A presentation at Black Hat several years ago walked through the lifecycle of zero-days and how they were released and exploited, demonstrating that if proof-of-concept exploits aren't publicly disclosed, the vulnerabilities in question aren't discovered for an average of 7 years by anyone else (threat actors included).

Unfortunately, during the log4j scramble, this was discovered a little too late. Although the initial tweets and disclosures were quickly withdrawn, the harm had already been done. Even the most recent revelation, which resulted in the release of patch 2.17.1, generated so much criticism from the security community that the researcher apologized publicly for the publication's bad timing. 

It's encouraging to see that public disclosure of PoC exploits is becoming more common. Researchers who choose to jump the gun need to be criticized, but all must all work together to ensure that more rigorous disclosure mechanisms are in place for everyone so that the public PoC scenario is avoided the next time a vulnerability like Log4Shell is uncovered.

Expert Releases PoC Exploit for MacOS Gatekeeper Bypass

 

Cybersecurity expert Rasmus Sten, an F-Secure software engineer, published a PoC exploit code for MacOS Gatekeeper bypass that Apple fixed earlier in 2021. The PoC (Proof of Concept) exploit attacks CVE-2021-1810 vulnerability, which leads to escaping three protection that Apple has built against harmful file downloads, particularly Gatekeeper, notarization and file quarantine. The vulnerability was discovered in the Archive Utility component of MacOs Big Sur and Catalina and can be compromised using specifically made ZIP file. 

For the compromise to be successful, the attacker has to fool the user into downloading and installing the archive to deploy malicious codes in the system. The vulnerability exploit would allow an attacker to execute unsigned binaries on MacOS systems, including Gatekeeper that enforces code signatures and user wouldn't be aware of the malicious code execution. According to Sten, the vulnerability is linked to a pattern where Archive Utility controls file paths. Especially, if the paths are larger than 886 characters, the com.apple.quarantine feature couldn't be enabled, which will allow Gatekeeper bypass for the malicious files. 

During the investigation of long path file names samples, Sten found that few MacOS parts showed unexpected pattern after the final path length touched a certain point. In the end, experts found that it may be possible to make an archive with a hierarchical structure, in this case, the path length would be long enough for Safari to call Archive Utility to unload it and wouldn't use com.apple.quarantine attribute, but small enough for Finder to browse and MacOS to deploy the malicious codes in the system. 

To lure the victim easily, attacker could hide archive folder structure using a symbolic link in root which is almost indifferent from a single application bundle in an archive root. "Sten, who also released a video demo of the exploit, has published PoC code that creates the archive with the path length necessary to bypass CVE-2021-1810, along with a symbolic link to make the ZIP file look normal.The vulnerability was addressed with the release of macOS Big Sur 11.3 and Security Update 2021-002 for Catalina," reports Security Week.

Hackers are Selling Tool to Hide Malware in GPUs

 

Cybercriminals are moving towards malware attacks that can execute code from a hacked system's graphics processing unit (GPU). Although the approach is not new, and demo code has been published in the past, most of the projects to date have come from academics or were unfinished and unpolished. 

Recently in August, the proof-of-concept (PoC) was sold on a hacker forum, perhaps signaling hackers' shift to a new level of complexity in their attacks. 

Code Tested on Intel, AMD, and Nvidia GPUs

In a brief post on a hacking forum, someone offered to sell the proof-of-concept (PoC) for a strategy that keeps harmful code protected from security solutions scanning the system RAM. The seller gave a brief description of their technique, claiming that it stores malicious code in the GPU memory buffer and then executes it from there. 

As per the advertiser, the project only works on Windows PCs that support OpenCL 2.0 and above for executing code on various processors, including GPUs. It also stated that he tested the code on Intel (UHD 620/630), Radeon (RX 5700), and GeForce (GTX 740M(? ), GTX 1650) graphics cards. 

However, there are fewer details regarding this new hack, but the post went live on August 8 and was apparently sold for an unknown amount on August 25.

Another hacker forum user mentioned that GPU-based malware had been done before, citing JellyFish, a six-year proof-of-concept for a Linux-based GPU rootkit. 

The vendor dismissed the links to the JellyFish malware, stating that their approach is unique and does not rely on code mapping to userspace. There is no information regarding the transaction, such as who purchased it or how much they paid. Only the seller's article claims to have sold the malware to an unidentified third party. 

Academic Study

Researchers at the VX-Underground threat repository stated in a tweet on Sunday that the malicious code allows binary execution by the GPU in its memory region. They also noted that the technique will be demonstrated soon. 

PoCs for a GPU-based keylogger and a GPU-based remote access trojan for Windows were also disclosed by the same researchers that created the JellyFish rootkit. All three projects were released in May 2015 and are open to the public. 

While the mention of the JellyFish project implies that GPU-based malware is a new idea, the foundation for this attack approach was developed around eight years ago. 

Researchers from the Institute of Computer Science - Foundation for Research and Technology (FORTH) in Greece and Columbia University in New York demonstrated in 2013 that GPUs can execute a keylogger and save recorded keystrokes in their memory space [PDF document here]. 

The researchers previously evidenced that malware authors may use the GPU's processing capabilities to pack code with extremely sophisticated encryption methods considerably faster than the CPU.