SSRF 보호 우회

여보세요,

오랫만에 포스팅합니다. 사설 프로그램에서 사냥하다가 찾은 깔끔한 SSRF 바이패스를 공유하고자 합니다.

SSRF는 서버 측 요청 위조를 나타냅니다. 서버 측 요청 위조를 통해 공격자는 HTTP 요청을 악용하여 서버 내부 또는 내부 네트워크에 대한 정보를 요청할 수 있습니다.

주의해야 할 점은? url= next= host= image= img= 등과 같은 매개변수. 서버에 웹 요청을 하는 것으로 보이는 모든 것. 그런 다음 내부적으로 요청을 가리키도록 남용될 수 있습니다.

취약한 끝점을 어떻게 찾았습니까?

개인 프로그램에서 사냥하는 동안 광범위한 정찰을 수행했습니다. 나는 주로 censys에서 가져오는 거대한 하위 도메인 목록을 수집했습니다. 그 후, 나는 모든 호스트의 URL에 대해 웨이백 머신에서 무차별 대입을 하고 검색했습니다. 그 당시에는 ssrf에 초점을 맞추었기 때문에 디렉토리와 엔드포인트 출력을 수집하고 "proxy.php"를 찾았습니다. 운 좋게도 나는 히트를 쳤다.

요청을 조사할 때 이것은 지정된 URL에 대한 아웃바운드 HTTP 요청을 만드는 것이었습니다. Burp 공동 작업자 링크를 입력하면 조회를 받지 못했습니다. 나는 127.0.0.1과 내부 호스트의 IP 표기법을 입력하는 일반적인 기본 사항을 시도했는데 요청에 웹 사이트 호스트 이름이 없으면 각 요청이 차단되었습니다.

이것은 일이 기술적으로 이루어지는 곳입니다. url=https:// hostnameofwebsite.com@myburpcollablink 와 같이 브라우저 자격 증명 형식과 함께 내 트림 협력자와 같은 요청을 보낼 때 나는 반격을 받았습니다.

그런 다음 현재 위의 브라우저를 사용하여 myburpcollablink에 대한 자격 증명으로 hostnameofwebsite를 보내는 브라우저를 사용하고 있었기 때문에 이것을 변경하여 악용하려고 시도했지만 좋지 않았습니다.

나는 최근에 \를 사용하면 첫 번째 호스트 이후 백엔드에서 구문 분석을 중지한다고 설명했을 때 Google에서 ssrf 비디오를 보았습니다. 프런트 엔드는 hostnameofwebsite로 요청을 myburpcollablink에 대한 자격 증명으로 해석하지만 백엔드는 hostnameofwebsite로 프런트 엔드 요청만 처리합니다. 여기에서 변경하고 url=http://169.254.1698.254\@hostnameofwebsite를 사용했습니다.

설명하자. 169.254는 AWS 메타데이터의 내부 IP 주소입니다. 프런트 엔드 요청은 hostnameofwebsite에 대한 자격 증명으로 169.254로 보고 있으며 hostnameofwebsite가 요청에 있어야 하므로 프런트 엔드 검사를 통과합니다. 백엔드는 이 형식을 무시하고 다음과 같이 처리합니다.http://169.254.169.254\그런 다음 요청을 차단하고 전달합니다.

해결된 대로 종료됨