7 ms·

LeakyX, a vulnerability that Apple and Microsoft have known about for years

69 points by Aaronn 9y ago

jlgaddis 9y ago
To be clear, the issue in "Test A" is the lack of certificate validation. It wasn't immediately clear (poorly worded, IMO) but that's the (only) issue I see in that scenario and that is, indeed, a security issue (allows a MITM attack). "Test B", however, is not a security issue at all, IMO; instead, it is "working exactly as intended". > The Apache logs are not even needed without SSL enabled because the first request to the web server includes the username and password in clear text. If SSL isn't enabled then, yes, of course it does. This may come as a shock to the author but standard IMAP4/POP3 without SSL also sends credentials in the clear (as does -- gasp! -- every other plain-text protocol!) > Even when SSL is not enabled the client should not be sending the credentials without first verifying that it is a real exchange server. And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response? > Realistically the client should not even send the password before verifying the user exists. That, however, would be an information disclosure vulnerability (identifying valid usernames on the server). That's why no other mail server in use on the Internet does that either. Not to mention that it's real easy for a malicious attacker (in control of the server) to lie about that too. Aside: if you're running an Exchange server, set up Autodiscover [0] and all your users need to set up their mail account is their username and password (no server details are needed!). For other (i.e. non-Exchange) mail servers, there's a similar "Autoconfiguration" method that is supported by various mail clients, such as Thunderbird [1]. [0]: https://msdn.microsoft.com/en-us/library/office/jj900169(v=exchg.150).aspx https://msdn.microsoft.com/en-us/library/office/jj900169(v=e... [1]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...
- creator_lol 9y ago
  > And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response? umm , yes?? Even a simple check would increase the complexity a successful attack. Yes it could be duplicated , but having a client that just dumps the credential without any verification does not sound like a good idea and is poor programming.
  - tomsmeding 9y ago
    Including some fixed piece text in a server response is not complex. It does not increase the security of the system.
