curl -i http://192.168.3.137:8011/

공격 표면 평가

HTTP 응답과 웹 인터페이스를 통해 다음 정보를 식별했습니다:

Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Drupal version: 8.5.0 Install path: /core/install.php Public port: 8011 -> 80/tcp

이 정보는 CVE와 연관 짓는 데 중요한 지문(fingerprints) 역할을 합니다. 특히 Drupal 8.5.0은 CVE-2018-7600, 일명 Drupalgeddon2와 직접 관련된 버전입니다.

공식 Drupal 권고에 따르면 SA-CORE-2018-002 / CVE-2018-7600은 다음 버전에 영향을 미칩니다:

>= 8.5.0 < 8.5.1

현재 대상은 다음과 같이 실행 중입니다:

Drupal 8.5.0

따라서 영향을 받는 버전 범위에 속합니다.

⇒ 생각:

현재 단계에서 Drupal 버전 8.5.0은 의심되는 CVE를 식별하는 강력한 증거입니다. 다음과 같이 추론합니다:

1. docker ps는 Lab이 포트 8011을 통해 HTTP 서비스를 노출함을 보여줍니다.
2. curl -i는 Apache/PHP로부터 유효한 HTTP 응답을 반환합니다.
3. 응답이 /core/install.php로 리디렉션됩니다.
4. 웹 인터페이스에 Drupal 8.5.0이 명확하게 표시됩니다.
5. Drupal 권고는 Drupal >=8.5.0 <8.5.1이 CVE-2018-7600의 영향을 받음을 확인합니다.
6. 대상은 정확히 Drupal 8.5.0을 실행 중이므로 CVE-2018-7600을 테스트하기 위한 버전 기준을 충족합니다.

대상은 Apache/PHP에서 실행되는 Drupal 8.5.0입니다. 이 버전은 Drupal의 공식 권고에 따라 CVE-2018-7600의 영향을 받는 범위 내에 있습니다. 다음 단계는 실제 악용 조건을 확인하여 대상이 RCE가 가능한지 검증하는 것입니다.

Drupal 버전 기반 CVE-2018-7600 확인

이전 지문 수집 단계에서 대상이 Drupal 8.5.0을 명확히 표시함을 확인했습니다. Drupal의 공식 권고에 따르면 취약점 SA-CORE-2018-002 / CVE-2018-7600은 Drupal 코어 버전:

>= 8.5.0 < 8.5.1에 영향을 미칩니다. 현재 대상은 정확히 Drupal 8.5.0을 실행 중이므로 영향을 받는 버전 범위에 속합니다. Drupal 권고에 따르면 이는 Drupal 코어의 원격 코드 실행 취약점으로, 공격자가 여러 공격 벡터를 악용하여 전체 사이트를 손상시킬 수 있습니다.

그러나 대상이 /core/install.php로 리디렉션되고 GUI에 Drupal 설치 화면이 표시되는 것을 볼 수 있습니다. 이는 Drupal이 설치가 완료되지 않은 상태일 수 있음을 시사합니다. 사이트 설정이 완료되지 않은 경우 Drupalgeddon2를 트리거하는 데 일반적으로 사용되는 /user/register, /user/password, /user/login과 같은 엔드포인트가 제대로 작동하지 않을 수 있습니다. 따라서 이 엔드포인트들을 확인할 필요가 있습니다.

curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login

엔드포인트들이 여전히 /core/install.php로 리디렉션되는 것을 볼 수 있습니다.

결론:

대상은 Drupal 8.5.0을 실행 중이며, Drupal의 공식 권고에 따라 CVE-2018-7600의 영향을 받는 버전 범위 내에 있습니다. 그러나 테스트 시점에 애플리케이션은 설치 프로그램 상태에 있으며 /user/register, /user/password, /user/login과 같은 라우트를 지속적으로 /core/install.php로 리디렉션합니다.

이는 Drupalgeddon2를 확인하는 데 일반적으로 사용되는 엔드포인트가 완전히 설치된 Drupal 사이트처럼 아직 작동하지 않음을 보여줍니다. 따라서 대상은 현재 버전 조건만 충족할 뿐 원격 코드 실행을 입증하기 위한 런타임 조건은 아직 충족하지 못합니다.

=> 생각:

Drupal이 런타임 상태에서 취약한 라우트/양식을 처리할 수 있고, 공격자가 인증 없이 엔드포인트에 접근할 수 있으며, id와 같은 검증 페이로드가 성공적으로 실행될 수 있음을 추가로 입증해야 합니다.

