Public/Portswigger Lab

SSRF(Server Side Request Forgery) - lab

haru0909 2023. 1. 8. 03:56

문제 1: 이 랩에는 내부 시스템에서 데이터를 가져오는 재고 확인 기능이 있습니다. 랩을 해결하려면 재고 확인 URL을 변경하여 에서 관리 인터페이스 http://localhost/admin에 액세스 하고 carlos 사용자를 삭제하십시오.

 

연구실에 액세스한다.

 

쇼핑을 하러 간다. View details 클릭

 

하단에 London, paris 등 도시를 선택하여 재고를 선택할 수 있다. burp suite를 통해 확인해 본다.

stockApi로 특정 주소에 접속해 재고를 확인하는 것을 알 수 있다. 

 

문제에서 나온 대로 해당 부분은 http://localhost/admin으로 바꿔본다.

carlos - delete가 가능한 것 같아 보여 바로 클릭... 을 하면

 

안 된다고 한다. 외부에서 요청을 했기 때문이다.

 

response에서 나온 주소대로 다시 stockapi에 넣어주고 send

 

성공했다.

 

문제 2: 다른 백엔드 시스템에 대한 기본 SSRF

이 랩에는 내부 시스템에서 데이터를 가져오는 재고 확인 기능이 있습니다.
랩을 해결하려면 재고 확인 기능을 사용하여 192.168.0.X포트 8080에서 admin 인터페이스의 내부 범위를 스캔한 다음

이를 사용하여 carlos 사용자를 삭제합니다.

 

연구실에 들어간다..

 

문제에 나온 대로 재고 기능을 확인하자

stockApi=http%3a%2f%2f192.168.0.1%3a8080%2fproduct%2fstock%2fcheck%3fproductId%3d1%26storeId%3d1

이 부분을 변조하면 될 것 같다.

 

intruder로 보내서 문제대로 192.168.0.$변조$:8080/admin로 변경해 준다.

 

1~254까지 넣어준다.

 

http://192.168.0.129:8080/admin에서 유일하게 200을 반환했다. (오지게 느림)

 

반가운 carlos가 보인다.. 

http://192.168.0.129:8080/admin/delete?username=carlos를 stockApi에 넣어준다.

 

302 redirect 되었다. 

 

다시 http://192.168.0.129/admin에서 carlos가 지워진 것을 확인한다.

문제 3: 랩: 블랙리스트 기반 입력 필터가 있는 SSRF

이 랩에는 내부 시스템에서 데이터를 가져오는 재고 확인 기능이 있습니다.

랩을 해결하려면 재고 확인 URL을 변경하여 http://localhost/admin에서 admin 인터페이스에 액세스 하고사용자를 삭제하십시오.

개발자는 우회해야 하는 두 가지 약한 SSRF 방지 방어를 배포했습니다

연구실로 가자

 

익숙하게 재고를 확인해 준다.

재고 확인 URL을 변경하여 http://localhost/admin에서 admin 인터페이스에 액세스해야 한다.

 

문제에서 말한 대로 방어가 생겼다. 우회를 해보자

 

127.0.1로 localhost를 우회하였고, admin의 대소문자 변형을 하여 Admin으로 해줬더니 200이 떴다.

반가운 carlos 너를 지워주지..

 

stockApi=http://127.0.1/Admin/delete?username=carlos로 바꿔주고 send를 한다.

302가 떴다 /admin으로 가서 확인을 해본다.

 

SOLVED!

 

문제 4: 랩: 블랙리스트 기반 입력 필터가 있는 SSRF

이 랩에는 내부 시스템에서 데이터를 가져오는 재고 확인 기능이 있습니다.

랩을 해결하려면 재고 확인 URL을 변경하여 http://localhost/admin에서 admin 인터페이스에 액세스 하고사용자를 삭제하십시오.

개발자는 우회해야 하는 안티 SSRF 방어를 배포했습니다.

연구실로 가자

 

재고 확인 기능에 가서 SSRF를 할 곳을 찾는다. 

 

문제에서 나온 대로 http://localhost/admin을 시도하면 host를 변경하라고 한다.

전 문제와는 다르게 애플리케이션이 url 구문을 분석하고 호스트를 추출한 다음 화이트리스트 방식으로 유효성을 검사한다. 호스트 추출을 어떻게 하는지 확인하는 것이 관건이다.

 

user@host 형태로 바꿔주었더니 500 error가 떴다.

 

 

이에 # 해시사인을 넣어주면 @stock~ 부분을 해시 값으로 만들어줘서 a에 위치한 localhost로 요청을 보낼 수 있다.

그러나 #을 인식을 하지 못해 다시 host를 넣으라고 하고 있다. url encoding을 해준다.

 

url 인코딩을 했으나 여전히 인식을 하지 못하는 모습이다. 한 번 더 url 인코딩을 해준다.

 

200이 드디어 떴다

 

admin으로 들어가자 carlos를 지울 수 있는 url을 볼 수 있다. 

 

stockApi=http://localhost%2523@stock.weliketoshop.net/admin/delete?username=carlos 를 요청하자

302가 뜬다. 다시 admin으로 돌아가서 carlos가 존재하는지 확인한다.

 

문제 해결!