Is it possible for an attacker to change my sent emails content before arrival?

Question

I have a web application that sends "change password link" to user that wants to changhe his password.

The link is something like this:

http:// www.my-domain.com/changepass?uid=username&secretkey=some-hardly-encoded-secure-key

Is it possible to change my email content before arrival? I have a scenario in my mind but I don't know anything about possibility of it.

1. Attacker gets my sent email before recipient
2. Attacker changes the link inside my email to something like this:

http:// www.attackers-domain.com/changepass?uid=username&secretkey=some-hardly-encoded-secure-key

1. Attacker Sends the email to recipient (The original user)
2. User clicks on the wrong link inside email and goes to wrong place for changing his password
3. User enters his new password in attackers site
4. Attackers site sends new password using right protocol to me and changes users password

and now:

1. User does not know anything about the attack
2. Attacker has users new password

Answer 1

It is possible, but requires a relatively sophisticated attack. E-mail is generally insecure. Secure protocols do exist for exchanging e-mail, but very few servers actually use it.

If the attacker is able to execute what is known as a man in the middle attack, they could change anything they wanted about the e-mail. A man in the middle attack requires that they have control over some part of the e-mail's route from sender to recipient. This could be either the sending or receiving mail server, the user's e-mail client, or any Internet router that the e-mail happens to pass through along its way.

If the attacker can get in the middle, it is trivial to adjust, but it is relatively hard to get in to the middle unless they are a relatively established hacker with a decent amount of resources available to them.

In your case, the easiest countermeasure is the use of an HTTPS based link. If you use SSL and the user bothers to check that the URL corresponds to your site, then the attack scenario doesn't work. You could also tell them the domain that the link will go to when they choose to reset their password, that way they know if it is valid. This is probably the easiest solution.

Answer 2

The possibility you describe exists; as others have noted, it is a "man in the middle attack".

In order to thwart it, you would need an additional secret that is not sent by email, such as (poor secret as it is) a cookie key. You can ask the user to reset the password using the same computer and browser used to send the "I want to reset my password" command.

Then, the attacker will be unable to send the appropriate cookie, because his domain being different from the original one, the browser won't have told him the appropriate cookie value to use.

A stricter possibility is to require the user to insert in the "Password reset" page, without closing it, a code that is being sent through email. The email at that point doesn't even contain a link. The attacker knows the code, but he hasn't control on the open browser window. The window may either contain a hidden secret that the server is "telling" to itself, or a cookie (which is basically the same thing). To avoid using persistent information, the server might store in the page a random string, and send the random string hashed with a secret salt. The user will then fill in a form that has both values (one hidden, one copied from the email). The server hashes the code with its secret salt. If the two strings are equal, the change is approved. To avoid "repeat attacks" in this case (i.e., reuse of a known challenge/hash pair), the check might include the user name and a timestamp:

form
    username    hidden (e.g. "lserni")
    timestamp   hidden (e.g. 20140108131005)
    hash        hidden (e.g. "e2961ca083b4393690ec74b93d3c4b32")
    code        input

The user receives the code "123456", at random from 100000 to 999999. There's one possibility in about nine hundred thousand of successfully guessing it. The server concatenates SERVERSECRETPASSWORD.lserni.20140108131005.123456 and verifies that it hashes to e2961ca083b4393690ec74b93d3c4b32.

The attacker can guess the timestamp, but has no access to the hash. Knowing a hash and its corresponding code will only work on the rightful username, and only until the difference between the stored timestamp, that can't be changed, and the wall clock won't grow too large, at which point the server shall offer to send another email.

A possible (unavoidable) problem

On the other hand, if the attacker has control of the email, he can initiate a password recovery himself and be granted full access to the resource at least once. To guard against this, some other information (e.g. a "secret question") should have to be supplied to initiate password reset. Also, a warning in case of unsuccessful authentication should be issued to the user, so that he is made aware of the problem ("Wrong password. Please remember that you changed the password yesterday at 17:23 from IP 1.2.3.4. If you did not do that, please be advised that...");

Another possible issue

On some systems, you will be allowed to ask the server to "remember you". The server will do this by issuing a cookie that is, in every respect, a weak authentication and might no longer be connected with the password.

A change of password should invalidate all such cookies, otherwise the attacker can: - take control of the email - initiate a password reset - intercept the password reset code - delete the email with the password reset - change the password - ask the server "Remember me" and obtain a "Get Home Free" cookie - profit - the user will discover himself unable to login - he will change the password and log back in - the attacker will still be able to log in with his cookie.

One way to do this is to set the cookie to a random string plus the hash of a server secret, the random string, the user name, and the user's password hash in the database. A change of password will then automatically obsolete all extant authentication cookies for that user.

Answer 3

TL;DR: Yes. Standard unencrypted email is roughly as secure as a message scrawled on the back of a postcard.

Longer answer: This is entirely possible if the attacker has admin privileges to at least one of the following:

1. The mail servers the message travels through (Open an email message, select "full headers" in whatever mail client you use, each Received: from [foo] by [bar] line indicates a mail server that this message passed through). If you have admin privileges to a mail server, you can access its queue, suspend a message in the queue and edit the message before sending it on its way.

2. Any of the TCP/IP routers that the message traveled through. In this case the attacker could theoretically route all SMTP traffic to a local relay server that would act as a transparent proxy, but tag and hold specific messages in a queue for the attacker to modify before sending it on. Tricky, but doable.

NOTE: The second method can sometimes be prevented by using smtp-over-ssl, but this practice isn't nearly as commonplace as it should be and smtps or smtp/tls only work when both sides* support it; The first method can not be prevented by encrypting the transmissions because the attack happens at a legitimate (if subverted) checkpoint.

What would work against both attack vectors would be using an public/private keypair to sign the message, but that would require the recipient to have a copy of your public key, which can be something of a chicken-and-the-egg problem.

Answer 4

If your email is sent in the clear an attacker could in theory modify the contents of the email exactly how you have described, with the exact result.

In order to intercept and modify this email the attacker would have to either take control of an email server which is going to handle the email in transit, or take control of a routing device with the ability to modify the email. This is not trivial to do, if the attacker is going to get access to anything but the originating email server they would have to know the exact path the email is going to take, which means knowing who your customer base is. The best way to learn your customer base would be to hack your systems, and if they can do that then they have your users' passwords anyway. Also, writing the screen-scraper software and website for capturing the password changes would be a significant effort.

Some phishing attacks already use a very similar attack method except instead of intercepting and modifying emails they simply send crafted spam emails, which is much easier. Banks have spent a great deal of time making their sites resistant to screen-scraper attacks, if you have concerns I'd suggest you do some research on their site designs and incorporate some countermeasures into your site in order to make these attacks more difficult.

I could see the merits of intercepting and modifying emails as it will make spam filtering much less likely, and as the user has requested a password change they will be more likely to trust the links in the email. Still, given the complexity of the attack a site would have to be pretty high value before anyone would be willing to invest the time and effort to do it. Whether your site would be a target is something you'd need to decide for yourself.

Answer 5

You can protect against this type of attack by using either SMIME or DKIM. Both technologies verify the message header, and DKIM optionally protects the message body (or the first X characters therein).

DKIM is a public key that is stored in DNS, and your email administrator "signs" the message and stamps this in the header. Learn more about DKIM here: http://en.wikipedia.org/wiki/DKIM

Relying on DKIM means that the end user needs trust their own email admin to not modify the message. There are DKIM client side software packages that verify DKIM, but they aren't widely in use (AFAIK).