블로그
분류 먼저, 패치는 나중: 실용적인 워드프레스 보안 감사
모든 플러그인 업데이트를 똑같이 취급하지 마세요. 인증되지 않은 위험에 초점을 맞추고 비기술적 이해관계자에게 결과를 설명하는 분류 우선 워드프레스 보안 감사를 배워보세요.
요약
이 글은 워드프레스 플러그인을 무분별하게 패치하는 것이 비생산적인 보안 습관인 이유를 설명하고, 보다 목표 지향적인 분류 우선 감사 방법을 제안합니다. 플러그인 취약점의 약 43%가 인증 없이 악용될 수 있으므로 우선적으로 처리해야 한다는 점을 강조합니다. 이 체크리스트는 취약점 분류, 플러그인 목록 정리, 스캔 결과를 건강한 회의적 시각으로 읽기, 사용자 권한 감사, 웹셸 및 로그 이상 징후 확인, 감사 보고 간소화를 다룹니다. 각 단계에는 실용적인 예제와 주의사항이 포함되어 있으며, 비기술적 관리자에게 보안 작업을 설명해야 하는 마케터를 위해 작성되었습니다. 이 접근 방식을 따르면 모든 경고를 쫓는 대신 실제로 중요한 위험에 제한된 리소스를 집중할 수 있습니다.
모든 플러그인을 같은 날 패치하는 것은 책임감 있는 것처럼 느껴지지만 실제로는 역효과를 낼 수 있는 보안 습관 중 하나입니다. 그 배경에는 타당한 생각이 있습니다. 업계 연구는 지속적으로 워드프레스 생태계 취약점의 96% 이상이 타사 플러그인에서 발생한다고 말하며, 최근 공개 속도는 그 두려움을 더욱 시급하게 만듭니다. SecurityWeek에 따르면 2024년에만 8,000개의 새로운 워드프레스 취약점이 보고되었습니다. 그러나 '모든 것을 동일하게 업데이트'하는 것은 모든 취약점이 동일한 위험을 제기하는 것처럼 취급하지만, 실제로는 그렇지 않습니다. 플러그인 결함의 상당 부분은 공격자가 먼저 로그인해야 하며, 인증되지 않은 비율은 대략 43%로 추정됩니다. 이는 익명 봇이 대규모로 공격할 수 있는 결함이며, 기존 계정이 필요한 결함과는 완전히 다른 대응이 필요합니다.
이 글은 패치 속도가 아니라 도달 가능성, 활동성, 잔여 위험을 중심으로 구축된 체크리스트인 분류 우선 감사 방법을 제시합니다. 비기술적 의사결정자와 보안 결과를 예산 논의로 전환해야 하는 사람을 염두에 두고 작성되었습니다. 워드프레스 감사의 가장 어려운 부분은 도구 실행이 아니라, 평온하고 우선순위가 정해진 목록이 극적인 '모든 것을 패치하라'는 경보보다 왜 더 유용한지 설명하는 것이기 때문입니다.
"로그인 없이 도달할 수 있는 사람"을 기준으로 취약점 목록 분류하기
취약점 심각도 점수는 피해가 얼마나 심각할 수 있는지 알려주지만, 누군가가 그것을 악용할 가능성은 알려주지 않습니다. 인증 요구 사항이 첫 번째 필터입니다.
사이트에 관리자 자격 증명이 필요한 저장형 XSS 결함이 있는 페이지 빌더와 방문자가 임시 폴더에 파일을 업로드할 수 있는 작은 가져오기 플러그인이 있다고 가정해 보세요. 페이지 빌더의 취약점은 CVSS 점수가 더 높을 수 있지만, 공격자는 이를 악용하려면 이미 관리자 계정이 있어야 합니다. 반면 가져오기 플러그인은 지나가는 모든 스캐닝 봇에 노출됩니다. 점수가 더 높다고 페이지 빌더를 먼저 패치하는 것은 실제로 열려 있는 문을 잠그지 않는 실수입니다.
보안 스캐너 또는 자문 피드에서 플러그인 취약점 목록을 가져와 '원격, 인증 없음'과 '역할 필요'의 두 그룹으로 나누세요. 인증 없는 그룹은 몇 시간 안에 패치하고, 취약점이 CISA 알려진 악용 취약점 카탈로그에 나타나면 실제 공격에 이미 사용되고 있는 결함을 추적하는 카탈로그이므로 긴급 상황으로 취급하세요. 인증된 그룹은 업데이트 테스트와 함께 예약된 일반 유지 관리 작업이 됩니다.
인증된 취약점을 무시해도 된다는 의미인가요? 아닙니다. 그러나 특히 사이트에 작성자나 편집자가 많은 경우 다른 주기에 속합니다. 분류는 위험을 무시하는 것이 아니라 순서를 정하는 것입니다. 표준 플러그인 감사는 버전을 추적하지만 도달 가능성은 추적하지 않습니다. 이 단계가 차이를 만듭니다.
사용하지 않는 것은 삭제하세요 (또는 최소한 숨기세요)
설치한 모든 플러그인은 공격자가 이용할 수 있는 경로이며, 비활성 플러그인은 종종 그중에서 최악입니다. 아무도 감시하지 않고, 업데이트하지 않으며, 스캐너가 인식하는 알려진 디렉터리 구조에 그대로 남아 있습니다.
전 인턴이 2주간의 출시 캠페인에 사용했던 예약 게시 플러그인을 생각해 보세요. 비활성화되었지만 디스크에 남아 있고, 공급업체는 3년 동안 업데이트를 발표하지 않았습니다. 공격자는 당신이 그것을 사용하지 않는다는 사실에 관심이 없습니다. 그들이 관심을 두는 것은 /wp-content/plugins/launch-scheduler/ajax.php 파일이 존재하고 인증되지 않은 요청을 수락한다는 점입니다. 비활성화된 플러그인은 사고 검토에서 '우리는 그것을 업데이트할 필요가 없다고 생각했다'는 주제의 일반적인 원인입니다. 존재하는 플러그인은 활성 여부와 관계없이 공격 표면입니다.
인벤토리를 작성하고 각 플러그인에 '활발히 사용 중', '필요하지만 비활성', '더 이상 필요 없음'으로 레이블을 지정하세요. 마지막 그룹에 해당하는 것은 비활성화하고 삭제하세요. 플러그인 코드는 제거될 때까지 읽을 수 있으므로 비활성화만 해서는 안 됩니다. '필요하지만 비활성' 그룹의 경우 최소한 플러그인 파일에 대한 액세스를 제한하거나 데이터를 잠긴 위치로 이동하세요. 하나의 캠페인을 위해 설치되고 결코 제거되지 않은 플러그인이 얼마나 많은지 놀라게 될 것입니다. 버려진 플러그인은 버려진 워드프레스 플러그인에 대한 심층 분석에서 다루었듯이 부채가 되기 쉽습니다.
삭제조차도 위험을 수반합니다. 플러그인이 페이지에 아직 있는 콘텐츠를 지원했다면 삭제 시 문제가 발생할 수 있습니다. 따라서 인벤토리 단계는 무분별하게 삭제하라는 명령이 아니라, 무엇을 왜 유지할지 문서로 결정할 이유입니다.
스캔을 판결이 아닌 출발점으로 취급하세요
자동화된 스캔은 서명 일치 작업입니다. 사이트의 알려진 패턴을 알려진 나쁜 패턴의 데이터베이스와 비교합니다. 구성, 사용자 역할 또는 사용자 지정 코드 상호 작용에 대해서는 추론하지 않습니다.
| 스캔이 잡아내는 것 | 스캔이 놓치는 것 |
|---|---|
| 알려진 CVE가 있는 오래된 플러그인 버전 | 과도한 권한을 가진 사용자 계정 |
| 노출된 파일 및 기본 관리자 사용자 이름 | 비정상적인 로그인 패턴 또는 새 관리자 사용자 |
| 알려진 악용 서명 | 잘못 구성된 파일 권한 |
| 최근 악성코드 패턴 | 사용자 지정 코드 및 플러그인 상호 작용의 논리적 결함 |
SANS의 워드프레스 플러그인 취약점 스캐닝과 같은 가이드는 스캐닝이 실제 방법론을 갖춘 전문 활동임을 분명히 하며, OWASP의 웹 보안 테스트 가이드는 정적 및 동적 테스트(SAST 및 DAST)를 대체물이 아닌 보완 계층으로 간주합니다. 스캔이 깨끗하게 나왔다면 알려진 서명이 일치하지 않았다는 뜻일 뿐, 사이트가 실제로 안전하다는 것은 말해주지 않습니다.
스캔을 사용하여 단서를 생성한 다음 각 결과를 수동으로 검증하세요. 그리고 또 다른 보안 스캐닝 플러그인을 설치하기 전에 보안 플러그인이 쌓이면 역효과가 나고 사각지대가 생길 수 있다는 점을 고려하세요. 보고서의 깨끗함이 실제 위험보다 더 중요해지면, 그것은 요점을 놓친 것입니다.
공격자가 사용자를 열거하는 방식으로 사용자 감사하기
'인증되지 않은' 공격 표면은 긴급한 주의를 받지만, 인증된 공격은 공격자에게도 저렴합니다. 자격 증명만 있으면 됩니다. 사용자는 시스템으로 가는 경로이며, 사용자 목록은 그 경로의 지도입니다.
워드프레스 사용자 목록에는 marketing 같은 사용자 이름과 Marketing2020 같은 비밀번호를 가진 'admin' 계정, 삭제되지 않은 전직 프리랜서의 편집자 계정, 외부 공급업체를 위해 만들었는지조차 기억나지 않는 몇 개의 계정이 포함되어 있을 것입니다. 공격자는 공개 이메일 주소와 유출 데이터를 사용하여 후보 목록을 만든 다음 수백만 개 사이트에서 해당 사용자 이름과 비밀번호를 시도합니다. 재사용된 비밀번호를 가진 잊혀진 계정은 완벽하게 적절한 로그인 수단입니다. 전면 문을 통해 걸어 들어갈 수 있다면 플러그인 취약점을 깨뜨릴 필요가 없습니다.
모든 사용자 목록을 내보내고 검토 시간을 따로 마련하여 더 이상 액세스가 필요 없는 계정을 제거하거나 권한을 낮추세요. 모든 관리자 계정에 2단계 인증을 적용하고 회사 이름 변형처럼 보이는 비밀번호는 모두 변경하세요. 그 후 최소 권한 구조를 고려하세요. 대부분의 일상적인 콘텐츠 편집자는 최대 편집자 역할이 필요하며, 관리자 역할은 실제로 플러그인을 설치하거나 코드를 변경하는 사람을 위해 예약되어야 합니다.
워드프레스 REST API는 사용자 ID를 누구에게나 노출하므로 사용자 이름을 완전히 숨길 수는 없습니다. 그러나 예측 가능한 명명 규칙을 피함으로써 추측하기 어렵게 만들 수 있고, 명백한 무차별 대입 시도를 자동으로 차단할 수 있습니다.
공격자가 남긴 것을 찾아보세요
침해는 단일 순간이 아니라 과정입니다. 진입점은 패치될 수 있지만 백도어를 설치한 공격자는 취약점이 수정된 후에도 계속 액세스할 수 있습니다. 지속성을 감사하는 것은 진입을 감사하는 것과 다릅니다.
Fastly의 보안 팀은 워드프레스 플러그인의 인증되지 않은 저장형 XSS의 활발한 악용에 대해 썼습니다. 이는 공격자가 합법적인 사용자의 브라우저에서 세션을 탈취할 수 있는 스크립트입니다. Invicti의 독립적인 연구는 서명 기반 스캐너를 자주 통과하는 기술인 PHP 객체 인젝션의 증가를 지적합니다. 그리고 WP2Shell의 유명한 사례에서는 핵심 워드프레스조차 공개 익스플로잇이 있는 RCE 결함이 있었습니다. 이러한 것들은 단순한 '알려진 악성코드 확인' 스캔이 안정적으로 잡아내는 종류가 아닙니다. 공통점은 추가 관리자 사용자, wp-content/uploads/에 업로드된 PHP 파일, 새 IP에서 오전 3시 로그인과 같은 흔적을 남긴다는 것입니다.
최소한 매달 업로드 폴더의 .php 파일에 대한 POST 요청과 예상치 못한 위치의 관리자 로그인을 위해 액세스 로그를 검토하세요. 생성하지 않은 새 관리자 계정이 있는지 사용자 목록을 살펴보세요. 파일 무결성 모니터를 실행할 수 있다면 wp-admin 및 wp-includes의 변경 사항을 알리도록 구성하고, 그렇지 않다면 파일 수정 시간의 한 줄 차이 비교가 좋은 저기술 대안입니다.
로그 검토는 오탐을 생성합니다. 요령은 사고 후가 아니라 사고 전에 '정상'에 대한 기준을 정의하는 것입니다. 평소 트래픽의 모습을 알게 되면 이상 징후가 더 분명해집니다.
상사가 실제로 필요로 하는 한 페이지 감사 메모 작성하기
피치 미팅 형식의 보안 조언은 우선순위로 전환되지 않으면 가치가 없습니다. 목표는 상사에게 공격을 받고 있다고 설득하는 것이 아니라, 무엇을 확인했는지, 무엇을 수정했는지, 그리고 무엇이 아직 열린 결정인지 알고 있음을 보여주는 것입니다.
관리자가 '우리 안전한가요?'라고 물을 때 정직한 대답은 한 단어가 아닙니다. 짧은 설명입니다: '지난주에 플러그인 목록을 확인하고 사용하지 않는 플러그인 4개를 제거했습니다. 전 직원의 관리자 계정 하나를 발견하여 비활성화했습니다. 두 가지 미결 항목이 있습니다: 레거시 플러그인을 교체할지 결정해야 하고, 한 계정에 2FA를 적용하지 않았습니다. 다음 검토는 한 달 후입니다.' 그 대답은 두려움에 대한 질문을 과정에 대한 질문으로 바꾸고, 비기술적 청취자에게 실제로 위층에서 다시 설명할 수 있는 무언가를 제공합니다.
점검 세션이 끝나면 한 페이지 분량의 감사 메모를 작성하세요. 확인됨, 수정됨, 열림, 다음 검토라는 간단한 표를 사용하세요. 위험 기호나 두려움 통계가 아닌 평이한 언어로 작성하세요. 휴가를 가는 경우 메모는 관리자 액세스 권한이 있는 다른 사람에게 인계하는 문서가 됩니다. 이것은 두 주 후에 상사가 갑자기 '우리 괜찮나요?'라고 물을 때 꺼내볼 문서이기도 합니다. 이것이 월간 리듬이 된다면 일회성 스캔이 아닌 사전 예방적 보안 감사를 수행하는 것입니다.
메모에 스캔의 모든 취약점 점수를 채워 넣지 마세요. 요점은 하룻밤 사이에 침투 테스터가 되었다는 것이 아니라 일관된 주기를 유지하고 있음을 보여주는 것입니다. 평온한 한 페이지가 놀라운 전체 보고서보다 더 유용합니다.
가장 강력한 워드프레스 사이트는 플러그인이 가장 많거나 스캔 보고서가 가장 시끄러운 사이트가 아니라, 누군가가 도달 가능성, 접근성, 지속성에 대해 신중한 결정을 내린 사이트입니다. 인증되지 않은 공격 표면에서 시작하여 필요 없는 것을 정리하고, 스캔을 단서로 취급하고, 사용자 역할을 검토하고, 후속 조치를 계획하세요. 모든 것을 패치하는 것이 아니라 더 현명하게 패치하고, 다음 예산 논의에서 우선순위를 방어하세요.
