5 ms·

The blog post is a bit poor; this seems like a packet racing vulnerability where by the attacker attempts to hijack the session. This means that the attacker n

The blog post is a bit poor; this seems like a packet racing vulnerability where by the attacker attempts to hijack the session. This means that the attacker needs to be on the same network network as the victim as spoofing the IP on a TCP connection is rather challenging. Not great but also not particularly useful in the real world either.

tremon 2y ago
That's not the only way, DNS cache poisoning or hijacking can also redirect a victim to an attacker-controlled proxy. Or am I missing something?
- dogma1138 2y ago
  If you can redirect the victim to a proxy via DNS poisoning you don’t need this attack you can simply pretend to be the mail server; not only that but it doesn’t actually allows you to execute this specific attack. How this works is that you inject the commands into the plain text of the victim which requires packet racing or some other local network attack that allows you to take over the TCP stream. How this works is that the victim sends from:, creds, to:, email content but you somehow inject starttls, from:, creds:, to: a head of it which forces the entire message from the victim to be treated as data fully so the SMTP commands are disregarded which means you will be receiving an email with their credentials. I highly suspect that SMTP without starttls will work in the same manner, but perhaps the opportunistic encryption gives more time for this attack to be more effective. Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover. I honestly can’t really think of a scenario where you could launch a network attack that would allow you to inject yourself in the middle in this manner that won’t allow you also to eavesdrop on credentials sent in plaintext or MITM the entire thing.
  - jsiepkes 2y ago
    > If you can redirect the victim to a proxy via DNS poisoning you don’t need this attack you can simply pretend to be the mail server. Not if the client uses SMTPS (i.e. SMTP with TLS) on port 587. Which is actually quite common for mail clients.
    - dogma1138 2y ago
      Yes but then this attack doesn’t work either, you need a client that is happy with either unencrypted SMTP or one that will attempt opportunistic encryption.
  - maxdamantus 2y ago
    > Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover. MITM attacks is one of the major reasons for using TLS/PKI. You might have total control over the TLS connections I make to a website, but you won't be able to inject information in either direction. All you can do is observe the amount of data being transferred and terminate/hang/throttle the connection. If you send something effectively different to what was intended by the sender, the recipient will detect it as a TLS error and terminate the connection. This attack involves injecting information before STARTTLS which puts the connection into a state that the client is not aware of, this is not normally possible in plain TLS connections.
    - dogma1138 2y ago
      MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now. So this leaves internet scale MITM which means TLAs and other actors at a similar scale. The TLDR here is that if you can MITM a clear text protocol without any integrity verification then you can alter the message, I’m honestly not entirely sure why is this report worthy on its own. The issues with STARTTLS are known since the RFC was published.
      - Avamander 2y ago
        > MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now. That's a strong claim. Most home networks most certainly aren't. There's also no enforcement so someone evil can always set up an evil twin, so what that the original has client isolation.
        stackskipton 2y ago
        I would imagine ~99.9% of email submitted by end users is done over HTTPS which are highest risk. Servers talking to Servers are almost entirely wired so risk there is much lower which is probably why email providers have been slow to patch this.
