What is Apache OFBiz?

Apache OFBiz is an integral part of the digital backbone of numerous industries, ranging from financial services to healthcare. This open-source Enterprise Resource Planning (ERP) system is a key player in managing complex business processes, which is essential for large enterprises. This is what makes the CVE-2023-51467 vulnerability something more than a technical glitch. Its extensive exploitation can be a potential gateway for catastrophic disruptions in critical services and infrastructure​​.

Apache OFBiz Vulnerability – Technical side

SonicWall’s research team detected this critical zero-day vulnerability and promptly disclosed it to Apache OFBiz’s maintainers. The root of this vulnerability lies in the application’s login functionality. Attackers exploiting CVE-2023-51467 can bypass authentication by manipulating the checkLogin function in Apache OFBiz. By setting the “requirePasswordChange” parameter to “Y” in the URI and supplying null or invalid credentials, the function mistakenly returns a success status, thus allowing unauthorized access​​​​. The vulnerability specifically affects the login process of Apache OFBiz.

How does the exploit work?

1. Manipulating the CheckLogin Function
   The core issue lies in the “checkLogin” function. Normally, this function should validate a user’s credentials before granting access. However, due to a flaw in its implementation, it fails to perform this task correctly under certain conditions.
2. Exploiting Null or Invalid Credentials
   The exploit involves sending a crafted HTTP request where the “USERNAME” and “PASSWORD” parameters are left empty, or invalid values are provided. However, the exploit includes the “requirePasswordChange=Y” parameter in the URI.
3. Bypassing Authentication Checks
   Due to the flawed logic in the “checkLogin” function, when it receives null or invalid credentials along with the “requirePasswordChange=Y” parameter, it incorrectly bypasses the usual authentication checks. Specifically, it fails to enter the conditional block that checks whether the username and password are null. Consequently, it erroneously returns a success status, allowing the authentication process to be bypassed.
4. Potential for Server-Side Request Forgery (SSRF) or Remote Code Execution (RCE)
   By bypassing authentication, an attacker could potentially perform SSRF or RCE, leading to unauthorized access to sensitive data or control over the system.

The exploitation of this flaw could lead to dire consequences. Attackers could potentially gain control over sensitive systems, compromise confidential data, and disrupt essential services. Also, he widespread use of Apache OFBiz in various sectors heightens the risk of large-scale, coordinated attacks that could target multiple facets of society simultaneously​​.

Patch and Recommendations

In response to this alarming discovery, Apache released a security update. The new version, 18.12.11, addresses the vulnerability and is strongly recommended for immediate implementation. Additionally, organizations are advised to conduct thorough security audits and apply patches to all affected platforms promptly​​.

Users of Apache OFBiz are strongly advised to:

• Upgrade to Apache OFBiz version 18.12.11, which contains the fix for this vulnerability.
• Regularly audit systems for vulnerabilities and apply necessary patches.
• Keep an eye on system logs and access patterns to detect any signs of exploitation attempts.
• Utilize XDR solutions proactively to prevent cyberattacks by continuously monitoring and correlating data across endpoints, networks, and cloud environments. Early threat detection and rapid response are key.

The post Apache OFBiz Vulnerability Exposes Millions of Systems appeared first on Gridinsoft Blog.

New Apache Struts 2 RCE Vulnerability Discovered

Recently, Apache has issued a security advisory highlighting this critical vulnerability in the Struts 2 framework, which could lead to remote code execution. The vulnerability stems from defective file upload logic, potentially allowing unauthorized path traversal. Under certain conditions, this flaw can be exploited to upload and execute arbitrary code.

Struts 2, employing the Model-View-Controller (MVC) architecture, is a Java framework extensively used in building enterprise-level web applications. While there are no reports of active exploitation of this vulnerability, the history of Apache Struts vulnerabilities, such as CVE-2017-5638 (CVSS score: 10.0), which was used in the notorious Equifax breach in 2017, underscores the importance of proactive security measures.

Affected Struts 2 Versions

The vulnerability affects the following versions of Apache Struts 2.3.37 (End of Life), 2.5.0 to 2.5.32 and Struts 6.0.0 to 6.3.0. Apache released patches in Struts versions 2.5.33 and 6.3.0.2 or later to address this issue. The developer does not offer any workarounds to mitigate the issue, so applying the patch update as soon as possible is crucial. The project maintainers strongly recommend developers implement the update, and they have stated that “This is a drop-in replacement, and upgrade should be straightforward”. This update is necessary to protect systems from potential exploits.

Preventive measures and recommendations

Since Apache Struts 2 is integral to numerous enterprise web applications, it makes this vulnerability particularly concerning. The potential for unauthorized remote code execution could lead to significant data breaches and disruptions in critical services. In light of this development, Apache Struts 2 users are urged to:

