Cybersecurity Up in the Air

Joao Correia

January 25, 2023 - Technical Evangelist

On a fictional tv show that started airing last year, a spy fell out of grace by forgetting some classified intelligence papers on a public train. Said papers contained a list of spies working undercover abroad and were highly important.

In a “reality imitates tv” moment last week, an improperly secured server belonging to CommuteAir, a US airline company, left a document containing the “No Fly List” accessible to motivated hackers.

The No-Fly List

Sometimes stories are just unbelievable. The No Fly List is a list of individuals who have been banned from flying commercial flights in the US, and it has serious national security implications. I will not go into detail on the fields contained in the data, or even debate how justified or not such a list is, or even how useful it is. If such aspects of this story are of interest to you, the original write-up by theDaily Dot covers it in detail and makes for a very interesting read.

It is, at the very least, cringeworthy to acknowledge that a list with over 1.5 million entries has been left in an accessible location (and, I assume, unintentionally).

Cybersecurity, but just a smidgen

According to the original report by the Daily Dot, the airline indicated that the server where the file was exposed was “a development server, used for testing purposes” (quoting the Daily Dot story). Implicit in this comment is how much less importantly this server was considered when compared to other systems.

The company also confirmed that the data was real, albeit from a 2019 version of said No Flight List.

In accordance with existing regulations, and given the seriousness of the event and the potential security ramifications, federal-level authorities like the TSA, FBI, and CISA have been involved.

Looking at how the discovery was made, which was by a hacker, it turns out that it was identified in a Shodan search for Jenkins servers – a software package that automates build and testing processes in software development and is, unfortunately, a familiar name in common cybersecurity incident stories. For the ones less familiar with the name, Shodan is a public service that offers google-like searches for Internet-facing services. For example, one can ask it to find all email servers reachable on the Internet or find all unprotected remote desktop-running systems with a public IP address. For threat actors and script kiddies alike, learning how to use Shodan is “Hacking 101” material.

Now, some services in IT are somewhat difficult to classify properly into clearly defined “public-facing” and “private-only” access – meaning services that require access from outside the organization, being internet accessible, for example, and services that should only be reachable from inside the perimeter network and have no direct contact with the outside.

However, Jenkins is one of those that offers no argument. It is clearly and exclusively an infrastructure-only service, only useful for developers, and as such, should never have been reachable by a Shodan query. While very complete, Shodan is not magical – it can’t find a server if said server is not exposed.

But locating the Jenkins-running server was only the first step. There had to be some form of unprotected or unauthenticated share inside Jenkins where the file was located. The Jenkins project provides guidance towards protecting a deployment. It looks like some of the advice provided there was not even followed.

So what should have been done differently?

For starters, real world data should never be used, and abused, like this. You don’t really need the actual list on your testing system just to make sure your software can properly deal with it. That’s why there are practices like “data mocking“, to create “fake” real-looking data for this exact purpose.

Next, Jenkins best practices should have been followed – no unprotected access points, no shares, nothing exposed.

Then, infrastructure servers should never have had outside access in the first place. They don’t require it for their proper execution, and if actual outside connections are necessary for testing some type of external integration, that’s what ipsec tunnels are for.

But the real crux of the matter is that IT teams still have different views of “secondary” systems like these when it comes to cybersecurity. Frontline systems, core systems, and critical systems get all the attention, but infrastructure systems like the one in this story and others like print servers, internal file sharing servers and the like might get a glance every now and then, probably when someone complains about a problem.

Cybersecurity warrior

(All the servers are secured – except that one Jenkins box.

https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot)

This type of different attention gives rise to dents in the proverbial armor – and all it takes is one small breach for the whole castle to crumble.

Everything, everywhere, IT version

Secure, monitor, and patch all the servers, all the time, as if critical business data was in each and every one of them. This should be the mantra – the only mantra – for a modern security posture. Automate as much as possible, but without overlooking any systems. They are all equally important in regards to security.

A threat actor won’t really care much if he can’t breach the database server directly. As long as he can get into the virtualization host first, it’s just a quick step into the important data.

The actual path to the prize is meaningless. Only the reward matters. It’s up to the blue team to make sure all such paths are blocked and protected properly.

source for image: https://i.kym-cdn.com/entries/icons/original/000/035/146/knight.jpg

https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot

Summary