SSRF 감지에 대한 몇 가지 생각
DNS 플랫폼은 즉시 요청을 받은 것이 아니라 일정 시간 이후에 다른 요청 정보를 받았는데 이는 적어도 에코가 있거나 없는 SSRF가 있다는 것을 보여주지만 더 큰 피해가 있다는 것을 증명하기는 어렵지만 적어도 SSRF의 위험이 있음을 보여주므로 다음으로 그 원리를 살펴보겠습니다.
렌즈 크래킹
Cracking the lens의 연구를 바탕으로 작성된 프로젝트 홈페이지의 소개도 있습니다. 작성자의 영어 레벨이 4 미만이므로 작성자가 잘못된 요청을 구성 하고 특수 요청 헤더를 추가하여 서버 프로세스 문제를 만드는 방식으로 사용자 HTTP정의 서버에 요청을 했다는 것을 거의 이해할 수 없습니다. 간단하게 들리지만 어디에서나 colaborator 도구를 사용할 때 사실입니다.영어와 비교하면 코드가 이해하기 쉽습니다. 주입 지점과 payload형태를 정의합니다.
요청을 처리하고 각 요청에 위의 내용을 추가합니다.payload
주입 지점이 무엇이든 요청 헤더가 추가됨을 알 수 있습니다 Cache-Control: no-transform. 이 필드의 주요 기능은 캐시를 제어하는 것이며 no-transform어떤 상황에서도 처리가 수행되지 않음을 의미합니다. 요청 응답. 이 필드는 전송 중에 요청이 처리되어 정상적인 감지가 수행되지 않는 것을 방지하기 위해 추가됩니다. 처리된 요청 헤더는 다음과 같습니다.
[1] 모든 리소스 획득 <1] 1. 네트워크 보안 학습 경로 2. 전자책(흰색 모자) 3. 보안 대기업의 내부 비디오 4. 100개의 src 문서 5. 일반적인 보안 면접 질문 6. 일반적인 질문 분석 ctf 경쟁 7 , 도구 키트 전체 세트 8, 비상 대응 메모
지금까지는 실제로 찾았 SSRF지만 접속 기록만으로는 부족하고, 트리거 요청과 접속 기록을 연관시켜 작성자가 감지한 결과를 게시하는 것도 필요하다.
collaborator요청이 수신되었는지 확인하기 위해 루프를 돌고 요청과 그 원인을 표시합니다.
지금까지 도구의 구현 원리는 이해되었지만 기사의 소개와 분명히 비교할 때 주입 지점은 header필드에만 적용되며 Blind-SSRF는 보완이라고 할 수 있습니다.
블라인드-SSRF
세 가지 유형의 템플릿으로 나눌 수 있습니다.
-
특정 요청 헤더 추가
-
Host필드 수정 -
URL처리 하다
사실 요청 헤더를 추가하는 것은 말이 필요 없다 위와 같지만 요청에 필드를 추가하는 방식을 사용한다는 점에서 차이가 있다 요청 패킷 중 하나는 다음과 같다
WL-Proxy-Client-IP유사 와 유사하게 X-Forwarded-For일반적으로 클라이언트를 얻는 데 사용됩니다 IP.
후자의 두 가지 처리는 훨씬 더 복잡하며 일반적으로 원문에서 언급한 예와 같이 논리적 처리 오류로 인해 발생하는 문제입니다.
Url backendURL = "http://public-backend/";String uri = ctx.getRequest().getRawUri();URI proxyUri;try {proxyUri = new URIBuilder(uri).setHost(backendURL.getHost()).setPort(backendURL.getPort()).setScheme(backendURL.getScheme()).build();} catch (URISyntaxException e) {Util.sendError(ctx, 400, INVALID_REQUEST_URL);return;}
코드 복사
버전 으로 시작 하는지 여부 Apache HttpComponents 4.5.1는 감지하지 않습니다 . 즉, 잘못된 형식의 요청을 구성하여 지정된 주소 이외의 주소에 액세스 할 수 있습니다. 예를 들면 다음과 같습니다.uri/HTTPbackendURL
스플라이싱 후 얻은 형식은 proxyUri실제로 http://public-backend@host이 형식이며 @전자는 public-backend사용자 이름으로 사용되며 실제 요청된 주소는 uri에 지정됩니다 host.
버프4SSRF
이전 기사의 두 가지 도구는 이미 감지할 수 SSRF있지만 아직 몇 가지 결함이 있습니다.
-
collaborator-everywhere 상황은 포괄적으로 다루지 않으며, 요청에서
referer직접 수정 등을 한 후 요청 오류가 발생하는 경우가 있습니다. -
blind-ssrf는 취약점을 시각적으로 표시할 수 없습니다.
이러한 문제에 대해 저자는 collaborator-everywhere더 넓은 영역을 커버하도록 간단한 수정을 가함과 동시에 정상적인 요청이 영향을 받지 않도록 수동 스캐닝 방법을 채택하기로 결정했습니다.
첫 번째는 요청 방식을 수정하는 것입니다. 이것은 매우 간단합니다. 에서 원래 상속을 IProxyListener변경하기 만 IScannerCheck하면 됩니다. 전자는 요청이 진행 중일 때 요청이 처리됨을 나타내고 후자는 능동 또는 수동으로 전달됩니다. 처리를 위한 스캐너 변경된 스캔 로직은 함수에 Injector있습니다 doPassiveScan.
injectPayloads인젝션 후 에 header함수 를 사용하여 param요청 을 보냅니다.requestmakeHttpRequest
주입 지점 처리 Host및 주입 지점으로 여기에 새로운 기능이 uri추가되었습니다 .injectAnyWhere
기존 주입 지점을 처리한 후 나머지는 별도로 처리 raw됩니다 . 다음 은 요청 패킷의 첫 번째 줄에서 교체한 것입니다. 이 두 가지 유형은 요청 본문에 돌이킬 수 없는 영향을 미치기 때문에 여기에서는 각 요청을 한 번 전송합니다. 이전 사례에서와 같이 모든 통합을 한 번 보내는 대신 . 지금까지 처음 몇 가지 문제가 해결되었으며 실제 사용 후 결과는 다음과 같습니다.hostrawpayloadpayload
요약하다
DNSLog이것은 새로운 기술은 아니지만 실제 침투에서 예상치 못한 이득이 있는 경우가 많습니다