무슨 일이 있었나요?
아마존 위협 인텔리전스 팀이 AWS 보안 블로그에 흥미로운 분석을 올렸어요. PHP2Shell이라는 이름이 붙은 취약점이 세상에 공개되기 전인 10월 17일에 이미 실제 공격에 쓰이고 있었다는 정황을 자체 허니팟 네트워크인 MadPot에서 잡아냈다는 내용이에요.
보통 취약점은 ‘발견 → 개발사에 비공개 제보 → 패치 → 공개’ 순서로 흘러가요. 그런데 공개 전에 이미 공격이 돌고 있었다면, 누군가 이 구멍을 먼저 알고 조용히 쓰고 있었다는 뜻이에요. 이런 걸 제로데이(zero-day) 공격이라고 불러요. 막는 쪽에게 주어진 대비 시간이 ‘0일’이었다는 뜻이죠.
이름으로 짐작해보면, PHP 환경에서 원격으로 셸을 얻는 데까지 이어지는 유형으로 보여요. 셸을 얻는다는 건 서버에 마음대로 명령을 내릴 수 있게 된다는 뜻이고요. 다만 영향받는 버전이나 패치 여부 같은 구체적인 정보는 원문과 공식 보안 권고에서 꼭 직접 확인하세요. 여기서는 이 일이 왜 중요한지, 우리가 뭘 해야 하는지에 집중해볼게요.
MadPot은 어떻게 공개 전 공격을 잡아냈을까
허니팟(honeypot)이 뭐냐면, 말 그대로 ‘꿀단지’예요. 공격자가 좋아할 만한 허술한 서버인 척하는 미끼를 인터넷에 던져두고, 누가 와서 무슨 짓을 하는지 몰래 기록하는 시스템이에요. 진짜 서비스는 하나도 없고 오직 관찰하려고 만든 거죠.
MadPot은 아마존이 자기 인프라 곳곳에 대규모로 깔아둔 허니팟 네트워크예요. 워낙 크다 보니 인터넷을 훑고 다니는 스캐너나 공격 트래픽이 거의 한 번씩은 걸려들어요. 그래서 평소에 못 보던 형태의 PHP 요청이 여러 곳에서 한꺼번에 들어오기 시작하면 이상 신호로 잡을 수 있어요. 나중에 취약점이 공개된 뒤 로그를 되짚어서 “10월 17일부터 이미 이 공격이 들어오고 있었네” 하고 시간 순서를 다시 맞춰볼 수도 있고요.
아마존은 2025년에도 MadPot 데이터를 근거로 시스코와 시트릭스 제품의 취약점이 공개 전부터 악용되고 있었다는 분석을 내놓은 적이 있어요. 대형 클라우드 회사가 일종의 인터넷 조기경보 레이더 역할을 하고 있는 셈이에요.
PHP 취약점이 유독 무서운 이유
PHP는 ‘한물간 언어’라는 농담을 듣지만, 아직도 전 세계 웹사이트 중 상당수가 PHP로 돌아가요. 워드프레스나 그누보드 같은 CMS가 대표적이고, 한국에서는 오래된 쇼핑몰 솔루션이나 기관 홈페이지에서도 흔하게 보이죠.
PHP에서 원격 코드 실행 취약점이 터지면 피해가 커지는 이유는 두 가지예요. 설치된 곳이 엄청나게 많고, 업데이트 없이 방치된 서버도 많아요. 2024년에 나온 PHP-CGI 인자 주입 취약점(CVE-2024-4577)이 좋은 예예요. 윈도우의 특정 언어 설정에서 문자를 변환하는 방식에 허점이 있었고, 이걸 이용하면 필터를 피해서 코드를 실행할 수 있었어요. 공개되고 며칠 만에 랜섬웨어 조직과 봇넷이 대량으로 스캔을 시작했고, 한참 뒤까지도 패치 안 된 서버들이 계속 당했어요.
이런 공격은 보통 이런 순서로 진행돼요.
1. 인터넷 전체를 스캔해서 취약한 PHP 서버를 찾는다
2. 조작된 요청 하나로 서버에서 명령을 실행시킨다
3. 웹셸을 심어서 언제든 다시 들어올 수 있게 한다. 웹셸은 브라우저로 서버를 원격 조종할 수 있게 해주는 작은 PHP 파일이에요
4. 채굴기, 봇넷 에이전트, 랜섬웨어 같은 걸 설치한다
PHP2Shell이라는 이름은 2~3단계, 그러니까 ‘PHP 요청 하나로 셸까지’를 한마디로 줄인 표현으로 읽혀요.
업계 맥락: 공개와 악용 사이의 시간이 사라지고 있다
예전에는 취약점이 공개되고 나서 대규모 공격이 시작되기까지 몇 주쯤 여유가 있었어요. 요즘은 그 간격이 며칠, 심하면 몇 시간으로 줄었어요. 이번처럼 공개 전부터 공격이 시작되는 경우도 늘고 있고요. 패치 전후 코드를 비교해서 취약점을 거꾸로 찾아내는 기법이나 AI 분석 도구가 발전하면서 공격자가 빨라진 영향도 커요.
그래서 ‘패치 나오면 적용하자’만으로는 부족하다는 목소리가 커지고 있어요. WAF(웹 애플리케이션 방화벽)로 공격 패턴을 미리 막아두는 가상 패치, 이상 트래픽 탐지, 최소 권한 설정처럼 패치 전에도 피해를 줄일 수 있는 다층 방어를 기본으로 갖춰야 한다는 거죠.
한국 개발자에게 주는 시사점
- PHP 자산 목록부터 만들기: 운영 중인 서비스뿐 아니라 잊고 있던 관리자 페이지, 테스트 서버, 지난 이벤트 페이지까지 다 포함해서요. 사고는 대부분 ‘있는 줄도 몰랐던 서버’에서 터지거든요.
- 버전과 지원 기간 확인:
php -v로 버전을 확인해보세요. 보안 지원이 끝난 버전이라면 업그레이드 일정부터 잡으세요. - 10월 중순 이후 웹 로그 점검: 평소와 다른 쿼리 스트링이나 처음 보는 PHP 파일에 접근한 기록이 있는지 보세요. 웹 서버 프로세스가 셸 명령을 실행한 흔적이 있는지도 확인해보세요.
- 웹 서버 권한 최소화: PHP 프로세스가 업로드 폴더에 파일을 쓰고 그 파일을 실행까지 할 수 있다면, 웹셸에게 문을 활짝 열어둔 거나 마찬가지예요.
- 공식 권고 구독: PHP 보안 공지, 쓰고 있는 배포판의 보안 알림, KISA 보호나라 공지를 받아보면 대응 속도가 확 달라져요.
마무리
한줄 정리: 취약점이 ‘공개된 날’이 더 이상 공격이 ‘시작된 날’이 아니에요. 패치를 기다리는 동안에도 버틸 수 있는 구조를 만들어둬야 해요.
여러분 회사에는 누가 관리하는지 애매한 오래된 PHP 서버가 몇 대나 있나요? 제로데이에 대비해서 실제로 운영 중인 방어 장치가 있다면 경험을 나눠주세요.
🔗 출처: Hacker News