1-Day analysis - Confusion Attacks (DEFCON 32) (작성중)

웹 보안 동향 오프라인 강의 과제

TODO: PoC 작성

 

black hat USA 2024에서 Orange Tsai 님이 발표한 Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server에 대해 조사했습니다.

연구 제목: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!

발표일: 2024.08.08, blackhat USA 2024

취약점 유형: Sematic Gap

관련 링크: 영상1, 영상2, 발표자료, 블로그 글

 

이 연구를 고른 이유와 찾은 과정

저는 워게임 문제에서 이 연구를 처음 접했습니다. 그 문제를 해결하기 위해서는 웹쉘을 업로드해야 했습니다. 하지만 PHP 관련 키워드가 있으면 정상적으로 업로드할 수 없었고, 대신 php_xxxxxx와 같이 저장되는 임시 파일을 PHP 엔진이 해석하도록 하는 작업이 필요했습니다.

문제의 설정 파일에서 RewriteRule 설정을 따로 적용한 점이 의심스러워 관련 설정을 찾아봤고, 연구자 가 직접 정리한 글을 찾았습니다. 하지만 Apache 내부 구조를 잘 알지 못해 이해하는 데 어려움이 있었습니다. 문제를 푸는 데 필요한 취약점 유형 중 하나라고만 생각하고 연구를 자세히 살펴볼 생각은 하지 않았습니다.

우연히도, 오프라인 강의에서 퀴즈로 이 연구가 언급되었습니다. Apache의 다양한 모듈들이 상호작용하는 과정에서 filename 필드를 처리하는 방식이 다르다는 취약점의 원인이 Semanic Gap 유형이라고 생각해서, 다시 조사해 봤습니다. 글을 다시 읽어보면서 Handler Confusion에 관련된 내용도 알 수 있었습니다.

공개된 취약점이고 패치도 제시되었으므로, 연구 내용을 정리하고 패치를 분석하는 방향으로 보고서를 작성했습니다. 감사합니다.

 

---

내용 요약

연구자는 오픈소스 프로젝트 중, 파급력이 높은 Apache HTTP Server를 분석했습니다. 연구자가 언급한 Apache 서버를 선택한 이유는 다음과 같습니다.

• 아파치는 각각 개발된 모듈이 상호작용하는 구조

• 136개의 공식 모듈 중, 절반 이상의 모듈이 기본적으로 활성화

• 공용 자료구조인 request_rec를 접근하는 방식이 모듈마다 다름

• 같은 설정을 다른 모듈로 할 수 있음

 

특히, 같은 필드를 모듈마다 다르게 해석하고 수정하기 때문에 Semantic Gap이 발생합니다. 연구자는 이런 차이 때문에 발생한 공격 표면을 Confusion Attack이라고 정했고, Apache HTTP Server에서 세 가지 유형의 Confusion Attack을 발견했습니다.

Apache 2.4.60 버전에서는 9개의 취약점이 패치되었지만, UnsafeAllow3F등 하위 호환성이 없는 조치들이 적용되었습니다. 패치와 관련해서 불만을 가진 글도 찾을 수 있었는데, 보안 담당자의 역할에 대해 생각해 보게 되었습니다.

 

Filename Confusion

Semantic Gap: request_rec.filename 필드를 (1) URL로 / (2) PATH로 인식

첫 번째 취약점 유형은 request_rec.filename필드를 처리하는 방식이 달라서 발생하는 Sematic Gap을 이용합니다.

• URL로 인식

  • mod_rewrite

  • mod_proxy

• PATH로 인식

  • mod_authz_core

 

 

(정보 출처: Apache Docs, 이미지 출처: Perplexity+ChatGPT)

 

mod_rewrite 모듈은 filename 필드를 URL로 해석해서 filename필드에서 ? 이후에 오는 글자들을 잘라버립니다. 이후 모듈들은 filename 필드에 ?을 기준으로 잘린 경로를 받습니다. 이 동작은 두 취약점으로 이어집니다.

• Path Truncation(CVE-2024-38474)

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

이 상황에서 /user/admin%2fsecret.yml%3F와 같이 입력하면 apply_rewrite_rule 함수에서

1. r->filename 필드에는 /user/admin%2fsecret.yml%3F이 들어와 있고, RewriteRule을 적용해 /user/admin/secret.yml?/profile.yml 저장

