Search This Blog
Powered by Blogger.

Blog Archive

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label PoC. Show all posts
Windows Vulnerability
Cybersecurity Threats Enterprise security PoC Technology Windows Windows Vulnerability

Critical Windows Event Log Vulnerability Uncovered: Enterprise Security at Risk

 

In a recent discovery, cybersecurity researchers have identified a critical zero-day vulnerability posing a significant threat to the Windows Event Log service. This flaw, when exploited, has the potential to crash the service on all supported versions of Windows, including some legacy systems, raising concerns among enterprise defenders. 

Discovered by security researcher Florian and reported to Microsoft, the zero-day vulnerability is currently without a patch. The Windows Event Log service plays a pivotal role in monitoring and recording system events, providing essential information for system administrators and security professionals. The exploitation of this vulnerability could result in widespread disruption of critical logging functions, hindering the ability to track and analyze system activities. 

In PoC testing, the team discovered that the Windows Event Log service restarts after two crashes, but if it experiences a third crash, it remains inactive for a period of 24 hours. This extended downtime poses a considerable risk, as many security controls rely on the consistent functioning of the Event Log service. The fallout includes compromised security controls and non-operational security control products. This vulnerability allows attackers to exploit known vulnerabilities or launch attacks without triggering alerts, granting them the ability to act undetected, as outlined in the blog. 

During the period when the service is down, detection mechanisms dependent on Windows logs will be incapacitated. This grants the attacker the freedom to conduct additional attacks, including activities like password brute-forcing, exploiting remote services with potentially destabilizing exploits, or executing common attacker tactics such as running the "whoami" command, all without attracting attention. 

While the vulnerability is easily exploitable locally, a remote attacker aiming to utilize the PoC must establish an SMB connection and authenticate to the target computer. Configuring Windows to prevent this attack without completely disabling SMB poses a challenge, given its role in various network functionalities like shares and printers, according to Kolsek. Internet-facing Windows systems are unlikely to have open SMB connectivity, reducing the likelihood of remote exploitation. 

The vulnerability proves advantageous for an attacker already present in the local network, especially if they have gained access to a low-privileged user's workstation. As a temporary solution until Microsoft issues a patch, users can apply a micro patch provided by Acros through the 0patch agent, tailored for multiple Windows releases and server versions. This helps mitigate potential real-time detection issues linked to the Event Log service's disablement.
Read more »
User Privacy
Data Breach Microsoft Phishing Attacks PoC URL User Privacy

Microsoft Teams: Bugs Use GIFs to Construct Reverse Shells

Malicious hackers can utilize Microsoft Teams to launch innovative phishing attacks and discreetly carry out commands to steal data via GIFs using a new attack method known as "GIFShell."

The new attack pattern demonstrates how hackers can merge various Microsoft Teams flaws and security holes to reap the benefits of reliable Microsoft infrastructure and distribute malicious files, and orders, and perform data exfiltration via GIFs.

This attack chain can be highly destructive, especially in network security environments where Microsoft Teams may be one of a limited set of authorized, trusted hosts and apps, as per Raunch. The GIFShell stager can be persuasively dropped and implemented on the victim's computer by exploiting two additional vulnerabilities found in Microsoft Teams, including a lack of permission enforcement and attachment spoofing.

Bobby Rauch, a cybersecurity expert, and pentester revealed multiple holes in Microsoft Teams that may be chained together for code execution, data theft, cybersecurity bypasses, and phishing attacks. This led Rauch to the discovery of the new attack chain.

This attack's primary tool is referred to as "GIFShell," and it enables an attacker to build a reverse shell that sends malicious commands via base64-encoded GIFs in Teams and exfiltrates the output using GIFs recovered by Microsoft's own servers.

GIFShell Attack

Since the data exfiltration takes place through Microsoft's own systems, security software that interprets the traffic as normal Microsoft Team activity will have a hard time identifying it.

The attacker must first persuade a user to install a malicious stager that runs commands and uploads command outputs via a GIF URL to a Microsoft Teams web hook to construct this reverse shell.

Rauch created a new phishing attack on Microsoft Teams to help with this. As we know, phishing assaults are effective at infecting devices.

The 'stager,' a malicious program that GIFShell uses to mislead users into launching on their devices, continuously scans the Microsoft Teams logs.

Any malware on the system can access these logs because they contain all received messages and are viewable by all Windows user groups.

Hackers would build their own Microsoft Teams tenant after installing the stager and get in touch with other Microsoft Teams users from outside their organization. Attackers can easily accomplish this since Microsoft Teams by default permits external communication.

