juanschallibaum/cve-2024-38473-nuclei-templateNuclei 템플릿으로 CVE-2024-38473 취약점이 있는 Apache 서버 탐지
CVE-2024-38473에 취약한 Apache 서버를 탐지하도록 설계된 Nuclei 템플릿입니다. 먼저 기본 PHP-FPM 설정으로 Apache < 2.4.60을 실행하는 서버를 식별합니다. 그런 다음 이 취약성으로 인해 우회될 수 있는 ACL로 보호된 잠재적인 PHP 파일을 퍼징합니다.
이 Nuclei 템플릿을 사용하려면 저장소를 클론해야 합니다. 다음 명령을 실행하여 수행할 수 있습니다:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
클론된 저장소 디렉토리로 이동합니다:
cd CVE-2024-38473-Nuclei-Template
단일 호스트에서 nuclei 템플릿 실행:
nuclei -t CVE-2024-38473.yaml -u http://example.com
호스트 목록에 대해 nuclei 템플릿 실행:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
유효한 .html 또는 .php 파일을 지정하여 단일 호스트에서 nuclei 템플릿 실행:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
이 방식으로 Nuclei를 실행하면 더 높은 탐지율을 얻을 수 있습니다. 호스트 파일에 이 형식의 URL을 포함하여 해당 목록에 대해 템플릿을 실행할 수도 있습니다.
CVE-2024-38473 취약성을 쉽게 테스트하려면 Docker를 사용하여 취약한 환경을 설정할 수 있습니다. 다음 단계에 따라 Nuclei 템플릿의 효과를 빠르게 확인하십시오:
Docker 데몬이 실행 중인지 확인: 시스템에서 Docker 데몬이 실행 중인지 확인하십시오. 실행 중이 아닌 경우 다음 명령으로 시작할 수 있습니다:
sudo systemctl start docker
Docker 컨테이너 실행: 저장소 디렉토리 내에서 다음 Docker 명령을 사용하여 취약한 Apache 및 PHP-FPM 설정으로 컨테이너를 시작하십시오:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
취약성 테스트:
수동으로: 웹 브라우저를 열고 http://localhost:8787로 이동하여 Docker 컨테이너에서 실행 중인 Apache 서버와 상호 작용합니다. http://localhost:8787/info.php에 접속하여 취약성을 테스트합니다. 이 파일은 ACL로 보호되어 있으며, ACL 우회가 성공하면 phpinfo()의 출력을 볼 수 있습니다:
Nuclei 템플릿 사용: 다음 Nuclei 명령을 실행하여 템플릿으로 서버를 테스트합니다:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
2024년 8월 8일, 보안 연구원 Orange Tsai가 Black Hat USA 2024에서 Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!라는 제목의 프레젠테이션을 했습니다. 이 프레젠테이션에서 그는 Apache HTTP Server에 영향을 미치는 여러 취약점을 보고했습니다. 그는 Apache가 수백 개의 모듈로 구성된 고도로 모듈화된 아키텍처를 가지고 있으며, 각 모듈은 거의 100개의 필드로 구성된 request_rec이라는 공유 구조를 읽고 쓰면서 기능을 수행한다고 설명했습니다.
보안 연구원이 보고한 취약점의 근본 원인은 서로 다른 Apache 모듈이 공유 구조의 다양한 필드를 처리하는 방식의 불일치에 있습니다. 예를 들어, mod_authz_core는 r->filename 필드를 파일로 처리하는 반면, mod_proxy는 이를 URL로 처리하여 불일치가 발생하고, 이로 인해 광범위한 취약점이 발생합니다.
프레젠테이션에서 Orange Tsai는 "Filename Confusion"이라는 공격 유형을 정의합니다. 이 공격은 다양한 공격 표면을 가지고 있지만, 이 템플릿에서 다루는 CVE-2024-38473은 "Filename Confusion" 공격을 적용하여 Apache ACL을 우회하고 제한된 파일에 접근하는 방법을 나타냅니다.
문제는 Apache의 인증 모듈인 mod_authz_core가 r->filename 속성을 파일로 처리하는 반면, mod_proxy는 이를 URL로 처리할 때 발생합니다. 이로 인해 기본 구성에서 PHP-FPM을 사용하는 Apache 설치가 이 취약점의 영향을 받습니다. Apache와 PHP-FPM을 실행하는 서버에 다음과 같은 ACL이 구성되어 admin.php 파일에 대한 액세스를 자격 증명으로 보호한다고 가정해 보겠습니다:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
취약성으로 인해 위와 같이 개별 파일을 보호하는 ACL을 우회할 수 있습니다. 실제로는 다음 요청을 보내는 것만으로 쉽게 수행할 수 있습니다: http://server/admin.php%3fooo.php.
이를 깊이 이해하려면 Apache가 위와 같은 요청을 처리할 때 mod_authz_core 모듈이 공유 구조의 r->filename 필드에서 admin.php?fooo.php 값을 읽는다는 점을 고려하는 것이 중요합니다. 이 값은 요청된 파일의 이름으로 처리되며, ACL과 비교할 때 admin.php?fooo.php가 admin.php와 다르기 때문에 일치하지 않습니다.
그런 다음 admin.php?fooo.php가 .php로 끝나므로 요청은 PHP-FPM에 의해 처리됩니다. PHP-FPM은 처리하기 전에 Apache로부터 받은 파일 이름에서 ? 다음의 모든 것을 제거하여 파일이 아닌 URL로 처리합니다. 결과적으로 PHP-FPM은 admin.php를 직접 처리합니다. ACL 검사가 이전에 통과되었기 때문에 공격자는 인증 없이 admin.php에 접근할 수 있습니다.
현재 Nuclei 템플릿은 무차별 대입으로 보호된 파일을 발견하는 것뿐만 아니라 ACL로 보호된 파일 사례가 감지되지 않더라도 서버에 PHP-FPM과 함께 취약한 Apache < 2.4.60 구성이 있는지 식별하는 논리를 포함합니다. 기본 흐름에서는 먼저 서버에 취약한 구성이 있는지 식별하려고 시도한 다음, 긍정적인 경우 ACL로 보호될 수 있는 일반적인 파일을 식별하려고 시도합니다.
Apache < 2.4.60 및 PHP-FPM이 있는 취약한 구성을 감지하는 아이디어는 두 가지 기본 전제에 기반합니다:
취약한 구성에서 서버에 file.php가 존재하는 경우 http://server/file.php%3fooo.php에 대한 요청은 http://server/file.php에 대한 요청과 동일한 200 상태 코드와 동일한 본문 길이를 반환합니다(PHP-FPM이 %3fooo.php를 제거하면 요청된 파일이 동일하기 때문입니다).
취약한 구성에서 서버에 file.html이 존재하는 경우 http://server/file.html%3fooo.php에 대한 요청은 403 Access Denied를 반환합니다. 이는 PHP-FPM이 .php 대신 .html 확장자를 가진 파일을 로드하려고 시도하기 때문이며, 이는 기본적으로 허용되지 않습니다.
템플릿 흐름은 7개의 요청 그룹으로 구성됩니다. 이들은 순서대로 실행되어야 하며, 각각의 일치 조건을 충족해야 다음 요청 그룹으로 진행됩니다. 이는 조건이 이미 충족되지 않는 것으로 알려진 경우 헛되이 전송되는 요청 수를 최소화하는 데 도움이 됩니다.
템플릿은 존재하지 않는 파일인 index.phpooo.php%3fooo.php에 요청을 보냅니다. 아이디어는 PHP-FPM이 구성되지 않은 경우에도 index.php%3fooo.php가 200 상태 코드와 index.php와 동일한 본문을 반환하는 경우의 오탐을 걸러내는 것입니다. 이는 예를 들어 요청된 파일이나 "index"로 시작하는 파일을 index.php로 재작성하는 규칙이 있는 경우 발생할 수 있습니다. 예:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
이 요청은 서버에 위와 같은 규칙이 있는 경우 200 상태 코드를 반환해야 하며, PHP-FPM이 구성될 수 있는 일반적인 경우에는 404 상태 코드를 반환해야 합니다. 이 요청이 404 상태 코드를 반환하지 않으면 템플릿은 이 호스트에서 처리를 중지합니다.
템플릿은 존재하지 않는 파일인 foo.phpooo.php%3fooo.php에 요청을 보냅니다. 아이디어는 PHP-FPM이 구성되지 않은 경우에도 index.html%3fooo.php가 403 상태 코드를 반환하는 경우의 오탐을 걸러내는 것입니다. 이는 예를 들어 URL 어디에서든 %3f 문자를 금지하거나 .php로 끝나는 파일에 대한 액세스를 제한하는 규칙이 있는 경우 발생할 수 있습니다. 이러한 규칙의 예는 다음과 같습니다:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
이 요청은 서버에 위와 같은 규칙이 있는 경우 403 상태 코드를 반환해야 하며, PHP-FPM이 구성될 수 있는 일반적인 경우에는 404 상태 코드를 반환해야 합니다. 이 요청이 404 상태 코드를 반환하지 않으면 템플릿은 이 호스트에서 처리를 중지합니다.
템플릿은 서버에서 사용 가능한 일부 파일을 식별하기 위해 요청을 보냅니다. 먼저 index.php를 사용할 수 있는지 식별하려고 시도합니다. 그런 다음 index.html 및 index.htm을 확인합니다. 마지막으로 사용자가 제공한 URL에 있는 파일이 존재하는지 테스트합니다. URL에 유효한 파일을 지정하여 Nuclei를 실행하면 일반적인 인덱스 파일이 존재하지 않는 경우 탐지 효과를 높일 수 있습니다.
템플릿은 PHP-FPM이 구성되지 않은 경우에도 index.php%3fooo.php가 200 상태 코드와 index.php와 동일한 본문을 반환하는 경우의 마지막 오탐을 걸러내기 위해 존재하지 않는 파일에 요청을 보냅니다. 일부 웹 서버, 특히 Apache가 아닌 서버는 %3f 뒤의 모든 것을 무시합니다. 따라서 index.php%3fooo.php를 보내면 서버는 이를 index.php로 처리합니다. 이러한 경우를 걸러내기 위해 템플릿은 index.php%3fooo.html(서버에서 index.php를 찾은 경우) 또는 index.html%3fooo.html(서버에서 index.html을 찾은 경우)에 요청을 보냅니다. .html로 끝나기 때문에 PHP-FPM이 구성될 수 있는 일반적인 경우에는 PHP-FPM에 의해 처리되지 않으며 논리적으로 존재하지 않는 정적 파일로 처리되어 404 상태 코드가 발생합니다. 그러나 %3f 뒤의 모든 것이 무시되는 필터링하려는 경우에는 200 상태 코드를 반환합니다. 이 요청이 404 상태 코드를 반환하지 않으면 템플릿은 이 호스트에서 처리를 중지합니다.
템플릿은 취약한 구성을 식별하기 위해 요청을 보냅니다. 두 가지 경우가 있으며, 그중 적어도 하나의 일치 조건이 충족되어야 합니다:
사례 1: 요청 #3에서 index.php를 찾았습니다. 이 경우 Apache < 2.4.60이고 기본 구성으로 PHP-FPM이 활성화된 경우 %3fooo.php 부분을 제거하고 index.php를 로드하여 요청 #3에서 얻은 것과 동일한 길이의 200 응답이 발생합니다. mod_php 또는 다른 핸들러를 사용하는 경우 index.php%3fooo.php를 전체 파일 이름으로 처리하고 404를 반환합니다. 이 경우가 일치하려면 요청이 200을 반환하고 요청 #3의 응답과 동일한 길이의 본문을 반환해야 합니다.
사례 2: 요청 #3에서 index.html을 찾았습니다. 이 경우 Apache < 2.4.60이고 기본 구성으로 PHP-FPM이 활성화된 경우 %3fooo.php 부분을 제거하고 index.html을 로드하려고 시도하며, 이는 PHP-FPM이 허용되지 않는 확장자를 가진 파일을 로드하려고 하므로 403 Access Denied를 반환합니다. mod_php 또는 다른 핸들러를 사용하는 경우 index.php%3fooo.php를 전체 파일 이름으로 처리하고 404를 반환합니다. 이 경우가 일치하려면 요청이 404를 반환해야 합니다.
템플릿이 이 지점에 도달하면 서버에 취약한 구성이 있음을 나타냅니다. 결과적으로 템플릿은 403 상태 코드를 반환하거나 인증이 필요하여 401 상태 코드를 반환하는 잠재적인 보호된 파일을 퍼징하기 위해 요청을 보냅니다. 기본적으로 가장 일반적이고 잠재적으로 보호되는 파일 이름 몇 개만 식별하려고 시도합니다. 그러나 350개의 가능한 PHP 파일 이름이 포함된 사용자 정의 워드리스트를 사용하기 위해 줄의 주석을 해제할 수 있습니다.
템플릿은 요청 #6에서 식별된 보호된 파일이 우회와 함께 200 상태 코드를 반환하는지 확인하기 위해 요청을 보냅니다.