[KISA] Log4j 위협 대응 보고서_v0.1

Log4j 란?

Apache 재단의 무료 오픈소스 프로그램으로 자바 기반의 모든 애플리케이션에서 사용 가능하다. 따라서 일반적인 웹 사이트, 쇼핑몰, 그룹웨어 등 다양한 자바 기반의 서비스에서 로브 기록을 위해 사용될 수 있다. 이러한 대중적인 프로그램에서 알려지지 않은 취약점이 발견되고, 해당 취약점을 악용하는 공격 기법이 매우 빠른 시간에 세상에 공개되어 매우 심각한 이슈로 다루고 있다. 해당 취약점은 공통 취약점 등급 시스템에서 10점의 Crtical 등급을 평가되었으며, 해커가 해당 취약점을 악용할 경우 시스템 관리자 권한을 획득할 수 있는 위협이 있다.

 

취약점 발생 원인

(본 문서에서는 Log4j에서 최근 발생한 여러 취약점 중 최초 취약점이면서 가장 파급력이 큰 Log4Shell(CVE-2021-44228) 취약점에 대해서 다룬다.

Log4Shell 취약점은 log4j에서 구성, 로그 메시지 및 매개 변수에 사용되는 JNDI(Java Naming and Directory Interface)에서 발생하는 취약점으로, 공격자는 Lookup 기능을 악용하여 LDAP 서버에 로드된 임의의 코드를 실행할 수 있다.

JNDI(Java Naming and Directory Interface) : Java 응용 프로그램이 필요한 자원 (데이터베이스 등) 및 실행에 필요한 다른 프로그램 정보를 찾을 수 있는 기능 제공

Lookup : JNDI를 통해 찾은 자원을 사용하는 기능

영향 받는 버전 : 2.0-beta9 ~ 2.14.1 이하

※ 취약점이 해결된 버전(2.3.1, 2.12.2 및 2.12.3) 제외

 

취약점 분석

(결론) jndiManager.lookup() 메소드로 인해 발생한다. 인자로 전달된 LDAP 입력 값에 대해 검증 절차 없이 바로 lookup() 기능을 통해 접근을 시도하여 컨텍스트를 검색함으로써 공격자 LDAP 서버에 Exploit 엔티티를 요청하게 된다.

 

취약점 조치방안

Log4j 취약점 스캐너 - 여러 보안업체에서 배포중(이스트시큐리티, SK쉴더스 등) 
운영체제 기본 검색 기능 - Log4j 버전 확인

JAVA 버전에 따라 Log4j을 최신 버전으로 업데이트
- JAVA 8 이상 : 2.17.1 이상
- JAVA 7 : 2.12.4 이상
- JAVA 6 : 2.3.2 이상
(2022년 1월 기준, Logj4 최신 버전)

업데이트가 어려운 경우 임시 조치방안으로 JndiLookup 클래스만 제거

 

주요 이슈 요약

Log4j 이슈는 보안 업데이트가 특정 취약점에 대한 조치일 뿐 프로그램의 완결성을 의미하지 못한다는 점을 집중적으로 경험할 수 있었던 대표적 사례이다.
KISA는 Log4j 취약점 보안공지를 지속 업데이트하고 있다. 보안담당자들은 KISA의 보안공지 현황을 지속적으로 참고해야 하며, 신규 내용이 공지될 경우 신속히 조치해야 한다.

해당 프로그램은 다양한 제품 내에 패키지 형태로 포함되어 사용되고 있으므로 보통 취약점 발견 시 특정 해당 제품에 대한 패치를 진행하면 되지만, Log4j와 같이 제품 내에 패키지 형태로 포함되는 프로그램에서 취약점이 발견될 경우 해당 프로그램 사용 여부를 상세히 파악하기가 쉽지 않다.

금번 Log4j 취약점 이슈가 발생했을 때 기업들이 가장 어려워했던 부분은 자사 기업 내에서 Log4j 프로그램을 사용하는 3rd-party 제품이 있는지 여부를 식별하는 것이었다.

특정 프로그램에 대한 보안 업데이트 권고가 발표되었으나 해당 프로그램의 존재 여부를 식별하는 것 자체에 많은 시간이 소요되는 것은 매우 큰 위협이 된다. 이러한 위협에서 우리는 어떻게 Security를 유지해 나갈 수 있는지 검토해보아야 한다.

업데이트를 완료하였으면, 내부 시스템에 침투하였는지 2차 점검이 필요하다. Log4j는 여러 서비스에서 사용되는 프로그램이기에 취약점 공격이 성공하였더라도 남는 흔적이 정형화되어 있지 않고 서비스마다 다르기 때문에 공격 명령에 사용되는 Class 파일도 피해 시스템에 뚜렷한 흔적으로 남지 않는다.

따라서 기업에서는 Log4j 취약점 패치 이후 내부 중요시스템을 중심으로 전반적인 비정상 여부 점검을 상세하게 진행해야 한다. 평소와 다른 외부 통신 발생 여부 및 비정상 프로세스 존재 여부 등 다양한 관점에서의 점검이 필요하다.

 

시사점

KISA에서 발췌한 Log4j 위협 대응 보고서를 통해 실제 크리티컬한 취약점 발생 시 바라보는 관점을 빌려볼 수 있었다. 취약점이 발생한 개요 - 취약점 원인 - 위협 분석 - 대응방안 - 시사점 의 단계로 바라보았으며, 실제적으로 우리가 어떠한 노력을 해야되는지를 살펴보았다. 먼저, Log4j는 신속한 패치가 중요한 취약점으로 실제 패치 관리가 잘되지 않는 기업의 경우 패치 식별 즉 버전을 식별하는 작업에 큰 시간이 소요되어 그 자체로 취약한 상황이 될 수 있다. 

요약하자면 크게 아래와 같은 노력이 필요하겠다.

1. Log4j 패치
2. 내부 시스템 침투 확인
3. 보안장비 탐지룰 업데이트
4. 모니터링 강화
5. 시스템 로그 관리

컨설턴트 입장으로 바라봤을 때 가져야할 자세는 아래와 같다.

1. 보안이슈, 동향에 대해 민감해야 한다.
2. 기술적인 대응방안만을 고집하지 말고, 신속히 이루어질 수 있는 '절차'를 세우는 것이 중요하다.
3. 즉 전체적인 프로세스에 대한 이해와 개선에 집중할 수 있도록 식견을 넓혀야 한다.

 

본 포스팅은 KISA에서 발췌한 Log4j 위협 대응 보고서 v1.0에 대한 요약이 있습니다.

Log4j 위협 대응 보고서.pdf

12.32MB