현재 대상에서는 엔드포인트가 설치 프로그램으로 리디렉션되므로, 다음 경로는 Drupal 설치 화면이 자체적인 공격 표면을 생성하는지 평가하는 것이며, Drupalgeddon2 RCE를 즉시 결론짓지 않아야 합니다.

Drupal 설치 프로그램의 공격 표면 평가

/user/register, /user/password, /user/login과 같은 Drupal 런타임 엔드포인트가 모두 /core/install.php로 리디렉션됨을 확인한 후, 설치 프로그램 화면을 분석했습니다.

설치 프로그램을 지원하는 데이터베이스 서비스 확인

Drupal 설치 프로그램이 현재 데이터베이스 구성 단계에서 중단되어 있으므로, 일반적인 데이터베이스 서비스가 외부에 노출되어 있는지 확인했습니다:

nmap -sV -p 3306,5432,33060 192.168.3.137

대상은 현재 외부에 Drupal 설치 프로그램을 노출하고 있지만, 공격자 시스템에서 직접 접근 가능한 데이터베이스 서비스는 감지되지 않았습니다.

결론: 이 Lab은 Drupal 8.5.0 설치 프로그램을 노출하고 있으며, 취약한 버전에 대한 정보 공개가 있습니다. CVE-2018-7600은 유효한 의심 벡터이지만, 성공적인 악용은 아직 입증되지 않았습니다.

CVE-2018-7600의 악용 조건

CVE-2018-7600은 Render Array 구조를 활용하는 Drupal Form API의 취약점을 악용합니다. AJAX 요청을 처리할 때 Drupal은 element_parents 매개변수를 사용하여 폼 트리에서 요소를 찾지만, # 문자로 시작하는 키를 검사(새니타이즈)하지 않습니다. 공격자는 POST 데이터를 통해 #post_render, #markup, #type과 같은 속성을 주입하여 렌더링 엔진이 임의의 PHP 함수(예: exec, passthru, system)를 실행하도록 강제합니다.

선행 조건: Form API를 사용하는 최소 하나의 엔드포인트가 유효한 응답을 반환해야 함(리디렉션되지 않고, 접근 제어에 차단되지 않음) 그래야 공격자가 페이로드가 포함된 AJAX 요청을 보낼 수 있습니다.

공개 PoC에서 일반적으로 사용되는 엔드포인트:

• /user/register (등록 양식 - 로그인 불필요)
• /user/password (비밀번호 찾기 양식 - 로그인 불필요)
• /user/login (로그인 양식 - 로그인 불필요)

현재 대상: 위 3개의 엔드포인트는 모두 302를 통해 /core/install.php로 리디렉션됨 ⇒ 아직 충족되지 않음

Drupal Form API + Render Array 엔진이 완전히 부트스트랩되어야 함

취약점은 Form API의 AJAX 처리 파이프라인 내에서 발생합니다: FormBuilder → RenderArray → #post_render 콜백 실행. 이 파이프라인은 Drupal이 모든 필요한 하위 시스템(라우팅, 폼 상태, 렌더 엔진)을 부트스트랩할 때만 작동합니다.

설치 프로그램 상태에서 Drupal은 최소 부트스트랩 모드로 실행됩니다. 즉, 설치 양식을 표시하는 데 필요한 만큼만 초기화되며, 라우팅, AJAX 핸들러, 전체 렌더 파이프라인과 같은 하위 시스템은 아직 완전히 활성화되지 않았을 수 있습니다.

현재 대상: Drupal은 설치 프로그램 상태에 있음 ⇒ 추가 확인 필요

요청에서 # 문자를 차단하는 WAF 또는 입력 필터링 메커니즘이 없어야 함

공식 Drupal 패치는 RequestSanitizer 클래스와 stripDangerousValues() 메서드를 추가하여 부트스트랩 초기 단계에서 $_GET, $_POST, $_COOKIE 전체를 스캔하고 #으로 시작하는 키를 제거합니다.

대상이 패치되지 않은 경우(8.5.0 실행), RequestSanitizer 클래스가 존재하지 않음 → #이 포함된 입력이 필터링되지 않음 ⇒ 충족

악용 조건 요약

