Sep 15 2022

Organizations should fear misconfigurations more than vulnerabilities

Category: Security vulnerabilitiesDISC @ 8:43 am

Censys launched its State of the Internet Report, a holistic view into internet risks and organizations’ exposure to them.

Through careful examination of which ports, services, and software are most prevalent on the internet and the systems and regions where they run, the research team discovered that misconfigurations and exposures represent 88% of the risks and vulnerabilities across the internet.

“Assessing the state of the internet is crucial in understanding an organization’s own risks and exposures,” said Zakir Durumeric, Chief Scientist of Censys.

Key findings

  • Misconfigurations â€“ including unencrypted services, weak or missing security controls and self-signed certificates – make up roughly 60% of observed risks. When analyzing the risk profile of organizations across industries, missing common security headers accounted for the primary security error.
  • Exposures of services, devices, and information represent 28% of observed risks. This includes everything from accidental database to device exposures.
  • Critical vulnerabilities and advanced exploits only represent 12% of observed risks. When analyzing organizations by industry, the Computer and Information Technology industry had the widest spread of different risks, while Freight Shipment and Postal Services had the second widest.

Researchers also conducted a holistic assessment of the internet’s response to three major vulnerabilities – Log4j, GitLab and Confluence – to understand mitigation strategies based on how a vulnerability is perceived. From this analysis, Censys learned how the internet responds differently to vulnerability disclosures.

Three distinct types of behavior in response to vulnerability disclosures

  • Near-immediate upgrading: Systems vulnerable to Log4j acted quickly based on the widespread coverage of the vulnerability. By March 2022, Censys observed only 36% of potential vulnerable services were left unpatched.
  • Upgrading only after the vulnerability is being actively and widely exploited: While the GitLab vulnerability was being exploited, the remediation process acted slower than others until researchers discovered a botnet composed of thousands of compromised GitLab servers participating in DDoS campaigns.
  • Near-immediate response by taking the vulnerable instance off the internet entirely: Rather than upgrading, users chose to remove assets entirely from the internet after Confluence’s vulnerability became public between June 2021 and March 2022.

The internet constantly evolves as new technologies emerge, vulnerabilities are discovered, and organizations expand their operations that interact with the internet. Security teams have the responsibility to protect their organizations’ digital assets and need proper visibility into the entire landscape to do so.

Although vulnerabilities often garner the bigger headlines, it’s undetected misconfigurations and exposures that create the most risk for an organization, making it important to regularly assess any new hosts or services that appear in your infrastructure. Regardless of vulnerability type, providing organizations with the visibility and tools needed to strengthen their security posture introduces a proactive, more vigilant approach to digital risk management.

World

Secure By Design

Tags: misconfigurations, Secure By Design


Dec 16 2021

While attackers begin exploiting a second Log4j flaw, a third one emerges

Category: App Security,Log4j,Security vulnerabilitiesDISC @ 9:54 am

Experts warn that threat actors are actively attempting to exploit a second bug disclosed in the popular Log4j logging library.

American web infrastructure and website security company Cloudflare warns that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library.

The CVE-2021-45046 received a CVSS score of 3.7 and affects Log4j versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (which was released to fix CVE-2021-44228).

The Apache Software Foundation (ASF) has already released a patch for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially address the flaw in certain non-default configurations. An attacker with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.

Both issues were assessed with the release of Log4j 2.16.0 version that addresses the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.

“Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.” states CloudFlare.”This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.”

The bad news are not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.

This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.

“However, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.” states the post published by Praetorian.

This image has an empty alt attribute; its file name is image-13.png

Secure By Design

Secure Software Development Fundamentals Professional Certificate

Tags: Log4j, Log4shell, Secure By Design


Dec 15 2021

Log4Shell: A new fix, details of active attacks, and risk mitigation recommendations

Category: Log4j,Security vulnerabilitiesDISC @ 1:22 pm

New versions of Log4j

The recent discovery of a second Log4j vulnerability (CVE-2021-45046) has shown that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

This vulnerability could allow attackers to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DoS) attack.

“Note that previous mitigations involving configuration such as to set the system property ‘log4j2.noFormatMsgLookup’ to ‘true’ do NOT mitigate this specific vulnerability,” the Apache Log4j security team noted.

“Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).” The team advises users either to upgrade to version 2.12.2 (for Java 7) or 2.16.0 (for Java 8 or later), in which the Message Lookups feature has been removed and access to JNDI has been disabled by default, and explained why some of the mitigation measures shared a few days ago are incomplete.

Active exploitation

PoCs are constantly popping up on GitHub and getting forked. GitHub is steadily working on removing them, but the proverbial cat is now out of the bag, and there is no going back.

Exploitation attempts detected so far in the wild can be tied to ransomware groups and access brokers, botnet herders (delivering coin miners), and nation-backed APTs.

“The way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers – cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints,” says Michael Assraf, CEO at Vicarius.

“As fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting. Examples include: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE, and many more.”

Gallagher says that the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems.

“Where systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third party vendors who may also be at risk,” he advised.

Mathew Eble, VP of Services at Praetorian, also warned the issue will be prone to false negatives.

“Externally there is no way to cover all the possible paths that exploitation can take. Even when external scanning tools get more sophisticated in how they identify the issue, we strongly advocate not relying on scan results as strong indicator of your risk,” he noted.

This recommendation is based on four issues the company has confirmed when working with customers. Based on this, they have expanded their initial recommendations for defenders.

Log4Shell mitigation

Secure By Design

Secure Software Development Fundamentals Professional Certificate

Tags: Log4j, Log4shell, Secure By Design