Thursday, April 17, 2014

iOS clients not vulnerable to Heartbleed. What does the source say?



Apple's language in their assertion that they are not vulnerable to heartbleed on iOS are troubling as they specifically say (via ReCode), "IOS and OS X never incorporated the vulnerable software..."  However, not incorporating the vulnerable OpenSSL software is merely one way that their customers could have been made vulnerable.  What about the Apple SSL/TLS implementation?  Has anyone checked it?  Did they incorporate RFC 6520 for heartbeat support?  I couldn't find anything Google so figured I would share what I found.

Since the Apple SSL library code is open sourced, we can actually look at the code.  And based on my read of the code, Apple doesn’t even implement the heartbeat extension. http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslHandshake.h doesn’t even define the heartbeat helloextension code 15 in the data structure:

/* Hello Extensions per RFC 3546 */
typedef enum
{
 SSL_HE_ServerName = 0,
 SSL_HE_MaxFragmentLength = 1,
 SSL_HE_ClientCertificateURL = 2,
 SSL_HE_TrustedCAKeys = 3,
 SSL_HE_TruncatedHMAC = 4,
 SSL_HE_StatusReguest = 5,

 /* ECDSA, RFC 4492 */
 SSL_HE_EllipticCurves  = 10,
 SSL_HE_EC_PointFormats = 11,

    /* TLS 1.2 */
    SSL_HE_SignatureAlgorithms = 13,

    /* RFC 5746 */
    SSL_HE_SecureRenegotation = 0xff01,

 /*
  * This one is suggested but not formally defined in
  * I.D.salowey-tls-ticket-07
  */
 SSL_HE_SessionTicket = 35
} SSLHelloExtensionType;

Then in the implementation http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslHandshakeHello.c, they actually only support one extension, SSL_HE_SecureRenegotation. All others return an error code.

     switch (extType) {
            case SSL_HE_SecureRenegotation:
                if(got_secure_renegotiation)
                    return errSSLProtocol;            /* Fail if we already processed one */
                got_secure_renegotiation = true;
                SSLProcessServerHelloExtension_SecureRenegotiation(ctx, extLen, p);
                break;
            default:
                /*
                 Do nothing for other extensions. Per RFC 5246, we should (MUST) error
                 if we received extensions we didnt specify in the Client Hello.
                 Client should also abort handshake if multiple extensions of the same
                 type are found
                 */
                break;
        }
So, it appears from the library code that they would not be vulnerable to this bug at all.

Sunday, April 13, 2014

Using VNC to securely connect to OSX without exposing an unlocked console

I couldn't believe how supremely difficult it is to securely use VNC to access an OSX mac remotely.  Turns out that by default, using a standard VNC client (as opposed to an Apple Remote Desktop client) does not afford you an option to have the physical console lock when someone connects to the VNC server.  Some third-party clients make this an option, but all that I could find were paid VNC clients that support it.  It is somewhat ridiculous that this setting is left to the client rather than enforced on the server, but I digress...

I tried a few things suggested, such as enabling the screen saver or screen blanker, but those did not solve the problem as they did not differentiate between the VNC session and the physical desktop session so applied equally (the only states that were valid were either both unlocked or both locked).  Other options people suggested were to just turn the screen brightness all the way down.  This is security through obscurity though (the display is still unlocked and anyone who can get to your mouse/keyboard could mess with your computer, they just would be blind to what's on the screen).  It also seems problematic for usability (imagine you turn the brightness down and then come into the office the next day; how are you supposed to see the screen when you login if the brightness is still forced to the minimum?)

The solution I found that had the right security and usability properties was to use fast user switching + the Vine VNC Server.  This enables you to have a different set of content on the physical display from what you see remotely on VNC.  Unfortunately, fast user switching with the Apple VNC "Screen sharing" server doesn't work.  It mirrors your display exactly to the VNC display so does not allow you to have separate physical and remote displays.  I presume that's why it has a name like "Screen sharing".  It's also not surprising that this doesn't quite work as well outside of the Apple monoculture.
  1. Download and install Vine VNC Server
  2. Enable Fast User Switching on the mac
  3. Enable fast user switching on OSX Mavericks
  4. Connect to Vine VNC Server on OSX with any VNC client (e.g. on port 5901).  I configure Vine to require SSH so it doesn't listen to any remote port and requires SSH port tunneling to use it.  Less attack surface.
  5. Go to the fast user switching menu and select "Login Window..."  When you do this, the physical display will change to the login screen but the VNC window will remain unlocked and functional, as desired.
Switch to login screen


I get an IRS scam voice-mail

Had to share this hilarious voice-mail I received from an IRS scammer (happened to come in with Unknown caller ID -- I read online that others had been spoofing US phone numbers for caller ID in the past). The transcript does not do it justice.  I laughed out loud when I heard the phrase, "and you get arrested" as that is precisely what one would expect to hear from the IRS.


They actually tried calling me back and I got to talk to one of the people that afternoon, but my crummy cell service in my office resulted in the call dropping before I could chat with them too much. I told them that I didn't believe them that they were from the IRS. Maybe they'll call back again this week?

I plan on reporting it, as suggested.  Head over to the IRS Tax Fraud Alerts page.  Perhaps the best channel will be via their Phishing page.  The IRS warning regarding this scam provides some information but there is of course no direct links to report the issue.  I wonder if the 20,000 that reported it are a small fraction of those victimized since it's so difficult to find a way to report it?  They also suggest lodging a complaint with the FTC as well, but that is also somewhat difficult to determine how to categorize it for reporting.

See also: "IRS monitor: $1 million phone scam 'largest ever' - Mar. 20, 2014 ." Last modified 04/14/2014 05:10:31. http://money.cnn.com/2014/03/20/pf/taxes/irs-phone-scam/ (accessed 4/13/2014).


Transcript

Good morning. This is Willy ["Villy"] Mandersen, calling you from Internal Revenue Service...Crime Investigation Department.  The nature and the purpose of this call is just to let you know that....we have received...a legal petition notice...against your name...under your social security number. So, before this matter goes to the Federal claim court house...and you get arrested, kindly call us back at (866) 978-8320. I repeat (866) 978-8320.  Remember, don't disregard the message...as it is very important for you.  And if you don't return the call, then the situation will be worse. So take care about it, and call us back as soon as possible. Goodbye.