Hacker News

PHP2Shell: Exploitation attempts and remediation trends

PHP2Shell 공격 시도와 대응 동향

Wiz는 PHP2Shell 공개 이후 자사 텔레메트리와 허니팟에서 포착한 공격 시도를 분석했습니다. 메모리 고갈까지 이어진 시도는 있었지만 후속 메모리 유출과 코드 실행은 확인하지 못했고, 인터넷 노출 취약 시스템은 감소했습니다.

에디터 노트

Wiz의 관측 결과는 공개 키트가 메모리를 고갈시켜도 주소 유출과 코드 실행으로 이어지지 않았다는 점을 보여줍니다. 다만 이 자료는 Wiz 텔레메트리와 허니팟에서 포착한 시도이며, 성공 사례를 부정하지 않습니다. 글도 Karimi의 단일 작업자 mod_php 허니팟 사례를 별도로 언급합니다. 댓글에서 반복된 쟁점은 성공 여부보다 재현 가능한 대상 범위입니다. Steal My Bitcoin 사례는 PHP가 실제로 동작하는 환경을 마련한 뒤 성공했지만, 댓글은 개발용 서버와 단일 작업자 구성이 일반적인 운영 환경을 대표하지 않는다고 지적합니다. 따라서 이 사례는 취약점의 악용 가능성을 뒷받침하지만, 공개 키트의 대규모 자동 악용 가능성까지 입증하지는 않습니다. Wiz의 노출 감소 수치도 패치 효과만 따로 측정한 값은 아닙니다.

AI 요약

PHP2Shell 공개 이후 Wiz Research는 실제 환경과 허니팟에서 공격 시도와 대응 동향을 관찰했습니다. 자체 텔레메트리에서는 완결된 공격을 확인하지 못했지만, 다른 연구자의 허니팟에서는 성공 사례가 보고됐습니다. 이 글은 공개 PoC의 공격 단계가 어디까지 진행됐는지, 배포 환경 차이가 왜 공격 성공을 어렵게 하는지 설명합니다.

노출 환경 변화

10월 21일 공개 뒤 며칠 동안 인터넷에 노출된 취약 시스템의 일일 고유 대수가 약 67% 줄었습니다. 취약 시스템 가운데 공식 백포트가 제공되지 않은 PHP 7.3 이하 버전의 비중은 5일 사이 8.3%에서 5.7%로 감소했습니다. 취약 시스템을 하나 이상 노출한 조직 수도 약 47.9% 줄었습니다. Wiz 데이터셋에서는 조직의 65%가 PHP를 사용합니다. 이 수치는 패치와 업그레이드, 시스템 폐기, 인터넷 접근 제한이 함께 반영된 추세입니다. 각 조치가 얼마나 기여했는지는 구분하지 못하며, 스캔 범위와 관측 대상 규모도 결과에 영향을 줍니다.

공개 익스플로잇의 진행 상황

Wiz는 공개된 오픈소스 익스플로잇 키트의 두 변형을 관찰했습니다. 오래된 변형은 1,005개 파트와 약 12MB 패딩을 담은 요청을 보냈지만, 허니팟의 post_max_size 설정인 8MB를 넘겨 PHP가 본문을 처리하지 않았습니다. Roundcube를 겨냥한 뒤이은 시도도 필요한 메모리 고갈에 도달했다는 증거가 없었습니다.

새 변형은 다른 Apache 작업자를 미완성 요청으로 점유해 연속 요청이 같은 자식 프로세스에 도달하도록 시도했습니다. 한 IP는 익스플로잇 단계 전에 미완성 연결 399개와 GET 요청 400개를 열었습니다. 첫 단계 A1은 974개 파트로 메모리를 소진했고, PHP의 메모리 한도 초과 오류와 HTTP 500 응답을 일으켰습니다. 하지만 이 결과만으로 다음 단계에 필요한 오래된 세션 상태가 남았다고 확인할 수는 없습니다.

약 1초 뒤 이어진 B1 단계는 같은 작업자에서 메모리 내용을 세션 쿠키로 유출하고, 그 안에서 힙과 libphp 주소를 얻으려 했습니다. 관찰된 실행에서는 한 건을 제외하고 응답 없이 연결이 닫혔고, 나머지 한 건도 정상적인 32자 세션 쿠키를 돌려줬습니다. 후속 코드 실행 단계는 관찰되지 않았습니다. 공격 키트가 기준으로 삼은 환경은 PHP 8.4.26 Apache 이미지와 128MB 메모리 한도였습니다. Wiz의 Roundcube 허니팟은 PHP 버전은 같았지만 빌드와 확장 모듈이 달랐고 메모리 한도는 64MB였습니다. 이런 차이는 힙 배치와 메모리 재사용에 영향을 줍니다. 네트워크 지연과 요청 시간 제한도 연속 요청을 같은 작업자에 보내는 일을 방해했습니다.

