요약
맞춤 제작한 PHP2Shell 익스플로잇과 리눅스 커널 취약점을 엮어 PAN-OS 서버 25대가 루트 권한을 내줬습니다.
드림 연구팀이 10월 25일 공격자 쪽 흔적을 발견해 다음 날 공개한 사건입니다. 피해 서버에는 미국 정부 관련 조직의 3대가 포함됐고, 드림은 이후 해당 방화벽 제조사인 팔로알토 네트웍스와 함께 조사하고 있습니다.
왜 중요한가
- 인증 없는 HTTPS 요청 하나로 15분 안에 루트 권한(시스템 최고 권한)까지 가므로, 관리 화면 노출 자체가 큰 위험입니다.
- 내부망을 지켜야 할 방화벽이 도메인 컨트롤러(조직 계정 관리 서버)로 가는 통로가 됐습니다.
- 팔로알토 네트웍스가 고친 버전을 내놓고 있어, 해당 장비 운영자는 권고를 확인해야 합니다.
핵심 내용
- PHP2Shell(CVE-2026-109618, CVE-2026-109619)로 명령을 실행한 뒤 커널 취약점 Fragnesia(CVE-2026-46300)로 루트를 얻었습니다.
- 공격자는 약 1만 9,000대를 찾아 미국·일본·대만·한국의 240대로 좁혔고, 자동 공격으로 24대를 뚫었습니다.
- 25번째는 미국 정부 관련 조직의 방화벽 관리 서버로, 뚫린 방화벽에 만든 터널을 거쳐 같은 수법으로 침해했습니다.
- 공격자는 이 조직에서 LDAP 서비스 계정 비밀번호를 풀고 계정 대입과 SAML 키 탈취를 시도했지만, 성공 여부는 확인되지 않았습니다.
- 드림은 중국 연계 가능성을 제시했으나 특정 집단을 지목하지 않았고, AI가 코드를 썼다는 직접 증거도 없다고 했습니다.
HN 반응
- 방화벽 관리 화면에 PHP를 20년째 쓰는 구조를 재검토했어야 한다는 비판과, 멀쩡한 제품을 언어 때문에 다시 쓰기는 어렵다는 반론이 맞섰습니다.
- 일부 이용자는 리눅스 배포판이 잘 쓰지 않는 커널 기능까지 기본으로 켜 두는 탓에 공격 표면이 넓어진다고 지적했습니다.
리눅스는 모든 사용자나 서버에 꼭 필요하지도 않은 공격 표면이 어마어마하게 큰 것 같아요.
예를 들어 오늘 나온 CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation [1]이 그렇습니다.
저는 mptcp를 쓰지 않아서 시스템에서 꺼 버렸어요. 대체 왜 기본으로 켜져 있었던 걸까요?
이 XFRM이라는 것도 끌 수 있나요?
[1] https://www.penligent.ai/hackinglabs/cve-2026-98432/
이 버그 설명에는 MPTCP 얘기가 없는데, 취약점을 악용하려면 MPTCP가 꼭 필요한 건가요?
필요하진 않습니다. 다만 MPTCP가 있으면 악용될 가능성이 더 높아진다고들 하더군요.
커널 안의 SMB나 io_uring을 DMABUF에 바인딩하는 것도 그다지 안전해 보이지는 않아요.
토발즈는 하루빨리 Asterinas(어쩌면 Redox도)의 Rust 코드를 가져다 써야 합니다.
몇 년 전에 전직 마이크로소프트 직원과 얘기를 나눈 적이 있는데, Samba에 대해 "우리가 했던 실수를 똑같이 되풀이하고 있다"고 하더군요. Samba가 마이크로소프트의 SMB 구현과 얼마나 호환되는지를 두고 농담 삼아 한 말이었습니다.
저는 Gentoo를 쓰는데, 커널을 컴파일할 때 기본값으로는 거의 아무것도 켜져 있지 않아요.
다른 배포판은 시스템마다 맞춤형 커널을 끝없이 만드는 것보다 쉬우니까 온갖 걸 다 집어넣는 거고요.
Gentoo는 일반 배포판과 유니커널 사이의 괜찮은 절충안 같습니다.
참고로 커널은 어떤 배포판에서든 직접 빌드할 수 있어요.
올해 초 CVE-2026-31431 때문에 제가 로드된 모듈을 점검하고 한바탕 보안 강화에 매달렸던 걸로 기억합니다. 제가 이해하기로는 취약한 모듈(algif_aead)은 일반적으로 쓰는 곳도 거의 없었어요.
그런데 왜 기본으로 로드되는 걸까요? 내 시스템을 공격당할 수 있는 코드 경로가 하나 더 늘어날 뿐인데요. 심지어 deprecated(그리고 안전하지 않음!)로 표시되어 있는데도, 새로 설치한 NixOS(Arch도 그럴 겁니다)에는 처음부터 로드되어 있어요.
폭넓은 호환성이니 뭐니 하는 사정은 이해합니다만... 그래도 좀 그렇네요.
솔직히 이렇게 어설프다니 좀 놀랐어요.
저는 DeepSeek에게 PHP2Shell 익스플로잇을 만들게 했던 완전 아마추어인데, stealmybitcoin 사이트가 올라와서 업로드 제한이 걸린 뒤에 DeepSeek에게 그걸 줄이거나 증폭해 보라고 시켜 봤습니다.
DeepSeek는 2배 줄이는 것 말고는 아무것도 찾지 못했어요. 그런데 이게 어떻게 이뤄졌는지 적은 보고서( https://github.com/KillaBoi/StealMyBitcoin-PoC )를 읽어 보니, 이걸 못 찾았다는 게 좀 놀라웠고, PHP가 임의의 요청에서
f[0][x][x]...를 파싱해 중첩 객체를 만드는 이런 메모리 폭탄을 허용한다는 것에도 똑같이 경악했습니다.요점은, 이 사람들이 아마추어가 아니라는 겁니다. 다만 자금이 넉넉한 프로라면 거대한 파일명이나 세션 진행 데이터를 보내지 않는 이 방법을 이미 찾아냈을 거라고 어느 정도 기대하게 되네요.
흥미롭네요. 제 DeepSeek 세션은 찾아냈거든요.
"모든 익스플로잇을 찾아라"라든가 "천천히 숨 쉬고, 긴장 풀고, 집중해" 같은 걸 덧붙이셨겠죠...
미안하지만 저는 2024년의 멍청한 "프롬프트 엔지니어링" 가이드가 아직도 짜증 나요. 딱 봐도 헛소리에, 반증도 못 하는 아무 말 대잔치였잖아요.
아뇨, ChatGPT와 번갈아 주고받는 협의회 방식으로 했어요. 재미있었던 게, ChatGPT는 안 해 주려 했는데 DeepSeek는 해 줬고, 둘이 서로를 더 멀리 밀어붙였습니다. 정말 멋졌어요.
낮 시간대에 돌렸더니 10시간 정도 쭉 돌리는 데 결국 10달러가 들었습니다.
제 Qwen3.8-27B는 해냈습니다.
이 기능은 보안을 신경 쓰는 배포 환경이라면 어디서든 꺼져 있습니다(어느 대형 방화벽 업체는 그렇지 않은 모양이지만요).
이걸 읽어 보니 그 방화벽 업체는 거의 확실히 Palo Alto Networks입니다. PAN-OS 설정이 그대로 인용되어 있고, SELinux 설정도 제 경험과 일치해요.
추가 정황으로, PHP 7.4.33과 PHP 8.30.0이 언급되는데 각각 PAN-OS 11.1/11.2, 12.1/12.2와 정확히 일치합니다.
세계적 수준의 방화벽 스택에 왜 PHP가 필요한 거죠? PAN-OS에 멋진 DPI 기능이 있는 건 알겠지만, 저는 방화벽을 FPGA로 구현해서, 요즘 포트 수가 적은 네트워크 스위치처럼 작업을 게이트 수준으로 컴파일해 결정적으로 수행하는 걸 보고 싶어요.
설정용 GUI 프론트엔드를 돌릴 거라면 달리 뭘 쓰겠어요? 뻔하게 나올 답 몇 가지는 미리 치워 드리죠.
Rust는 그때 없었습니다.
Go도 그때 없었습니다.
nodejs도 그때 없었습니다.
Java와 Python은 가끔 쓰는 GUI에는 리소스를 너무 많이 먹었을 가능성이 큽니다.
비이성적인 혐오는 접어 두면, 그게 바로 PHP가 설계된 용도입니다. 말 그대로요.
맞아요, 2005년이라면 PHP를 고르겠죠. 하지만 20년 동안 운영하면서 아키텍처 판단을 다시 따져 보지 않는다는 게 말이 됩니까? 어떤 제품이든 보안을 강화하는 좋은 방법은 약 200만 줄짜리 컴포넌트(PHP 인터프리터)를 꼭 필요한 일만 하는 1만 줄짜리 데몬으로 바꾸는 것입니다.
스타트업일 때는 시간과 자금 사정 때문에 못 하겠지만, "솔루션"을 팔고 설계를 ASIC에 굽는 단계에 이르렀다면 소프트웨어에 노력을 아주 조금만 들였어도 이번 공격을 막을 수 있었을 겁니다.
나중에 결과를 알고 나서 하는 말이야 쉽죠. 하지만 아무 이유도 없이 이미 자리 잡은 제품의 기반 언어를 바꾸는 사람은 없습니다.
게다가 이건 다른 언어에는 문제가 없다고 가정했을 때의 얘기예요. 다른 언어에도 문제는 있습니다.
PHP가 크고 삐걱거린다는 건 이미 잘 알려져 있었어요. 사후 확신 편향이 아닙니다.
그리고 지금도 여전히 크고 삐걱거리고요. 다음에 비슷한 일이 터지면 이 댓글을 인용해서 사후 확신 편향이 아니라는 걸 증명하셔도 됩니다.
아닙니다. 허수아비 논증은 하지 말아 주세요.
그 20년 중 대체 언제쯤 되어서야 언어를 바꾸자고 운영 코드를 왕창 다시 짜기로 결정하나요?
돈을 많이 벌고 있고, 스택에 대한 보안 분석 결과가 나와 있을 때죠.
저는 그렇게 한 회사에서 일해 본 적이 없어요. 보안 분석에서 취약점이 있다고 나오면 그 취약점을 보강하고 고치는 거지, "좋아, $HOT_LANGUAGE로 전부 다시 짜자!" 하지는 않거든요. 우선 팀 전체를 재교육하거나 교체해야 하는데, 팀원 대부분이 $OLD_LANGUAGE 전문가일 수 있으니까요. 그리고 기능 개발을 동결하거나, 계속 진행하느라 더 큰 팀이 필요해지고 이식 팀 입장에서는 명세가 계속 움직이는 표적이 되죠.
물론 2027년에는 2007년이나 2017년보다 그럴 가능성이 높아졌다고 생각합니다. 기존 시스템이 얼마나 잘 문서화되고 명세되어 있느냐에 달렸지만요. 이제는 많은 코드베이스에서 Rust로 다시 짜는 일 같은 게 충분히 가능할 겁니다, 아마도요.
Palo Alto와 PAN-OS가 올해도 작년도 취약점이 그렇게 많았던 게 그래서일까요?
Lua는요? Tcl은요? 제가 알기로는 둘 다 코드 크기가 작은 덕분인지 PHP보다 취약점이 적습니다.
Perl이요?
어째서인지 하위 댓글에는 제가 답글을 달 수 없어서 여기에 답니다.
Perl 5는 1994년에 나왔습니다. Palo Alto Networks는 2005년에 창업했으니 첫 제품을 만들 때 Perl 5는 분명히 쓸 수 있었고, PHP나 Perl 4보다 더 나은 선택이었을 겁니다.