3 ms·
Is it based on mail undeliverable errors? Or attempts to login using IMAP or SMTP with it? Or is it exposed during the SMTP protocol?
by rubatuga 3mo ago
Is it based on mail undeliverable errors? Or attempts to login using IMAP or SMTP with it? Or is it exposed during the SMTP protocol?
- hunter2_ 3mo agoAs someone who doesn't rely on this feature, I'd love to know now as well, but perhaps the etiquette in public would be to align ourselves with: > we will not discuss or disclose the details of the exploits until they're fixed. But if there's a public forum where the cat's already out of the bag, then game on. Perhaps this: https://www.reddit.com/r/apple/comments/1ukilw1/apple_hide_my_email_vulnerability_reveals_peoples/oux8arw/ https://www.reddit.com/r/apple/comments/1ukilw1/apple_hide_m... ...which makes it seem like perhaps the attack surface is limited to scenarios involving a Yahoo/Sonic address (assuming that Apple only sends X-Sonic-* headers when talking to those providers that want to see it), which might be a small percentage of users.
- deleted 3mo ago[deleted]
- Dibby053 3mo agoMy guess would be it has nothing to do with email itself. Maybe it's some iCloud API that accepts obfuscated emails but returns the original email in the response, or an ID which can be used to retrieve the iCloud email from another API endpoint. Could be as simple as an "add contact/friend" feature in some Apple product (like a mail client, or a file sharing service) that resolves the obfuscated email to the original iCloud account.
- jijijijij 3mo agoI think they are hinting at the ad hoc "use hidemyemail" feature within e.g. the mail client. I don't know what I am doing, but from a quick test, the mail header is at least disclosing the internal recipient (mail@host.com) "translation address" (as mail_at_host_com_12345abc_12345abc@icloud.com) and an alias creation date. But the latter seems to be a unix timestamp related to the real address alias creation time and is identical between an hidemyemail mail and a normal one, so there may be already a possible information leak for correlation. Side note, it also seems like the sending hidemyemail server contains the unsuspicious name "junk_forwarder". Lol. Disclosing an address as alias and particularly as throwaway alias (through the translation address and server) already seems kinda counterproductive to begin with, but I would bet you can use this information somehow to get the sender "translation address". Either by some API interaction, or by messing with the mail header scrubbing of the translation service somehow. A server named "junk_forwarder" may be a little more lenient about what to accept or not. Edit: Can confirm the Reddit comment linked. You simply send an email to the HME address, reply from Apple mail client, and then the real mail address gets disclosed. Mind you not even hidden. It's shown as sending from the HME alias in mail, but I received the mail with the real address as sender......... Jesus fucking christ, Apple. Did you even test this a little?
- impish9208 3mo ago> You send an email to the HME address, reply, and then the real mail gets disclosed in the mail source. Does the initial sender matter? Like if it’s the HME address that sends first and receives the reply? I have around 180 of these addresses.
- jijijijij 3mo ago> then the real mail gets disclosed in the mail source. It's not just in the source, I totally overlooked the fact the real email address is shown as sender. Lol. > Does the initial sender matter? Like if it’s the HME address that sends first and receives the reply? I have around 180 of these addresses. Appears so. Here is exactly what I did: 1. Created the HME through mail, sending to other email service address (OMA). (This disclosed the information in my original comment.) 2. Did some reply ping pong. (No additional disclosure.) 3. Send a new email from OMA to above HME. 4. Replied from iOS mail client (UI showing usage of HME alias. Yes, I verified this multiple times not to make a fool of myself.) 5. Received at OMA, the real address is disclosed. 6. On the iOS client side, the mail shows up as sent from the real mail address, too. Not sure if 1. for HME creation is required, you can likely skip straight to 3. for any HME address. Funny enough, I observed 6. in the wild before, but was kinda hoping that's an artifact of forwarding a copy of the mail to the thread. I tested this some, but not this particular ping-pong. So yeah... I now gonna check where I evidently leaked my real mail address already...
- dustyharddrive 3mo ago6. is a sign of bad UX but not leakage to the recipient.
- jijijijij 3mo agoThat's what I thought, but I happens to coincide with the actual leakage, so.... What is bad UX is the fact there are two reply buttons in the iOS client. One "in" the mail and one for the thread. The mail one pretends to reply from HME alias, the thread one does not. This alone could expose you by accident, since anyone would expect to reply with HME in any case, but you get exposed either way.
- freehorse 3mo agoIn the comment section of the 404media article Joseph Cox writes when asked whether it reveals the icloud address the email is forwarded to or the apple id [0]: > It reveals the email linked to the Apple ID. So I assume you are right that it has nothing to do with the email itself, but prob some other service that links the obfuscated email to the appleid of the user. [0] https://www.404media.co/apple-hide-my-email-vulnerability-reveals-peoples-real-email-addresses/#ghost-comments-6a452ca779d2b20001b8bf6d https://www.404media.co/apple-hide-my-email-vulnerability-re...
- nashashmi 3mo agoI wonder if it is replies to delivery receipts that causes this problem
- deleted 3mo ago[deleted]