3 ms·

1. Attacker goes to website, initiates signup up for an account 2. Website generates mail link for attacker to send 3. Attacker uses mail link to spoof emai

1. Attacker goes to website, initiates signup up for an account 2. Website generates mail link for attacker to send 3. Attacker uses mail link to spoof email 4. Account is opened for the attacker using email address This spoof attack works for both account creation and password reset (account takeover). This attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to. Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.

dcow 4y ago
Can you explain (3)?
- throwaway892238 4y ago
  The attacker just sends an email that they got from the target server's "mailto" link. They just have to use a spoofing method when they do. Such as: 1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works. It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.
9935c101ab17a66 4y ago
The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?
- remram 4y ago
  Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".
- throwaway892238 4y ago
  Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
  - archi42 4y ago
    The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails. I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
  - samtho 4y ago
    > or an attack on DNS or BGP, or any other novel spoofing attack Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries. Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
    - throwaway892238 4y ago
      It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.
- frenchman99 4y ago
  Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits. If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
  - throwaway892238 4y ago
    As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not. I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.

dcow 4y ago

Can you explain (3)?

throwaway892238 4y ago
The attacker just sends an email that they got from the target server's "mailto" link. They just have to use a spoofing method when they do. Such as: 1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works. It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.

9935c101ab17a66 4y ago

The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?

remram 4y ago
Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".
throwaway892238 4y ago
Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
- archi42 4y ago
  The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails. I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
- samtho 4y ago
  > or an attack on DNS or BGP, or any other novel spoofing attack Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries. Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
  - throwaway892238 4y ago
    It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.
frenchman99 4y ago
Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits. If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
- throwaway892238 4y ago
  As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not. I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.