A little over a week ago I discovered a startling vulnerability in Yahoo Mail. I could log in to any of my accounts, and I presume many others, with any password. It seems to be fixed now, but Yahoo’s response left much to be desired.
First I’ll outline the vulnerability, then I’ll discuss Yahoo’s response.
I discovered this while working on Triage, an iPhone app for busy people who struggle to stay on top of their email. John Gruber said “since I’ve been using Triage, I’m more caught up on my email than I have been in years.”” You should download Triage from the App Store now.
To be more specific, I could log into my accounts on Yahoo’s IMAP servers with any password. Of the three accounts I tested, the first was created in April, the other two a couple of weeks ago. This issue didn’t affect my colleague who had a much older Yahoo Mail account. Perhaps the date the accounts were created had something to do with it?
If so, I wonder if Marissa would have fallen into the new Yahoo! Mail accounts camp? ;)
Here’s a transcript of the commands I used. Nothing fancy. Just IMAP commands. I also made a Youtube video of the vulnerability using three separate accounts.
$ openssl s_client -host imap.mail.yahoo.com -port 993
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=CA/L=Sunnyvale/O=Yahoo! Inc./CN=imap.mail.yahoo.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
(removed for brevity)
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Sunnyvale/O=Yahoo! Inc./CN=imap.mail.yahoo.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
---
No client certificate CA names sent
---
SSL handshake has read 3485 bytes and written 444 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: B462753AD5E31875DF769ACE765FDE067090D390FB4ADAC9D8BF5286B4A9316E
Session-ID-ctx:
Master-Key: 9A37586CD75F079581F6E9EB1F870109BE36A593E9B365331C0BE9BC1CE59C45139AEF1D1CC6E4D7087EEBD3C6A378D4
Key-Arg : None
Start Time: 1368067492
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
* OK [CAPABILITY IMAP4rev1 ID NAMESPACE X-ID-ACLID UIDPLUS LITERAL+ CHILDREN XAPPLEPUSHSERVICE XYMHIGHESTMODSEQ AUTH=PLAIN AUTH=LOGIN > AUTH=XYMCOOKIE AUTH=XYMECOOKIE AUTH=XYMCOOKIEB64 AUTH=XYMPKI] IMAP4rev1 imapgate-0.7.68_14.357900 imap402.mail.aue.yahoo.com
1 LOGIN "mailtriageapp@yahoo.com" asdf
1 OK AUTHENTICATE completed - Mailbox size in bytes is 32815
2 SELECT INBOX
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1366345105] UIDs valid
* OK [UIDNEXT 19] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] Permanent flags
* OK [HIGHESTMODSEQ 5875762758974036000]
2 OK [READ-WRITE] SELECT completed; now in selected state
3 UID SEARCH UNSEEN
* SEARCH 18
3 OK UID SEARCH completed
4 UID FETCH 18 (UID FLAGS RFC822.SIZE ENVELOPE BODY.PEEK[HEADER.FIELDS (References)])
* 3 FETCH (FLAGS (\Answered) UID 18 RFC822.SIZE 5781 ENVELOPE ("Thu, 9 May 2013 11:58:24 +1200" "Yaahooooo" (("Nick Malcolm" NIL > "nick" "malcolm.net.nz")) (("Nick Malcolm" NIL "nick" "malcolm.net.nz")) (("Nick Malcolm" NIL "nick" "malcolm.net.nz")) (("Mail > Triage" NIL "mailtriageapp" "yahoo.com")) NIL NIL NIL "<B3BF01ABA37D4DB1AB43C819DBDDE658@malcolm.net.nz>") BODY[HEADER.FIELDS (> REFERENCES)] {2}
)
4 OK UID FETCH completedYou can see, after connecting to the server, that I log in to the account “mailtriageapp@yahoo.com” with the password asdf. The password was not asdf, nor was it any of the other incorrect passwords I attempted. I then opened the Inbox, and read the first unread message.
To me that seems like a huge vulnerability.
I immediately reported this to the Yahoo security team, and included transcripts of exploiting this with two of my accounts. This was on the 9th of May. Unfortunately, like others have noted, their response left much to be desired.
"I refused to report more bugs to them because it’s boring to talk with bots." - Nils Jünemann
When you email security@yahoo-inc.com, you get an automated response:
This is an automated message acknowledging your recent submission for help to Yahoo! Customer Care.
Please do not reply to this automated message as replies will not been seen or answered by a Yahoo! Customer Care representative.
If you reported abuse, we will investigate and take action where appropriate, and may be contacted if additional information is required to complete our investigation. We appreciate your efforts to make our community better.
If you are submitting a request for assistance, or asking a question, a representative will respond as soon as possible.
Your Incident ID is: removed
Sincerely, The Yahoo! Customer Care Team
Like so many companies, Yahoo sent a “do not reply to this email” email. I simply can’t understand why any company would want to ignore user feedback. At the very least it should be simple enough to tack a customer’s response to the support ticket.
Later that day I got another seemingly automated response.
Recently you requested personal assistance from our on-line support center. Below is a summary of your request and our response.
Subject I can log in to IMAP with incorrect password
Discussion Thread Response Via Email (Leslie Davids)
Hello Nick,
Thank you for contacting Yahoo!.
I have analyzed your message, and it is best addressed by our Yahoo! Accounts team. To protect account security, this team requires specific information about your Yahoo! account that you provided during sign-up or when you last updated your account. I will need to ask you to contact Yahoo! Accounts team directly to provide the necessary information to resolve your issue.
Note: Please do not reply to this message. Submitting an email through the form is the best way to get your answer.
Please visit Yahoo! Privacy Center for information regarding Yahoo!’s Privacy Policy.
Also, please read the help article about registering a Yahoo! ID.
For additional help with Yahoo! products, please visit the Yahoo Help pages.
Thank you again for contacting Yahoo!.
Regards,
Leslie Davids
Yahoo! Customer Care www.yahoo.com
The reason I suspect this is a robot:
Again I was faced with the familiar “Please do not reply to this message”. To make matters worse, the suggested “contact Yahoo! Accounts team” link did not work in Chrome, Firefox, or Safari, neither when I was logged in or out of a Yahoo account.
I replied to Leslie with the strong suggestion of sending this directly to the security team, and also told her the contact form was broken. Later that night I made the Youtube video, just to prove I wasn’t making things up.
About three days later I noticed that Yahoo was now refusing bad passwords. That’s pretty quick, so at least someone is paying attention over there. All’s well that ends well, I guess.
I’m not sure what I expected. It feels good to have reported my first vulnerability. Especially one which seems to be so simple, yet very serious and far reaching. A thank you might have been nice.
But I really wish all companies, from startups to global behemoths, would stop sending “Do not reply” messages. It’s so impersonal. Just don’t do it.
If you’d like to reply to this post, find me on twitter @nickmalcolm.
Follow this story on Hacker News.
20 May 2013