2. ?을 기준으로 잘라, filename 필드에 /user/admin/secret.yml을 저장

3. 이후 모듈에서는 r->filename 필드로 /user/admin/secret.yml 사용

하는 과정을 거쳐, 의도하지 않은 파일이 전송됩니다. 설정에서 허용된 경로라면, 직접 접근 가능한 경로가 아니더라도 모든 파일을 읽을 수 있게 만드는 취약점입니다. 이 취약점은 DocumentRoot Confusion 공격에서도 사용됩니다.

 

• Mislead RewriteFlag Assignment (CVE-2024-39573)

RewriteRule에는 Rewriterule Flag를 통해, 정규표현식을 만족하는 요청에 환경변수 변경 / 핸들러 변경 등의 작업을 할 수 있습니다. 공식 문서에서도 H 옵션을 이용해 핸들러를 설정하는 방법을 소개합니다. 하지만, Path Truncation과 같은 원리로 정규표현식을 만족한 이후에 querystring을 자르는 로직 때문에 확장자가 올바르지 않은 파일에도 핸들러가 적용됩니다.

다음과 같은 규칙에서, 확장자가 .php가 아니어도 PHP 엔진이 실행됩니다.

xxxxxxxxxx
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

제가 풀었던 문제도 이 취약점을 이용하는 문제였습니다.

 

인증 모듈과 프록시 모듈에서 발생하는 Semantic Gap을 이용하는 공격도 있습니다.

• ACL Bypass 공격(CVE-2024-38473)

Apache에서는 Files 지시어로 특정 파일/경로에 대한 접근을 제어할 수 있습니다. 이 동작을 담당하는 mod_authz_core 모듈은 filename 필드를 파일 경로로 인식합니다. admin.php%3fhello와 같이 파일이름을 인식하면, 이른 admin.php와 다르기 때문에 ACL을 통과합니다.

mod_proxy 모듈은 filename 필드를 URL로 인식합니다. 따라서 ? 이후에 오는 구문을 파라미터로 인식하고, admin.php를 요청합니다. 이 취약점을 이용하면 한 글자만으로 접근이 차단된 파일들을 읽고 실행할 수 있습니다.

 

DocumentRoot Confusion

Semantic Gap: RewriteRule에서 경로를 (1) 파일시스템의 root로 / DocumentRoot 이후의 경로로 인식

RewriteRule은 치환할 대상으로 URL과 파일 경로를 모두 허용하기 때문에, mod_rewrite 모듈에는 DocumentRoot를 붙인 경로와 붙이지 않은 경로 모두를 허용합니다. 이 때문에 잘못된 설정으로 RewriteRule 사용하면 파일시스템의 root부터 읽을 수 있습니다.

취약한 설정은 여러 가지가 있습니다. 연구에서 언급된 몇 가지 설정은,

xxxxxxxxxx
# Remove mykey=???
RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
RewriteRule "(.*)" "$1?%1%3"

xxxxxxxxxx
RewriteRule  "^/html/(.*)$"  "/$1.html"

xxxxxxxxxx
RewriteRule  "^(.*)\.(css|js|ico|svg)" "$1\.$2.gz"

등이 있습니다. 특히, 다음 설정은 DocumentRoot Confusion과 Filename Confusion(RewriteFlag assignment)에 모두 취약합니다.

xxxxxxxxxx
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

 

하지만 DocumentRoot Confusion이 발생한다고 하더라도, Apache의 디렉토리 ACL 때문에 모든 파일에 접근할 수 있는 것은 아닙니다. 기본 설정으로 허용된 /var/www/html, /usr/share등을 제외한 경로에는 접근할 수 없습니다(앞서 언급된 Filename Confusion을 통한 ACL Bypass는 mod_rewrite가 mod_authz_core보다 먼저 실행되어서 적용할 수 없습니다).

 

DocumentRoot Confusion을 활용할 수 있는 공격 시나리오는 두 가지가 있습니다.

 

• Source Code Leak

CGI 애플리케이션들은 ScriptAlias를 이용하여 핸들러를 지정합니다. 그 외의 경로는 static file로 취급받기 때문에, URL prefix가 아니라 (약간의 게싱과 함께) 절대경로를 제공하면 소스코드를 다운받을 수 있습니다.

