In this (pretty long) post, I’m going to attempt to coin a name for an application vulnerability, most commonly found in mobile apps. This is “App Forgery”.
I’ve decided it’d be better to explain the details of this vulnerability using a report-style write-up for an example, real, vulnerable app.
I’ve picked on the first app which came to mind vulnerable to app forgery, which is the “Trainline” app for iOS. The app allows travellers in the UK to purchase digital train tickets and, in this instance, app forgery allows Mr Bad Guy the ability to travel for free indefinitely.
Trainline app usage (skip ahead if you’ve used the app a few times):
For the unfamiliar, basic usage of the app is this: You link your bank card, tell the app where you want to go, type in the 3-digit CVC from the card and you can now download a mobile ticket (which they insist on calling an “mTicket”). An mTicket shows all of the travel information you would find on a normal ticket and is even designed to look a little like a traditional physical one. You tap “activate” on that ticket the day you want to use it and it goes from greyed-out and static to coloured-in and animated, showing that its active.
The guts of an mTicket is displayed across two views in the app, which are toggled via a “UISegmentedControl” (a button).
View one shows a QR code which contains all of the train ticket information. Scanning this QR code with a device provides the only realistic means to easily validate information contained on the mTicket, since inspectors don’t have the time or means to validate tickets manually from the visual portion of the ticket. After scanning the code, the handheld devices I have seen appear to light up either green for “valid” or presumably red for “invalid”.
View two contains a visual representation of a traditional ticket, with journey and ticket details. The current time scrolls from left to right in <marquee> fashion, against a background made from three different colours. These colours differ for each journey and there is no discernible way to determine a journey’s colours prior to activating a ticket. In theory, inspectors on any train should be aware of the “correct colours” for that journey and spot a fake ticket. The fact the current time shown on the ticket scrolls also thwarts people attempting to share tickets via screenshots/video.
Basic introduction to the app out of the way, here’s the write-up for App Forgery.
MEDIUM – “App Forgery” Possible
It is possible for an unlawful person to create a forged/counterfeit Trainline application and mTickets, allowing the forger to travel on trains for free.
It was found that mTickets created within the application are almost always incorrectly validated¹; with validation occurring based on the physical appearance of mTickets, rather than a proven tie between data on a passenger’s mTicket and server-side data.
Typical mTicket validation pre-boarding a train normally involves scanning the mTicket’s QR code at a barrier to allow passing through it. If, for any reason, the mTicket fails to validate, validation will fall back to the ticket being inspected manually by nearby staff. Alternatively, some stations without these barriers only perform manual inspection, and many smaller stations perform no ticket checks at all prior to boarding. Then, at some point during the journey, additional ticket checks are often performed by an on-board ticket inspector, using a handheld device for scanning the QR code on mTickets. This device is often unavailable to inspectors, also resulting in mTicket validation being performed manually.
Manual mTicket inspection consists of the inspector assessing, by eye, the physical appearance of the second (non QR code) view of the mTicket. This portion of the mTicket contains no piece of information from which the inspector can use to appropriately validate it, given their time and resources². This permits anyone with moderate iOS development skill the chance to create forgeries of the Trainline app/mTickets.
As a proof of concept, the Trainline’s mTicket section was forged from scratch. The process took around 5 hours, which mainly consisted of determining some of the assets in use in the real Trainline app, such as fonts, and the exact positioning of UI elements.
The QR code and background colours of the current time area will ofcourse be invalid on any forgery, although these are so infrequently checked that it really does not matter. When the QR code fails to validate at barriers or, on rare occasion, on a train… the likely outcome is that inspectors will briefly assess the right segment of the mTicket and allow the passenger to continue travelling.
For this particular app forgery, it was designed such that each of the journey detailson the mTicket behave like a text-field and are modifiable by clicking on them. This allows a forger to easily recreate the appearance of any journey details they wish and travel on that journey for free.
Some of the considerations/context which resulted in this issue being attributed with a “Medium” severity risk rating were:
- The attack does not rely on any server-side processing, and is therefore difficult to detect.
- In theory, a person could purchase a legitimate ticket, note the ticket’s QR code and colours, refund the ticket and implant these into a forged app. Recreating a more legitimate-appearing ticket.
- The level of social engineering involved is minimal, inspectors whom are able to spot errors in a forged app are unlikely to assume anything untoward and, at worst, would likely except the ticket as the result of an error within the legitimate app.
- The barrier to creating a forged app is relatively high, although one could be easily shared/distributed afterwards.
- mTickets should be validated only by way of QR code. There is no appropriate alternative within Trainline mTickets currently. This will likely involve greatly increasing the numbers of available QR code scanners to station and train ticket inspectors.
- Consider a revision/upgrade to the handheld QR code scanners. These devices do not appear to offer the inspector enough verbosity to allow them to determine if a scanned QR code is either fake, has been previously scanned, expired, or erroneous. These devices, if network connected, should be able to provide this information to help catch and deter forgeries.
1. This has been determined from the personal experience of the tester, having used the application for a number of years. This does not account for other user’s experiences.
2. A small mitigation technology to app dummying does exist by way of the coloured background where the current time is displayed. These colours change depending on journey details and should provide a means for inspectors to determine suspicious tickets. However, from experience discussing this feature with inspectors, staff are usually unaware of the correct colours for their journey.
Hopefully this explains things well enough to help you spot and report on app forgery vulnerabilities in the future.