log4j log4j2 보안 취약점 조치방법 : pom.xml에서 라이브러리 찾는법 및 설정 변경

주말 사이에 아주 난리가 났다 ^_ㅠ

오픈소스인 log4j2의 취약점으로 인해 대대적인 점검 및 조치가 있었다. 최고 위험도의 보안 취약점이라고 하는데 JAVA 공화국이나 다름없는 대한민국은 더더욱이나 위험하다고 보인다.


아니나다를까 전자정부 프레임워크에도 log4j를 사용하고 있는 관계로 프레임워크 버전별로 사용중인 log4j 버전을 안내하고 조치 방안을 공지하는듯 하다.

https://www.egovframe.go.kr/home/ntt/nttRead.do?pagerOffset=0&searchKey=&searchValue=&menuNo=74&bbsId=6&nttId=1838

공지사항 | 표준프레임워크 포털 eGovFrame

log4j-core-2.x 조치방법 : pom.xml에서 라이브러리 찾는법 및 설정 변경

사실 전자정부 프레임워크를 안써서 모르겠고
어차피 조치방식은 다 동일해보이므로 제일 공신력있는 한국인터넷진흥원 KISA 보호나라에서 올려준 보안 업데이트 글을 기준으로 조치를 진행하려고 한다

https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389

KISA 인터넷 보호나라&KrCERT

나 보기 편하자고 원문을 캡쳐해서 아래에 추가한다.
위에 추가한 URL로 들어가시면 전체를 볼 수 있습니다.

 

반응형

 

~ 간단요약 ~

1. log4j 1.x 버전을 쓰고 있다면 관계가 없으나, 해당 버전은 이미 2015년 이후 기술지원이 종료된 버전이므로 이 취약점 이외에도 타 영향도가 있을 수 있음 => 일단 이번 이슈와 관계없으나 이미 이 버전 자체가 너무 오래된 버전이라 자체로 이슈임 ^0^
2. log4j 2.x 버전을 사용중이면서 JDK 1.8 이상을 사용하고 있다면 log4j 2.15.0 버전을 사용하자
3. log4j 2.x 각 버전별 조치방법은 위 캡쳐화면 참고

위의 내용을 처리하기 위해서 maven project를 기준으로 log4j를 사용중인 프로젝트를 확인하는 방법과 이에 따른 조치방법을 소개하고자 한다.

1. 프로젝트별 pom.xml 확인하기

프로젝트의 library 참조 내역을 관리하는 pom.xml파일에서 직접적으로 dependency로 지정한 경우는 pom.xml 탭에서 log4j 로 검색해보면 어떤 버전을 사용하는지 알 수 있음


만약 직접 참조하지 않는 경우도 있으므로 여튼간에 import 되어서 사용하는지를 확인하기 위해서는
Dependency Hierarchy탭을 보면 오른쪽에 Resolved Dependencies가 존재한다.
거기에서 log4j-core 2.x 버전이 존재하면 클릭해보자.

실제로 얘가 어디서부터 끌고와졌는지를 알 수가 있는데 본인의 경우는 생각치도 못한 부분에서 얘를 간접 참조하고 있어서 log4j가 import 되고 있었다.

이것만 아니었어도 남의 일인데 ^_ㅠ
참고로 logback, slf4j을 사용하고 있어서 무관했는데 있는지도 몰랐던 저 놈 때문에 이 난리를 펴고 있다...

 

2. 프로젝트에서 못찾겠을땐 서버에서 찾기

서버에서 log4j-core 라이브러리를 직접 찾아보자.
linux 서버 기준으로 인스턴스가 올라가있는 경로에서 아래의 명령어를 치면 jar 파일을 찾을 수 있다.

find . -name log4j-core*.jar

루트 경로에서 다 찾으려면 sudo find / -name log4j-core*.jar 넣으면 되겠지만 내가 가진 계정에서 저 명령어가 될리가 없다. 되시는 분들은 저렇게 쓰셔도 됩니다.

여기 있다? 그럼 어디선가 끌어쓰고 있는지 잘 찾아보셔야 합니다...☆

3. log4j import 내역 변경 및 삭제

dependency로 지정해서 실질적으로 사용하고 있는 경우는 안타깝지만 KISA에서 조치 가이드 한대로 진행을 해야한다.

본인의 경우는 2.7 이 import 되어있어서 해당 library에서 취약한 class인 JndiLookup.class 파일을 제외하고 다시 묶어버리는 명령어를 사용하라는 가이드가 있었다.

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

근데 이건 일회성 조치에 지나지않는다.
빌드 후 war파일로 재배포 시 라이브러리를 다시 묶어서 배포해버리면 원래의 라이브러리가 짜잔 나타나므로 원천 해결을 해야한다 ^_ㅠ

• 해당 라이브러리를 사용하지 않는 경우, pom.xml에서 해당 라이브러리를 exclusion 처리해서 제외하자.
• 이걸 쓴다면 log4j 2.15.0로 업그레이드 하거나 (JDK 8 버전 필요) logback, slf4j 등 대체할 방법을 찾자.

평화로울 줄 알았던 12월에 폭탄 떨어짐

그래도 빨리 방향 정해서 조치한 나 자신 잘 했어
그 와중에 블로그각 보고 부지런히 정리한 나 자신도 잘했어~~~


미래의 내가 제일 도움받겠지만 최근 이슈이니 누군가에게도 빠른 퇴근에 도움되는 글이길!




참고1. spring boot 사용하시는 분들을 위해
https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

Log4J2 Vulnerability and Spring Boot

참고2. KISA에서 해당 이슈와 관련해 올린 QnA 형태의 게시글 (PDF 참고)
https://www.boho.or.kr/data/guideView.do?bulletin_writing_sequence=36390&queryString=YnVsbGV0aW5fd3JpdGluZ19zZXF1ZW5jZT0zNjM5MA==

KISA 인터넷 보호나라&KrCERT

#CVE-2021-44228 #log4j취약점