결론: 대상은 버전 조건과 패치 부재 조건을 충족합니다. 그러나 사용 가능한 엔드포인트 및 전체 부트스트랩 조건은 Drupal이 설치 프로그램 상태이므로 아직 입증되지 않았습니다. 다음 단계는 설치 프로그램 양식(/core/install.php) - 역시 Form API와 Render Array를 사용함 - 이 표준 엔드포인트를 대체하여 악용될 수 있는지 테스트하는 것입니다.

II. 악용

대상이 설치 프로그램 상태에서 Drupal 8.5.0을 실행 중임을 식별한 후, CVE-2018-7600을 악용하는 데 일반적으로 사용되는 /user/register, /user/password, /user/login과 같은 표준 엔드포인트가 모두 /core/install.php로 리디렉션됩니다. 인터페이스 설정을 완료하지 않았기 때문일 수 있다고 생각했지만, 더 조사해보기로 했습니다.

확인 결과, 설치 프로그램 양식이 동일한 취약한 Form API와 Render Array 엔진을 사용하는 것으로 밝혀졌습니다. 그러나 AJAX 파이프라인은 Form Cache가 작동해야 합니다. 기본적으로 데이터베이스를 백엔드로 사용합니다. 데이터베이스가 아직 없기 때문에 설치 프로그램 양식에 대한 AJAX 요청은 FormBuilder.php:333에서 FormAjaxException을 반환하며, 이는 파이프라인이 활성화되었지만 캐시 로딩 단계에서 실패했음을 확인합니다.

생각: SQLite를 사용하여 Drupal을 설치할 것입니다. SQLite는 전용 서버가 필요 없고 컨테이너 디스크에 대한 파일 쓰기 권한만 있으면 되는 데이터베이스입니다.

CVE-2018-7600 악용 — 원격 코드 실행

Drupal이 온라인 상태가 되면 /user/register 엔드포인트가 정상적으로 작동하며 주입 지점으로 사용됩니다. 페이로드는 렌더 배열 주입 메커니즘을 활용합니다:

• element_parents=account/mail/%23value — 폼 트리에서 mail 필드 위치 지정
• mail[#post_render][]=passthru — 콜백 함수 passthru() 주입
• mail[#markup]=id — passthru()에 인수로 전달되는 내용

응답 분석:

uid=33(www-data) 결과는 페이로드가 www-data 사용자의 권한으로 운영 체제에서 실행되었음을 나타냅니다. 이는 일반적으로 Debian 기반 Linux에서 Apache/PHP 웹 서버를 실행하는 사용자입니다. id 명령이 서버 측에서 실행되고 출력을 반환했으므로 성공적인 원격 코드 실행이 확인됩니다. 그러나 현재 권한은 www-data이며 root가 아니므로 초기 제어 범위는 웹 서버 권한으로 제한됩니다.

III. 권장 사항 및 해결 방안

엔드포인트 접근 제어

사이트에 공개 사용자 등록이 필요하지 않은 경우 /user/register 엔드포인트를 비활성화합니다:

• 관리자 → 구성 → 계정 설정 → 누가 계정을 등록할 수 있는지 → 관리자만 선택

WAF 규칙 — 특징적인 페이로드 차단

POST 본문에 #post_render, #pre_render 또는 #markup 키가 포함된 요청을 차단하는 WAF 규칙을 추가합니다:

웹 서버에 대한 최소 권한 원칙

웹 서버는 root 권한으로 실행되어서는 안 됩니다. Lab 결과는 프로세스가 uid=33(www-data)로 실행됨을 확인합니다. 이는 올바른 구성이지만, 다음과 같은 개선 사항을 적용해야 합니다:

• www-data의 쓰기 권한을 필요한 디렉토리(sites/default/files/)로만 제한합니다.
• 코드 디렉토리(/var/www/html/core/, /var/www/html/modules/)에 대해 파일 시스템을 읽기 전용으로 마운트합니다.

설치 프로그램을 인터넷에 노출하지 마십시오

이 Lab에서는 설치 프로그램이 공개되어 있어, 공격자가 이를 악용하여 SQLite를 사용해 Drupal을 재설치하고 악용을 수행할 수 있습니다. 실제 운영 환경에서는 다음이 필요합니다:

• 설치 완료 후 /core/install.php를 삭제하거나 접근을 제한합니다.
• .htaccess 규칙 또는 웹 서버 구성을 추가하여 /core/install.php에 대한 외부 접근을 차단합니다.