Message-ID: <CAG--3ks0xiKdKhvSrYgiMwuW4pT2P-6hV_nx0GacVJkvP+2m6w@mail.gmail.com>
Date: Sun, 22 Feb 2015 11:07:08 +0000
From: Douglas Held <risk@...glasheld.net>
To: fulldisclosure@...lists.org
Subject: [FD] Fwd: Apple OS X: Don't trust,
	and don't prompt to trust certificates

Summary:

It is essential to provide a configuration option in the operating system
to:
1. never trust invalid certificates, and
2. to not prompt to trust them.


Steps to reproduce:

1. Install OS X on an Apple laptop.
2. Configure Mail.app (for example) to connect over SSL to your mail
server. Prepare a draft email with sensitive information about the
iPhone 8 or whatever.
3. Go treat yourself to a hotel visit.
4. Connect to the hotel Wifi SSID but do not pay or authenticate yet.
5. The dialog appears: "Verify Certificate. Mail can't verify the
identity of "your.secure.server.apple.com". The certificate for this
server is invalid. You might be connecting to a server that is
pretending to be "foo" which could put your confidential information
at risk. Do you want to connect to the server anyway?"
6. Accidentally click "Continue"
7. Send your sensitive email.


Remarks:

Networks implemented with a walled garden, or a malicious fake network
returning false DNS responses will both behave in the same way.  DNS
responses and any TCP responses are liable to be completely fake data.
In the case of the hotel network, until authentication every IP
address and HTTP response probably resolves to the Wifi login service.
Likewise, outbound SSL connections will return some sort of fake
response, including an invalid certificate, until you establish the
hotel's Wifi service.

In the alternate case of a malicious Wifi network, only a specified
subset of responses need to be fabricated, but clearly these would be
tailored by the attacker to steal or modify private data.

The certificate mechanism is the last line of defense for the end user
against such a Man-in-the-middle attack. To override the default trust
with a quick click of a "Connect" button robs the average user of a
reasonable level of protection from the operating system.

Further, the text "DO YOU WANT TO CONNECT TO THE SERVER ANYWAY?" and
the placement of the "Connect" button make it seem like a default
option and for the user who TL;DR the last sentence actually reads
like a goading suggestion.  A Google search of the error message
confirms, most users are concerned with clicking through the dialog
rather than their data privacy.


Expected Results:

1. For practical purposes, if the Mail.app program is configured with
SSL, then it does not actually have a connection to the mail server.
This is evident in the certificate mismatch itself.

2. User actions with high security implications should default to
secure options and should require a positive and unequivocal input for
setting any dangerous configuration.

3. A maximally secure, but still functional, setting should be possible.


Actual Results:

1. The Mail.app program connects to the invalid server once the user
clicks "Connect", or inadvertently types the Enter key at the same
time the dialog pops up.

2. In the case of a malicious Wifi network, the sensitive email has
now been sent to the Man-in-the-middle attacker.

3. It is not even possible to configure OS X to simply reject invalid
certificates outright.



Proposed changes:

1. Change the dialog box so it is much more difficult to ACCIDENTALLY
accept the invalid certificate;

2. Provide a global configuration option for the system administrator,
that trusts only a whitelist of mismatched certificates, and silently
rejects any other invalid SSL connection attempt.


Timeline:

April, 2014 - Disclosed to Apple via Bug Reporter #16505012
January 27, 2015 - attempt to request contact at Apple via
FullDisclosure. Result below.
January 29, 2015 - Reminded Apple to review, and advance notice of
public disclosure.



On Wed, Jan 28, 2015 at 8:58 PM, <fulldisclosure-owner@...lists.org> wrote:
>
> Your request to the Fulldisclosure mailing list
>
>     Posting of your message titled "Contact at Apple application
> security team"
>
> has been rejected by the list moderator.  The moderator gave the
> following reason for rejecting your request:
>
> "Numerous Apple employees are subscribed to this list so you should be
> able to get their attention by sending full details of the vuln to the
> list.  Cheers."
>
> Any questions or comments should be directed to the list administrator
> at:
>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists