8 ms·

Security downgrade with IMAP STARTTLS leads to information leakage

28 points by based2 6y ago

corty 6y ago
That is why one should always use the appropriate "s" port if possible, like in imaps, pop3s or smtps. Then downgrade to TLS-less via fiddling with the STARTTLS exchange maliciously or through a bug is impossible. Imho STARTTLS needs to die. Maybe thats impossible for SMTP, but for everything else we can and should get rid of it!
- grawlinson 6y ago
  Any sysadmin worth their salt would’ve seen this coming from a mile off. My self hosted mail server only runs {smtp,imap}s, due to encryption being required from the get-go. Any other way seems foolish.
  - corty 6y ago
    Well, I do run possibly unencrypted smtp on port 25, because I want to receive all my email, not just a tiny fraction of it. Most mails will use smtp and starttls, some plaintext smtp. Nothing uses smtps on 465... Oh, and the smtp submission port 587 of course still uses starttls, which, together with mandatory authentication on that port, also makes for wonderful misconfiguration opportunities on the server. Of course in addition to clients stupidly sending auth over plaintext on 587.
    - user5994461 6y ago
      A ton of embedded systems and software relies on having an open SMTP relay to send emails. Network printers and monitoring solutions are a prime culprit. Companies very often have open SMTP relays, actively used by these. It's a plague to remove SMTP because how can you remove open SMTP when these things don't support TLS nor authentication?
- jojobas 6y ago
  This bug could have an equivalent in imaps if the client decided to send plaintext data under some conditions.
  - corty 6y ago
    Yes, but TLS downgrade bugs that revert to plaintext are getting rarer due to better TLS libraries preventing the use of NULL ciphers and the like. I would say it is possible but far less likely than a starttls downgrade, where the plaintext stuff is an integral part of every connection, and the dangerous codepath is right next to the encrypted happy path with frequent crossings...
- gittes 6y ago
  It's a similar story with LDAPS, in that LDAP+TLS starts off on a plain text connection to negotiate TLS, and it can be all the same port 389 (can be different port 636 too). You might be able to query too much info from a poorly configured LDAP server if it downgrades or sustains that TLS-less connection. You still see people and software libraries preferring LDAP+SSL on the dedicated SSL port 636 even though the LDAPS+TLS is suppose to be the "modern" method and apart of the LDAP spec.
- cm2187 6y ago
  SMTP needs to die too. Is there even a competing protocol in the pipeline that would mandate encryption and prevent the spoofing of the sender? Every piece of duck tape on top of smtp (startrls, spf, dkim) are optional, cannot be relied on, and often isn’t relied on.
  - user5994461 6y ago
    Agreed on everything but SPF. SPF is very simple and works really well.
    - cm2187 6y ago
      But it is so often misconfigured or not configured that it is not that useful. Something like a strict spf should be part the mandatory protocol so you can safely reject incoming mails who fail the rules.
  - corty 6y ago
    Just use any modern IM protocol for that, like matrix, xmpp or maybe even one of the proprietary ones. They all do what SMTP does and more, you would just need to skin the client to look like a mail client to fool your users.
    - cm2187 6y ago
      I meant rather with the aim of progressively replacing smtp. We complain about these protocols that are too widespread to ever be retired but the reality is that TLS and http are managing the pace, ftp, pop and imap are almost gone, and smtp is probably the last of the 1990s protocols that is frozen in time while being a backbone of communications (and attack vectors) on the internet.
      - corty 6y ago
        Maybe, but progressive replacement also got us dkim, spf and all that. So I'm not sure that there is a possible way to do this for SMTP in any "good" way...
