In Security

I just released a new version of SSLyze which brings new features and improvements. As usual, pre-compiled packages available in the release section of the project’s page on GitHub.

Most of the changes were toward making the XML output more consistent and easier to parse. As a consequence, the updated XML formatting will break any application that was processing XML results from the previous version. However, I’ve also generated an XML Schema Definition to help developers work with the XML output.

As described in the changelog, additional new features were implemented, most of them coming from pull requests from various contributors including cjeanneret, arirubinstein, wolfgangkarall and bluec0re. As always, it is pretty cool to see people getting involved!

Full Changelog

• Added support for Postgres StartTLS; see --starttls=postgres
• Added the --ca_file option for specifying a local trust store to validate the server’s certificate
• Added the --quiet option to hide any text output when using –xml_out
• Improved the formatting of the XML output to make it easier to parse and more useful; this will break any tool that was processing the XML output from previous versions, but an XML Schema Definition is now available in SSLyze’s root folder
• Bug fixes for EC certificates, HSTS, XMPP and LDAP
• Updated OpenSSL to 1.0.2a
• Updated Microsoft, Apple and Mozilla trust stores

SDWebImage is a popular iOS library for implementing asynchronous image downloads. Last year, I reported to the development team that SDWebImage had SSL certificate validation disabled when fetching data over HTTPS.

The issue was introduced in June 2014 in version 3.7.0: certificate validation was disabled as a side-effect of adding support for NTLM authentication to the library’s NSURLConnectionDelegate. The specific commit is available here.

The team just released version 3.7.2, which finally addresses this issue and re-enables certificate validation; the actual fix can be seen here. If you’re using SDWebImage in your App, make sure to update the latest version (as always)!

What I thought was the most unexpected thing described in the MASQUE attack on iOS was the ability for an App with the same bundle ID, but signed by a different developer identity, to replace the original App already installed on the device; when doing so, the evil App would then have access the original App’s private files!

Among many other security vulnerabilities, Apple fixed this issue with the release of iOS 8.1.3:

MobileInstallation
Available for: iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later
Impact: A malicious enterprise-signed application may be able to take control of the local container for applications already on a device
Description: A vulnerability existed in the application installation process. This was addressed by preventing enterprise applications from overriding existing applications in specific scenarios.

On iOS 8.1.3 if you try to trigger a malicious update, the installation will fail and mobile_installation_proxy will return the following error message:

Upgrade’s application-identifier entitlement string (ZRJBFW2XA8.com.package.name) does not match installed application’s application-identifier string (G4686YFCAH.com.package.name); rejecting upgrade.”

The team ID (which is tied to the developer’s signing identity) is now validated to ensure that the old App and the new App use the same one.

The tcprelay.py and usbmux.py Python scripts from the usbmuxd project make it possible to SSH into an iOS device over USB. This makes it easy to interact with the device without having to rely on WiFi, as described here.

I have modified tcprelay.py to allow forwarding SSH connections to multiple devices connected via USB, instead of just one. The device’s udid can be specified using the -u option:

python tcprelay.py -t 22:5000 -u ddbc43f3247126671d2c7c279723cb2f9f93ace1

If -u isn’t supplied, tcprelay.py will use the first device available.

See the project page for more details and code.

Last week, I presented my talk about how I reverse-engineered Apple’s Multipeer Connectivity framework at Hack in the Box in Kuala Lumpur.

I made various changes to the slide deck compared to what I presented at Black Hat US so the updated slides are available here.

I just released a new version of SSLyze which brings new features and improvements. As usual, pre-compiled packages available in the release section of the project’s page on GitHub.

Diffie-Hellmann Parameters Size

When listing the cipher suites supported by the server, SSLyze will now display the size of the Diffie-Hellmann parameters for DHE and ECDHE cipher suites. The output looks like this:

* SSLV3 Cipher Suites:
  Preferred:
             ECDHE-RSA-RC4-SHA             ECDH-256 bits  128 bits

The DHE and ECDHE cipher suites are being widely deployed because they provide perfect forward secrecy. However, a server using extremely weak Diffie-Hellmann parameters would give an attacker the ability to crack the session key and decrypt the SSL traffic. Adam Langley wrote a blog post about it:

So the first way to mess up forward secrecy is to use under sized DH groups. Ideally the DH group would match or exceed the RSA key size but 1024-bit DHE is arguably better than straight 2048-bit RSA so you can get away with that if you want to. If you’re using ECDHE then you don’t need to worry about it being too small because the smallest EC group that clients support (P-256) is far, far stronger than 2048-bit RSA anyway.

