Log4j의 또 다른 취약점 2. Log4j의 문제는 Maven 패키지의 8%에 영향을 미칩니다.

Log4j 2 라이브러리(CVE-2021-45105)에서 또 다른 취약점이 확인되었습니다. 이는 이전 두 문제와 달리 위험하지만 치명적이지는 않은 것으로 분류됩니다. 새로운 문제로 인해 서비스 거부가 발생할 수 있으며 특정 라인을 처리할 때 루프 및 충돌 형태로 나타납니다. 이 취약점은 몇 시간 전에 출시된 Log4j 2.17 릴리스에서 수정되었습니다. 이 문제는 Java 8이 설치된 시스템에서만 나타난다는 사실로 인해 취약점의 위험이 완화됩니다.

취약점은 로그 출력 형식을 결정하기 위해 ${ctx:var}와 같은 상황별 쿼리(컨텍스트 조회)를 사용하는 시스템에 영향을 미칩니다. 4-alpha2.0부터 1까지의 Log2.16.0j 버전에는 제어되지 않는 재귀에 대한 보호 기능이 부족하여 공격자가 대체에 사용된 값을 조작하여 루프를 발생시켜 스택 공간이 고갈되고 충돌이 발생할 수 있었습니다. 특히, "${${::-${::-$${::-j}}}}"와 같은 값을 대체할 때 문제가 발생했습니다.

또한 Blumira의 연구원들은 외부 네트워크 요청을 받아들이지 않는 취약한 Java 애플리케이션을 공격하는 옵션을 제안했다는 점을 주목할 수 있습니다. 예를 들어 Java 애플리케이션 개발자 또는 사용자의 시스템이 이러한 방식으로 공격받을 수 있습니다. 이 방법의 핵심은 사용자 시스템에 로컬 호스트의 네트워크 연결만 허용하거나 RMI 요청(Remote Method Invocation, 포트 1099)을 처리하는 취약한 Java 프로세스가 있는 경우 실행되는 JavaScript 코드를 통해 공격이 수행될 수 있다는 것입니다. 사용자가 브라우저에서 악성 페이지를 열 때. 이러한 공격 중에 Java 애플리케이션의 네트워크 포트에 대한 연결을 설정하기 위해 HTTP 요청과 달리 동일 출처 제한이 적용되지 않는 WebSocket API가 사용됩니다(WebSocket을 사용하여 로컬에서 네트워크 포트를 스캔할 수도 있습니다). 사용 가능한 네트워크 핸들러를 결정하기 위해 호스트).

또한 Log4j 종속성과 관련된 라이브러리의 취약성을 평가하여 Google에서 발표한 결과도 흥미롭습니다. Google에 따르면 이 문제는 Maven Central 저장소에 있는 모든 패키지의 8%에 영향을 미칩니다. 특히 직접적, 간접적 종속성을 통해 Log35863j와 관련된 4개의 Java 패키지가 취약점에 노출되었습니다. 동시에 Log4j는 17%의 경우에만 직접적인 첫 번째 수준 종속성으로 사용되며 영향을 받는 패키지의 83%에서는 Log4j에 의존하는 중간 패키지를 통해 바인딩이 수행됩니다. 두 번째 이상의 중독(21% - 두 번째 수준, 12% - 세 번째, 14% - 네 번째, 26% - 다섯 번째, 6% - 여섯 번째). 취약점을 수정하는 속도는 여전히 부족한 부분이 많습니다. 취약점이 식별된 지 일주일 후 확인된 35863개의 패키지 중 현재까지 문제가 해결된 패키지는 4620개에 불과합니다. 13%.

한편, 미국 사이버 보안 및 인프라 보호국은 연방 기관에 Log4j 취약점의 영향을 받는 정보 시스템을 식별하고 23월 28일까지 문제를 차단하는 업데이트를 설치하도록 요구하는 긴급 명령을 발표했습니다. 23월 XNUMX일까지 조직은 업무 내용을 보고해야 합니다. 문제가 있는 시스템 식별을 단순화하기 위해 취약점이 있는 것으로 확인된 제품 목록이 준비되었습니다(목록에는 XNUMX개가 넘는 응용 프로그램이 포함되어 있습니다).

출처 : opennet.ru