- bigiain 6y ago
  I once billed $majorAustralianBank about $70k for time spent debugging (and proving to their IT team) that an edge router in their internal network was a Cisco box that was running a specific (and well out of date) version of the OS that in default configuration was intentionally munging any STARTTLS commands that went through it, so all mail passing through was force downgraded to plain text across int internet (into their Microsoft Office hosted mail system). Nobody involved at $bank even knew of the existence of this router, and they spent several weeks not believing they even owned that model of Cisco gear or that they had any Cisco gear that wasn't fully updated. It was "fun times" debugging that and documenting/proving exactly what was breaking with no more access than sftp to a web server running non root privileged PHP. (We may have gone fairly dark-grey hat and broken quite a few internal rules to achieve that... Then had to "parallel construct" our investigation (before I even knew that term) to explain to their tech people haw we'd identified the root cause.)
  - jlgaddis 6y ago
    ASA Version 8.3(3)? Or were they actually using the IOS Firewall on a router instead of a firewall? PIX and ASA appliances used to ship with "ESMTP inspection" enabled by default -- which would strip out the "STARTTLS" advertisement (replacing it with "X"s) from a server's response.
  - joombaga 6y ago
    I'd never heard the term "parallel construct" before either, but I've definitely walked that grey line carefully when disclosing privilege escalation discovery methods. Can you say anymore? I'm curious what you came up with. For the benefit of others (from Wikipedia) > Parallel construction is a law enforcement process of building a parallel, or separate, evidentiary basis for a criminal investigation in order to conceal how an investigation actually began.
- tialaramex 6y ago
  For a new protocol there's no reason an unencrypted variant would exist. Even for HTTP/2 which is fairly old at this point, there aren't in practice unencrypted servers. So STARTTLS only matters for protocols that already existed, like SMTP and IMAP, and as a result your advice isn't useful without a time machine. I'd be impressed if as much as 50% of the world's IMAP clients would actually prevent a trivial MITM attack today regardless of this bug, because usually it's left to the user and we know users just want to see the funny cat pictures.
pronoiac 6y ago
Very helpful subtitle: "Security Vulnerabilities fixed in Thunderbird 68.9.0"
BuildTheRobots 6y ago
I believe Dovecot can be configured not to even advertise AUTH capability until after you've upgraded to TLS capability. Does anyone know if that would stop this problem? Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help.
- mjevans 6y ago
  The correct response is to require TLS before auth clientside (as well) unless expressly configured to not attempt TLS auth.
- jlgaddis 6y ago
  > Does anyone know if that would stop this problem? Based on my experiences with Dovecot, I believe it would, > Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help. Well, hopefully your client isn't braindead and will negotiate an encrypted session first, before sending credentials unencrypted -- especially if you've configured it to use STARTTLS.

28 points by based2 6y ago

That is why one should always use the appropriate "s" port if possible, like in imaps, pop3s or smtps. Then downgrade to TLS-less via fiddling with the STARTTLS exchange maliciously or through a bug is impossible. Imho STARTTLS needs to die. Maybe thats impossible for SMTP, but for everything else we can and should get rid of it!

grawlinson 6y ago
Any sysadmin worth their salt would’ve seen this coming from a mile off. My self hosted mail server only runs {smtp,imap}s, due to encryption being required from the get-go. Any other way seems foolish.
- corty 6y ago
  Well, I do run possibly unencrypted smtp on port 25, because I want to receive all my email, not just a tiny fraction of it. Most mails will use smtp and starttls, some plaintext smtp. Nothing uses smtps on 465... Oh, and the smtp submission port 587 of course still uses starttls, which, together with mandatory authentication on that port, also makes for wonderful misconfiguration opportunities on the server. Of course in addition to clients stupidly sending auth over plaintext on 587.
  - user5994461 6y ago
    A ton of embedded systems and software relies on having an open SMTP relay to send emails. Network printers and monitoring solutions are a prime culprit. Companies very often have open SMTP relays, actively used by these. It's a plague to remove SMTP because how can you remove open SMTP when these things don't support TLS nor authentication?
jojobas 6y ago
This bug could have an equivalent in imaps if the client decided to send plaintext data under some conditions.
- corty 6y ago
  Yes, but TLS downgrade bugs that revert to plaintext are getting rarer due to better TLS libraries preventing the use of NULL ciphers and the like. I would say it is possible but far less likely than a starttls downgrade, where the plaintext stuff is an integral part of every connection, and the dangerous codepath is right next to the encrypted happy path with frequent crossings...