- dogma1138 9y ago
  There is no lack of certificate validation in step A, they've just gracefully omitted it: https://imgur.com/a/OXIal https://imgur.com/a/OXIal
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
- willstrafach 9y ago
  > To be clear, the issue in "Test A" is the lack of certificate validation. It wasn't immediately clear (poorly worded, IMO) but that's the (only) issue I see in that scenario and that is, indeed, a security issue (allows a MITM attack). Actually, even this is completely wrong. You are understandably giving a charitable reading to the poorly worded explanation. I have tested this earlier today on an iOS 10.3.3 device and an iOS 11 device, and the TLS certificate is absolutely validated properly. As you've stated with Test B, yes, if SSL is turned off then the information is indeed sent in plaintext during the account setup. However, I don't know what the purpose of this test was, as this is (as you said) expected behavior.
  - ktta 9y ago
    The TLS is validated properly, but the credentials are sent even before (or right when?) the dialog shows up about the certificate error. To be clear, here is what I did. 1. Settings->Add new account-> Exchange 2. Entered email ID (with @leakyx.com domain) and password and selected 'Next' (iOS 11 required hitting Next, and entering password on the next screen. iOS 9.3.5 has only one prompt for both email and password) At this point, a dialog showed up about the cerficate not being valid. You have the option to continue and trust the certificate or hit 'cancel' 3. I hit cancel. (Which means, you don't trust the certificate) The credentials still showed up. I did it twice to be sure. On leakyx.com, ktta@leakyx.com is with iOS 9.3.5 and iOS11@leakyx.com is with iOS 11
throwaway613834 9y ago
[Edit: nope, I misunderstood the issue... ignore my comment.]
- deleted 9y ago
  [deleted]
- AaronFriel 9y ago
  This is a bigger issue because those credentials can be used to authenticate to the Exchange server to download emails or, if they're using Active Directory elsewhere in the enterprise, to VPN in, to log in to servers, so on and so forth.
  - throwaway613834 9y ago
    Oh you're right :\ will remove my comment, thanks for pointing this out.
MichaelGG 9y ago
So a more realistic scenario might be after gaining access to a company's LAN, or at a public WiFi? Did I read it right, you can force downgrade Exchange clients from TLS to plaintext, essentially? What more did Apple say on the phone? No rationale given?
- mirashii 9y ago
  I see no evidence of a force downgrade, you can see in the screenshots that he configured SSL off. If you configure SSL off, your credentials go over the wire in plaintext. Surprise surprise.
  - MichaelGG 9y ago
    Oh. Well then it's a complete non issue. No wonder MS told them off.
    - hexadecimated 9y ago
      I don't see what other response he could have reasonably expected from Microsoft, given that his complaints were about the iOS Exchange connector, and actually had nothing to do with Exchange Server.
- dogma1138 9y ago
  No, there is no vulnerability here there is no real way to force downgrade or redirect traffic, iOS will prompt a message asking you to confirm a self signed certificate..... What the author claims is a vulnerability isn't one in any real sense. They basically "complain" that the mailbox on the iOS phone doesn't "validates" that the server is a real exchange server, in all honestly neither does outlook, nor most other client-server protocols I know off if the server isn't correct it will fail that's it. Even if there was a way to downgrade or redirect traffic if you have the ability to do that it's game over, if you can MitM an SSL connection between an iOS device and it's server faking a layer 7 handshake isn't really hard to do at that point.
  - 9y ago
mavhc 9y ago
Why is it sending a password at all?, surely it should be at least a hash of the password
- raverbashing 9y ago
  Do not send hashes. Do send challenge/responses. Hashes can be replayed. (Or send passwords over TLS)
  - mavhc 9y ago
    Sure, my question is more is there a history to this protocol? Is it from the 80s or something?
- jlgaddis 9y ago
  No, it surely shouldn't.
- lawnchair_larry 9y ago
  If that would work, it would mean the hash is actually the password.
mirashii 9y ago
There's nothing newsworthy here, just some guy trying to make a name for himself by giving his so called vulnerability a flashy name and website.
- mdeeks 9y ago
  No, underneath the bad writing it appears there is a real problem here. If you go to his simple walkthrough page you get a better understanding: https://leakyx.com/info.php https://leakyx.com/info.php Credentials are sent BEFORE prompting the user to accept a self signed cert. So it sounds like an attacker can harvest credentials on a rogue wifi by spoofing DNS and using a self-signed cert. I don't have an iOS device so I can't test.
  - mirashii 9y ago
    Can't edit to correct, but if what you say is true, I agree. Also no iOS device to test. It's really difficult to tell that's what's happening in the midst of all the incorrect statements and conclusions even up to that point, and with the B section being even more absurd. It's quite possible that the reporting to vendors would also miss the legitimate vulnerability through the rest of the noise.
  - DiThi 9y ago
    That link explains the problem much better than TFA.
  - willstrafach 9y ago
    > Credentials are sent BEFORE prompting the user to accept a self signed cert. So it sounds like an attacker can harvest credentials on a rogue wifi by spoofing DNS and using a self-signed cert. I don't have an iOS device so I can't test. This does not appear to be the case (Tested on an iOS 10.3.3 device and an iOS 11 device).
    - mdeeks 9y ago
      Thanks for confirming. So then there is nothing at all of substance in this article.
frlnBorg 9y ago
Would this affect Office 365 hosted exchange servers?
- deleted 9y ago
  [deleted]
Stranger43 9y ago
And all this while everyone is paying billions for complex info-sec software that does a lot less then it says on the tin. It's similar to the epidemic problem with non-verified/signed SSH keys where everyone just clicks Ok to any host-key presented. Though a bit more subtle, and something that should have been avoidable with a proper designed protocol. It's the kind of trivial little thing that gets ignored(along with boring old maintenance tasks like patching infrastructure servers ect.) not despite of but because of all the attention given and budget spend on attending conferences on cyber-warfare and never to be correctly installed(let alone monitored) infosec appliances. Almost every major hack ever blamed on super advanced state sponsored groups turns out to be someone fumbling a routine update (like what happened with equifax and wannacry) or setting a bad password(guccifer 1+2 etc.) And yet the lesson that gets drawn is never, "lets start following proper procedures for maintenance and training" but "lets reduce the maintenance budget some more by spending on infosec conferences and toys."
DiThi 9y ago
So basically typosquatting? It seems to me that any service that doesn't show the SSL certificate (or the EV name) is vulnerable to this, not just Exchange on iOS. Edit: It seem it doesn't check the SSL certificate either. But it's super easy to get a valid SSL certificate nowadays, so just checking the SSL certificate for validity wouldn't be enough.
- jlgaddis 9y ago
  Why wouldn't it be enough?
  - DiThi 9y ago
    Because setting up a let's encrypt certificate is almost as easy as to making a self signed one. We're talking about typosquatting, having a completely valid domain of your own that is the same as someone else's but with a typo. Edit: From what it is said in another comment, it's not exactly about typosquatting, but the author expresses the problem very badly. It seems credentials are sent to the domain before the certificate is checked. So one is vulnerable to DNS spoofing in e.g. a public wifi.
    - lesserknowndan 9y ago
      I'm not sure how they can be more clear than the first sentence, "So back in February I discovered that an iPhone was sending usernames and passwords unencrypted to an exchange server even when SSL was enabled." Are you saying the later text contradicted this statement?
      - deleted 9y ago
        [deleted]
      - ktta 9y ago
        It was a bit confusing since he talks about typosquatting. He also talks about credentials sent unencrypted when SSL is off, which further makes everyone question the validity of his claims. But he did find a vulnerability in iOS's Mail app.
jlgaddis 9y ago
I find it funny that people are injecting alert()'s into the testing tool -- a vulnerability in a vulnerability report! cf. https://leakyx.com https://leakyx.com.
deleted 9y ago
[deleted]

69 points by Aaronn 9y ago

To be clear, the issue in "Test A" is the lack of certificate validation. It wasn't immediately clear (poorly worded, IMO) but that's the (only) issue I see in that scenario and that is, indeed, a security issue (allows a MITM attack). "Test B", however, is not a security issue at all, IMO; instead, it is "working exactly as intended". > The Apache logs are not even needed without SSL enabled because the first request to the web server includes the username and password in clear text. If SSL isn't enabled then, yes, of course it does. This may come as a shock to the author but standard IMAP4/POP3 without SSL also sends credentials in the clear (as does -- gasp! -- every other plain-text protocol!) > Even when SSL is not enabled the client should not be sending the credentials without first verifying that it is a real exchange server. And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response? > Realistically the client should not even send the password before verifying the user exists. That, however, would be an information disclosure vulnerability (identifying valid usernames on the server). That's why no other mail server in use on the Internet does that either. Not to mention that it's real easy for a malicious attacker (in control of the server) to lie about that too. Aside: if you're running an Exchange server, set up Autodiscover [0] and all your users need to set up their mail account is their username and password (no server details are needed!). For other (i.e. non-Exchange) mail servers, there's a similar "Autoconfiguration" method that is supported by various mail clients, such as Thunderbird [1]. [0]: https://msdn.microsoft.com/en-us/library/office/jj900169(v=exchg.150).aspx https://msdn.microsoft.com/en-us/library/office/jj900169(v=e... [1]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...

creator_lol 9y ago
> And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response? umm , yes?? Even a simple check would increase the complexity a successful attack. Yes it could be duplicated , but having a client that just dumps the credential without any verification does not sound like a good idea and is poor programming.
- tomsmeding 9y ago
  Including some fixed piece text in a server response is not complex. It does not increase the security of the system.
dogma1138 9y ago
There is no lack of certificate validation in step A, they've just gracefully omitted it: https://imgur.com/a/OXIal https://imgur.com/a/OXIal
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
willstrafach 9y ago
> To be clear, the issue in "Test A" is the lack of certificate validation. It wasn't immediately clear (poorly worded, IMO) but that's the (only) issue I see in that scenario and that is, indeed, a security issue (allows a MITM attack). Actually, even this is completely wrong. You are understandably giving a charitable reading to the poorly worded explanation. I have tested this earlier today on an iOS 10.3.3 device and an iOS 11 device, and the TLS certificate is absolutely validated properly. As you've stated with Test B, yes, if SSL is turned off then the information is indeed sent in plaintext during the account setup. However, I don't know what the purpose of this test was, as this is (as you said) expected behavior.
- ktta 9y ago
  The TLS is validated properly, but the credentials are sent even before (or right when?) the dialog shows up about the certificate error. To be clear, here is what I did. 1. Settings->Add new account-> Exchange 2. Entered email ID (with @leakyx.com domain) and password and selected 'Next' (iOS 11 required hitting Next, and entering password on the next screen. iOS 9.3.5 has only one prompt for both email and password) At this point, a dialog showed up about the cerficate not being valid. You have the option to continue and trust the certificate or hit 'cancel' 3. I hit cancel. (Which means, you don't trust the certificate) The credentials still showed up. I did it twice to be sure. On leakyx.com, ktta@leakyx.com is with iOS 9.3.5 and iOS11@leakyx.com is with iOS 11

throwaway613834 9y ago

[Edit: nope, I misunderstood the issue... ignore my comment.]

deleted 9y ago
[deleted]
AaronFriel 9y ago
This is a bigger issue because those credentials can be used to authenticate to the Exchange server to download emails or, if they're using Active Directory elsewhere in the enterprise, to VPN in, to log in to servers, so on and so forth.
- throwaway613834 9y ago
  Oh you're right :\ will remove my comment, thanks for pointing this out.

MichaelGG 9y ago

So a more realistic scenario might be after gaining access to a company's LAN, or at a public WiFi? Did I read it right, you can force downgrade Exchange clients from TLS to plaintext, essentially? What more did Apple say on the phone? No rationale given?

mirashii 9y ago
I see no evidence of a force downgrade, you can see in the screenshots that he configured SSL off. If you configure SSL off, your credentials go over the wire in plaintext. Surprise surprise.
- MichaelGG 9y ago
  Oh. Well then it's a complete non issue. No wonder MS told them off.
  - hexadecimated 9y ago
    I don't see what other response he could have reasonably expected from Microsoft, given that his complaints were about the iOS Exchange connector, and actually had nothing to do with Exchange Server.
dogma1138 9y ago
No, there is no vulnerability here there is no real way to force downgrade or redirect traffic, iOS will prompt a message asking you to confirm a self signed certificate..... What the author claims is a vulnerability isn't one in any real sense. They basically "complain" that the mailbox on the iOS phone doesn't "validates" that the server is a real exchange server, in all honestly neither does outlook, nor most other client-server protocols I know off if the server isn't correct it will fail that's it. Even if there was a way to downgrade or redirect traffic if you have the ability to do that it's game over, if you can MitM an SSL connection between an iOS device and it's server faking a layer 7 handshake isn't really hard to do at that point.
- 9y ago

mavhc 9y ago

Why is it sending a password at all?, surely it should be at least a hash of the password

raverbashing 9y ago
Do not send hashes. Do send challenge/responses. Hashes can be replayed. (Or send passwords over TLS)
- mavhc 9y ago
  Sure, my question is more is there a history to this protocol? Is it from the 80s or something?
jlgaddis 9y ago
No, it surely shouldn't.
lawnchair_larry 9y ago
If that would work, it would mean the hash is actually the password.

mirashii 9y ago

There's nothing newsworthy here, just some guy trying to make a name for himself by giving his so called vulnerability a flashy name and website.

mdeeks 9y ago
No, underneath the bad writing it appears there is a real problem here. If you go to his simple walkthrough page you get a better understanding: https://leakyx.com/info.php https://leakyx.com/info.php Credentials are sent BEFORE prompting the user to accept a self signed cert. So it sounds like an attacker can harvest credentials on a rogue wifi by spoofing DNS and using a self-signed cert. I don't have an iOS device so I can't test.
- mirashii 9y ago
  Can't edit to correct, but if what you say is true, I agree. Also no iOS device to test. It's really difficult to tell that's what's happening in the midst of all the incorrect statements and conclusions even up to that point, and with the B section being even more absurd. It's quite possible that the reporting to vendors would also miss the legitimate vulnerability through the rest of the noise.
- DiThi 9y ago
  That link explains the problem much better than TFA.
- willstrafach 9y ago
  > Credentials are sent BEFORE prompting the user to accept a self signed cert. So it sounds like an attacker can harvest credentials on a rogue wifi by spoofing DNS and using a self-signed cert. I don't have an iOS device so I can't test. This does not appear to be the case (Tested on an iOS 10.3.3 device and an iOS 11 device).
  - mdeeks 9y ago
    Thanks for confirming. So then there is nothing at all of substance in this article.

frlnBorg 9y ago

Would this affect Office 365 hosted exchange servers?

deleted 9y ago
[deleted]

Stranger43 9y ago

And all this while everyone is paying billions for complex info-sec software that does a lot less then it says on the tin. It's similar to the epidemic problem with non-verified/signed SSH keys where everyone just clicks Ok to any host-key presented. Though a bit more subtle, and something that should have been avoidable with a proper designed protocol. It's the kind of trivial little thing that gets ignored(along with boring old maintenance tasks like patching infrastructure servers ect.) not despite of but because of all the attention given and budget spend on attending conferences on cyber-warfare and never to be correctly installed(let alone monitored) infosec appliances. Almost every major hack ever blamed on super advanced state sponsored groups turns out to be someone fumbling a routine update (like what happened with equifax and wannacry) or setting a bad password(guccifer 1+2 etc.) And yet the lesson that gets drawn is never, "lets start following proper procedures for maintenance and training" but "lets reduce the maintenance budget some more by spending on infosec conferences and toys."

DiThi 9y ago

So basically typosquatting? It seems to me that any service that doesn't show the SSL certificate (or the EV name) is vulnerable to this, not just Exchange on iOS. Edit: It seem it doesn't check the SSL certificate either. But it's super easy to get a valid SSL certificate nowadays, so just checking the SSL certificate for validity wouldn't be enough.

jlgaddis 9y ago
Why wouldn't it be enough?
- DiThi 9y ago
  Because setting up a let's encrypt certificate is almost as easy as to making a self signed one. We're talking about typosquatting, having a completely valid domain of your own that is the same as someone else's but with a typo. Edit: From what it is said in another comment, it's not exactly about typosquatting, but the author expresses the problem very badly. It seems credentials are sent to the domain before the certificate is checked. So one is vulnerable to DNS spoofing in e.g. a public wifi.
  - lesserknowndan 9y ago
    I'm not sure how they can be more clear than the first sentence, "So back in February I discovered that an iPhone was sending usernames and passwords unencrypted to an exchange server even when SSL was enabled." Are you saying the later text contradicted this statement?
    - deleted 9y ago
      [deleted]
    - ktta 9y ago
      It was a bit confusing since he talks about typosquatting. He also talks about credentials sent unencrypted when SSL is off, which further makes everyone question the validity of his claims. But he did find a vulnerability in iOS's Mail app.

jlgaddis 9y ago

I find it funny that people are injecting alert()'s into the testing tool -- a vulnerability in a vulnerability report! cf. https://leakyx.com https://leakyx.com.

deleted 9y ago

[deleted]