JetBlue Vulnerability - How Not To CISO

JetBlue is the 6th largest airline in the United States, with an estimated yearly revenue over seven billion dollars and more than 20,000 employees, but they have a nonexistent security policy and a CISO who only seems to work when he really wants to (not on weekends).

On a Wednesday afternoon the team at Day After Exploit, a cybersecurity company based in England which employs unorthodox methods to poach clients, was busy manually reviewing tens of thousands of servers that have been flagged by their in-house security tools as being 'insecure' and they hit the jackpot.

They managed to find an insecure JIRA server, with a peculiar hostname.

Digging deeper into the rabbit hole, they stumbled across a few worrying finds.

C:\Users\Dylan>curl -X GET https://[redacted]

{
  "reasons": [
    {
      "code": "PERFO",
      "desc": "Public performance, clinics, workshops, athletic and other competitions and exhibitions"
    },
    {
      "code": "PRORM",
      "desc": "Professional research or professional meetings"
    },
    {
      "code": "FAMLY",
      "desc": "Family Visits"
    },
    {
      "code": "SUPRT",
      "desc": "Support for the Cuban people"
    },
    {
      "code": "EXPRT",
      "desc": "Travel related to certain authorized export transactions"
    },
    {
      "code": "INFOR",
      "desc": "Exportation, importation, or transmission of information or informational materials"
    },
    {
      "code": "PRIRM",
      "desc": "Activities of private foundations or research or educational institutes"
    },
    {
      "code": "HUMAN",
      "desc": "Humanitarian projects"
    },
    {
      "code": "RELIG",
      "desc": "Religious activities"
    },
    {
      "code": "CUNAT",
      "desc": "I am a Cuban National and Resident of Cuba"
    },
    {
      "code": "EDUCA",
      "desc": "Educational activities and people-to-people exchanges"
    },
    {
      "code": "GOVMT",
      "desc": "Official business of the U.S. Government, foreign governments and certain intergovernmental organizations"
    },
    {
      "code": "JOURN",
      "desc": "Journalistic activity"
    },
    {
      "code": "LICEN",
      "desc": "Specific License"
    }
  ],
  "sessionId": "[redacted]"
}

Without delving deeper into the companies API, it's not sure what could've been done, but we where able to notice code to list passengers, customers, flight paths, and other otherwise internal information. If we were malicious we could have dug much deeper than we did and not notify the airline, but we are white-hats.

Following several hours of exploration the team leader sent out an open Tweet to @JetBlue and attempted to open up a disclosure channel of communication with them. The official @JetBlue tweeted a response to DM, which went a lot like this.

With a little google-fu, it became clear that this was the standard approach Jet Blue has for dealing with security researchers who want to disclose vulnerabilities, we found another researcher experiencing similar frustrations in 2015.

Could this really be how JetBlue valued their security? If they ‘WANT’ information, they’ll reach out, if I was on the board, I’d be very upset knowing my company wasn't listening to security researchers attempting to disclose serious vulnerabilities, not only not listening but not even following up with them later to help remediate.

SSRF & XSS vulnerabilities
Now, to make matters worse, the team was able to identify several other faults with the site, and decided to have some fun. SSRF is short for Server-Side Request Forgery, an attack vector used to abuse the server into spitting out URL as if it came from the server, this can lead to API pulls from AWS which can spit out otherwise sensitive information. We stopped short of leveraging this further.

Then we were informed by an intermediary we had tried to use to contact Jet Blue's CISO that the JetBlue CISO was impatient to begin his weekend and wanted a write up made immediately available on the Monday, with no discussion.

Through our intermediary the CISO said that he would only be available the following Monday, the day after we chose to publish this article. This is the write up he requested that he can expect to read on Monday when he gets back into work.

We don’t want to set a precedent where companies with billion dollar turnovers can force security researchers to disclose only when their CISO is at work.

We are sick of a world where security researchers go unrewarded, where they are left in the dark about their disclosure, or being ignored simply because a CISO is only able to reply 9-5, Monday to Friday. Here is the problem with that, your adversaries don’t only work weekdays, planes sure as hell don’t only operate weekdays, an airline CISO should be alert to security threats no matter what day of the week it is.

Even though we are veteran security researchers, it is still a shock to see very large companies not prioritize their security. That same day, the team managed to disclose and resolve a security issue with another separate company in under 6 hours, from initial contact to company resolution and vulnerability remediation.

It is worth noting that this other company was a lot smaller than JetBlue, had a lot less security budget, but saw fit to properly respond to what could have been a serious security issue and remediate it immediately. That is how it is done.

I urge all readers to make sure their company has a CISO that is always on call, that their security policies are up to date and that they follow an ISO27001 framework.

Honestly there are hospitals in Rwanda with better security and documentation than a major US airline, in what world is this an acceptable situation?

Don't be like JetBlue's CISO who still does not know if their data is leaking or not.