Tired Of Airport Security Queues? SQL Inject Yourself Into The Cockpit, Claims Reseachers

Updated Cybersecurity researchers say they’ve found a vulnerability that allowed them to skip US airport security checks and even fly in the cockpit on some scheduled flights.

Ian Carroll and Sam Curry worked on the findings together after the Known Crewmember (KCM) queue caught their attention at an airport during their routine travel. The lane can sometimes be seen at airports and it allows verified pilots and crew to skip the often lengthy security queues, courtesy of a Transportation Security Administration (TSA) initiative.

Actual crew can apply for verification to the program and present a badge that grants them queue-skipping privileges. A similar initiative also exists for pilots only, the Cockpit Access Security System (CASS), which allows verified pilots to sit in the spare cockpit seat (jumpseat) during flights they need to take for whatever purpose, like commuting or leisure travel.

Of course, many of us have seen these authorized line jumpers while standing like chumps waiting to sling our stuff onto the security scanner belts, wishing we were one of them. But according to the researchers, you don’t need to put yourself through pilot school to get access to a jumpseat; you just need to learn how to exploit a SQL injection bug.

One small caveat

Despite as many as 76 airlines signing up for the KCM program, this wouldn’t have worked with the bigger providers.

ARINC, the company running the system that verifies individuals’ KCM status, is contracted by the TSA. At the airport, the TSA will initiate a check for a pilot or crewmember’s KCM or CASS status, which is passed to ARINC, which then routes that request to the airline to check whether the individual is, in fact, a real pilot or crewmember.

Bigger airlines tend to develop their own authorization systems to handle and respond to these requests, and are therefore not believed to be vulnerable.

Smaller operators, however, are more likely to rely on a third-party vendor’s services to fulfill their KCM and CASS system requests, the researchers note. In searching for one of these vendors, they happened upon a site called FlyCASS, through which they claim they were able to cause some mischief.

Up to no good

FlyCASS essentially offers FAR121 and FAR135 airlines a way to manage KCM and CASS requests without having to develop their own infrastructure. It pitches itself as a service requiring zero upfront cost to airlines that can be fully set up in 24 hours, with no technical staff required.

The researchers note that each airline has its own login page, which is exposed to the internet. According to the research, these login pages could be bypassed using a simple SQL injection.

“With only a login page exposed, we thought we had hit a dead end,” Carroll said in his writeup. “Just to be sure though, we tried a single quote in the username as a SQL injection test, and immediately received a MySQL error.

“This was a very bad sign, as it seemed the username was directly interpolated into the login SQL query. Sure enough, we had discovered SQL injection and were able to use sqlmap to confirm the issue. Using the username of ‘ or ‘1’=’1 and password of ‘) OR MD5(‘1’)=MD5(‘1, we were able to login to FlyCASS as an administrator of Air Transport International!”

After gaining access, the pair say they were able to create new approved pilots on the CASS program without any additional checks.

“At this point, we realized we had discovered a very serious problem,” Carroll added. “Anyone with basic knowledge of SQL injection could log in to this site and add anyone they wanted to KCM and CASS, allowing themselves to both skip security screening and then access the cockpits of commercial airliners.

“We ended up finding several more serious issues but began the disclosure process immediately after finding the first issue.”

Disclosure difficulties

Carroll says that the first port of call would ordinarily have been to alert FlyCASS, but the researchers opted against this since “it appeared to be operated only by one person and we did not want to alarm them.”

ARINC and the FAA were up next, closely followed by the Department of Homeland Security (DHS), the CISO of which responded saying it was being taken very seriously. A day later, on April 25, FlyCASS was disconnected from both the KCM and CASS programs.

When it came to disclosing the findings, it seems the US authorities didn’t want this coming out, if the researchers’ account is anything to go by. Carroll says the DHS completely ignored all attempts to disclose the findings in a coordinated way.

He also claimed the TSA “issued dangerously incorrect statements about the vulnerability, denying what we had discovered.”

According to Carroll: “The TSA press office said in a statement that this vulnerability could not be used to access a KCM checkpoint because the TSA initiates a vetting process before issuing a KCM barcode to a new member.

“However, a KCM barcode is not required to use KCM checkpoints, as the [transportation security officer (TSO)] can enter an airline employee ID manually. After we informed the TSA of this, they deleted the section of their website that mentions manually entering an employee ID, and did not respond to our correction. We have confirmed that the interface used by TSOs still allows manual input of employee IDs.”

The Register got in touch with the DHS, TSA, FAA, and FlyCASS for their side of the story and we’ll update this if we receive responses.

We also asked FlyCASS about an observation that Alesandro Ortiz made. The software engineer pointed to a Joe Sandbox report on FlyCASS which included screenshots of what appears to be a ransomware infection dated February 7 this year.

If true, details from the ransom note suggest the Medusa-derived L54 ransomware strain may have been used. Many features of the note, including the contact email format, are similar or identical to those in known L54 attacks from the past. ®

Updated at 15.20 on August 30 to add:

A TSA spokesperson sent us a statement.

“In April, TSA became aware of a report that a vulnerability in a third party’s database containing airline crewmember information was discovered and that through testing of the vulnerability, an unverified name was added to a list of crewmembers in the database. No government data or systems were compromised and there are no transportation security impacts related to the activities.

“TSA does not solely rely on this database to verify the identity of crewmembers. TSA has procedures in place to verify the identity of crewmembers and only verified crewmembers are permitted access to the secure area in airports. TSA worked with stakeholders to mitigate against any identified cyber vulnerabilities.”

READ MORE HERE