PHP2Shell 이름을 붙인 다른 도구

일부 도구는 취약점 자체가 아닌 세션 포이즈닝과 별도의 로컬 파일 포함(LFI) 취약점을 이용했습니다. 이 도구는 업로드 진행률 기능으로 세션 파일에 PHP 코드를 쓰고, lfi_sink.php를 통해 실행하려 했습니다. 해당 엔드포인트는 PoC 실습 환경이 제공하는 취약한 파일이며 실제 대상에 같은 기능이 없으면 코드 실행으로 이어지지 않습니다. Wiz는 메모리 고갈 탐지는 했지만 코드 실행은 관찰하지 못했습니다.

Wiz는 자체 텔레메트리에서 완결된 PHP2Shell 공격을 보지 못했다고 밝혔습니다. 동시에 Adel Karimi의 공개 자료에서는 익스플로잇 트래픽과 메모리 정보 유출, 코드 실행이 상관관계를 보였다고 설명합니다. 해당 허니팟은 단일 작업자 Apache mod_php 구성으로, 다른 배포 환경에서도 같은 성공률을 보인다는 뜻은 아닙니다. Wiz는 PHP 보안 업데이트 적용이나 다른 방식의 노출 완화를 권고합니다.

Hacker News 반응

  • @xx_ns — Wiz 허니팟에서 실제 공격이 성공하지 않았다는 말이지, 실제 환경 어디에서도 성공하지 않았다는 뜻은 아닙니다. Steal My Bitcoin 과제에서 취약점이 실제로 악용됐고, Trail of Bits의 Dan Guido도 범용 익스플로잇을 갖고 있다고 주장했습니다. 그들의 이력을 보면 현재로서는 의심할 이유가 없습니다.
    • @ForHackernews — 두 가지가 동시에 참일 수 있습니다. 500달러와 인터넷 명성을 원하는 숙련자가 AI 도구의 도움을 받아 취약점을 악용할 수 있습니다. 그렇다고 자동화 봇이 대규모로 쉽게 악용한다는 뜻은 아닙니다.
    • @NitpickLawyer — 제가 이해한 바로는 처음에는 사이트에서 PHP를 실행하지 않아 악용할 수 없었습니다. PHP 서버를 추가한 뒤 약 2시간 만에 문제가 해결됐습니다.
  • @NorwegianDude — Steal My Bitcoin 과제는 흔한 PHP 운영 환경과 거리가 멉니다. 개발용 PHP 서버를 썼고, 그 서버는 인터넷에 공개하지 말라고 명시돼 있습니다. 같은 작업자에 요청을 보내야 한다면 그 자체가 큰 제약입니다. php-fpm의 pm.max_requests가 1이면 요청마다 작업자를 다시 띄우는데, 이 경우 범용 익스플로잇이라는 주장은 어떻게 성립하나요?
  • @idoubtit — 제가 아는 한 최신 PHP 운영 스택에서 취약점이 입증된 사례는 없습니다. Steal My Bitcoin은 장난감 프로젝트였고, 대상은 개발용 내장 PHP 서버 php -S였습니다. mod_php에서 입증된 공격이 있다는 점과 PHP-FPM에서 완결된 공격이 시연되지 않았다는 점을 구분해야 합니다.
  • @makmanalp — 특정 설정, 특히 단일 작업자 mod_php나 실험실 환경에서 성공한 사례가 여럿 있습니다. Dan Guido와 Trail of Bits의 광범위한 익스플로잇 주장은 있지만 세부 정보는 많지 않습니다. 실제 침해 증거는 적고, Unit 42는 이전 주장을 철회했습니다.
  • @CircuitsFit44 — 패치 중인 팀은 인터넷에 노출된 호스트와 컨테이너 가운데 실제로 취약 PHP 버전을 실행하는 대상을 먼저 목록화해야 합니다. 패치만으로 이미 심어진 파일이 사라지지는 않으므로 웹 루트와 업로드 디렉터리의 신규·변경 PHP 파일, 패치 전 접근 로그도 확인할 만합니다.
  • @pizlonator — Fil-C로 PHP를 포팅하는 작업만으로도 충분하며, 자체 테스트에서는 익스플로잇을 서비스 거부(DoS)로 바꿨습니다.
    • @ericol — 어떤 테스트와 PoC를 썼나요? 공개 키트는 기본 설정의 PHP 8.4에서 8번 모두 작업자를 충돌시켰고 셸은 얻지 못했습니다. 메모리 고갈을 일으키는 결과가 이미 DoS라면 Fil-C의 효과인지 구분하기 어렵습니다.

원문: Wiz / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