[EVI$ION 7기] OWASP top 10 / A10 2021-Server Side Request Forgery(SSRF)

김예원·2024년 12월 29일

1. Lab: SSRF with blacklist-based input filter

admin 인터페이스에 접근해서 유저 carlos를 삭제시키는 것이 목표.

Visit a product, click "Check stock", intercept the request in Burp Suite, and send it to Burp Repeater.
Change the URL in the stockApi parameter to http://127.0.0.1/ and observe that the request is blocked.
Bypass the block by changing the URL to: http://127.1/
Change the URL to http://127.1/admin and observe that the URL is blocked again.
Obfuscate the "a" by double-URL encoding it to %2561 to access the admin interface and delete the target user.

우선 재고 확인하는 요청을 burp suite를 사용해서 가로챈다.


admin 페이지에 접근하기 위해 stockApi를 http://127.0.0.1/로 바꾸면 block되는 것을 볼 수 있다.

해당 문제는 블랙리스트 기반 입력 필터가 있는 SSRF 문제이기 때문에 127.0.0.1 또는 localhost와 같은 호스트 이름을 포함하여 입력하거나
/admin과 같은 민감한 URL를 포함한 경우 차단될 것임을 알 수 있다.

이를 우회하기 위해서는 127.0.0.1을
->
정수형 표현(2130706433), 8진수 표현(017700000001), 단축 표현(127.1)

/admin을
-> /%41dmin

이런 식으로 바꿔준다.


그러면 delete할 수 있는 페이지까지는 접근이 가능하지만


이렇게 다시 막힌다.

이중 인코딩을 통해 a를 %41 -> %2561로 바꿔줬는데도 안돼서..


그냥
http://127.1/%2561dmin/delete?username=carlos
이렇게 요청보내서 삭제했다.

2. Lab: SSRF with whitelist-based input filter

아까와 같이 admin 권한으로 유저 carlos를 삭제하는 것이 목표.
이번에는 whitelist 기반 입력 필터가 있는 ssrf 문제이다.

whitelist 기반 입력 필터는 입력 값이 특정 조건을 충족하는 경우에만 허용한다.

이번에도 재고 확인 요청을 가로채서, stockApi 파라미터를 http://127.0.0.1/로 바꿔서 확인해보면


이렇게 stock.weliketoshop.net과 호스트명이 일치해야 한다고 뜬다.

우회하는 방법은 여러 가지가 있는데, 우선 @를 사용해서 자격증명 정보를 삽입할 수 있다.
http://localhost@tock.weliketoshop.net/으로 변경해보면


이렇게 internal server error랑 Could not connect to external stock check service라는 문구가 뜬다.
따라서 호스트명 검사에 통과했다고 볼 수 있다.

다음은 # 문자를 통해 url fragment를 이용해볼 것이다.
url fragment 부분은 원래 서버로 전송이 되지 않는다. 즉, # 이전의 내용만 유효하기 때문에


http://localhost#stock.weliketoshop.net/ 이렇게 요청을 하면 호스트명이 stock.weliketoshop.net이어야 한다고 뜬다.

그런데 whitelist를 통과하기 전에는 stock.weliketoshop.net가 포함되어서 검사를 무사히 넘기고, 그 후에는 해당 부분이 무시되도록 하고 싶으므로
-> # 문자를 이중 인코딩해서(한 번 인코딩으로는 똑같음) fragment 부분을 표시하는 #가 아닌 것처럼 stock.weliketoshop.net를 그대로 포함시키고, whitelist를 통과한 후에는 # 뒤부터 / 전까지의 내용을 날리도록 하자.


http://localhost%2523@stock.weliketoshop.net/ 이렇게 우회하면 제대로 접근이 가능함을 확인할 수 있다.

carlos를 삭제하기 위해
http://localhost%2523@stock.weliketoshop.net/admin/delete?username=carlos 이렇게 변경해주면


해결!

3. Blind SSRF 취약점

Blind SSRF?

  • 애플리케이션 서버 내부적으로 백엔드 HTTP 요청이 발생되었지만, 해당 요청에 대한 응답이 프론트엔드 응답으로 반환되지 않을 때 발생함.

Blind SSRF 취약점의 영향

  • 단방향 특성 때문에 SSRF 취약점보다 영향이 낮은 경우가 많음.
  • 백엔드 시스템에서 민감한 데이터를 검색하는 데 쉽게 악용될 수는 없지만, 상황에 따라서는 완전한 원격 코드 실행을 달성하는 데 악용될 수 있음.

Blind SSRF 취약점을 찾고 exploit하는 방법

out-of-band (OAST)

  • 공격자가 컨트롤하는 외부 시스템에 HTTP 요청을 발생시키고, 해당 시스템과의 network interaction을 모니터링함.

a) 찾기: Burp Collaborator를 사용하여 고유한 도메인 이름을 생성하고, 이를 페이로드로 애플리케이션에 보내서, 해당 도메인과의 모든 상호 작용을 모니터링. 애플리케이션에서 들어오는 HTTP 요청이 확인되면 SSRF에 취약한 것!

*SSRF 취약성을 테스트할 때 제공된 Collaborator 도메인에 대한 DNS 조회는 관찰되지만 후속 HTTP 요청은 관찰되지 않는 것이 일반적임.

b) 공격: 백엔드 요청의 응답을 볼 수 없으므로, out-of-band HTTP request를 발생시킬 수 있는 blind SSRF 취약점을 식별하는 것을 통해 애플리케이션 서버가 도달할 수 있는 시스템의 콘텐츠를 탐색할 수는 없음. 그러나 서버 자체 또는 다른 백엔드 시스템의 다른 취약성을 조사하는 데에는 활용 가능. -> 잘 알려진 취약점을 탐지하도록 설계된 페이로드를 보내 내부 IP 주소 공간을 파악. 해당 페이로드가 out-of-band 기술도 사용하는 경우 패치되지 않은 내부 서버에서 중요한 취약점을 발견할 수 있음.

Blind SSRF 취약점을 악용하는 또 다른 방법은 애플리케이션이 공격자의 제어 하에 있는 시스템에 연결하도록 유도하고, 연결된 HTTP 클라이언트에 악성 응답을 반환하는 것. 서버의 HTTP implementation에서 심각한 client-side 취약점을 공격할 수 있다면 애플리케이션 인프라 내에서 원격 코드를 실행할 수 있음.

참고

https://portswigger.net/web-security/ssrf/blind

0개의 댓글