비슷한 원리로, 앞단에 Apache 서버를 두고 뒷단에 PHP 서버와 static file 서버를 두는 환경을 공격할 수 있습니다. 이런 환경에서는 URL prefix로 요청을 어떤 서버로 보낼지 결정합니다. 절대경로를 입력한다면 prefix가 맞지 않아 static file 서버로 요청이 전송되고, 소스코드를 다운받을 수 있습니다.

 

• Using Local Gadgets

기본 설정으로, Apache는 /usr/share에 대한 접근과 symbolic link를 타고 들어가는 기능을 허용합니다. 애플리케이션을 설치할 때 데모 파일들을 이 경로에 저장하는데, 이 데모들을 이용하여 다른 공격을 할 수 있습니다.

연구자는 다음 파일들을 예시로 제시하였습니다.

/usr/share/davical/htdocs/setup.php (환경변수 유출)

/usr/share/libreoffice/help/help.html (Reflected XSS)

/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php (LFI)

이 외에도 SSRF, RCE 등 치명적인 공격을 가능하게 하는 몇 가지 가젯들도 제시했습니다.

 

단순히 /usr/share밑에 있는 몇 가지 가젯을 이용하는 방법 외에도, 하위 경로의 symbolic link들을 사용하여 다른 경로에 있는 파일에도 접근할 수 있습니다. 연구자는 /usr/share/mediawiki/config -> /var/lib/mediawiki/config/ 등의 여러 가젯을 제시했습니다.

 

이렇게 symbolic link를 따라가 파일을 읽는 방식으로, 환경설정 파일을 읽어낼 수도 있습니다. 예시로 Redmine 데몬의 비밀번호를 유출하여 Ruby on Rails Desirialization 공격으로 RCE를 성공하는 과정이 제시되었습니다.

 

Handler Confusion

Semantic Gap: request_rec.content_type 필드가 (1) AddType 지시어로 설정되었는지 / (2) Content-Type 에러도 설정되었는지 구분하지 못한 채로 handler 정보로 사용

Apache에서 CGI 스크립트 등의 handler를 제시하는 방법은 두 가지가 있었습니다.

1. AddHandler handler-name extension

2. AddType media-type extension

두 방법 모두 사용 가능하지만, AddHandler 지시어는 request_rec.handler를 / AddType 지시어는 request_rec.content_type을 설정합니다. AddType으로 handler를 설정할 수 있는 이유는 request_rec.handler필드가 비어있을 경우 content_type필드를 사용하는 코드가 있기 때문입니다. Handler Confusion은 이 content_type 필드를 임의로 설정하여 관리자가 의도하지 않은 handler를 실행하는 공격입니다.

 

• Soruce Code Leak

Apache는 순서대로 모듈을 거치다 에러가 발생하면 fixups 파트에서 회복합니다. 이때 r->content_type을 text/html로 설정됩니다.

ModSecurity에서 발생했던 취약점이 그 예시입니다. ModSecurity에서 에러를 잡지 않아 fixup에 해당하는 ap_run_fixups함수까지 내려갔고, 이때 content_type 필드를 변경해 소스코드가 그대로 전송되는 취약점이 있었습니다.

 

• Invoke Arbitrary Handler

CRLF Injection이 가능한 CGI 스크립트가 있다면 content_type 필드를 변경할 수 있습니다.

Apache에서 CGI를 구현한 모듈은 스크립트 실행 결과 Location 헤더가 서버 경로를 가리키면 내부적으로 요청을 처리하는 기능이 있습니다. 요청을 처리할 때 r->content_type을 복사하고 handler를 호출합니다. 이때 CRLF Injection으로 HTTP 응답의 Content-Type필드를 조작할 수 있다면, 임의의 handler 호출이 가능합니다.

 

이 공격은 헤더를 조작해야 한다는 어려움이 있습니다. 연구자는 공격 시나리오로 두 가지를 제시했습니다.

1. CGI 애플리케이션에서 CRLF 취약점이 있음

2. 헤더를 조작 가능한 SSRF 취약점이 있음