• Assess and Update. As I’ve said many times before, the updates contain essential fixes. Postponing or ignoring them jeopardizes the entire target network. So, evaluate their current version of Apache Struts and apply the necessary patches.
• Stay Informed. I recommend continuously monitoring official channels for updates or additional information. Keeping yourself informed will allow you to take necessary precautions and mitigate any potential risks associated with the vulnerability.
• Logging and Monitoring. Implement a comprehensive logging system to capture all application activity and user actions. Also, implement log analysis tools to identify suspicious activity and potential security incidents.
• Penetration Testing. Regularly perform vulnerability scans and penetration testing to identify and address security vulnerabilities and weaknesses. This will help not only to enhance software security, but also to pick a secure network architecture and hardware options.

The post New Apache Struts 2 Vulnerability Allows for RCE appeared first on Gridinsoft Blog.

Apache ActiveMQ Vulnerability Allows for RCE

Analysts from TrendMicro warn about an active exploitation of an ActiveMQ vulnerability, discovered back in late October 2023. CVE-2023-46604 allows for remote code execution due to the failure of class type validation. Typically for RCE vulnerabilities, it received a high CVSS score of 9.8/10. Apache warned its clients, released fixes and recommendations regarding supplementary software that is related to the successful exploitation.

Despite the fast reaction from the company, hackers managed to start using this vulnerability for malicious purposes. As it usually happens, companies hesitate with updates, especially when they are not exploited at the moment. And it is completely understandable – for large corporations, who are the main ActiveMQ users, installing updates is always a pain in the neck. But now, there is a chain of successful exploitation – a great stimulus towards getting the latest software version.

ActiveMQ Vulnerability Exploited in the Wild

As the same research says, the known exploitation cases were aiming at the installation of Kinsing malware. This Linux threat is also known under the name of h2miner – which already says enough about its capabilities. Aside from Kinsing, hackers were using another, unnamed miner. Other reports say that CVE-2023-46604 exploitation is primarily done by the threat actor that stands behind HelloKitty ransomware.

Still, the 9.8 score for this vulnerability is not just to scare people. Being an RCE vulnerability, it can help with delivering any other malware to the target environment, depending on the wish of the attacker. It is great luck that the detected exploitation cases were mostly related to coin miners. There is always a chance that the very next attack will introduce ransomware, spyware, or their mix.

Available CVE-2023-46604 Mitigations

Back on October 24, 2023, Apache released a lineup of recommendations for ActiveMQ users. The main one though was concentrated on updating the protocol brokers to the versions where the breach is patched.

List of versions with the vulnerability fixed:

The company offers no temporal mitigations, which leaves 0 ways to circumvent patching. However, several other approaches will provide you with better exploitation protection.

Extended Detection and Response solutions (XDR) are the cornerstone of modern corporate cybersecurity. When joined by SOAR and SIEM systems, XDR allows detecting, stopping and blocking all further attempts of a cyberattack within the entire environment. Policies like zero trust will enhance protection against exploitation even further, weeding out attempts to use well-known and trusted software in the attack.

The post Apache ActiveMQ Vulnerability Exploited In The Wild appeared first on Gridinsoft Blog.

Let me remind you that we also wrote that the Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions.

Issue CVE-2022-42889 was disclosed earlier this week. Apache Commons Text is an open-source Java library for manipulating character strings. And back in March 2022, GitHub Security Lab expert Alvaro Muñoz discovered that the library was vulnerable to an RCE vulnerability related to unreliable data handling and variable interpolation.

Apache Commons developers last week, with the release of version 1.10.0, where the problematic interpolators were disabled.

Since many developers and organizations use Apache Commons Text, and the vulnerability even affects versions of the library released back in 2018, some experts warned that the problem could become a new Log4Shell. As a result, CVE-2022-42889 was named Text4Shell or Act4Shell, but it soon became clear that such concerns were most likely unnecessary.

In particular, analysts from Rapid7 published their analysis of the problem. They explained that not all library versions from 1.5 to 1.9 are vulnerable, and the potential for exploitation is associated with the version of the JDK used. They also note that it is not entirely correct to compare the new vulnerability with Log4Shell.

The researchers tested the PoC exploits on various versions of the JDK, and it worked without warning only on versions 9.0.4, 10.0.2, and 1.8.0_341. However, it should be noted that an updated PoC exploit has already been presented that works on all vulnerable versions, and it turned out that JDK 15+ versions are also affected by the bug.

Sophos experts also agreed with colleagues’ point of view, who said that the vulnerability is dangerous, but at present, it is not as easy to use it on vulnerable servers as Log4Shell. And even Munoz himself, who discovered the bug, also explained that, despite the similarity to Log4Shell, the new vulnerability is likely to be widespread and much less dangerous.

This is also the opinion of the Apache security team, who stated that the scale of the problem is not comparable to Log4Shell, and string interpolation is a documented feature. That is, it is unlikely that applications using the library will inadvertently pass unsafe input without validation.

However, despite all these reports of specialists, Defiant analysts warned that hackers have already begun to exploit CVE-2022-42889. The company has monitored 4,000,000 sites since the issue was disclosed (October 17) and now reports that it has detected hacking attempts that originate from approximately 40 IP addresses and began on October 18. So far, it is only about intelligence.

It should also be noted that the Apache Commons Text library remains vulnerable even after updating to version 1.10.0, and the exploitation of the problem “depends on how it is used and there are no guarantees in the unsafe use of the library inside your product or a borrowed package.”