gerdesj 2y ago
Many cloudy environments end up economizing on IP addresses. That means that there will be loads of neighbours, not all of them will be your mates. Once you have found a way in via another method, you now have this weapon to deploy. STARTTLS is massively used to secure internal comms as a (cough) "best practice". The article notes email related protocols but AD via LDAP is often accessed via port 389 with STARTTLS. You may not be familiar with Hanno - he's been around for a while and knows what he is on about. I'm not sure which real world you inhabit. This is quite horrendous. (I'm not sure why "implicit" is used instead of "explicit" for full on TLS over STARTTLS. I suspect English as a foreign language).
- mistrial9 2y ago
  as a civilian, if cloud compute server conditions internally result in exposing some mid-transaction packet insertion problem as a real thing, AND that in turn justifies some massive re-deployment of new network drivers stacks to the detriment of just about everybody's gray hairs and finite hours in the day, then actually screw that, with emphasis.
  - gerdesj 2y ago
    Your keyboard should have at least two shift keys. We are generally all civilians (both of my parents were soldiers - I'm not but I did love growing up in West Germany, funny old world). This is yet another CVS and as I happen to be the MD of an IT company, I take it seriously. It is a bit of a pain having to patch a lot of systems every month and fiddle with firewall rules in response to notes and more besides. I don't intend to feature in an el Reg or HN article. I've been lucky so far. Have you found the shift keys?
- thayne 2y ago
  > STARTTLS is massively used to secure internal comms as a (cough) "best practice" Well, I've seen it be a "best practice", because of some legacy component that only supported ldap with starttls or plaintext. It wasn't so much "starttls is great" as "starttls is the best we can do right now".
- 2y ago
USiBqidmOOkAqRb 2y ago
With the amount of air conditioners and coffee makers (et al.) connected to WiFi I think lapses in correct separation is more frequent than anyone would be willing to admit. Maybe not too practical to hijack a TCP stream, but still worth to remember if anyone claims to be protected by NAT.

tremon 2y ago

That's not the only way, DNS cache poisoning or hijacking can also redirect a victim to an attacker-controlled proxy. Or am I missing something?

dogma1138 2y ago
If you can redirect the victim to a proxy via DNS poisoning you don’t need this attack you can simply pretend to be the mail server; not only that but it doesn’t actually allows you to execute this specific attack. How this works is that you inject the commands into the plain text of the victim which requires packet racing or some other local network attack that allows you to take over the TCP stream. How this works is that the victim sends from:, creds, to:, email content but you somehow inject starttls, from:, creds:, to: a head of it which forces the entire message from the victim to be treated as data fully so the SMTP commands are disregarded which means you will be receiving an email with their credentials. I highly suspect that SMTP without starttls will work in the same manner, but perhaps the opportunistic encryption gives more time for this attack to be more effective. Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover. I honestly can’t really think of a scenario where you could launch a network attack that would allow you to inject yourself in the middle in this manner that won’t allow you also to eavesdrop on credentials sent in plaintext or MITM the entire thing.
- jsiepkes 2y ago
  > If you can redirect the victim to a proxy via DNS poisoning you don’t need this attack you can simply pretend to be the mail server. Not if the client uses SMTPS (i.e. SMTP with TLS) on port 587. Which is actually quite common for mail clients.
  - dogma1138 2y ago
    Yes but then this attack doesn’t work either, you need a client that is happy with either unencrypted SMTP or one that will attempt opportunistic encryption.
- maxdamantus 2y ago
  > Every other scenario requires you to be able to MITM the traffic which is pretty much already gameover. MITM attacks is one of the major reasons for using TLS/PKI. You might have total control over the TLS connections I make to a website, but you won't be able to inject information in either direction. All you can do is observe the amount of data being transferred and terminate/hang/throttle the connection. If you send something effectively different to what was intended by the sender, the recipient will detect it as a TLS error and terminate the connection. This attack involves injecting information before STARTTLS which puts the connection into a state that the client is not aware of, this is not normally possible in plain TLS connections.
  - dogma1138 2y ago
    MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now. So this leaves internet scale MITM which means TLAs and other actors at a similar scale. The TLDR here is that if you can MITM a clear text protocol without any integrity verification then you can alter the message, I’m honestly not entirely sure why is this report worthy on its own. The issues with STARTTLS are known since the RFC was published.
    - Avamander 2y ago
      > MITM attacks today are extremely difficult to execute. Most local networks are immune to traditional types of attacks such as arp spoofing/poisoning and wifi networks outside of one’s home have had client isolation enabled by default for at least a decade now. That's a strong claim. Most home networks most certainly aren't. There's also no enforcement so someone evil can always set up an evil twin, so what that the original has client isolation.
      - stackskipton 2y ago
        I would imagine ~99.9% of email submitted by end users is done over HTTPS which are highest risk. Servers talking to Servers are almost entirely wired so risk there is much lower which is probably why email providers have been slow to patch this.

gerdesj 2y ago

Many cloudy environments end up economizing on IP addresses. That means that there will be loads of neighbours, not all of them will be your mates. Once you have found a way in via another method, you now have this weapon to deploy. STARTTLS is massively used to secure internal comms as a (cough) "best practice". The article notes email related protocols but AD via LDAP is often accessed via port 389 with STARTTLS. You may not be familiar with Hanno - he's been around for a while and knows what he is on about. I'm not sure which real world you inhabit. This is quite horrendous. (I'm not sure why "implicit" is used instead of "explicit" for full on TLS over STARTTLS. I suspect English as a foreign language).

mistrial9 2y ago
as a civilian, if cloud compute server conditions internally result in exposing some mid-transaction packet insertion problem as a real thing, AND that in turn justifies some massive re-deployment of new network drivers stacks to the detriment of just about everybody's gray hairs and finite hours in the day, then actually screw that, with emphasis.
- gerdesj 2y ago
  Your keyboard should have at least two shift keys. We are generally all civilians (both of my parents were soldiers - I'm not but I did love growing up in West Germany, funny old world). This is yet another CVS and as I happen to be the MD of an IT company, I take it seriously. It is a bit of a pain having to patch a lot of systems every month and fiddle with firewall rules in response to notes and more besides. I don't intend to feature in an el Reg or HN article. I've been lucky so far. Have you found the shift keys?
thayne 2y ago
> STARTTLS is massively used to secure internal comms as a (cough) "best practice" Well, I've seen it be a "best practice", because of some legacy component that only supported ldap with starttls or plaintext. It wasn't so much "starttls is great" as "starttls is the best we can do right now".
2y ago

USiBqidmOOkAqRb 2y ago

With the amount of air conditioners and coffee makers (et al.) connected to WiFi I think lapses in correct separation is more frequent than anyone would be willing to admit. Maybe not too practical to hijack a TCP stream, but still worth to remember if anyone claims to be protected by NAT.