6 ms·

We saw the issue for a wide variety of hidden address domains. We use Mailgun to send emails so we were seeing Mailgun logs with things like this. I replaced th

We saw the issue for a wide variety of hidden address domains. We use Mailgun to send emails so we were seeing Mailgun logs with things like this. I replaced the customer's real email username with "redactedForPrivacy". "delivery-status": { "code": 550, "description": "This is a system-generated message to inform you that your email could not\r\nbe delivered to one or more recipients. Details of the email and the error are as follows:\r\n\r\n\r\n<redactedForPrivacy@gmail.com>: host 127.0.0.1[127.0.0.1] said: 550 5.7.1 message\r\n content rejected due to spam; if you feel that your email was rejected in\r\n error, please forward a copy to icloudadmin@apple.com (in reply to end of\r\n DATA command)\r\n", "enhanced-code": "5.7.1", "message": "smtp; 550 message content rejected due to spam; if you feel that your email was rejected in error, please forward a copy to icloudadmin@apple.com" } The "description" fields' contents were almost identical regardless of the hidden email address's mail host, but I don't know if that means anything. It sounds like iCloud limits messages to 20 megabytes. You might have needed to be forwarding to a final destination with a smaller limit so that the rejection came from the final destination rather than from iCloud. We didn't test that until July 7.

js2 2mo ago
So what I'm trying to clarify here is whether this worked when the final address was an icloud.com address. i.e. there are two scenarios: 1. hello_world_0a@icloud.com -> real@icloud.com 2. hello_world_0a@icloud.com -> real@example.com where example.com is not any of icloud.com, me.com, mac.com (such as in your example, gmail.com) HME can be configured for either of setups. I really want to establish whether you were able to unmask a real address under (1), since in this case any bounce message should occur too early to disclose the real address. Under (2), the bounce message can occur after rewriting and I can totally see how it was leaking the real address. (For the purposes of the exploit, it doesn't matter that you used Mailgun to send the email, but I appreciate that detail.)
- tjames7000 2mo ago
  Okay, I see what you mean. We never paid attention to whether (1) was happening. I imagine Apple can tell based on the code that was running at the time. Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain? We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell.
  - js2 2mo ago
    > Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain? I don't think so because when I examine the headers of an HME delivered message to my real@icloud.com address there's only a single MTA involved. > We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell. The full headers of the bounce message will tell you.
    - tjames7000 2mo ago
      We don't have full headers, unfortunately. I'm not very familiar with SMTP, but to test things out, we ended up running a minimal custom mail server with the nodejs 'net' module to have full control over responses. I think it'd be possible to set something similar up so that the same mail server handles Hide My Email and normal iCloud addresses differently. const net = require('net') const server = net.createServer((socket) => { socket.setEncoding('utf8') socket.write('220 ...') socket.on('data', (data) => { if (isHideMyEmail(data)) { // handle one way } else { // handle another way } }) ... }) server.listen(25, '0.0.0.0', () => { console.log(`Ready for incoming emails`) }); That being said, I have no idea how Hide My Email works technically. Maybe the headers would make it clearer.

js2 2mo ago

So what I'm trying to clarify here is whether this worked when the final address was an icloud.com address. i.e. there are two scenarios: 1. hello_world_0a@icloud.com -> real@icloud.com 2. hello_world_0a@icloud.com -> real@example.com where example.com is not any of icloud.com, me.com, mac.com (such as in your example, gmail.com) HME can be configured for either of setups. I really want to establish whether you were able to unmask a real address under (1), since in this case any bounce message should occur too early to disclose the real address. Under (2), the bounce message can occur after rewriting and I can totally see how it was leaking the real address. (For the purposes of the exploit, it doesn't matter that you used Mailgun to send the email, but I appreciate that detail.)

tjames7000 2mo ago
Okay, I see what you mean. We never paid attention to whether (1) was happening. I imagine Apple can tell based on the code that was running at the time. Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain? We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell.
- js2 2mo ago
  > Even in case (1), isn't it possible that Hide My Email bounces happen differently from regular @icloud.com bounces despite being on the same domain? I don't think so because when I examine the headers of an HME delivered message to my real@icloud.com address there's only a single MTA involved. > We've also been wondering whether Hide My Email was ever responsible for generating the messages with meant-to-be-hidden addresses or whether it was only passing them along and failing to hide them. I don't think we have enough information to tell. The full headers of the bounce message will tell you.
  - tjames7000 2mo ago
    We don't have full headers, unfortunately. I'm not very familiar with SMTP, but to test things out, we ended up running a minimal custom mail server with the nodejs 'net' module to have full control over responses. I think it'd be possible to set something similar up so that the same mail server handles Hide My Email and normal iCloud addresses differently. const net = require('net') const server = net.createServer((socket) => { socket.setEncoding('utf8') socket.write('220 ...') socket.on('data', (data) => { if (isHideMyEmail(data)) { // handle one way } else { // handle another way } }) ... }) server.listen(25, '0.0.0.0', () => { console.log(`Ready for incoming emails`) }); That being said, I have no idea how Hide My Email works technically. Maybe the headers would make it clearer.