Help!! Need To Sniff My iOS Mail Password

[macusertoday]

I entered my Gmail credentials into the Mail app on the iPhone when I first bought it and never logged into Gmail again, and after years I have forgotten the password. The phone still syncs with the account so I can read and send emails but I need to log into the account online and the only way to do this is, obviously, with the password.

I thought this would be relatively easy by getting the password from the Keychain but discovered that the Keychain only stores manually entered passwords, but the Mail app stores them in hashed tokens. It would seem the only solution is to sniff the password as the iPhone fetches mail, and there is a blog post describing how SSLsplit can do this, but it only mentions it with using Thunderbird on iOS, not the Mail app itself.

Anyone here have any ideas or experience with this that can help me? I would be glad to pay someone for their time as this is very important.

 

[eyoungren]

Have you not tried to recover your account?

https://accounts.google.com/signin/recovery

 

[macusertoday]

Have you not tried to recover your account?

https://accounts.google.com/signin/recovery

Of course, should have mentioned this... my account was created BEFORE Google required a secondary email and phone for resetting the password. For these older accounts, there is literally no support or way to reset the account. They have an automated process that (and I kid you not) requires you to type your last known password, and when you can't (because... duh you've forgotten it) it says, sorry we cannot reset your account. So the short answers is, yes I tried and no, I can't reset it.

 

[NoBoMac]

You don't mention which version of iOS is in use.

Don't think sniffing will work, as Google uses OAuth for their authentication, so, the password is not used, just the OAuth token. To minimize sniffing exposure.

 

[macusertoday]

Ughhh.... that does not sound good. I think it's the latest or near the latest version as it always updates automatically. I am not so well versed in this but base my inquiry on this post from someone who is...

Where he successfully does this using Thunderbird on iOS, so it would seem that the Google side does play well with a MITM attack, unless it does something different with the Mail app.

https://blog.heckel.xyz/2013/08/04/...e532bd6574843a79cedf4d3ad77ce3#comment-245708

3.2. Sniffing IMAP over SSL (imap.gmail.com)
In the second example I used Thunderbird to connect to my Gmail account. Unlike a web based mail client, Thunderbird connects to the Google/Gmail server via IMAP on port 143 or via IMAP over SSL on port 993. While the communication on port 143 is unencrypted and can be read with other tools (Wireshark, tcpdump, etc.), IMAP over SSL requires a man-in-the-middle proxy to split the SSL communication.

The screenshot above captures the initial connection of Thunderbird to the Gmail IMAP server (normally imap.gmail.com, here: imap.googlemail.com) on port 993. Like in the first example, the upper console shows the SSLsplit debug output (showing how SSLsplit forged the certificate), and the lower console shows the bytes exchanged over the SSL socket.

As you can see in the screenshot, the IMAP communication includes an exchange of client and server capabilities (1 capability) with a little inside joke from the developers of the server (1 OK That's all she wrote ...), as well as the authentication (3 login "e-mail@gmail.com" "password"). The latter part is probably most interesting to attackers.

After the authentication, client and server both agree to continue the conversation using compression (4 COMPRESS DEFLATE), so the rest of the message is naturally not human readable anymore. However, since it’s only compressed and not encrypted, it can be made readable using simple Linux tools.​

 

[NoBoMac]

A bit apples vs oranges, but basically, probably out of luck.

Blog is six-ish years old. Google services on iOS has been OAuth for at least two years (believe official support began with v11). Thunderbird is not iOS. Any other client will need the password to setup, so, need to know that: dead end. Other app might use token, but as mentioned, token is not the hashed password.

 

[macusertoday]

Well, thanks for setting me straight so that I don't waste more time on this. Basically, Google has me in a no-win situation. I opened the account with a backup email because it was never asked of me and not required and they won't reset the password without it. So it appears I am totally out of luck. If I understand you right, Google does not rely on the password itself but a one-off auth that, once issued, remains in place so that even if I were to sniff it, what I end up with is useless for logging on manually. Definitely a case of overkill in this particular scenario. Ultimately, it's my fault for not remembering/archiving the password, but still...
[doublepost=1561327179][/doublepost]I assume even were there a way to use SSLsplit or something similar, there would be no way to coax the password back downstream in some readable form the Google server.
[doublepost=1561327318][/doublepost]And finally, brute force (I am assuming) would cause gmail to freak out and close the account down after so many tries, and that would only work if I had used normal words, not some weird variation that I most likely conjured up on the spot.

 

[NoBoMac]

Yes, basically, out of luck. OAuth tokens are in place to prevent giving up passwords.

 

[macusertoday]

Well, I've looked into this further and I think (and hope!) you are only partially right in that Gmail, Yahoo and other do use the newer OAuth tokens, but only if the user has turned on 2-Step verification, which I think (and hope!) I never did years ago. So it's possible in at least my case that the old-fashioned username/password is still in operation.

From the Gmail website:

Sign in using App Passwords
An App Password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on.

 

[chrfr]

Well, I've looked into this further and I think (and hope!) you are only partially right in that Gmail, Yahoo and other do use the newer OAuth tokens, but only if the user has turned on 2-Step verification

That's not what that says. Google is using OAuth with any modern mail client whether or not you've turned on 2-factor authentication.

 

[MacDawg]

Strange, I've periodically had to re-enter my Gmail credentials on my iPhone and have never gone "years" without being forced to do so

 

[chrfr]

Anyone here have any ideas or experience with this that can help me? I would be glad to pay someone for their time as this is very important.

Have you ever used the account on a Mac? If so, the password might be saved in your keychain, and it's easy to read that.

 

[macusertoday]

The IMAP password is not stored in the Keychain, only manually entered passwords, and I can tell you that this password was entered in 2016 in iOS Mail and has never had to be entered again since then.

As for OAUTH, you are 100% correct because I was able to intercept the SSL traffic going to/from the Gmail servers and the token is right there where you would ordinarily see the password, so that's a dead end, although I'm curious about this: wouldn't at least the first time the Mail app seeks authentication when the account is added to Mail, it would need to send the password at least that one time, since it doesn't send you to Gmail itself to do that... you input it on the phone itself, and second, is there any scenario in which over time it might once again have to send the credentials in order to get a new token or one renewed, so that continued sniffing might eventually find something?

If not, and brute force is the only remaining option, how does one get around the CAPTCHA that comes up after x number of tries, or worse, blocks the IP or account?