Rauch's GIFShell Python script enables the hackers to transmit a message to a Microsoft Teams user that comprises a specially created GIF to start the attack. This GIF file was altered to add instructions to run on the target's computer.

The email and the GIF will be saved in Microsoft Team's logs when the victim receives them, which the malware stager watches.

The base64-encoded commands will be extracted by the stager and run on the device when it recognizes a message that contains a GIF. The output of the command will subsequently be converted to base64 text by the GIFShell PoC.

The hacker's open Microsoft Teams webhook is accessed by the stager using this base64 text as the filename for a remote GIF placed in a Microsoft Teams poll card.

To get the GIF, which would be named using the base64-encoded result of the executed command, Microsoft's servers will link back to the hacker's server URL when Microsoft Teams creates flashcards for the user.

This request will be received by the GIFShell server, which is installed on the hacker's server, and will instantly decode the filename so that the hackers can view the results of the command issued to the targeted device.

The Microsoft Teams files folder has also been discovered to be accessed by other software, including malware and commercial monitoring tools like Veriato.

In a report to BleepingComputer, Microsoft purely reaffirmed its claim to Rauch stating, "We evaluated the methods mentioned by this researcher and found that the two stated do not satisfy the requirements for an immediate security fix. To help maintain customer security, we're always exploring for new ways to better combat phishing, and we might do something in a future release to assist prevent this tactic."

Users should ensure ethical computing habits online, including vigilance when clicking on links to websites, opening unexpected files, or allowing file transfers. Users shall remain aware of this type of phishing.
Read more »
Vulnerability and Exploits.
API Atlassian CVE PoC Vulnerabilities and Exploits Vulnerability and Exploits.

Atlassian Bitbucket: Vulnerability Spotted Inside Data Center

Bitbucket Server and Data Center users are being alerted by Atlassian about a major security vulnerability that may allow attackers to run arbitrary code on weak systems.

The most updated vulnerability that involves command injection affects several software product API endpoints and is identified as CVE-2022-36804. Given that it has a CVSS severity score of 9.9 out of a possible 10.0,  it can be concluded that the vulnerability is critical and needs to be fixed immediately.

According to an advisory from Atlassian, "A hacker with access to a public Bitbucket repository or with r permissions to a private one can execute arbitrary code by sending a malicious HTTP request."

Bitbucket is a Git-based code hosting service connected with Jira and a part of the business' DevOps solution. Bitbucket offers both free and paid options and supports an infinite number of private repositories.

All Bitbucket versions issued after 6.10.17 are impacted, thus "all instances that are operating any versions between 7.0.0 and 8.3.0 inclusive are affected by this vulnerability," according to Atlassian, which also alleges that the flaw was introduced in version 7.0.0 of Bitbucket.

Atlassian advises disabling public repositories using 'feature.public.access=false' as a temporary solution in situations where the patches cannot be applied immediately to stop unauthorized users from taking advantage of the problem.

It warned that "this can not be regarded a complete mitigation as an attacker with a user account could still succeed,", implying that hackers who already have legitimate credentials obtained through other ways could take advantage of it. 

It is advised that users of the affected software versions update as soon as possible to the most recent version in order to reduce security risks.

Max Garrett, a security researcher, disclosed CVE-2022-36804 to Atlassian via the company's bug bounty program on Bugcrowd and was rewarded with $6,000 for his discovery.

The teenage researcher tweeted yesterday that he will publish a proof-of-concept (PoC) attack for the problem in 30 days, allowing system administrators plenty of time to implement the now available remedies.

There is no guarantee that the significant RCE weakness won't be actively exploited more frequently before the PoC is released, but it is inevitable. Reverse engineering Atlassian's patch, according to Garrett, shouldn't be too challenging for knowledgeable hackers.

The motivation is there because remote code execution is the most dangerous type of vulnerability, allowing attackers to cause significant harm while evading all security protocols.

As a result, users of Bitbucket Server and Data Center are urged to install any security updates or mitigations as soon as they become available.


Read more »
python
Code Execution Flaw CVE vulnerability Cyber Security macOS Microsoft PoC Privacy Sandbox python

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.


Read more »
zero Day vulnerability
Bugs Exploits Flaws Log4j PoC Vulnerabilities and Exploits Vulnerability management Vulnerable Systems zero Day vulnerability

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.
Read more »
Vulnerability and Exploits
Cybersecurity Breach Mac macOS PoC Vulnerability and Exploits

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.
Read more »
Windows
AMD GPU Intel malware Memory Cards Nvdia PoC Windows

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.
Read more »
Subscribe to: Posts (Atom)