관리자 계정 없이도 서버를 잡는다, WordPress 코어를 노린 wp2shell 결함 읽기

이미지 출처: The Hacker News

전 세계 웹사이트 열 곳 중 넷 이상이 WordPress로 돌아간다는 통계는 이제 새롭지도 않음. 그런데 그 '넷 중 하나'가 플러그인이나 테마도 아니고 코어(core) 자체에서 인증 없이 원격 코드 실행을 허용한다면 이야기가 완전히 달라짐. 이번에 보고된 wp2shell 결함이 바로 그 자리를 건드렸음. 남의 계정을 훔칠 필요도, 관리자 페이지에 로그인할 필요도 없이, 그냥 열려 있는 요청 경로만으로 서버 안에서 코드가 돌아가는 구조라는 점이 핵심임.

핵심 요약

• wp2shell은 WordPress 코어를 노린 인증 불필요(unauthenticated) 원격 코드 실행 결함으로, 로그인 없이도 서버 측 코드 실행이 가능한 유형임.
• 공격 성공 시 웹셸 업로드·계정 탈취·측면 이동으로 번지므로, 개별 사이트가 아니라 호스팅 전체가 위험해짐.
• 방어는 즉시 패치가 1순위, 그다음이 WAF 규칙·파일 무결성 모니터링·이상 요청 로그 탐지의 다층 조합임.

무엇이 문제인가

공격을 개념 수준에서만 정리하면 이런 흐름임. 사용자가 보낸 값이 서버에서 충분히 검증되지 않은 채 실행 경로로 흘러 들어가고, 그 과정에서 인증 검사가 우회되거나 애초에 인증이 필요 없는 엔드포인트가 악용됨. 코어 결함이 무서운 이유는 특정 플러그인을 깔았느냐와 무관하게, 기본 설치 상태만으로도 노출 면적이 생긴다는 데 있음. 즉 "나는 이상한 플러그인 안 썼는데?"가 방어가 되지 못하는 상황임.

왜 규모가 위협인가

단일 사이트 하나가 뚫리는 걸로 끝나지 않는다는 게 이 부류의 특징임. 공유 호스팅이나 다중 사이트(멀티사이트) 환경에서는 한 곳에서 얻은 실행 권한이 같은 서버의 다른 계정으로 번지기 쉬움. 공격자는 보통 이렇게 움직임.

• 취약 요청으로 서버 측 코드 실행 확보
• 은닉형 웹셸이나 백도어 파일을 조용히 심음
• 관리자 계정 생성·크론 작업 등록으로 지속성(persistence) 확보
• 같은 호스트의 다른 사이트로 측면 이동

그래서 "우리 사이트는 트래픽도 적은데 노리겠어?"라는 생각이 위험함. 자동화 스캐너는 규모와 무관하게 취약 버전을 통째로 훑기 때문임.

어떻게 탐지하는가

패치 전이든 후든, 방어자는 흔적을 볼 줄 알아야 함. 개인적으로는 로그를 먼저 보라고 추천함. 눈여겨볼 지점은 다음과 같음.

• 평소에 호출되지 않던 엔드포인트로 몰리는 비정상 POST 요청과 반복적인 4xx/5xx 패턴
• wp-content/uploads나 테마 디렉터리에 갑자기 생긴 PHP 파일, 특히 무작위 이름의 짧은 스크립트
• 내가 만들지 않은 관리자 계정, 알 수 없는 예약 작업(WP-Cron·시스템 크론)
• 웹서버 프로세스가 외부로 내는 아웃바운드 연결(콜백·다운로더 징후)

파일 무결성 모니터링(FIM)을 걸어 두면 코어·플러그인 파일이 조용히 바뀌는 순간을 잡아낼 수 있음. 이미 감염이 의심되면 서버에서 직접 신뢰 가능한 원본과 해시를 비교하는 편이 확실함.

어떻게 완화하는가

순서가 중요함. 화려한 대응보다 기본기가 먼저임.

• 즉시 패치: 취약 버전이라면 안전한 버전으로 코어를 올리는 게 1순위. 자동 업데이트가 켜져 있는지도 이번 기회에 점검하기.
• 가상 패치(WAF): 당장 올릴 수 없는 사정이면 취약 요청 패턴을 막는 규칙으로 시간을 벎. 어디까지나 임시 방편임.
• 권한 최소화: 웹서버 실행 계정이 코어 파일을 마음대로 못 쓰게 파일 권한을 조이고, 업로드 디렉터리의 PHP 실행을 막기.
• 노출 축소: 안 쓰는 REST 엔드포인트·XML-RPC를 정리하고, 관리 화면 접근을 IP나 2단계 인증으로 감싸기.
• 백업 검증: 복구가 필요할 때를 대비해 감염 이전 시점의 깨끗한 백업이 실제로 복원되는지 미리 확인해 두기.

마무리

코어 결함은 "설마 내 사이트가"라는 방심을 먹고 자람. 하다 보니 느끼는 건데, 결국 이기는 방어는 대단한 장비가 아니라 패치 속도 + 로그를 읽는 습관 + 최소 권한이라는 지루한 삼종 세트인 것 같음. 오늘 당장 내 WordPress 버전부터 확인하고, uploads 폴더에 낯선 PHP 파일이 없는지 한 번만 훑어보길 권함. 여러분은 어떤 방식으로 코어 무결성을 챙기고 있는지, 좋은 팁 있으면 댓글로 같이 나눠 보아요.