Don’t leave your cloud storage to chance.
Log4J is an open-source java-based logging utility that is a component of the Apache Logging Services; Log4J is a project of the Apache Software Foundation.
On December 9th, the Apache Software Foundation published a security advisory alerting their community of a severe vulnerability for Log4J, also known as Log4Shell. MITRE, “the free, globally accessible service that offers comprehensive and current cyber security threat information” to organizations; recorded and assigned the vulnerability its highest severity rating of Critical severity 10, CVE-2021-44228. Once the vulnerability was disclosed and picked up by hackers, it came as no surprise they began a campaign to attack the vulnerability.
For Storj Customers, Storj Service Node Providers, Users, and Affiliates
The Storj open source decentralized network is unaffected because we do not use Log4J in our product, meaning Storj does not use anything on the JVM within the product. Storj has investigated all third-party and cloud servers and has confirmed that either they were not affected or if the endpoint was affected and are using Log4J, they were immediately patched and protected. We continue to watch and monitor additional Log4J developments.
Storj has a Cybersecurity Program, which includes an Incident Response Plan and cybersecurity resources that are continuously monitoring and detecting vulnerabilities and responding to all severity levels and remediating based on Storj’s vulnerability plan.
Log4Shell Vulnerability, Exploits, and Mitigation
For people who use Java or JVM technology, the Log4J vulnerability is located within the Java Naming and Directory Interface (JNDI), which can be exploited using a malformed LDAP request or similar technology, resulting in data leakage from the targeted server. The following process flow will exploit the targeted server using the Log4Shell vulnerability: Hacker connects to the server-> malicious payload sent to server-> malicious payload uses JNDI exploit-> malicious java code is injected-> the server is infected and is compromised.
The above is just one common scenario out of numerous attack vector possibilities; this example demonstrates how easily a hacker can exploit the vulnerability.
While hackers, in general, have increased their scanning activity for vulnerable servers and endpoints, the more experienced hackers typically won’t scan for this vulnerability because a credential scan is required to detect most Log4J configurations. Most experienced hackers will skip scanning and attempt to hack the server, hoping that it is one of the millions of endpoints using Log4J; since the vulnerability is target-rich the hackers will typically take this approach to attack.
Cybersecurity professionals and researchers seem to agree that hackers knew about the vulnerability before it was reported by Apache and therefore was a Zero Day exploit.
What Endpoints and Applications are at Risk?
All internet facing endpoints that are using Log4J are vulnerable. This vulnerability is very critical and so widespread that it is expected to be a challenge to the internet for many years in the future.
How to resolve and mitigate the vulnerability?
Conduct a complete credentialed (login to servers) vulnerability scan of all endpoints and record all of those using Apache Log4J.
Review all third-party applications and cloud servers for the same Log4J vulnerability.
Patch all affected endpoints and request that all third parties patch their servers as soon as possible.
Execute another vulnerability scan to make certain that all affected endpoints are patched.
Conduct a penetration test and use various attack vectors to confirm and validate that all exploits have been resolved.
The government agency CISA (Cybersecurity and Infrastructure Security Agency) in partnership with the Joint Cyber Defense Collaborative has created a webpage for the Apache Log4J vulnerability CVE-2021-44228, click the link below.
Please contact Storj if you have further questions or concerns.