Search This Blog
Powered by Blogger.

Blog Archive

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Vulnerable Systems. Show all posts
Vulnerable Systems
CISA Critical Infrastructure Ransomware Groups RWVP Vulnerabilities and Exploits Vulnerable Systems

RWVP: CISA Shares Vulnerabilities and Misconfigurations Targeted by Ransomware Groups


The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has recently revealed an insight into the misconfigurations and security vulnerabilities exploited by ransomware groups, in order to help critical infrastructure companies tackle their attacks. 

This information is part of a Ransomware Vulnerability Warning Pilot (RVWP) program conducted by CISA, which shows concern over the ransomware devices discovered on the networks of critical infrastructure organizations. 

To date, RVWP has discovered and identified over 800 vulnerable systems with internet-accessible vulnerabilities that are often targeted by different ransomware activities.  

CISA stated that "Ransomware has disrupted critical services, businesses, and communities worldwide and many of these incidents are perpetrated by ransomware actors using known common vulnerabilities and exposures (CVE) (i.e., vulnerabilities)." 

"However, many organizations may be unaware that a vulnerability used by ransomware threat actors is present on their network[…]Now, all organizations have access to this information in our known exploited vulnerabilities (KEV) catalog as we added a column titled, 'known to be used in ransomware campaigns.' Furthermore, CISA has developed a second new RVWP resource that serves as a companion list of misconfigurations and weaknesses known to be used in ransomware campaigns," CISA added.

RVWP is a component of a much larger effort that was initiated in response to the growing ransomware threat to critical infrastructure that first surfaced almost two years ago with a wave of cyberattacks targeting key infrastructure companies and U.S. government organizations, including Colonial Pipeline, JBS Foods, and Kaseya.

In June 2021, CISA broadened its horizon by launching the Ransomware Readiness Assessment (RRA), a component of its Cyber Security Evaluation Tool (CSET), whose goal is to help companies analyze and evaluate their preparedness in order to mitigate the risks and tackle from potential ransomware attacks. 

By August 2021, CISA also made recommendations to help vulnerable public and commercial sector organizations stop data breaches brought on by ransomware incidents.

In addition, CISA further formed an alliance with the business sector to defend vital US infrastructure against ransomware and other online dangers. All federal agencies and businesses who joined the cooperation have a collective response strategy embodied in this collaborative initiative, the Cyber Defense Collaborative.  

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 »
Vulnerable Systems
Arbitrary code execution attacks Data Disclosure Attack Private Data Sensitive data SmashEx Vulnerabilities and Exploits Vulnerable Systems

New SmashEx Attack Breaks Intel SGX Enclaves

 

A recently disclosed vulnerability affecting Intel CPUs could be used by attackers to get access to sensitive information kept within enclaves and potentially run arbitrary code on vulnerable systems. 

The vulnerability (CVE-2021-0186, CVSS score: 8.2) was found in early May 2021 by a group of academics from ETH Zurich, the National University of Singapore, and the Chinese National University of Defense Technology, who utilized it to perform a confidential data disclosure attack called "SmashEx" that can distort and compromise private data stored in the enclave. 

SGX (short for Software Guard eXtensions) was introduced with Intel's Skylake processors which allow developers to operate selected application modules in a totally isolated secure compartment of memory known as an enclave or a Trusted Execution Environment (TEE). It is designed to be guarded against processes running at higher privilege levels such as the operating system. Even if a computer's operating system has been tampered with or is under assault, SGX assures that data remains safe. 

The research stated, "For normal functioning, the SGX design allows the OS to interrupt the enclave execution through configurable hardware exceptions at any point." 

"This feature enables enclave runtimes (e.g., Intel SGX SDK and Microsoft Open Enclave) to support in-enclave exception or signal handling, but it also opens up enclaves to re-entrancy bugs. SmashEx is an attack which exploits enclave SDKs which do not carefully handle re-entrancy in their exceptional handling safely." 

Outside Calls, or OCALLS, enable enclave functions to call out to the untrusted programme and subsequently return to the enclave. However, when the enclave additionally handles in-enclave exceptions (e.g., timer interrupt or division-by-zero), the vulnerability allows a local attacker to take over the control flow of execution by injecting an asynchronous exception soon after the enclave is entered. 

With this power, the attacker can then damage the in-enclave memory, allowing sensitive data such as RSA private keys to leak or malicious code to be executed. Because SmashEx impacts runtimes that assist in-enclave exception handling, the researchers stated that "such OCALL return flow and the exception handling flow should be written with care to ensure that they interleave safely," and that "when the OCALL return flow is interrupted, the enclave should be in a consistent state for the exception handling flow to progress correctly, and when the exception handling flow completes, the enclave state should also be ready for the enclave to progress correctly." 

Since then, Intel has launched software updates to address this vulnerability, including SGX SDK versions 2.13 and 2.14 for Windows and Linux, respectively. Microsoft fixed the problem (CVE-2021-33767) in its July 2021 Patch Tuesday updates with Open Enclave version 0.17.1 of the SDK. The results of the research team are anticipated to be disclosed next month at the ACM Conference on Computer and Communications Security.  

The researchers stated, "Asynchronous exception handling is a commodity functionality for real-world applications today, which are increasingly utilizing enclaves and highlighted "the importance of providing atomicity guarantees at the OS-enclave interface for such exceptions."
Read more »
Subscribe to: Posts (Atom)