Internet security and cryptography have always been a huge interest of mine and are topics that are becoming increasingly more important for people to understand. To further my knowledge of the subject, I have recently been reading the absolutely brilliant Security Engineering by Ross Anderson, and have been particularly captivated by two particular attacks; man-in-the-middle attacks and the even more devastating phishing attack.
About a week ago, Andrew, a fellow engineer, approached me with an Android-based penetration suite which we decided to use to take a quick inventory of the security of our personal internet properties. While I personally have experience with elementary penetration testing (mostly through using the metasploit framework), I never thought I would be able to perform the more advanced man-in-the-middle-attack that has provoked my interest so thoroughly. To our surprise (and horror), we were able to perform this attack with a tap of a button. Shortly after initiating this attack, we discovered our own two email credentials appearing in plain on our devices. After performing a number of further tests (which I will expand on momentarily) we noticed a trend; it seemed like the Mac application, Airmail, was sending our credentials unencrypted over the network despite us both having SSL enabled within the client.
Before I go into more detail about how we tested this theory and how one could reproduce this, it might be appropriate for me to explain some basic concepts.
A man-in-the-middle attack is when a device (phone, computer, or router) spoofs your own personal device into thinking that it is the true party you are attempting to communicate with. The graphic below might help illustrate this concept:
In this example, Alice is attempting to communicate information with Bob (in the vulnerability we are reporting on, we were ‘Alice’ and the email server was ‘Bob’). In a man-in-the-middle attack, however, a third party (in this example, Mallory) intercepts both Alice and Bob’s internet traffic and tricks them into thinking they are talking directly to one another, but in reality, all traffic is going through Mallory who is able to view any unencrypted data.
A key point about a man-in-the-middle attack is that theoretically, only unencrypted information is at risk. Cryptographers have developed a number of extremely effective methods of encryption to prevent this problem; The most popular and widely used being SSL. When you visit a website and see the green “lock” button (assuming you are using Chrome), that indicates your traffic is being encrypted using the SSL protocol. Without going into too many details, SSL, when enabled on your email client, will communicate with the server using an encrypted channel. Even if someone intercepts this traffic, they would have to decrypt the information (an operation that requires a massive amount of time and computational power, or access to either user’s secret key) to be able to read the contents of any data sent between the two original parties. SSL additionally uses a third party to independently verify the integrity of both communicating parties. In essence, SSL is the main defense one can use to prevent any potential man-in-the-middle attacks from obtaining sensitive information.
The problem Andrew and I identified was that Airmail was sending our credentials without encryption, despite the fact that we selected the “SSL” option in the application’s settings and both email providers we used supported SSL. We are still not sure if this is a legitimate vulnerability or if there are other factors at play. In addition, we have notified developers at Airmail and are working with them to investigate this issue further. That being said, we wanted to walk through the steps we used to reproduce the problem in hopes that more knowledgeable members of the tech community will be able to verify or reject our conclusions.
To test this vulnerability, we first created a new Gmail and Yahoo mail account that we would use to test different mail clients and providers. We than loaded those accounts onto Apple’s “Mail” client, Airmail, and accessed each provider’s web client. We than initiated a man-in-the-middle-attack (using dSploit) on all traffic on our network, and sent an email using both Apple Mail and the web client. We were unable at that point to see the two accounts’ credentials. We than sent an email using Airmail (again with SSL enabled) and proceeded to intercept both accounts’ credentials. Not being satisfied with this test alone, we replicated the prior steps on additional networks. Time and time again, we were able to see credentials of accounts using Airmail, but no credentials of accounts using any other email client.
Until this issue comes to a conclusion (with us either being proven wrong, or an update being made to the software), we have discontinued all use of Airmail. In addition, we have encouraged our colleagues to take the following steps to protect themselves from any other potential attacks. Mainly, using a single password for numerous online services is a big mistake. We encourage everyone to use a password manager and generate completely random passwords for each site they use. While this does not prevent the attack we described in this post, it is a essential habit to practice. Additionally, we recommend using software such as HTTPS Everywhere to force websites to use SSL encryption if available.
As we move forward with investigating this issue, we will keep everyone up to date. As stated, we hope more knowledgable parties will reproduce our tests and help us move towards a conclusion.
Please feel free to reach out to email@example.com if you have any questions or information on this subject – or just leave it in the comments below.