둘 중 하나의 시나리오라도 만족한다면 임의의 handler를 실행할 수 있습니다. 그렇다면 Information Disclosure, SSRF, RCE까지 다양한 공격이 가능합니다. 기본 설정만으로는 공격이 어려우므로 자세하게 분석하지는 않았습니다.

 

---

Mitigation: CVE-2024-38474

Filename Confusion에 해당하는 CVE-2024-38474는 Apache 2.4.60에서 패치되었습니다. CVE 정보에서 알 수 있는 패치 번호 r1918561는 이 취약점과 CVE-2024-38475를 동시에 해결한 패치입니다.

 

xxxxxxxxxx
+        if (!(p->flags & RULEFLAG_UNSAFE_ALLOW3F) &&
+            ap_strcasestr(r->unparsed_uri, "%3f") &&
+            ap_strchr_c(newuri, '?')) {
+            ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO()
+                    "Unsafe URL with %%3f URL rewritten without "
+                    "UnsafeAllow3F");
+            r->status = HTTP_FORBIDDEN;
+            return RULE_RC_STATUS_SET;
+        }

이 패치에서는 RewriteRule에서 ?(또는 url encoded된 %3f)를 검사하는 내용이 추가되었습니다. 만약 ?이 발견되었고 특수 플래그가 없다면 요청을 거부합니다.

 

Mitigation: CVE-2024-38475

DocumentRoot Confusion에 해당하는 CVE-2024-38475는 CVE-2024-38474와 마찬가지로 Apache 2.4.60에서, 같은 커밋에서 패치되었습니다.

 

xxxxxxxxxx
         if (apr_stat(&sb, statpath, APR_FINFO_MIN, pool) == APR_SUCCESS) {
-            return 1;
+            if (!lastsub) {
+                rewritelog((r, 3, NULL, "prefix_stat no lastsub subst prefix %s", statpath));
+                return 1;
+            }
+
+            rewritelog((r, 3, NULL, "prefix_stat compare statpath %s and lastsub output %s STATOK %d ",
+                    statpath, lastsub->output, lastsub->flags & RULEFLAG_UNSAFE_PREFIX_STAT));
+            if (lastsub->flags & RULEFLAG_UNSAFE_PREFIX_STAT) {
+                return 1;
+            }
+            else {
+                const char *docroot = ap_document_root(r);
+                const char *context_docroot = ap_context_document_root(r);
+                /*
+                 * As an example, path (r->filename) is /var/foo/bar/baz.html
+                 * even if the flag is not set,  we can accept a rule that
+                 * began with a literal /var (stapath), or if the entire path
+                 * starts with the docroot or context document root
+                 */
+                if (startsWith(r, lastsub->output, statpath) ||
+                        startsWith(r, path, docroot) ||
+                        ((docroot != context_docroot) &&
+                          startsWith(r, path, context_docroot))) {
+                    return 1;
+                }
+            }
         }
     }

 

이 패치에서는 파일 검증을 강화하였습니다. 파일이 있는지 확인하고, 특수 플래그가 없다면 DocumentRoot를 붙이는 방식으로 패치되었습니다.

 

Mitigation: CVE-2024-38476

Handler Confusion에 해당하는 CVE-2024-38476은 Apache 2.4.60에서 패치되었습니다. CVE 정보를 통해 r1918560이 패치에 해당하는 커밋인 것을 알 수 있습니다.

xxxxxxxxxx
 /**
+ * Set the content type for this request (r->content_type).
+ * @param r The current request
+ * @param ct The new content type
+ * @param trusted If non-zero, The content-type should come from a
+ *        trusted source such as server configuration rather
+ *        than application output.
+ * for the AddOutputFilterByType directive to work correctly.
+ */
+AP_DECLARE(void) ap_set_content_type_ex(request_rec *r, const char *ct, int trusted);
+

xxxxxxxxxx
+AP_DECLARE(void) ap_set_content_type_ex(request_rec *r, const char *ct, int trusted)
+{
+    ap_set_content_type(r, ct);
+    AP_REQUEST_SET_BNOTE(r, AP_REQUEST_TRUSTED_CT, trusted ? AP_REQUEST_TRUSTED_CT : 0);
+}

 

신뢰할 수 있는 출처의 r->content_type인지 검증하는 함수가 추가되었고, 내부 요청을 처리하는 코드들에서 새로운 함수를 사용하도록 변경되었습니다.