Log4j 보안 취약점 사태

▶ Log4j란
Log4j는 Java/Kotlin/Scala/Groovy 코딩 도중에 프로그램의 로그를 기록해주는 라이브러리로, 이클립스, IntelliJ IDEA, 안드로이드 스튜디오 등에 추가해서 프로그램 실행 시 자동으로 지정한 경로에 로그를 저장해주는 기능을 한다.


▶ Log4j의 원리
하트블리드 사태와 비슷하게 이 취약점 사태 또한 여파와 다르게 취약점의 원리가 간단하다.

우선 이 취약점은 JNDI와 LDAP를 이용한다. JNDI는 Java Naming and Directory Interface의 약자로 1990년대 후반부터 Java에 추가된 인터페이스이다. Java 프로그램이 디렉토리를 통해 데이터(Java 객체 형태)를 찾을 수 있도록 하는 디렉토리 서비스이다.

JNDI는 이러한 디렉토리 서비스를 위해 다양한 인터페이스가 존재하는데 그 중 하나가 LDAP이다. 이 LDAP가 이번 취약점에 가장 중요한 포인트이다.

Java 프로그램들은 앞서 말한 JNDI와 LDAP를 통해 Java 객체를 찾을 수 있다.

예시로 URL ldap://localhost:389/o=JNDITutorial을 접속한다면 LDAP 서버에서 JNDITutorial 객체를 찾을 수 있는 것이다.

이러한 접근 인터페이스가 이번 사태에 치명적이게 된 이유는, Log4j에는 편리하게 사용하기 위해 ${prefix:name} 형식으로 Java 객체를 볼 수 있게 하는 문법이 존재하기 때문이다.

예를 들어 ${java:version}은 현재 실행 중인 Java 버전을 볼 수 있게 한다.

이런 문법은 로그가 기록될 때도 사용이 가능 했고, 결국 해커가 로그에 기록되는 곳을 찾아 ${jndi:sndi:snd://example.com/a}과 같은 값을 추가하기만 하면 취약점을 이용할 수 있는 것이다.

이 값을 넣는 방법은 User-Agent와 같은 일반적인 HTTP 헤더일 수도 있고 여러가지 방법이 있다.


▶ 취약점이 만들어진 경위
링크의 이슈로 부터 시작 되었다. Lookup 플러그인에 jndi을 추가하는게 이 이슈의 목적이였고, 추가된 jndi를 통해 취약점이 발생하게 된 것이다.

이 패치는 이슈에서 보다시피 2.0-beta9 버전에 적용되었고 이 사태가 벌어지기까지 약 8년이라는 오랜 기간 동안 방치되었다.
하지만 1.2 의 JMSAppender 클래스의 취약점이 추가 발견되면서 모든 버전에 대한 취약점 여파가 커졌다.


▶ Log4j의 보안 사태 전개
해당 버그는 2021년 11월 24일, 알리바바 클라우드 보안팀의 Chen Zhaojun가 발견했다.

이 이슈가 문제가 되는 것은 "서버에 로그인한 것 만으로 해커가 사용자의 컴퓨터를 사실상 원격 조종할 수 있는 것이기 때문이다."라고 경고했다.

KISA는 2021년 12월 11일 보안공지를 통해 영향을 받는 버전 별로 해결할 수 있는 방법을 게시했다. 이후 국정원은 국내 언론 보도에서 "11일 자정부터 해당 이슈에 대응했으며, 정부와 공공기관 측에 취약점 패치 적용 및 보안 대책을 구축되어 있는 시스템[22]을 통해 안내했다"고 밝혔다.

Apple은 2021년 12월 11일에 iCloud에서 보안 취약점 패치를 완료했다. macOS에서는 애초에 이 보안 취약점이 적용되지 않는다고 한다.

KISA는 2021년 12월 15일 보안공지의 내용을 추가하여, log4j 1.2 버전의 취약점을 공개하였다.

 

 

 

 

출처]

나무위키 : Log4j 보안 취약점 사태

 

 

 

 

대한민국의 아름다운 영토, 독도의 겨울