Major props to @elvanderb who had to mess with OpenSSL internals in order to get the DH parameters’ properties and implemented this feature from scratch!

Full Certificate Chain Returned

Previous versions of SSLyze only returned the server’s leaf certificate when using the --certinfo option. The full certificate chain is now returned in the tool’s XML output to allow for further processing/validation.

Chrome SHA-1 Deprecation Plugin

Google has started the process of deprecating SHA1-signed certificates by displaying additional HTTPS warnings in upcoming versions of Chrome. The --chrome_sha1 option can be used to check whether a server’s certificate chain will be affected by these changes:

* Google Chrome SHA-1 Deprecation Status:
  Chrome 41 behavior: AFFECTED - SHA1-signed certificate(s) will trigger the "Secure, but minor errors" icon.

Thanks to @tomrittervg for coming up with the idea and the initial implementation.

Python no Longer Required on Windows

The Windows release is now packaged as a single executable and no longer requires Python.

SSLyze is now Hosted on my own GitHub Account

Of lesser importance, I have also moved the SSLyze active repository to my personal GitHub account. The original repository will no longer be updated so please update your bookmarks. If you cloned the repo, you can update the repo’s origin by using the following command:

git remote set-url origin https://github.com/nabla-c0d3/sslyze.git

Full Changelog

• PluginOpenSSLCipherSuites now displays the size of the handshake’s Diffie-Hellmann parameters
• SSLyze on Windows is now packaged as a single .exe file
• PluginCertInfo now displays the server’s full certificate chain instead of its leaf certificate only, in both the console and XML results
• PluginHSTS now properly detects HSTS headers when receiving HTTP redirections
• New plugin to check if a server is affected by Chrome’s deprecation of SHA1-signed certificates. See –chrome_sha1
• Clarified the console output of most plugins and checks
• Bug fixes for XML output and client certificate support
• Updated OpenSSL to 1.0.1i
• Updated Microsoft, Apple and Mozilla trust stores

Update: in iOS 9, Apple implemented a mitigation for the downgrade attack I described in the presentation.

Earlier this month, I spoke at the Black Hat US conference about Multipeer Connectivity on iOS and OS X. The slides are available here and this post is follow up article with things I did not have time to talk about during the talk.

Multipeer Connectivity TL;DR

• The protocol used for data exchange (the “session phase”) is a simple UDP-based protocol, wrapped in DTLS 1.0 in most cases.
• The authentication (on or off) and encryption settings (MCEncryptionNone, MCEncryptionOptional, MCEncryptionRequired) set by the App developer control wether DTLS is used and the list of cipher suites enabled during the DTLS handshake.
• Enabling authentication causes the protocol to perform a mutually-authenticated DTLS handshake (ie. each side/peer exchanges their certificate).
• Disabling authentication with encryption enabled results in the usage of Anonymous TLS cipher suites (ie. no certificates get exchanged), which are vulnerable to man-in-the-middle attacks.
• Disabling both authentication and encryption switches DTLS off; the plaintext UDP protocol is directly used.
• Overall, most of the authentication and encryption settings work as advertised by the Apple documentation except for MCEncryptionOptional when used with Authentication, which is vulnerable to downgrade attacks:

This diagram extracted from the slide deck summarizes my analysis of Multipeer Connectivity’s security settings:

The details on why I “blacklisted” some of the security settings are available in the slide deck.

The Missing Slides

Multipeer Connectivity is a fairly complex Framework and there are quite a few interesting topics that I just did not have time to talk about during my Black Hat talk.

Implementing Authentication

When enabling authentication, the App developer has to deploy certificates and private keys to all instances of the App running on the users’ devices. Every device/App then has to validate these certificates when pairing with other devices. Properly deploying a PKI is a very difficult task; here are some pointers on how to achieve this in the context of Multipeer Connectivity.

Authentication using Trust-On-First-Use

One option is to generate the certificate and private key on the device the first time the App is launched (using SecKeyGenerate()). Then, the first time two devices pair with each other, they should store/pin each other’s certificate and validate it on subsequent Multipeer Connectivity sessions. The advantage of this solution is that it does not require an Internet connection.

Authentication using an identity server

Another option is to instead rely on a backend identity server to fetch user/device certificates. This is a simpler approach but requires an Internet connection to fetch identities, which may be a challenge as Multipeer Connectivity is designed to work without any Internet connectivity.

Apple has already deployed a similar device/user PKI tied to the user’s iCloud account; this is leveraged for example when using Airdrop with the “Contacts only” feature. It would have been pretty cool if Apple let developers use this existing PKI to authenticate devices based on the user’s contacts, when implementing Multipeer Connectivity within an App.

