SMTP Smuggling
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
이러한 유형의 취약점은 이 게시물에서 처음 발견되었습니다 여기서 이메일을 최종화할 때 SMTP 프로토콜이 해석되는 방식의 불일치를 악용할 수 있습니다. 이를 통해 공격자는 합법적인 이메일 본문에 더 많은 이메일을 밀어넣을 수 있으며, 이는 영향을 받는 도메인의 다른 사용자(예: admin@outlook.com)로 가장할 수 있게 해줍니다. SPF와 같은 방어를 우회합니다.
이는 SMTP 프로토콜에서 이메일로 전송될 메시지 데이터가 사용자(공격자)에 의해 제어되기 때문입니다. 이 사용자는 파서의 차이를 악용하여 수신자에게 추가 이메일을 밀어넣는 특별히 조작된 데이터를 보낼 수 있습니다. 원래 게시물의 이 그림 예제를 살펴보세요:
이 취약점을 악용하기 위해 공격자는 아웃바운드 SMTP 서버가 단지 1개의 이메일로 생각하는 데이터를 보내야 하지만 인바운드 SMTP 서버는 여러 이메일이 있다고 생각해야 합니다.
연구자들은 서로 다른 인바운드 서버가 이메일 메시지의 데이터 끝을 나타내는 서로 다른 문자를 고려한다는 것을 발견했습니다. 아웃바운드 서버는 그렇지 않습니다.
예를 들어, 데이터의 일반적인 끝은 \r\n.입니다. 그러나 인바운드 SMTP 서버가 \n.도 지원하는 경우, 공격자는 이 데이터를 이메일에 추가하고 새로운 이메일을 밀어넣기 위한 SMTP 명령을 시작할 수 있습니다. 이전 이미지와 같이.
물론, 이는 아웃바운드 SMTP 서버가 이 데이터를 메시지 데이터의 끝으로 처리하지 않을 경우에만 작동합니다. 그렇지 않으면 1개의 이메일 대신 2개의 이메일로 보게 되므로, 결국 이것이 이 취약점에서 악용되는 비동기화입니다.
잠재적인 비동기화 데이터:
\n.
\n.
또한 SPF가 우회되는 이유는 user@outlook.com의 이메일에서 admin@outlook.com의 이메일을 밀어넣으면 발신자는 여전히 outlook.com이기 때문입니다.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
