Emails, The Weak Link

Sean Wright -

Can anyone spot any issue with the above password reset email? I mean it's using HTTPS in the reset link after all, is it not?

WRONG!

I decided to keep all the emails which I have received recently (over a week period) and try determine how wide spread this problem really is:

  • Inbox 1 - 9 out of 14 (64%) senders sent emails containing at least 1 plain HTTP link.
  • Inbox 2 - 14 out of 21 (67%) senders sent emails containing at least 1 plain HTTP link.

HTTP = Bad

The problem with plain HTTP is that an attacker with MiTM can both alter and view any information sent over plain HTTP. I explained this concept some what in a previous post.

So an attacker could decide to either alter the content (e.g. serve a spoofed password reset page), inject malicious content (e.g. BEeF hook, or crypto miner) or sniff sensitive information (e.g. password reset code/token).

The Weakest Link

Going back to the above example. Here we have a password reset link being sent over plain HTTP. Now if an attacker has Man in The Middle, they could simply intercept this request and redirect the user to a page of their choosing. This would most likely be a spoofed password reset page. Now Pocket is not alone here, I've noticed quite a few companies performing this very practice.

And just to make sure that there was nothing such as HSTS (hopefully with preloading) at play I decided to view the request and response made when clicks on the link in the email:

Request (hxxp://email.getpocket.com/wf/click?upn=<redacted>)
GET /wf/click?upn=<redacted> HTTP/1.1
Host: email.getpocket.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: sess_guid=<redacted>; sess_start_time=1514568530
Connection: close
Upgrade-Insecure-Requests: 1
Response
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 29 Dec 2017 17:29:40 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Location: https://getpocket.com/forgot_reset.php?u=<redacted>&token=<redacted>
X-Robots-Tag: noindex, nofollow
Content-Length: 0

On a side note, could this also be a phishing attempt since the link does not match the text of the link?

Marketing Stuff

Many of the emails which had plain HTTP links in them seemed to have some type of marketing/analytics attached to the links:

Don't get me wrong, I understand the need and desire for marketing to sometimes have these numbers and analytics. However they should ensure that the links are delivered over HTTPS, thus preventing Man in The Middle attacks. Emails are not all that secure as it is, this is just compounding the issue even further.

View Online

Another common trait I've seen relating to emails with HTTP links, is the ability to view the email in a web page. Fine if that page is served over HTTPS, but it becomes a problem when it is served over plain HTTP:

Well now an attacker with MiTM has the ability to change the entire "email".

Mixed Content

We all know mixed content is bad, and should be avoided at all costs. So why do some companies not follow the same advice for emails? They send emails with a mixture of HTTP and HTTPS links. Take the following email as an example:

The link "Questions? Contact Google, Inc" is a HTTPS link:

So one might assume that since this link is served over HTTPS, that all other links in the email are also served over HTTPS. Well not quite:

Again like the first example, I decided to view the request and response when clicking on the link in the email:

Request (hxxp://support.google.com/googleplay/bin/answer.py?topic=1046717&ctx=topic&answer=2519990&hl=en_US)
GET /googleplay/bin/answer.py?topic=1046717&ctx=topic&answer=2519990&hl=en_US HTTP/1.1
Host: support.google.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: CONSENT=WP.268476; NID=120=nrIC23AFgW0CrvxrlW7tLeqkQmV97PjcVMnn_UFz84PHl1PFtl0fr1N1-zjd90xeRsTzruar5RCPihVab_UbMVne7qXR_FBzFBRLBw1Jv8-yBhr_QSvWnhTTb2JRFrD-
Connection: close
Upgrade-Insecure-Requests: 1
Response
HTTP/1.1 301 Moved Permanently`
Location: https://support.google.com/googleplay/answer/2519990?topic=1046717&ctx=topic&hl=en
Date: Fri, 29 Dec 2017 17:38:40 GMT
Expires: Fri, 29 Dec 2017 17:38:40 GMT
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Server: support-content-ui
Content-Length: 287
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Connection: close

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://support.google.com/googleplay/answer/2519990?topic=1046717&amp;ctx=topic&amp;hl=en">here</A>.
</BODY></HTML>

At least in this case a permanent redirect (a response code 301) is being returned in the response. This means the browser will always hit the HTTPS site instead, but only after the initial visit or assuming that the user has not cleared their browser cache.

Conclusion

There are some worrying trends about emails being sent with plain HTTP links in them. Most worrying of all is that some of these links were password reset links, as well as links associated with financial based emails. I find it difficult to find a reason why these links cannot be HTTPS links. I have started the process of trying to reach out to the numberous vendors to see if I can get them to change these links to HTTPS, so here's fingers crossed that most do! On a side note, some of these issues which I found might also have to do with Gmail converting some links to HTTP automatically: