3 ms·
Check out the TLS SNI exploit. The attack allows embedding CRLF in a TLS payload. The entire handshake leading up to it is ignored by an SMTP server, and the ne
by nothrabannosir 8y ago
Check out the TLS SNI exploit. The attack allows embedding CRLF in a TLS payload. The entire handshake leading up to it is ignored by an SMTP server, and the next command is valid SMTP. Meaning that if you ask something to e.g. load an image from, or send a callback to "https://smtp.targetcorp.com<space><CR><LF>...smtp https://smtp.targetcorp.com<space><CR><LF>...smtp instructions to send mail here...:25/" it'll actually work. As far as I understand this is the TLS handshake so even before any HTTP is done; post, get, whatever. All works.
Good moment to lock down outgoing requests, I guess. At least to port 25 :)
- deleted 8y ago[deleted]
- jrochkind1 8y agoWait, how does "targetcorp.com<space>etc" even DNS resolve? Trying to wrap my head around this one.
- jsjohnst 8y agoThat’s covered in the slides. Check Glibc section on gethostbyaddr().
- userbinator 8y agoI've not communicated with SMTP servers manually all that much, but I remember my ISP's SMTP server would just close the connection if you sent it something it didn't understand.
- Kalium 8y agoThat sounds like most SMTP servers - they just reject what they don't understand. The wrinkle here that might be, in the opinion of some, worth noting is that this gives SMTP servers something they understand fully. The HTTP server has been convinced to send perfectly well-formed and valid SMTP commands.
- treve 8y agoThat sounds like a good second mitigation then. Only allow known HTTP ports.