본문 바로가기
개발 지식/Backend

[Log] Apache Log4j2 취약점 발견 및 원인

by 에르주 2021. 12. 13.
반응형

어느날 인터넷 서핑을 하던중 Log4j2 취약점 발견이라는 기사를 접하게 되었다. 실무에서 사용하는 @slf4j 또한 연관이 있기 때문에 해당 내용을 자세히 알고 싶어졌고 어떤 취약점이 있는지 찾아보게 되었다.
(지극히 검색을 통해 알아낸 점이라 내용에 이상이 있으면 댓글 달아 주세요...)
일단 취약점 원인을 이해하기 위해서는 몇가지를 알고 있어야 한다.

  • JNDI
  • LDAP

1. JNDI (Java Naming and Diretory Interface)

"디렉터리 서비스에서 제공하는 데이터 및 객체를 발견하고 참고하기 위한 자바 API이다." 
라고 위키에 나와 있지만 이해가 되지 않아 구글링 해보며 결론적으로 내가 이해한 것 내용은 "DNS 서버랑 비슷하다" 였다.

DNS서버가 사람이 읽을수 있는 도메인 이름을 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 하는 것인데
JNDI는 자바 애플리케이션 설정을 통해 데이터베이스 또는 LDAP의 데이터 및 객체에 이름을 붙이고 그 이름으로 데이터 및 객체들을 발견하고 참고 하는데 활용 하는 것이다.

예를 들어 dataSource를 정의할 때 다음과 같이 JNDI를 선언할 수 있다.

<dataSource type="JNDI">
	<property name="data_source" value="java:/comp/env/jdbc/JpaShopDB"/>
</dataSource>

 

// 톰캣 서버에서의 DataSource 설정
// name: JDNI 이름 (java:comp/env 디렉토리에서 찾을 수 있다.)
<Resource name="jdbc/JpaShopDB" auth="Container" type="javax.sql.DataSource"
		.... />

 

try {
InitialContext initialContext = new InitialContext();
	if(initialContext != null) {
		DataSource datasource = (DataSource) initialContext.lookup( "java:/comp/env/jdbc/JpaShopDB" );

		if(datasource != null) {
			conn = datasource.getConnection();
		}
       }
}
catch {
 	...
}

해당 설정은 
1) dataSource type="JNDI" 에서 data source  'java:/comp/env/jdbc/JpaShopDB'라는 JNDI 이름을 만든다.
2) 톰캣 서버에서 JNDI가 'jdbc/JpashopDB' 라는 이름을 찾는다.
3) lookup() 메소드는 InitialContext 클래스의 메소드로 JNDI 인터페이스를 통해 서버에 등록된 객체 즉 resource를 반환 받는다.

즉 JNDI는 위의 datasource 객체를 받아오는 예시처럼 자바 애플리케이션 안의 데이터 및 객체를 발견하고 참고하는 것이다.



2. LDAP (Lightweight Directory Access Protocol)

LDAP는 TCP/IP위에서 디렉토리 서비스를 조회하고 수정하는 응용 프로토콜로 서버 내 디렉토리를 관리하는 것이라 이해 하면 될 것 같다. 
그리고 디렉토리라 하는 것은 간단하게 보면 말 그대로 컴퓨터나 서버 내 폴더 및 파일 구성을 말하는 것이다.

디렉토리...!

 


Apache에서는 다음과 같이 정의하였다.

CVE-2021-44228 : Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
// Apache Log4j2 JNDI 기능은 해커가 제어하는 LDAP 와 기타 JNDI 연관된 엔드포인트로부터 보호 되지 않는다. 

즉 내용을 정리하자면

Log4j2의 취약점은 Log4j의 JNDI 및 LDAP 이용하여 외부의 공격자가 서버 내부의 디렉토리 구조 및 내용을 확인할 수 있다는 점이다.


그럼 어떻게 Log4j의 JNDI 또는 LDAP를 외부에서 활용할 수 있을까라는 의문이 든다.

하나 예를 들자면
보통 Client에서 Server로 요청할 때 Log4j2를 이용하여 어떤 URL에서 요청이 오는지 로그 기록을 남길 때가 있다.
공격자가 JNDI를 자신의 서버의 LDAP 프로토콜로 설정 후 공격하려고 하는 서버에 요청하게 되면 해당 로그가 찍히면서 실행된다. 

그렇게 되면 공격자의 서버의 내부 서비스 클래스 파일을 해당 서버에서 실행 시킬 수 있는 것이다.
공격자 서버의 클래스 파일 Lookup 메소드를 통해 공격당한 서버의 디렉토리 구조와 내용을 확인하고 반환 받아 밖으로(제 3의 서버) 빼낼 수도 있고 그 서버의 치명적인 오류를 발생 시킬 수도 있다.

3. 해결책

그렇기 때문에 해결책으로써 

보호나라 홈페이지 참고 (https://www.boho.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389)

JNDI의 Lookup 메소드를 실행시키지 않게 하거나 Lookup 클래스를 제거하는 것이다.

 

마지막으로 Log4j2의 취약점을 쉽게 이해할 수 있는 유튜브 링크가 있어 첨부하고 이글을 끝내려 한다.

https://www.youtube.com/watch?v=5Jy7zDQLoSo 

log4j2 취약점 공격 영상

 

끝.

반응형

댓글