The post New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers appeared first on Gridinsoft Blog.

Let me remind you that the CVE-2021-44228 vulnerability, also called Log4Shell and LogJam, was discovered in the popular Log4j logging library in early December.

The researchers report that Aquatic Panda uses a modified version of the exploit for a bug in Log4j to gain initial access to the target system and then performs various post-exploitation activities, including exploration and credential collection.

To compromise an unnamed educational institution, the hackers targeted VMware Horizon, which used the vulnerable Log4j library. The exploit used in this attack was published on GitHub on December 13, 2021.

The attackers also conducted reconnaissance efforts to understand privilege levels better and learn more about the domain. Also, they attempted to interrupt a third-party endpoint threat detection and response solution.

After deploying additional scripts, the hackers tried to run PowerShell commands to extract the malware and three VBS files, which appeared to be reverse shells. In addition, Aquatic Panda made several attempts to collect credentials by performing memory dumps and preparing them for theft.

Experts write that the attacked organization was timely warned of suspicious activity and could quickly use the incident response protocol, fixing vulnerable software and preventing further development of the malicious activity.

The Aquatic Panda group has been active since at least May 2020 and typically engages in intelligence gathering and industrial espionage, targeting organizations in the government, telecommunications, and technology sectors. The group’s toolbox includes Cobalt Strike, FishMaster downloader, and njRAT.

Let me also remind you that I wrote that Log4j vulnerability threatens 35,000 Java packages, as well as that Another vulnerability found in Log4j, this time it is a denial of service.

The post Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions appeared first on Gridinsoft Blog.

The problem was originally discovered while catching bugs on Minecraft servers, but the Log4j library is present in almost all corporate applications and Java servers. For example, it can be found in almost all enterprise products released by the Apache Software Foundation, including Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo. Log4j is also actively used in open-source projects such as Redis, Elasticsearch, Elastic Logstash or Hydra.

I also said that Log4j vulnerability threatens 35,000 Java packages.

Thus, companies using any of these products are also indirectly vulnerable to attacks on Log4Shell, although they may not even know about it. Information security experts immediately warned that the solutions of such giants as Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and probably thousands of other companies could be vulnerable to Log4Shell.

It was previously revealed that the first patch for the original problem CVE-2021-44228 (version 2.15) only introduced a new RCE vulnerability CVE-2021-45046 to Log4j, which received 9 points out of 10 on the CVSS vulnerability rating scale.

Because of this, administrators were strongly advised to use only the current version 2.16 and follow further developments on the Log4j update page. The fact is that in Log4j version 2.15, two more less dangerous vulnerabilities were found (CVE-2021-4104 and CVE-2021-42550), which were also eliminated only with the release of version 2.16.

Unfortunately, version 2.16 didn’t last long either. Last weekend, Log4j version 2.17 was released, as a serious denial of service (DoS) issue was detected in the last release, which received the identifier CVE-2021-45105 (7.5 on the CVSS scale). The bug is related to the fact that Log4j does not always protect against infinite recursion during lookup evaluation.

At the same time, experts urge not to panic and not to rush to abandon the use of Log4j at all.

The post Another vulnerability found in Log4j, this time it is a denial of service appeared first on Gridinsoft Blog.

The patch was released as part of the 2.15.0 release.

The vulnerability was named Log4Shell and scored 10 out of 10 points on the CVSS vulnerability rating scale. The bug allows remote arbitrary code execution (RCE). Yesterday’s information security researcher aggravated the problem, p0rz9 published a PoC exploit on Twitter, and the vulnerability can be exploited remotely, and this does not require special technical skills.

The problem was originally discovered while searching for bugs on Minecraft servers, but Log4j is present in almost all corporate applications and Java servers. For example, the library can be found in almost all enterprise products the Apache Software Foundation released, including Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo, and so on. Log4j is also actively used in various open-source projects, including Redis, ElasticSearch, Elastic Logstash, Ghidra, and others.

Thus, companies using any of these products are also indirectly vulnerable to attacks on Log4Shell, but may even know about it. Information security specialists already report that solutions of giants like Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and probably thousands of other companies may be vulnerable to Log4Shell.

p0rz9 wrote that CVE-2021-44228 could only be exploited if the log4j2.formatMsgNoLookups parameter is set to false. KnownSec 404 Team reports that Log4j 2.15.0 has set this parameter to true to prevent attacks. Log4j users who have upgraded to version 2.15.0 and then set the flag to false will again be vulnerable to attacks.

Moreover, Log4j users who have not updated, but have set the flag to true, will still be able to block attacks even on older versions.

Unfortunately, this also means that all older versions are at risk, where this parameter is set to false by default. That is, all previous releases of Log4j, starting with 2.10.0, are vulnerable.

According to experts from Bad Packets and Greynoise, several cybercriminals are already scanning the network in search of applications that may be vulnerable to Log4Shell, which means that there is almost no time left to install patches.

Let me remind you that I also talked about the fact that the IIS bug with worm potential poses a threat to WinRM servers.

The post 0-day In Log4j Library Poses A Threat To Many Applications & Servers appeared first on Gridinsoft Blog.