Java 라이브러리 Log4j의 악명 높은 취약점에 대한 긴급 패치는 완벽하지 않습니다. Apache Software Foundation은 취약점을 완전히 수정하는 새 버전을 출시합니다.
널리 사용되는 Java용 라이브러리의 취약점이 전 세계 IT 환경을 뒤흔들고 있습니다. 라이브러리는 대부분의 기업 환경에 존재하는 것으로 추정됩니다.
Log4j는 주로 로깅에 사용됩니다. 애플리케이션의 이벤트는 메모로 등록할 수 있습니다. 로그인 시도 후 로그인 세부 정보의 출력물을 생각해 보십시오. 또는 Java 웹 응용 프로그램의 경우 사용자가 연결하려는 브라우저의 이름입니다.
후자의 예가 일반적입니다. 두 경우 모두 외부 사용자가 Log4j가 출력하는 로그에 영향을 줍니다. 그 영향력을 남용할 수 있습니다. 4년 13월 2013일부터 5년 2021월 XNUMX일 사이의 모든 LogXNUMXj 버전의 로그는 로컬 장치의 원격 서버에서 코드를 실행하도록 Java 애플리케이션에 지시할 수 있습니다.
2013년부터 Log4j는 API(JNDI 또는 Java Naming and Directory Interface)를 처리하고 있습니다. JNDI를 추가하면 Java 애플리케이션이 로컬 장치의 원격 서버에서 코드를 실행할 수 있습니다. 프로그래머는 응용 프로그램의 원격 서버에 대한 세부 정보를 한 줄 추가하여 지시합니다.
문제는 프로그래머만이 규칙을 응용 프로그램에 추가할 수 있다는 것이 아닙니다. Log4j가 로그인 시도의 사용자 이름을 기록한다고 가정합니다. 누군가 사용자 이름 필드에 앞서 언급한 줄을 입력하면 Log4j가 해당 줄을 실행하고 Java 응용 프로그램이 명령을 해석하여 지정된 서버에서 코드를 실행합니다. Log4j가 HTTPS 요청을 기록하는 경우에도 마찬가지입니다. 브라우저 이름을 줄로 변경하면 Log4j가 줄을 실행하여 원하는 대로 코드를 실행하도록 간접적으로 지시합니다.
긴급 패치도 안전하지 않을 수 있습니다
9월 4일에 취약점이 대규모로 밝혀졌습니다. Log2.15j의 개발자인 Apache Software Foundation은 취약점을 수정하기 위해 긴급 패치(2.15)를 출시했습니다. 그 이후로 소프트웨어 공급업체는 버전 XNUMX를 처리하고 조직에 패치를 제공하는 것이 최우선 과제였습니다.
그러나 보안 조직 LunaSec은 패치가 완전히 방수되지 않는다고 말합니다. 설정을 조정하고 기록된 JNDI 명령을 실행하는 것은 여전히 가능합니다.
참고: 2.15의 수정되지 않은 변형이 실제로 안전하도록 관련 설정을 수동으로 조정해야 합니다. 그럼에도 불구하고 Luna Sec은 공급업체와 조직이 Log4j 2.16으로 업데이트할 것을 권장합니다. 2.16은 LunaSec에 대한 응답으로 Apache Software Foundation에서 게시했습니다. 새 버전은 취약한 설정을 완전히 제거하여 남용 조건을 만드는 것이 불가능합니다.