워드프레스를 감사하고 있나요? 플러그인부터 시작하세요

요약

대부분의 WordPress 보안 감사는 거꾸로 되어 있습니다. 코어 업데이트와 스캐너 보고서를 강조하는 동안 실제로 피해를 입히는 취약점은 플러그인에 있습니다. SANS 백서에 따르면 생태계 취약점의 96% 이상이 타사 플러그인에서 발생하며, 약 43%는 인증이 필요 없습니다. 이 글은 모든 사람이 잘못된 레이어를 스캔하고 있기 때문에 해킹당한 사이트의 이야기를 통해 소규모 사내 마케팅 팀을 위한 플러그인 우선 감사를 안내합니다. 모든 플러그인을 목록화하고 분류하고, 인증되지 않은 공격 표면을 테스트하고, 사용자와 로그를 수동으로 검토하고, 결과를 기술에 능숙하지 않은 상사가 이해할 수 있는 위험 언어로 번역하는 방법을 배우게 됩니다. 그 결과는 체크리스트 실행이 아닌 분기별 트리아주 의식입니다.

대부분의 WordPress 보안 감사는 쇼에 불과합니다. 오후 내내 코어를 업데이트하고 관리자 비밀번호를 변경하고 "심각한 문제 없음"이라고 자랑스럽게 보고하는 플러그인 스캐너를 실행합니다. 한편, 파일 업로드를 허용하고 3년 전에 마지막으로 업데이트된 플러그인은 업로드 디렉터리에 조용히 자리 잡고 초대받지 않은 누군가를 기다립니다.

이 수치는 이를 뒷받침합니다. WordPress 플러그인 스캔에 관한 SANS 백서에 따르면 WordPress 생태계 취약점의 96% 이상이 타사 플러그인에서 발생하며, 테마는 4%, 코어는 1% 미만입니다. 그 결함의 약 43%는 인증 없이 악용될 수 있습니다. 따라서 감사가 대부분의 에너지를 코어에 쏟는다면, 나무를 살펴보는 동안 옆집 플러그인 디렉터리에서 산불이 시작되는 것입니다.

이것은 코어에 대해 당황하라는 것이 아닙니다. 최근 공개 익스플로잇이 발생한 wp2shell RCE 결함과 같은 코어 취약점은 발표 당일에 패치해야 합니다. 그러나 이러한 취약점은 드물기 때문에 감사 시간의 대부분을 할애할 가치가 없습니다. 대부분은 플러그인에 속하며, 실제 워크플로는 거기서 시작됩니다.

이전 시나리오를 상상해 보세요: 일요일 아침, 사이트가 카지노 페이지로 리디렉션되고 상사가 "우리 보안이 있는 줄 알았는데"라고 이메일을 보냅니다. 보안은 있었습니다. 체크리스트 감사가 있었던 것입니다. 이후 시나리오는 플러그인을 실제 공격 표면으로 취급하고 외부에서 테스트하며 스캐너가 볼 수 없는 것을 확인하는 트리아주 시스템입니다.

여러분은 2017년부터 운영된 WordPress 사이트를 가진 소규모 마케팅 팀에 있습니다. 2019년 프리랜서가 만든 사용자 정의 이벤트 등록 플러그인, 파일 업로드 필드가 있는 문의 양식 플러그인, 판매되어 더 이상 공개 업데이트 페이지가 없는 슬라이더 플러그인이 있습니다. 이것은 특이한 스택이 아닙니다. 여기가 감사의 시작점입니다.

---

플러그인 인벤토리는 보안 정책입니다

모든 플러그인과 테마의 인벤토리를 확보하세요. 버전, 마지막 업데이트 날짜, 공급업체가 여전히 활동 중인지, 그리고 실제로 사용하는 사람이 있는지 기록하세요. 그런 다음 각 항목을 유지 관리 및 사용, 유지 관리 및 미사용, 버려졌지만 사용, 버려졌고 미사용으로 분류하세요. 사용하지 않는 항목은 즉시 제거하세요. "월 50달러일 뿐이야"라는 변명은 무시하세요. 사용하지 않는 플러그인은 기능이 아니라 책임입니다. 버려졌지만 사용 중인 항목의 경우 교체할지 아니면 위험을 수용하고 상사가 본 위험 등록부에 기록할지 결정하세요.