Certificate validation

Remember that certificate validation is very tricky to get right. Be extra careful when implementing your session:didReceiveCertificate:fromPeer:certificateHandler: certificate validation method.

Implementing Customized Pairing

During the presentation, I only showed the default pairing process which displays a prompt to the user receiving the connection:

</img>

However, as a developer, it is possible to fully customize the pairing process. For example, an App could be implemented to not even display a prompt to the user during pairing, basically allowing auto-pairing. This is what the FireChat App does in order to allow nearby users to chat anonymously without having to go through a confirmation prompt. For a quite a few use cases (such as file sharing), auto-pairing could be a major security risk; as a developer, be very careful if you decide to customize the pairing process.

Real-world Apps Using Multipeer Connectivity

One of the questions I got asked was what kind of Apps currently available were using Multipeer Connectivity.

Non-Apple Apps

I found quite a few Apps on the store including:

• Audibly: Stream songs to other devices to use them as speakers.
• iTranslate Voice: “AirTranslate”: translate voice in real-time and stream the translation to a nearby device.
• FireChat: Anonymous “off-the-grid“ chat.

Of course there are tons of other possible use cases: collaborative editing, file sharing, multiplayer gaming, etc.

Apple Apps

I haven’t actually found any official Apple App that uses Multipeer Connectivity. However, I’ve only looked at a couple things so far:

• Airdrop: Airdrop uses very similar technologies (Bluetooth, Bonjour, etc.) but it’s not Multipeer Connectivity.
• HomeKit on iOS 8: HomeKit is a new Framework on iOS 8 which “enable users to discover devices in their home and configure them”; it does not use Multipeer Connectivity either.

There are other Apple Apps/features that could be leveraging Multipeer Connectivity, including Handoff on iOS 8, which I’ll eventually look at when time allows.

Earlier this week, I was speaking at the Black Hat US conference in Las Vegas. The topic of my talk was the Multipeer Connectivity Framework Apple introduced in iOS 7, which “provides support for discovering services provided by nearby iOS devices […] and subsequently communicating with those services by sending message-based data, streaming data, and resources (such as files).” This Framework will also be available on Mac OS X starting with Mac OS X Yosemite, which will be released in a month or so.

The slides for my presentation are now available for download.

I will post more information about Multipeer Connectivity on this blog later this week, including things that I did not have time to talk about during the presentation… stay tuned!

I just released a new version of SSLyze. This version brings a few improvements and bug fixes as well as a new plugin to identify servers affected by the Heartbleed vulnerability.

Heartbleed Testing

To implement the Heartbleed check, I used the methodology described on Mozilla’s blog, which has the advantage of not directly exploiting the vulnerability unlike most Hearbleed-testing scripts that have been released. Mozilla’s technique does not retrieve memory from the server, thereby avoiding server crashes or sensitive data exposure.

Additionally, SSLyze’s implementation uses the tool’s existing networking code, allowing Heartbleed testing against multiple servers at the same time and on StartTLS services including XMPP, LDAP, SMTP, FTP and POP. Also, just like all of SSLyze’s checks, Heartbleed tests can be tunneled through an HTTPS proxy.

Full Changelog

• Experimental support for Heartbleed detection; see --heartbleed. Heartbleed detection has also been added to --regular scans
• Capped the maximum number of concurrent connections to around 30 per server in order to avoid DOSing the scanned servers. Scans are slightly slower but a lot less aggressive, resulting in better scan results with less timeout and connection errors
• Support for Basic Authentication when tunneling scans through an HTTPS proxy with --https_tunnel
• Bug fixes for IPv6 and XMPP support
• Updated OpenSSL to 1.0.1g
• Updated the Apple, Microsoft, Mozilla and Java trust stores
• Cleaned up the text output of PluginOpenSSLCipherSuites

Download

SSLyze requires Python 2.7; the supported platforms are Windows 7 32/64 bits, Linux 32/64 bits and OS X 64 bits. Pre-compiled packages available in the release section of the project’s page on GitHub.

A few months ago, iSEC Partners performed a security audit of the Cryptocat chat application on iOS. This audit was commissioned by the (awesome) Open Technology Fund and I was the lead tester on this project.

The final report we delivered was publicly released a week ago by the Cryptocat project. The document is available on Hacker News, and the Cryptocat project has also written a blog post about some of the issues we found and what they did to address them.

The iOS application was the main focus of our testing but we also found some interesting issues affecting the desktop clients. If you’re interested in Cryptocat and/or penetration testing in general, you should definitely have a look at the report.