대회 제작자는 실험실 밖의 환경을 재현한 평범한 구성이라고 했지만, 실제로는 일반적인 PHP 운영 환경과 전혀 다른 구성이었음. fpm이나 mod_php 대신 PHP 내장 개발 서버를 띄우고 nginx가 요청을 프록시하도록 구성함.
PHP 개발 서버 문서 맨 위부터 애플리케이션 개발과 통제된 환경의 테스트·시연용이며, 완전한 웹 서버가 아니고 공개 네트워크에서 사용하면 안 된다고 경고함. 이런 용도가 아닌 느린 개발 서버를 썼으니 사이트가 계속 다운된 것도 설명되며, 실제 운영 구성이라면 초당 요청 처리량이 몇 자릿수는 늘어날 것임.
실제 PHP 사이트와 너무 달라 이번 도전은 별 의미가 없다고 봄. 현실적인 구성이었다면 일반 사이트에서 원격 코드 실행(RCE)을 얻기가 얼마나 어려운지 알아보는 데 훨씬 흥미롭고 유용했을 것임.
흥미롭게도 어제는 PHP가 전혀 없는 완전한 정적 웹사이트라며 불평하는 사람들도 있었음.
HITCON CTF에 현실적인 php2shell 문제가 있음. 확실하지는 않지만 지금까지 아무도 풀지 못한 것으로 알고 있음.
이 구성 때문에 서비스 거부가 발생해 경쟁 기회가 줄었다는 뜻인가, 아니면 침투가 더 쉬워졌다는 뜻인가? 얼핏 보기에는 취약점 입증 자체에는 영향이 없어 보임.
PHP-fpm과 nginx 환경에서도 php2shell이 작동하나? 로컬에서 이 개념 증명(PoC)을 제대로 재현하지 못하겠음.
이론적으로는 가능함. 다만 흔히 쓰는 nginx 구성과 보안 강화 설정 중 상당수가 악용을 매우 어렵게 만들며, 클라이언트의 요청을 같은 서버에 고정하지 않는 분산 구조도 마찬가지임.
아직 발견되지 않은 다른 악용 경로가 있을 수는 있음. 여기서 사용한 PoC는 패치 당일 공개된 악용 경로를 사용하되 mod_php는 쓰지 않음.
이번 도전으로 그렇게 쉽게 악용할 수 있는 취약점은 아니라는 사실은 입증했다고 봄. 당시 분위기와는 달리, 초기 며칠 동안 패치하지 않은 수많은 서버가 지금 전부 봇넷에 편입된 것은 아닐 가능성이 큼.
기존 PoC를 수정해야 할 만큼 비표준적인 구성이었는데도 약 2시간 만에 장악됨. 아직도 이 위험을 부정하는 게 황당함.
php2shell 소식이 나왔을 때 아파서 PHP를 쓰는 개인 사이트 두 곳을 약 48시간 동안 패치하지 못함. 열이 내린 뒤 패치했고 해킹은 당하지 않았음. 그냥 운이 좋았던 것이니 실제 악용 난이도를 추론해서는 안 되는 걸까? 아마 그럴 것임.
오히려 정반대로 봄. 비표준 구성인데도 첫 악용까지 겨우 19시간이 걸렸고, 이제는 PoC만 조정하면 해당 구성을 손쉽게 공격할 수 있음. 지금쯤 공격자들은 일반적인 구성 대부분을 악용할 도구를 갖췄을 가능성이 큼.
cloudlandsdev가 php-version.php를 공개하자마자 Kimi K3.1 Pro로 방법을 알아냈고, 로컬 Docker 실험 환경에서도 똑같이 공격이 작동함. 하지만 대회 약관이 자원 고갈을 금지해 거기서 멈춤.
Kimi에 PoC를 보여주니 “우승한 공격 과정은 의도적으로 요청별 메모리 고갈을 사용했으므로, 주최자가 우승을 인정했더라도 자원 고갈 금지 규정의 문구에는 어긋나는 것으로 보인다”라고 답함.
뭘 하고 있는지 제대로 이해하지 못하는 것 아닌가?
에이전트마다 이 지점에서 막혔음. 그런데 해당 취약점 중 하나는 그 자체가 메모리 고갈임.