이벤트 등록 플러그인은 버려졌지만 사용 중인 버킷에 속합니다. 결제를 처리하고 확인 이메일을 보내며 교체하는 것은 프로젝트이므로 지금은 유지합니다. 그러나 "이것이 향후 침해의 가장 가능성 있는 원인"이라는 메모를 작성하고 테스트 목록 맨 위에 추가합니다.

공격 표면	WordPress 알려진 취약점 비율	감사 우선순위
타사 플러그인	96% 이상	최우선 — 목록화, 스캔, 테스트, 교체
테마	약 4%	중간 — 사용자 정의 또는 오래된 경우에만
WordPress 코어	1% 미만	낮음 — 패치 유지, 계속 진행

SecurityWeek가 2024년에 8,000개 이상의 새로운 WordPress 취약점을 집계했을 때 대부분은 플러그인 문제이지 코어 패치가 아니었습니다. 스캐너는 공개되고 CVE가 부여된 항목을 알려줍니다. CVE가 없는 사용자 정의 프리랜서 코드는 아무도 주의 깊게 살펴본 적이 없기 때문에 알려주지 않습니다. 그 수동 검토가 여러분의 일입니다. 플러그인별 검사에 대한 더 깊은 안내는 WordPress 플러그인 취약점 감사 가이드를 참조하세요.

---

낯선 사람처럼 테스트하세요: 비밀번호가 필요 없는 43%

스캐너는 이미 아무 문제가 없다고 말했습니다. 이제 스캐너가 할 수 없는 일을 하세요: 로그인 없이 외부에서 사이트를 조사하세요. 모든 파일 업로드 필드, POST를 처리하는 모든 양식, 모든 admin-ajax 엔드포인트부터 시작하세요. 업로드가 실제로 파일 내용을 확인하는지 아니면 확장자만 확인하는지 확인하세요. 업로드된 파일은 어디에 저장되며 웹 서버가 해당 디렉터리에서 PHP를 실행할 수 있습니까? 인증이 필요 없는 43%의 플러그인 결함은 일반적으로 정확히 이러한 위치에 있습니다: 인증되지 않은 저장 XSS, 임의 파일 업로드, PHP 객체 주입입니다.

문의 양식 플러그인은 방문자가 이력서를 첨부할 수 있게 합니다. 방문자의 원래 파일명을 사용하여 파일 이름을 바꾸므로 "resume.php"를 업로드하면 설계상 쓰기 가능한 /uploads/contact/ 폴더에 저장됩니다. 서버가 해당 디렉터리에서 PHP 실행을 허용한다면 공격자는 웹쉘을 얻습니다. Fastly는 WordPress 플러그인에서 인증되지 않은 저장 XSS의 실제 악용을 문서화했습니다. 이것은 틈새 슬라이드덱 위험이 아닙니다. 테스트는 간단합니다: 알려진 내용의 파일을 만들고 업로드한 다음 원래 이름과 유형으로 돌아오는지 확인하세요. 그런 다음 .php 파일을 업로드해 보세요. .php로 돌아오면 악용 가능한 구멍을 찾은 것입니다.

이것은 또한 "하지만 우리 보안 플러그인에는 WAF가 있다"는 주장이 무너지는 지점입니다. WAF는 알려진 페이로드를 차단할 수 있지만 의존하는 경로 정규화 규칙은 서버가 실제로 수행하는 작업과 종종 다릅니다. OWASP 웹 보안 테스트 가이드는 대시보드보다 더 나은 참고 자료입니다. 파일 업로드 결함과 저장 XSS를 체계적으로 테스트하는 방법을 설명합니다. 그리고 플러그인이 버려졌다는 것을 발견하면 정리 프로토콜을 적용할 때입니다: 버려진 WordPress 플러그인의 숨은 위험은 죽은 확장 프로그램을 제거하고 워크플로를 조정하는 것보다 그대로 두는 것이 더 나쁜 이유를 설명합니다.

---

스캐너가 볼 수 없는 것: 사용자, 로그, 오래된 코드

동적 테스트는 현재 노출된 것을 잡아냅니다. 수동 검토는 이미 내부에 있는 것을 잡아냅니다. 사용자 계정부터 시작하세요: 관리자 목록을 열고 직접 만들지 않은 계정을 찾으세요. 무료 메일 주소를 가진 "support"라는 관리자가 뒤에 사람 없이 있다면 동료가 아니라 백도어입니다. wp-content/uploads의 파일 타임스탬프에서 콘텐츠가 아닌 최근 수정된 항목을 확인하세요. 서버 액세스 로그에서 사람의 브라우저가 아니라 봇의 curl 명령처럼 보이는 요청을 확인하세요.

