Breaking Electronic Baggage Tags - Lufthansa vs British Airways
*by Ruben Santamarta,*
If you are reading this article, I will venture to guess that you have already had the ‘pleasure’ of queuing to check a bag at an airport. In order to improve the checking procedure, Electronic Baggage Tag (EBT) solutions are being introduced on the market that leverage the new technologies most travellers have access to nowadays.
This time I will take a look at the security posture of two of the most prominent EBT solutions: British Airways’ TAG and Lufthansa’s BAGTAG.
First of all, IATA provides an implementation guide for these devices, which I recommend you read before continuing on with this blog post, as well as the IATA resolution 753 on baggage tracking.
Certain parts of the implementation guide are worth noting:
In general terms, an EBT solution is comprised of:
* Airline mobile app
* Airline backend
* EBT device
* NFC
* BLE
* Display (e-INK)
The communication channel between airline mobile app and the EBT is established through a BLE interface.
Now let’s see how close to the expected functionality of these EBT solutions is to the IATA security requirements.
## British Airways’ TAG
British Airways’ (BA’s) TAG is provided by ViewTag. As usual, by looking at the FCCID website, we can find a teardown of the device.
The differences between the teardown version and the one being commercialized are not significant.
It is as simple as it looks. The Nordic SoC is in charge of BLE communication with the mobile app. By reverse engineering the BA app, it was possible to easily figure out how the solution is working: Basically, the BA app directly transfers the data that will be used to update the EBT display via BLE without any additional security.
A custom payload written to the ‘PASS_DATA’ characteristic is the mechanism used to transfer the boarding pass/bag tag data that eventually will be rendered on the EBT device’s e-INK display. The device does not validate either the authenticity or the integrity of the data being transferred. The following code receives the booking information collected from the BA backend and generates the payload:
The payload is a string where the following items are concatenated in a specific order.
* passengerName
* bookingReference
* priority
* sequenceNumber
* destinationFlightNum
* destinationFlightDate (ddHHmm)
* destinationAirport
* destinationName
* firstTransferFlightNum
* firstTransferFlightDate
* firstTransferAirport
* secondTransferFlightNum
* secondTransferFlightDate
* secondTransferAirport
* departureAirport
* euDeparture (enable green bars)
* fullIdentifier
That’s it, not very interesting I know…
The above diagram sums up the overall implementation:
1. The BA app downloads the passenger’s booking info and checks the ability to generate a digital bag tag (only available to Executive Club members).
1. The BA app generates the bag tag payload and transfers it through the PASS_DATA characteristic
1. The EBT processes this payload and updates the e-INK display with the received information.
As a result of this design, anyone, not only the airline, is able to forge arbitrary bag tags and update the EBT device without any further interaction with BA. Obviously you still require physical access to the EBT device to press the button that will enable the BLE functionality.
The following proof-of-concept can be used to forge arbitrary bag tags and render them on a BA TAG.
**File: poc.py**
```python
import asyncio
from bleak import BleakClient
address = "" # Set Viewtag’s MAC Address here.
PASS_DATA = "f34e4323-2147-4c84-8208-264ab774f5ca"
payload = "" # Include here the data to be rendered in the viewtag
async def run(address, loop):
async with BleakClient(address, loop=loop) as client:
x = await client.is_connected()
print("Connected: {0}".format(x))
await client.write_gatt_char(PASS_DATA, bytearray(payload,'utf-8'))
print("payload written\n")
loop = asyncio.get_event_loop()
loop.run_until_complete(run(address, loop))
```
The following is a custom bag tag generated using this PoC:
## Lufthansa’s BAGTAG
Lufthansa decided to go with DSTAGS, a company founded by an NXP employee. This company created BAGTAG. I think it is worth mentioning this detail because my analysis revealed that the team behind the device seems to have significant experience with NXP components, although from a security perspective they missed some basic things.
As with the TAG solution, we can access a device teardown on the FCCID site, which is almost identical to the units used during the analysis.
The main components are:
* Nordic NRF8001 - BLE SoC
* NXP LPC115F – MCU
* NXP 7001C – Secure Element
As the following image shows, the Serial Wire Debug (SWD) headers were easily accessible, so that was the first thing to check.
Fortunately, the BAGTAG production units are being commercialized without enforcing any type of Code Read Protection (CRP) scheme in their MCUs. As a result, it was possible to gain complete access to the firmware, as well as to flash a new one (I used a PEmicro Multilink working with the NXP’s MCUxpresso built-in gdb server).
After reverse engineering the firmware (bare metal, no symbols, no strings) and the app, it was clear that this solution was much more complex and solid than BA’s. Basically, the BAGTAG solution implements a chip-to-cloud scheme using the NDA-protected NXP 7001C Secure Element, which contains the cryptographic materials required both to uniquely identify the EBT and to decrypt the responses received from the BAGTAG backend. The MCU communicates with the Lufthansa app through the NRF8001 BLE transceiver.
I came up with the following diagram to help elaborate the main points of interest.
- 1. The Lufthansa app downloads the passenger’s booking info and checks whether the user wants to generate an EBT.
- 2. The BAGTAG’s BLE service exposes two characteristics (receiveGUID and transmitGUID) that are basically used to transfer data between the app and the device.
Actually the important data comes encrypted directly from the BAGTAG cloud. In addition to the passthrough channel, there are two publicly supported commands:
The startSessionRequest returns an internal 59-byte ‘ID’ that identifies that specific BAGTAG device. This ID is stored inside the NXP 7001 Secure Element, which communicates with the MCU via I2C using an ISO-7816-compliant protocol.
There are two commands invoked in the firmware for the selected applet:
* 0x8036: Returns the Session ID and uCode (to generate the IATA’s GUID)
* 0x8022: Decrypt data (received from the BAGTAG backend through the BLE passthrough)
- 3. The user needs to register the BAGTAG device and create an account. Then the app serializes the booking info required to generate a valid BAGTAG (pretty much the same fields that were mentioned for BA’s solution) and submits it to the BAGTAG backend to be validated. If everything is correct, the BAGTAG backend returns an encrypted blob that goes through the BLE passthrough channel directly to the BAGTAG device. - 4. The MCU receives this encrypted blob and sends it to the 7001C Secure Element to be decrypted. The decrypted data received from the 7001C via I2C is then processed, eventually updating the e-INK display with this information.
It is worth mentioning that I didn’t perform any live tests on the Internet-facing servers to avoid any unexpected behaviors in the production environments.
At the intra-board communication level, the MCU does not implement a secure channel to talk to the NXP 7001C Secure Element. As a result, a malicious component on the I2C bus could provide arbitrary content that will eventually be rendered, as the MCU has no way of validating whether it came from the actual 7001C. Obviously, malicious firmware running in the BAGTAG device may perform the same actions without requiring an external component.
Intra-board attacks (SPI, I2C, etc.) are really interesting in those scenarios where the MCU offloads a specific functionality (network, crypto, radio, etc.) to a certain SoC. If you are into this kind of attacks, stay tuned ;)
For instance, we can see how this lack of intra-board security can also lead to a memory corruption vulnerability in this firmware:
See the issue?
At line 58 ‘transfer_to_i2c’ expects to read v12+2 bytes from the I2C slave, storing them at 0x100011A4. Then at line 63, it is using a byte that may be controlled by an attacker to calculate the number of bytes that will be copied in the memcpy operation. Now, if that byte is 0x00, we will face a wild memcpy corruption scenario.
## Conclusions
Lufthansa and British Airways were notified of these issues. Both consider these issues as low-risk threats.
### British Airways
"Through our own internal investigations we have validated that there are enough checks in the background that take place to ensure an unauthorised bag would not make it through.
The potential exploitation scenarios are overall really unlikely. The overall risk to the businesses is also considered to be low severity."
### Lufthansa
"From a security standpoint appropriate screening of hold baggage remains by far the most important pillar.
In addition the baggage handling process is robust against many forms of manipulation.
The manipulation by means of EBT is therefore only a supplement to already considered cases and does not mean a significant increase of the attacksurface.
In this respect, there is only a small additional probability of occurrence.
A piece of luggage manipulated via Bluetooth would be identified and transferred to a verification process.
This ensures that no luggage manipulated in this way can get on board of one of our aircrafts.
Lufthansa thanks the researcher for his cooperation.
We will gladly follow up such indications, among other things by means of our BugBounty program."
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.