Southwest Airlines iPhone App Unencrypted, Vulnerable To Eavesdroppers 139
New submitter davidstites writes "I am a masters computer science student at University of Colorado at Colorado Springs, and in November I performed a security audit of 230+ popular iOS applications because I wanted to know how secure apps on smartphones and tablets really are. I made a shocking discovery. The largest single potential security breach was with the Southwest Airlines application. Southwest Airlines' iPhone app leaves a user's information vulnerable to hackers. When you login to the application on your phone using your Rapid Rewards account, the app submits your username and password information as plain-text (unencrypted) to a Southwest remote server (mobile.southwest.com). A potential attacker can simply sniff for the data on the network and steal it. This situation is a hackers dream! If a victims credentials were captured, a hacker could use those credentials to login to that particular account and they would have access to anything the victim would have access to, such as addresses, birthdays, e-mail, phone and credit cards. They could even book a flight in the victims name." (Read on below for more details.)
davidstites continues: "This not only obviously worrisome from the standpoint of a potential attacker fraudulently using a victims account and credit card information, but also due to the possibility of terrorist threats in air travel.The possibility of being able to capture this data is especially probable since Denver International offers free WiFi and it is an unencrypted network. The probability that a Southwest passenger would login to their account is also quite high since they have an entire terminal to themselves (C concourse). However, this could occur on any unencrypted or encrypted network.
Consider the possibility of a person who is currently (and rightfully) on the Department of Homeland Security's 'No-Fly' list. If this person were able to capture a victim's credentials and create a fake ID, he could pass through TSA security without being stopped.
I don't know how Southwest Airlines let this happen, but sometimes companies have to decide between security and the bottom line. Companies rush to get products out, the engineering dollars are not there to complete the project, so security falls to the back. Usually, security is not thought of as a benefit, until it fails.
I contacted Southwest when the vulnerability was found in early December and they still have not released a patch as of today and they have never contacted me back about the vulnerability. Until the security flaw is fixed, the best solution is to not use the application.
A full list of applications with vulnerabilities can be found here. Additionally, some local NBC and ABC news stations and the Denver Post covered this story."
Part of this is because of US Export Restrictions (Score:5, Informative)
It's a pain in the behind to distribute apps with encryption code (even if all your app does is use SSL!) on the app store.
You need to go through hoops registering with the US government for an export license for every app you publish. When we built our software, we got hit with these requirements and had to go through a bunch of paperwork that really slowed us down and gave us a headache all because we communicate with only communicate with our web service via SSL.
It's ridiculous that there's no exemption for SSL usage on US export controls. It's just a pain in the ass for everyone in the process and you can't honestly claim that it prevents awfully dangerous tech from getting into the enemy's hands.
Re:Part of this is because of US Export Restrictio (Score:5, Informative)
Yep. You can't even preconfigure a server with openssl and ssl enabled if it is sold outside of the U.S. Pretty funny huh?
Re:I blame Denver Internation Airport ... (Score:5, Informative)
... because I'm just looking for someone else to blame, too. But there is this big WTF:
The possibility of being able to capture this data is especially probable since Denver International offers free WiFi and it is an unencrypted network.
It doesn't have to be unencrypted to be free.
Well, if you want a secure encrypted network, it's probably not going to be free.
There's only moderate additional security gained by having a WPA encrypted network where everyone has the same PSK since it's trivial to capture the association handshake (by forcing them to reassociate if neccessary) and steal the session key from anyone's session - Wireshark will do this for you. Alternatively, you can set up a hotspot on your laptop called "SouthwestAirlines" and nearby clients will connect to your laptop instead of the real Southwest network and you can capture all of their packets.
To make a secure encrypted network, they'd need to implement something like 802.1x security with unique username/passwords for each user and with Wifi clients configured to authenticate the network's 802.1x certificate (to prevent someone from setting up a rogue SouthwestAirlines access point).
Few providers of free Wifi service are going to be willing to run a helpdesk to assist all of the users with setting this up - it's not always trivial (depending on the device). So it's probably better to not provide the illusion of a secure encrypted network when it's not. The users that are sophisticated enough to set up 802.1x authentication on their device are probably also sophisticated to use a VPN to secure their data.
When I connect via an open Wifi network, I always VPN to my company or my home internet router so all of my wifi traffic is encrypted.
Re:Part of this is because of US Export Restrictio (Score:4, Informative)
It seems that if you let the user transmit or receive encrypted data (even if it's just a login!) you need to get a license.
We use the built in iOS classes for HTTP requests that support SSL transparently. The US government still required us to register for export compliance. It's really senseless.
Re:Part of this is because of US Export Restrictio (Score:4, Informative)
Chiming in here to agree with spac.
This is another annoying grey area with Apple's rules. When you submit an app to the App Store, it asks you if you use encryption, and if you do, you have to have an export license from the USA government. I don't believe there's anything that specifically addresses SSL/TLS in Apple's documentation. If you contact Apple, they usually tell you that you need a license for it, even if you use the features built into iOS. If you don't contact Apple and say that you don't use encryption, sometimes you can get through the approval process. I think it's a case of the Apple employees who you contact playing it safe while reviewers can be a bit sloppy.
I've personally been involved with an app that transmits personal information including GPS coordinates, names and telephone numbers, and it does so without using SSL/TLS for precisely this reason - the company wanted to release as quickly as possible without waiting to get an export license. I didn't like that, but unfortunately, the decision was out of my hands.
I think the best thing Apple could do, assuming that there is no way around the law, is to make it more clear to developers that this is required in their rules, to automatically scan apps for SSL/TLS use to reject apps without a license consistently, and to reject apps that don't use SSL/TLS to transmit personal information.
Re:Secret lists (Score:5, Informative)
Consider the possibility of a person who is currently (and rightfully) on the Department of Homeland Security's 'No-Fly' list. If this person were able to capture a victim's credentials and create a fake ID, he could pass through TSA security without being stopped
Oh, please. Fuck off with the fearmongering. Even the DHS knows that the threat of terrorism is a bunch of bullshit.
Not to mention the fact that the TSA has never stopped anything. Quadrupled boarding times, humiliated grannies, scared children, yes, but stopped anything? Oh wait, Ted Kennedy and Rand Paul. "Brillant!" [sic]