이벤트 플러그인에는 uploads/event-headshots/에 저장되는 "스피커 사진" 업로드가 있습니다. 테스트 중에 여러분의 파일이 아닌 무작위로 보이는 이름의 작은 PHP 파일을 발견합니다. 그것이 웹쉘입니다. 2주 전에 테스트한 동일한 업로드 결함을 통해 거기에 도달했으며, 지금쯤 스캐너는 여전히 "볼 수" 없습니다. 플러그인 취약점이 아니라 취약점의 증거이기 때문입니다. 수동 검토가 이를 찾아 삭제하고 로그에서 이를 넣은 IP 주소를 확인합니다. Invicti는 플러그인의 PHP 객체 주입이 증가하고 있으며 악성 객체가 실행 중에만 구체화되기 때문에 블랙박스 스캔에서는 거의 보이지 않는다고 언급했습니다. 이를 발견하는 유일한 방법은 사용자 입력에서 unserialize() 호출과 같은 위험한 패턴에 대해 코드를 읽는 것입니다. 사용자 정의 플러그인의 몇 백 줄을 읽는 것은 침해 대응 리테이너 비용을 지불하는 것보다 저렴합니다.

이것은 또한 "보안 플러그인을 더 설치하라"는 표준 조언이 한계에 도달하는 지점입니다. 보안 플러그인 3개를 쌓으면 서로를 차단하는 중복 WAF 규칙, 중복 로그 이메일의 홍수, 가끔 자신의 관리자 로그인에서 "차단되었습니다" 오류가 발생합니다. 잘 구성된 활성 보안 플러그인 하나면 충분합니다. 다른 것을 추가하기 전에 보안 플러그인이 너무 많으면 역효과가 나는 이유를 읽어보세요.

---

당황하지 않고 상사에게 진실을 말하기

상사는 CVSS 점수나 PHP 객체 주입에 관심이 없습니다. 그는 사이트 중단, 스토어가 주문을 받지 못하는 것, IT 예산에 관심이 있습니다. 번역은 간단합니다: "이 플러그인에는 알려진 인증되지 않은 원격 코드 실행 결함이 있습니다. 낯선 사람이 사이트 콘텐츠를 삭제하거나 백도어를 설치할 수 있습니다. 이번 분기에 교체해야 합니다." 그런 다음 우선순위 목록을 보여주세요: 이벤트 플러그인 교체, 파일 유형을 제대로 검증할 때까지 문의 양식의 파일 업로드 비활성화, 모든 관리자 자격 증명 교체, 다음 분기 검토 예약.

또한 언어적 이점이 있습니다: CISA는 알려진 악용 취약점 카탈로그를 유지 관리하여 어떤 공개된 결함이 실제로 활발히 악용되고 있는지 정확히 알려줍니다. 플러그인 중 하나가 여기에 나타나면 더 이상 이론적 논쟁이 아닙니다. 알려진 익스플로잇이 존재하며 시간이 촉박합니다. 그렇지 않더라도 "긴급"의 기준으로 사용하세요. CISA의 추적은 비기술적 상사가 이것이 피싱 이메일이 아니라 공격자가 지금 무엇을 하고 있는지에 대한 공개 데이터베이스라고 확신시키는 것을 더 쉽게 만듭니다. 분기가 끝나면 일회성 체크리스트 실행이 아닌 수정 워크플로를 갖게 됩니다. 취약점을 패치 주기로 전환하는 워크플로는 습관을 유지합니다.

---

이전은 깨진 사이트, 초조한 이메일, 아무 문제 없다고 말하는 깨끗한 스캐너 보고서였습니다. 이후는 분기별 의식입니다: 목록화, 분류, 외부 테스트, 사용자 및 로그 검토, 내린 결정과 수용한 위험을 기록합니다. 스캐너는 건강 증명서가 아니라 어디를 봐야 할지 알려주는 지도가 됩니다. 플러그인은 이름으로 알 수 있는 목록이 됩니다. 그리고 다음에 상사가 감사에 대해 물어볼 때, 손가락을 꼬지 않고 답할 수 있습니다.