우선 *KISA에서 발표한 Log4j 사태에 대한 가이드라인 링크를 아래 첨부한다. 해당 내용은 Log4j의 새로운 보안 취약점이 발견되거나 새로운 대응방안이 계속하여 업데이트 될 수 있으므로, Log4j 사태가 안정화될때까지 주기적으로 KISA 홈페이지를 접속하여 가이드라인을 따라야 할 것이다.
또한 라이브러리의 업데이트 및 서버 Configuration을 변경할 경우, 예기치 못한 에러나 버그가 발생할 수 있으니,
반드시 서버 백업을 우선 진행한 후 다음에 나오는 대응방안을 진행하여야 한다.
* KISA : 한국인터넷진흥원. 대한민국의 인터넷 진흥, 인터넷 정보보호 및 그에 대한 국제 협력 업무를 수행하는 과학기술정보통신부 산하 위탁집행형 준정부기관.
https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389
우선 Log4j의 버전별 대응방안을 알아보기 전에, 본인이 관리하는 서버에 Log4j 라이브러리가 설치되어 있는지, 어떤 버전인지부터 확인해보자!
- Linux
sudo dpkg -l | grep log4j
sudo find / -name 'log4j*'
- Windows
# option s : 옵션은 현재 디렉토리와 하위 디렉토리까지 모두 dir /s log4j*.jar
현재(2021.12.21)까지 공개된 Log4j의 취약점으로는 총 3가지로 다음과 같다.
2022.01.18. 아파치에서 Log4j의 추가 취약점을 공개했다. 이는 다음 단락에서 제시한다.
- Apache Log4j 2에서 발생하는 원격코드 실행 취약점(CVE-2021-44228)
- 버전 2.0-beta9 ~ 2.14.1 (Log4j 2.3.1, 2.12.2, 2.12.3 제외) 은 반드시 업데이트 필요.
- Java 8 : Log4j 2.17.0 으로 업데이트 / Java 7 : Log4j 2.12.3 으로 업데이트
Java 6 : Log4j 2.3.1 으로 업데이트
※ log4j-core-*.jar 파일 없이 log4j-api-*.jar 파일만 사용하는 경우 위 취약점의 영향을 받지 않음.
- 신규 업데이트가 불가능할 경우 -> 'JndiLoockup' 클래스를 경로에서 제거한다.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Apache Log4j 2에서 발생하는 원격코드 실행 취약점(CVE-2021-45046)
- 버전 2.0-beta9 ~ 2.15.0 은 (Log4j 2.12.2 제외) 반드시 업데이트 필요.
- CVE-2021-44228 대응방안과 동일. - Apache Log4j 1.x에서 발생하는 원격코드 실행 취약점(CVE-2021-4104)
- CVE-2021-44228 대응방안의 업데이트 방안을 따르는 것을 권고.
- JMSAppender 사용 확인이 되면 코드 수정 또는 삭제.
=> 리눅스에서 JMSAppender 사용여부는 config 파일에서 확인해야 하는데, 보편적으로 아래의 파일 패턴으로 설정파일이 생성되므로, 아래 명령어를 입력하여 설정파일에 들어가 JMSAppender 설정 부분을 모두 주석처리하여야 한다.
find / -name log4j.properties # 'log4j.properties'라는 이름의 파일 찾기. find / -name logger.xml # 'logger.xml'이라는 파일 찾기. find / -name logging.properties # 'logging.properties'라는 파일 찾기.
또한 리눅스 서버 내의 log4j 파일 위치에서의 JMSAppender.class 파일도 삭제하는 것이 안전하다.
find / -name *log4j*.jar # 'log4j'라는 문자열이 들어간 jar파일 모두 찾기. zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class -- 보통 위 디렉토리에 있을 것이므로, 해당 디렉토리의 JMSAppender.class 파일 삭제
- log4j 1.x 버전 사용자의 경우 추가적인 업그레이드 지원 중지로 인해 다른 보안위협에 노출될 가능성이 매우 높으므로, 최신버전(2.x) 으로 업데이트 적용을 권고한다.
이 단락은 2022.01.18. 아파치에서 추가적으로 공개한 3가지 취약점에 관한 내용이다. (2022.01.24. 수정)
- Apache log4j JMSSink 역직렬화 취약점(CVE-2022-23302)
- Log4j 1.x 버전에서, 기본값이 아닌 JMSSink를 사용하도록 특별히 Configuration된 경우에만 해당 취약점의 영향 받음.
- 취약점 내용)
공격자가 Log4j 설정에 대해 수정 권한을 갖고 있거나, 구성이 공격자가 엑세스할 수 있는 LDAP 서비스를 참조하는 경우, 모든 Log4j 1.x 버전 중 JMSSink가 데이터 역직렬화에 취약함.
공격자는 TopicConnectionFactoryBindingName 설정을 전달하여 JMSSink로 하여금 JNDI request를 실행하도록 하 수 있으며, 이는 CVE-2021-4104 와 유사한 방식으로 동작함.
- 해결방안)
Log4j 2.x 버전 으로 업데이트 - Apache log4j JDBCAppender SQL인젝션 취약점(CVE-2022-23305)
- Log4j 1.x 버전에서, 기본값이 아닌 JDBCAppender를 사용하도록 특별히 Configuration된 경우에만 해당 취약점의 영향 받음.
- 취약점 내용)
Log4j 1.2.x 중의 JDBCAppender는 SQL문을 매개변수로 허용하며, PatternLayout의 message converter는 해당 입력값에 대한 검증을 진행하지 않아 SQL 인젝션 취약점이 유발됨.
공격자가 해당 취약점을 악용하면, 응용 프로그램의 입력 필드 또는 헤더에 조작된 문자열을 입력하여 의도치 않은 SQL 쿼리를 실행할 수 있음.
- 해결방안)
Log4j 2.x 버전 으로 업데이트 - Apache log4j Chainsaw 역직렬화 코드실행 취약점(CVE-2022-23307)
- Log4j 1.x버전 및 Chainsaw 2.1.0 미만 버전이 영향을 받음.
- 취약점 내용)
Chainsaw v2는 Log4j의 XMLLayout 형식의 로그 파일을 읽을 수 있는 GUI 기반의 로그 뷰어인데, 해당 취약점은 Chainsaw에 존재하며, 임의코드실행을 허용하는 역직렬화 취약점으로, 이전에 CVE-2021-9493으로 명명되었음.
- 해결방안)
Log4j 2.x 버전 혹은 Chainsaw 2.1.0 버전으로 업데이트
참고) https://blog.alyac.co.kr/4440
아래 깃헙 주소를 통해 들어가면 웬만한 벤더들의 대응방안이 모두 정리되어 있다.
본 포스팅에서는 상용 WAS를 사용한다면 주로 사용하는 제품들에 한해서 살펴보기로 하자.
※ 본 포스팅의 대응방안 내용이 시점에 따라 변경될 수 있으므로, 벤더별로 log4j에 대한 가이드라인의 링크에 접속하여 반드시 최신화된 내용인지 확인해보길 바란다.
* 제조사별 현황 - 깃헙
https://github.com/NCSC-NL/log4shell/tree/main/software
- Apache - Tomcat
https://tomcat.apache.org/security-10.html
Tomcat의 10.x 버전의 경우, log4j에 대한 종속성이 존재하지 않는다. 따라서 10.x 버전을 사용한다면 log4j로 인한 취약성에 대해서는 안심해도 된다.
그러나, Tomcat에 배포된 웹 어플리케이션이 log4j에 대한 종속성을 가질 수 있으므로, 이럴 경우에는 Application 공급 업체에 지원을 요청해야 한다.
- 버전 2.10 이상)
시스템 속성 log4j2.formatMsgNoLookups 또는 환경 변수 LOG4J_FORMAT_MSG_NO_LOOKUPS 를 true 로 설정.
- 버전 2.7 ~ 2.14.1 의 경우)
모든 PatternLayout 패턴을 수정하여 메시지 변환기를 %m이 아닌 %m{nolookups}로 지정.
- 버전 2.0-beta9 ~ 2.10.0 의 경우)
classpath에서 JndiLookup 클래스를 제거.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Oracle - WebLogic
https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
- 버전 2.0 ~ 2.15.0 의 경우 모두 업데이트 및 설정 변경 대상이다.
자세한 사항은 위 링크의 'Patch Availability Document'에 'My Oracle Support Document'로 접속하면 된다.
- IBM - WebSphere
https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/
- 버전 Liberty 17.0.0.3 ~ 21.0.0.12 (zosConnect-1.0 or zosConnect-1.2 사용)
Interim Fix에 필요한 최소한의 Fix Pack으로 업그레이드 한 후, PH 42762 Interim Fix 적용.
또는 Fix Pack 22.0.0.1 또는 그 이후 버전 적용.
- 버전 9.0.0.0 ~ 9.0.5.10)
Interim Fix에 필요한 최소한의 Fix Pack으로 업그레이드 한 후, PH 42762 Interim Fix 적용
또는 Fix Pack 9.0.5.11 또는 그 이후 버전 적용.
- 버전 8.5.0.0 ~ 8.5.5.20)
Interim Fix에 필요한 최소한의 Fix Pack으로 업그레이드 한 후, PH 42762 Interim Fix 적용
또는 Fix Pack 8.5.5.21 또는 그 이후 버전 적용.
- 버전 8.0.0.0 ~ 8.0.0.15)
8.0.0.15 버전으로 업그레이드 후 PH 42762 Interim Fix 적용.
- 버전 7.0.0.0 ~ 7.0.0.45)
7.0.0.45로 업그레이드 후 PH 42762 Interim Fix 적용.
WebSphere 버전별로 위 과정을 진행했다면 아래 다음 단계를 진행한다.
- 만약 UDDI Registry Application이 WebSphere AS에서 구동되고 있다면, PH 42762 Interim Fix 적용 후, UDDI Registry Application을 재배포한다.
- 위 Interim Fix로 "kc.war"가 installableApps 및 디렉토리에서 제거되는데, 만약 여전히 남아있다면 Admin Console 또는 wsadmin을 이용하여 직접 제거해주어야 한다.
- "kc.war" 존재 여부 확인법
Linux)
Windows)grep -r com.ibm.kc.ui.UIRootServlet config/ | grep -v isclite
※ WebSphere AS V7.0 및 V8.0은 더이상 패치를 지원하지 않으니, 업그레이드가 필수적이다.findstr /s com.ibm.kc.ui.UIRootServlet config\* | findstr /v isclite
만약 PH 42762 Interim Fix가 즉각적으로 적용이 되지 않는다면, 아래의 임시 대응책을 적용해야 한다.
(단순히 상황의 심각성 및 복잡성, 계속 바뀌는 특성 때문에 임시 대응책을 사용하는 것은 권장되지 않는다.)
- WebSphere AS V9.0에서만 적용되는 방법
Admin Console로 <WAS_HOME>/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar 를 모두 제거한 후, WAS를 재부팅한다.
그리고 <WAS_HOME>/installableApps/kc.war 또한 제거한다. - V9.0을 제외한 모든 WebSphere 버전에서 적용되는 방법
- UDDI Registry Application 사용자 : <WAS_HOME>/installableApps/uddi.ear 에 있는 log4j*.jar를 제거하고, 설치 또는 배포되어 있는 UDDI Registry Application을 모두 업데이트,재배포 한다.
- UDDI Registry Application 미사용자 : <WAS_HOME>/installableApps/uddi.ear 를 제거한다. - zosConnect-1.0 및 zosConnect-1.2를 구동하는 z/OS의 WebSphere Liberty 유저의 경우
서버 configuration에 'fileSystemloggerInterceptor' 속성이 있다면 이를 제거한다.
- OZ - Server, Scheduler
http://www.oztn.net/kb/board-read.do?boardId=notice&boardNo=163938634984792&command=READ&page=1&categoryId=-1
- TIPCO - Rendezvous
https://www.tibco.com/support/notices/2021/12/apache-log4j-vulnerability-update
Rendezvous 버전 8.5.1 이상에서는 log4j 취약점이 해결되었다.
- Oracle - SQL Developer
https://oracle-base.com/blog/2021/12/19/log4j-vulnerabilities-my-random-thoughts/
오라클의 SQL Developer는 오라클 DB에서 SQL로 작업하기 위한 IDE로, Client Tool에 해당한다. 취약한 버전의 Log4j를 사용하기는 하나, 클라이언트 툴로서 특정 작업(AHF) 등을 별도로 하지 않는 이상 HTTP Request를 처리할 수 없어 Log4j에 대한 취약성이 낮으므로, 업데이트를 함으로써 생길 수 있는 시스템 안정성 문제를 잘 고려하여 업데이트를 진행해야 할 것이다.
- SAS(Statistical Analysis System) (2022.02.15. 수정)
https://support.sas.com/content/support/en/security-bulletins/remote-code-execution-vulnerability-cve-2021-44228.html#e0c256e8-de86-4198-aabb-7a52f748f515
- SAS 9.4의 플랫폼레벨 M0~M5의 경우, 별도의 조치사항 필요 없음.
- 플랫폼레벨 M6, M7의 경우, 아직 Log4j 2.17.1 버전을 사용할 수 있는 업데이트가 나오지 않음.
- Loguccino(취약점 'CVE-2021-44228', 'CVE-2021-45046'에 해당하는 log4j의 jar 파일을 찾고, JndiLookup 클래스를 제거하여 취약점 없이 JAR를 리패키징하는 툴) 이용 권장.
'Security' 카테고리의 다른 글
[보안] SSH Protocol의 암호화, Hashing 알고리즘 (feat. Linux OpenSSH) (0) | 2023.09.18 |
---|---|
[보안] Log4j 보안 취약점 동작원리 - (1) (0) | 2021.12.17 |
최근댓글