gittes 6y ago
It's a similar story with LDAPS, in that LDAP+TLS starts off on a plain text connection to negotiate TLS, and it can be all the same port 389 (can be different port 636 too). You might be able to query too much info from a poorly configured LDAP server if it downgrades or sustains that TLS-less connection. You still see people and software libraries preferring LDAP+SSL on the dedicated SSL port 636 even though the LDAPS+TLS is suppose to be the "modern" method and apart of the LDAP spec.
cm2187 6y ago
SMTP needs to die too. Is there even a competing protocol in the pipeline that would mandate encryption and prevent the spoofing of the sender? Every piece of duck tape on top of smtp (startrls, spf, dkim) are optional, cannot be relied on, and often isn’t relied on.
- user5994461 6y ago
  Agreed on everything but SPF. SPF is very simple and works really well.
  - cm2187 6y ago
    But it is so often misconfigured or not configured that it is not that useful. Something like a strict spf should be part the mandatory protocol so you can safely reject incoming mails who fail the rules.
- corty 6y ago
  Just use any modern IM protocol for that, like matrix, xmpp or maybe even one of the proprietary ones. They all do what SMTP does and more, you would just need to skin the client to look like a mail client to fool your users.
  - cm2187 6y ago
    I meant rather with the aim of progressively replacing smtp. We complain about these protocols that are too widespread to ever be retired but the reality is that TLS and http are managing the pace, ftp, pop and imap are almost gone, and smtp is probably the last of the 1990s protocols that is frozen in time while being a backbone of communications (and attack vectors) on the internet.
    - corty 6y ago
      Maybe, but progressive replacement also got us dkim, spf and all that. So I'm not sure that there is a possible way to do this for SMTP in any "good" way...
bigiain 6y ago
I once billed $majorAustralianBank about $70k for time spent debugging (and proving to their IT team) that an edge router in their internal network was a Cisco box that was running a specific (and well out of date) version of the OS that in default configuration was intentionally munging any STARTTLS commands that went through it, so all mail passing through was force downgraded to plain text across int internet (into their Microsoft Office hosted mail system). Nobody involved at $bank even knew of the existence of this router, and they spent several weeks not believing they even owned that model of Cisco gear or that they had any Cisco gear that wasn't fully updated. It was "fun times" debugging that and documenting/proving exactly what was breaking with no more access than sftp to a web server running non root privileged PHP. (We may have gone fairly dark-grey hat and broken quite a few internal rules to achieve that... Then had to "parallel construct" our investigation (before I even knew that term) to explain to their tech people haw we'd identified the root cause.)
- jlgaddis 6y ago
  ASA Version 8.3(3)? Or were they actually using the IOS Firewall on a router instead of a firewall? PIX and ASA appliances used to ship with "ESMTP inspection" enabled by default -- which would strip out the "STARTTLS" advertisement (replacing it with "X"s) from a server's response.
- joombaga 6y ago
  I'd never heard the term "parallel construct" before either, but I've definitely walked that grey line carefully when disclosing privilege escalation discovery methods. Can you say anymore? I'm curious what you came up with. For the benefit of others (from Wikipedia) > Parallel construction is a law enforcement process of building a parallel, or separate, evidentiary basis for a criminal investigation in order to conceal how an investigation actually began.
tialaramex 6y ago
For a new protocol there's no reason an unencrypted variant would exist. Even for HTTP/2 which is fairly old at this point, there aren't in practice unencrypted servers. So STARTTLS only matters for protocols that already existed, like SMTP and IMAP, and as a result your advice isn't useful without a time machine. I'd be impressed if as much as 50% of the world's IMAP clients would actually prevent a trivial MITM attack today regardless of this bug, because usually it's left to the user and we know users just want to see the funny cat pictures.

pronoiac 6y ago

Very helpful subtitle: "Security Vulnerabilities fixed in Thunderbird 68.9.0"

BuildTheRobots 6y ago

I believe Dovecot can be configured not to even advertise AUTH capability until after you've upgraded to TLS capability. Does anyone know if that would stop this problem? Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help.

mjevans 6y ago
The correct response is to require TLS before auth clientside (as well) unless expressly configured to not attempt TLS auth.
jlgaddis 6y ago
> Does anyone know if that would stop this problem? Based on my experiences with Dovecot, I believe it would, > Saying that, someone with MITM capability could just modify the response and advertise auth pre-tls, so it probably wouldn't help. Well, hopefully your client isn't braindead and will negotiate an encrypted session first, before sending credentials unencrypted -- especially if you've configured it to use STARTTLS.