1. HTTP handling anomalies
connection state attacks
First-request validation
리버스 프록시가 종종 host header로 request를 route 하도록 사용하며 whitelist로 접근 가능여부를 판단하는데 몇몇 프록시가 첫 request에만 whitelist를 적용하는 것을 발견
First-request routing
First-request routing 자체가 취약한것은 아니지만 공격자가 임의의 host header로 조작해서 back-end에 접근할수 있음 (password reset poisoning, web cache poisoning 등)
the surprise factor
http request smuggling 취약점은 대게 obfuscated Transfer-Encoding header을 통한 모호함을 이용하는 공격이라고 알려져있는데 HTTP/2 request에서 어떤 obfuscation없이도 공격이 성공하는것을 발견했다.
AWS application Load balancer에서 미스테리하게도 request를 back-end에 보낼때 message body에 아무런 변경없이 Transfer-Encoding: chunked 를 추가해서 보내는 것을 발견했다.
이것으로 알 수 있는 신기한점은 HTTP/2에서는 Content-length header가 없는것이 예외적으로 허용하지만 브라우저는 CL을 항상 보내도록 한다는것이다. 결론은 이 공격에 obfuscation, ambiguity가 꼭 필요하지 않다는것이다.
detecting connection-locked CL.TE
이 방법으로 CL.TE 사용여부를 판단할수 있다.
CL.0 browser-compatible desync
back-end가 body를 다음 request로 판단해버리는 경우가 있다. 이걸 CL.0 desync라고 한다.
정말 중요한점은 이 방법이 valid, specification-compliant HTTP request에서 발생하며 이는 front-end에서는 막을수 없음을 의미한다. 또 browser에서 발생하기도 한다. 이 공격은 back-end가 특정 request method를 요구하지 않았을때 발생한다.
H2.0 on amazon.com
아마존에서 발견한 취약점
2. Client-side desync
전형적인 desync attack은 front-end/back-end 구조가 없으면 불가능하다. 하지만 우리는 앞 내용에서 browswer-powered server-side desync를 봤다.
browser와 front-end사이에 발생하는 desync를 client-side desync(CSD)라고 하자. 이 공격은 single-server website를 공격할 수 있게한다.
Methodology
1. detect
CSD vector부터 확인해야한다.
1. server가 CL을 무시해야한다.
2. request가 web-browser cross-domain에서 가능해야한다
3. HTTP/2인지 알아내야한다. 맞을경우 실패할 확률이 크지만 proxy가 http/2를 지원하지 않는경우 가능하다.
2. confirm
3. explore / store / chain & pivot
내용이 많고 어려워서 추후 작성...
Akamai stacked-HEAD
Cisco VPN client-side cache poisoning
verisign fragmented chunk
pulse secure VPN
3. Pause-based desync
server-side
MITM-powered
4. Conclusion
further research
defence
summary
desync attack이 obfuscated or malformed requests를 막거나 내부 네트워커를 숨기거나, front-end를 가지지 않는다고 피할 수 있는것이 아님을 증명했다. custom HTTP 서버는 피하도록 해야한다.
