버그바운티(Bug Bounty) Write-up / Mass account takeovers [Slack]
Security/BugBounty Study

버그바운티(Bug Bounty) Write-up / Mass account takeovers [Slack]

https://hackerone.com/reports/737140

 

Slack disclosed on HackerOne: Mass account takeovers using HTTP...

This researcher exploited an HTTP Request Smuggling bug on a Slack asset to perform a CL.TE-based hijack onto neighboring customer requests. This hijack forced the victim into an open-redirect that forwarded the victim onto the researcher's collaborator cl

hackerone.com


해당 버그헌터는 HTTP Request Smuggling bug 라는 취약점을 이용해서 많은 계정들의 세션탈취를 성공했다고 합니다.

해당 버그는 처음들어봤는데요. 한국어로된 자료도 거의없었습니다.

https://paper.seebug.org/1049/

 

Protocol Layer Attack - HTTP Request Smuggling

Author:mengchen@Knownsec 404 Team Chinese version: https://paper.seebug.org/1048/ 1. Introduction I recently studied BlackHat's topic, and one of the topics - "HTTP Desync Attacks: Smashing into the Cell Next Door" has caused me great interest. The author

paper.seebug.org

해당 문서에 관련취약점에 대한 설명이 자세하게 되어있습니다. 간단하게 말하면, 동일한 HTTP 요청을 여러종류의 서버들이 각기 다른방식으로 처리하기 때문에 발생합니다.

Smugging bug 중에서도 CLTE(Content Length Transfer Encoding) 기법을 사용했는데 해당 공격기법은 Content-Length 헤더와 Transfer-Encoding 헤더를 동시에 전송하는 것입니다.

Transfer-Encoding은 hop-by-hop 헤더로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용하는 것입니다. 

라고 MDN에 나와있군요. 프론트엔드 서버에서는 Content-Length를, 백엔드 서버에서는 Transfer-Encoding을 각각 해석하는것을 이용하여 요청을 변조하는 것입니다.

위 그림이 실제 슬랙으로의 공격 패킷인데요. 프론트 서버에서 CL이 해석되어서, 바디값 내 GET 요청이 단순 바디데이터로 인식되어서 전송되었지만, 백엔드 서버에서 TE가 해석되면서 하나의 요청이 두개의 GET 요청으로 해석됩니다. 두번 쨰 요청에 있는 X: X 값이 버퍼에 남게되고, 또다른 요청이 올 때, 그 또다른 요청은 뒤에 붇게 되는데, 그 과정에서 변조된 하나의 패킷이 만들어 집니다.

어렵네요. Smuggling 취약점에 대해 알게되서 좋았습니다.