On the Struggle Bus: A Detailed SecurityAnalysis of the m-tickets App

Jorge Sanz Maroto, Haoyu Liu, and Paul Patras

School of Informatics, The University of Edinburgh, UK

Abstract. The growing shift from private to public transportation andthe increasing use of smartphones have lead to the development of digitaltransport ticketing systems. Such systems allow transport operators toenhance their services and income, therefore are important assets that re-quire secure implementation and protocols. This paper uncovers a rangeof vulnerabilities in the m-tickets app used by Lothian Buses, one ofthe leading transport operators in the United Kingdom (UK). The vul-nerabilities identified enable attackers to predict, reactivate and modifytickets, all of which can have damaging consequences to the operator’sbusiness. We further reveal poor implementation of encryption mecha-nisms, which can lead to information leakage, as well as how adversariescould harness the operator’s infrastructure to launch Denial of Serviceattacks. We propose several improvements to mitigate the weaknessesidentified, in particular an alternative digital ticketing system, whichcan serve as a blueprint for increasing the robustness of similar apps.

Keywords: Mobile app security · Reverse-engineering · Informationleakage.

1 Introduction

As of 2020, 3.5 billion smartphones have been produced [12], equivalent to 45.1%of the world population. The transportation industry is catching up with thistrend and transitioning from cash-based ticketing systems to digital tickets. Ina market that was estimated to be worth $500 billion in 2017 [13], the economicimpact of public transport ticketing apps is ever-growing. As these systems be-come more widespread, it is vital that their operation cannot be tampered withfor illicit purposes and user data remain protected.

This paper investigates the security and robustness of m-tickets, a popularlocal transport ticketing app deployed among others by Lothian Buses. LothianBuses manages the majority of public transport operations in Edinburgh, UK,and the Lothian region; it is also the biggest public municipal bus company in theUK, serving approximately 2.3 million passengers per week with a fleet of over840 buses, and has a daily revenue of approximately £440,000 [9]. We use this asa case study to reveal multiple weaknesses public transport ticketing apps sufferfrom, including the prediction of tickets and availability issues. Additionally, wepropose solutions to the problems identified, in order to improve the security ofsuch systems, whilst maintaining the intended functionality of the official apps.

2 J. Sanz Maroto et al.

Prior Work. One of the most notable vulnerabilities in the UK public transportticketing system was discovered by two Dutch security researchers in 2008 [15].By exploiting the fact that the older version of the London transport system’sOyster card used Mifare 1k chips, the researchers were able to extract an Oystercard’s encryption key and use this to clone and modify other cards as desired.This led to a swap of all Oyster cards in circulation with newly developed,encrypted cards, despite the massive cost incurred.

In terms of transport apps, get me there, which can be used for purchasingtickets valid in the Greater Manchester Metrolink tram system, was recentlycompromised, allowing hackers to create free tickets and defraud operators [14],while posting the methodology used on Reddit [11]. The group explained howthey were able to extract the private keys used to build the ticket QR codesdirectly from the source code, making the findings public without responsibledisclosure. The app was developed by Corethree, the same company that devel-oped the app in used by Lothian Buses, which we scrutinise in this study.

Contributions. To the best of our knowledge, there are no scientific papersundertaking a formal security analysis on public transportation apps. This paperaims to fill this important gap and stimulate further research on this topic. Assuch, we make the following key contributions:

1. We reverse-engineer the m-tickets app, revealing an exploit that enables topredict valid tickets for any future date; additionally, we devise a method tomodify the characteristics of any given ticket.

2. We design a simple app that works side by side with the official one, to re-activate old, expired tickets, thereby converting a single ticket purchase intoan unlimited source of tickets.

3. We propose an alternative system to fix all the vulnerabilities identified andpreserve the intended app functionality.

Responsible Disclosure. Prior to the submission of this manuscript, we con-tacted both the transport operator using this app and the company developingthe app, to disclose the vulnerabilities found. The developers are now aware ofthe problems we discovered and are working towards fixing these vulnerabilities.

2 The m-tickets App

Lothian Buses is a company primarily owned by The City of Edinburgh Coun-cil (91% ownership), which operates the majority of bus services that run inEdinburgh and some throughout the surrounding Midlothian, East Lothian andWest Lothian counties. The so called Lothian City division provides the localbus operations with an extensive network of routes that are active 24 hours/day,365 days/year. In addition, the company owns four other divisions with a focuson sightseeing, private services, and commuter routes.

Given the size of its customer base and the rapid uptake of mobile technology,the company has adopted a mobile app to offer a ticket purchasing and storageservice to users. The m-tickets app is developed by Corethree, an award winningcompany [1] specialised in solving the ticketing challenges faced by public and

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 3

(a) Main screen (b) Buying different tickets (c) Sharing a ticket

Fig. 1. Screenshots of the functionality of the m-tickets app.

private transport companies. Some of the apps in the company’s portfolio serveTransport for Greater Manchester, Transport of London, Northern Link Ferries,Translink, and many more. The m-tickets app is compiled from the same sourcecode for both Android and iOS platforms, has over 200,000 downloads, and weestimate 20%-35% of these correspond to active users [16]. Using the number ofweekly customers, we expect the Lothian Buses app accounts for 12.2%-21.3%of the tickets purchased on a daily basis, generating between £19.5 and £34.2million in revenue per year. Even though this is clearly an important asset forthe company, the app was known to have several connectivity and availabilityproblems [6], which we investigate in depth in this paper.

In this work, we focus on the Android version of the app, specifically ver-sion 9.7 released on the 17th of July 2019, which at the time of writing is thelatest version. Once the app is opened, the user is greeted with a screen dis-playing the number of tickets available or active (see Fig. 1a). The user has theoption to buy (Fig. 1b) or share (Fig. 1c) tickets displayed next to the availableones. Ticket sharing is performed by asking the user for the recipient’s emailaddress. The recipient will receive an email containing a hyperlink that, onceclicked, adds the sent tickets to their respective list of available tickets. Bothsharing and buying of tickets are not available without Internet access.

3 Adversary ModelWe expect an attacker to already have a copy of the Android app and havebasic understanding of the Android app ecosystem. Additionally, we expect theadversary to have some reverse-engineering knowledge and the appropriate toolsto intercept traffic from and to the app. Lastly, the attacker would have basicnetworking and programming knowledge, enough to identify vulnerable code.

4 J. Sanz Maroto et al.

Parts of the app that may be prone to attacks and possible scenarios include:

1. Financial Interest. The app’s main purpose is to provide tickets to users;however, this has an implied given cost. An attacker may attempt to exploitthis application to overcome the financial burden, by figuring out a way ofobtaining valid tickets without paying.

2. Denial of Service. Attackers may attempt to take control of the resourcesused by the transport operator and seek to disrupt the standard behavior ofthe app or servers. This may involve flooding target victims with unsolicitedmessages, which in the process can also harm the reputation of the operator,as the source of the hijacked resources would be attributed to them.

3. Reputation Damage. In addition, hacktivists may seek to publish on ded-icated platformed (e.g. Pastebin) information about how to obtain free tick-ets, simply due to a certain ideology.

4. Privacy Breach. Attackers may also seek to leak databases or files contain-ing information about the users of the m-tickets app. This would be donefor financial gains or, again, to harm the company’s reputation.

4 Methodology

4.1 Vulnerability Analysis

To study the app, we employ both Static Analysis, reverse-engineering andcode auditing whilst the app is not running, and Dynamic Analysis, whichcovers any activity and tests done whilst the app is running.

Static Analysis: We first reverse-engineer the Android application package(APK) of m-ticket by using dex2jar1 and jd-gui.2 dex2jar is a tool that decom-piles the .dex file inside the APK to a .jar file, which is a combination of Javaclasses aggregated as a single file; jd-gui further unpacks a .jar file into separate.class files. Some degree of obfuscation is inherently implemented during thecompilation of the APK, which means our reverse-engineered code loses all themethod and property names. However, given the fact that Java is a static strongtyped language, class names are still well preserved, which can reveal sufficientinformation for subsequent analysis.

A careful analysis reveals that no functionality is implemented in Java per se.Instead a NOTICE file indicates that the core functionality is implemented usingthe Xamarin cross-platform C# application development tool,3 which allowscreating a single application in C# that can be compiled into Android, iOS, andWindows apps. Indeed, C# code was compiled with MonoVM to shared objectsand the Java code is responsible for linking the classes in the shared objects andconstructing the overall functionality of the app.

Knowing that the overall functionality lies in the shared objects, we extractthe C# code from these objects, seeking to understand the functionality of the

1 dex2jar Github, https://github.com/pxb1988/dex2jar2 Java Decompiler, http://java-decompiler.github.io/3 Xamarin, https://dotnet.microsoft.com/apps/xamarin

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 5

app and reverse-engineer its features. Shared objects built with Xamarin act aswrappers of Dynamic-Link Libraries (DLLs), which hold the actual functional-ity of the app. We extract these DLLs using a small script [2]. Lastly, we useJetBrains dotPeek4 to decompile DLLs and retrieve the original source code.

Overall, the app consists of 88 DLLs with a total of 9,990 classes. However,the main functionality of the app is within the Core DLL, with 282 classes.

Dynamic Analysis: We split the dynamic analysis into two different phases:one concerning the communications between the app and the server, and thesecond focusing on analysing the internals of the app and what is stored in thephone once the app is installed.

Phone internals: Android is a mobile operating system based on the Linuxkernel. The default installation restricts the access to multiple files, in orderto prevent novice users from deleting/modifying critical functionality. However,this also means that the default version of Android does not allow a user toview the files any app uses/creates. Therefore, in order to further analyse thebehaviour of the app, we use a rooted Android phone. Rooting is the process ofallowing Android smartphone users to attain privileged control of the operatingsystem; this can be done by asking the manufacturer of the phone to providea code to de-activate the smartphone’s protections. With a rooted phone, wecan see what files our target m-tickets app would use upon execution. All theapp-related information is stored in the /data/data folder as shown below:

net.corethree.lothianbuses

cache

code cache

com.android.opengl.shaders cache

databases

com.microsoft.appcenter.persistence

corethree

google app measurement.db

files

.config

activated tickets.xml

alert notifications.xml

data.json

ticket last opened

ticket open dts

.local

share

appcenter

database large payloads

shared prefs

AppCenter.xml

net.corethree.lothianbuses preferences.xml

4 dotPeek – Free .NET Decompiler and Assembly Browser, https://www.jetbrains.com/decompiler/

6 J. Sanz Maroto et al.

We are now able to read and analyse all information the app saves and howinformation storage is handled. Nevertheless, to be able to modify this informa-tion, we first need to disable Security-Enhanced Linux, a kernel security modulethat provides a mechanism for supporting access-control security policies. In thiscase, it would not allow the execution of any program, if there was any tamper-ing of the files by an external process. This avoids malicious apps from stealingdata from other apps. In order to disable SE-Linux, it is sufficient to obtain aroot shell via the Android Debug Bridge (adb), and type setenforce 0.

Additionally, there are occasions where the behaviour of the app may beunexpected, therefore we also use Frida5 to trace events. Frida is a dynamiccode instrumentation toolkit that allows the injection of snippets of JavaScriptor own library into native Android apps. We use this tool to trace the files beingopened at certain points or which functions were triggered at certain times.

Communications: Modern day apps consist of two main parts: the app itselfand the server with which it communicates. On the app side, we perform staticanalysis and examine the phone internals. However, the extraction of informationfrom the server is not straightforward and we can only attempt ”black box”penetration testing. This consists of performing a vulnerability analysis withoutaccess to any of the server’s source code. As such, we can observe what messagesgo to and come from the server, but not the server’s inner logic, which makes ithard to identify flaws.

For this part, we built a man-in-the-middle (MITM) setup, using an AlfaAtheros AR9271 Wi-Fi adaptor to set up a controlled hot spot on a laptop, towhich the phone connects. We then route the traffic from the adaptor to Burp,6

an integrated platform for performing security testing of web applications. Ad-ditionally, we install Burp certificates on the phone, so that the phone wouldtrust the communications. Finally, the laptop connects to the Internet using itsintegrated Wi-Fi adopter, thereby allowing to intercept and modify whateverthe app running on the phone sends and receives from the server.

We notice the phone compresses requests prior to transmission, hence weload a dedicated module into Burp to decompress requests for inspection.

4.2 Connectivity and Availability Analysis

A key concern for Lothian Buses app users is the app’s availability. It has beenreported that in some cases the app would stop working and require Internetconnection in order to start, or would take too long to launch even when a con-nection is available [7]. Therefore, we analyse the minimum Internet connectionspeed required and the amount of bandwidth consumed when the app launches.

To this end, we use BradyBound,7 an app that throttles the phone’s Inter-net connection speed down to a user-defined value. Furthermore, we track theamount of data consumed by simply accessing Settings>Apps>m-tickets>Data usagebefore and after starting the application, and calculating the difference. We exe-cute all tests with a Motorola Moto G (3rd Generation) running Android v6.0.1.5 Fida analyzer, https://frida.re/docs/android/6 Burp analyzer, https://portswigger.net/burp7 BradyBound, https://m.apkpure.com/bradybound/com.oxplot.bradybound

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 7

5 Security Analysis

In this section we describe in detail the vulnerabilities found using the method-ology described previously. Most weaknesses are exploited when the phone isoff-line, taking advantage of the fact that the app can work without Internet ac-cess. We reveal how to predict, duplicate, and modify tickets as explained next.We also describe several functionality problems encountered in the app.

5.1 Generation of Tickets

One of the main goals of our study is to assess how securely ticket generation ishandled and how difficult it would be for an attacker to craft valid tickets whileevading payment. In order to accomplish this, we first need to understand howthe app generates a legitimate ticket.

(a) Ticket time view. (b) Ticket token view.

Fig. 2. Screenshots of an active ticket, alternating between a view of the current time(left) and the daily token (right).

Once a ticket is purchased, the user has the option to activate it wheneverthey board the bus. An activated ticket has a certain expiration time, whichdepends on ticket type (e.g. single ticket, day ticket, etc.), which bus drivers cancheck when presented with a view of the running app, as exemplified in Fig. 2.The ticket comprises several distinctive elements:

– Top Title – Describes the ticket type at the top of the ticket.– Watermark – Visible in the central part of the ticket, comprising the m-

tickets logo and a dynamic text block showing the current time and a numerictoken on a changing background, in an alternating fashion. The numerictoken is the same for all tickets activated during the same day, i.e. it is notunique to a ticket.

8 J. Sanz Maroto et al.

– Remaining time – Small countdown in the centre showing the remainingtime until the ticket becomes invalid.

– Lower body – Shows information including ticket type, ticket provider, dateof purchase, and passenger’s name.

One implementation decisions made by the app developer is the activationand generation of tickets without Internet connectivity. The downside to thisis that the app itself is in charge of generating the ticket, and not the server.This means an attacker with access to the source code could attempt to un-derstand and replicate the process of generating tickets. Clearly, the numerictoken is what bus drivers check in order to decide whether a ticket is valid.Hence, understanding how valid numeric tokens are obtained can compromisethe underlying mechanism.

Analysing the source-code, one particular function stands out, namely Gener-

ateWatermark(), located inside the Core.Utilities module. This function willbe called whenever a ticket is activated, performing the following computation:

token =

⌊(x− c)2

seed× 104 mod 104

⌋, (1)

where b·c : R → Z denotes the floor function, c is a date constant with value01/01/1990 and x represent the current date. The app uses this formula tocreate the numeric tokens, which are displayed to drivers for validation whenthe passenger is boarding the bus.

To accurately predict a token, it is necessary to understand how the seed vari-able is obtained. By performing a text pattern search through all of the app’sfiles, we identify a particularly interesting string, namely ‘‘Ticket.Seed’’:

‘‘71473’’, located in files/.config/data.json. Creating numeric tokens withthe logic shown above and this seed value across different days, and comparingagainst tokens for the same days embedded in legitimate tickets, the values matchperfectly. This means that the alleged seed is nothing but a hidden hard-codedvalue, rather than an actual seed of a pseudo-random sequence.

Besides, although the existence of the modulo and the floor operations inEq. 1 makes this computation irreversible, we show in Fig. 3 that this functionexhibits obvious periodic patterns, meaning that it does not qualify as a one-wayfunction. As shown in Fig. 3, the mapping between current date x and the tokenvalue presents a period-like relation, and the period gradually becomes longer asmore time elapses from the fixed referenced date c. Thus an attacker can simplymodify the system date and collect some data to recover the underlying functionthrough trial and error.

Finding: An attacker can retrieve the procedure and relevant variables(which are unfortunately hard-coded) from the app source code, easily gener-ate a valid numeric token for the current day, and embed that into a GraphicsInterchange Format (GIF) image that resembles a genuine ticket, thereby evad-ing payment. We also conclude that reverse-engineering of the application isnot necessarily needed to predict the token of any future date, since the tokengeneration algorithm reveals naive periodic patterns.

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 9

Fig. 3. Graphical illustration of token values, as the time since 01/01/1990 grows.

5.2 Re-activation of Expired Tickets

If one can already predict tickets, what would be the purpose of reactivatingexpired tickets? Predicting a ticket is one thing, but generating animated imageson a phone is not straightforward. An attacker may need to replicate the layoutof the official app to perfection and build a new app from scratch in order toexploit the vulnerability discussed in the previous subsection.

Therefore, we investigate whether it may be possible to reactivate an expiredticket, by analysing how the app saves the state of tickets. To this end, weexamine the changes made on the app whenever a ticket is activated, first savingall the files in the home directory of the app prior to the activation of a ticket,then comparing them against those changed after the ticket expired.

1 try {2 Runtime.getRuntime ().exec("su -c rm -rf /data/data/net.corethree.

lothianbuses ");3 Runtime.getRuntime ().exec("su -c rm /sdcard /. storage/atl.txt");4 Runtime.getRuntime ().exec("su -c cp -rp /data/data/tickets /data/data

/net.corethree.lothianbuses ");5 Toast errorToast = Toast.makeText(MainActivity.this , "Tickets

restored!", Toast.LENGTH_SHORT);6 errorToast.show();7 } catch (IOException e) {8 Toast errorToast = Toast.makeText(MainActivity.this , "Was not

successfull !", Toast.LENGTH_SHORT);9 errorToast.show();

10 }

Fig. 4. Source code of demo app exploiting ticket re-activation vulnerability uncovered.

Most files seem to be modified, however the app would not make any re-quests over the Internet connection. All of the modified files are inside thenet.corethree.lothianbuses folder, except for a small /.storage/atl.txtfile created after the activation of the first ticket. After analysing the decompiledapp code, it is clear that this file is just a back up of activated tickets.xml,a file used to store the serialised activated tickets. This means that the contentof net.corethree.lothianbuses is the representation of the state of the app.Hence, we can save its contents, activate as many tickets as previously purchased,

10 J. Sanz Maroto et al.

1 DateTime universalTime = app.CheckInLastSuccessfulTimestamp.ToUTCDateTime().ToUniversalTime ();

2 if (universalTime < DateTime.UtcNow.AddDays(-5.0))3 app.CheckIn_BlockSession = true;4 else if (universalTime < DateTime.UtcNow.AddDays(-3.0))5 app.CheckIn_ShowWarning = true;

Fig. 5. Code snippet mitigating the reactivation of expired tickets.

and then swap the saved folder with the one used by the app, thereby restoringall the tickets as if the app was never opened in the first place. To facilitate re-peated testing of this vulnerability and demonstrate the simplicity of the attack,we build a small app, which exploits this process, as detailed in Fig. 4.

In the above, we save the state of net.corethree.lothianbuses into a foldercalled tickets, and then use the app to substitute the files in the official appwith those saved in this folder. However, it appears that after one week of testing,the vulnerability can no longer be exploited. Since our exploit would return tothe state of the app after purchasing the tickets, from the apps point of view wehad not been connected to the Internet for more than 5 days, which is one of thesecurity measures that Corethree seem to have implemented. However, by thevery fact that this is a response to a certain event, we expect to find the relevantimplementation in the app’s source code. Indeed, the code checks if the valueCheckInLastSuccessfulTimestamp minus 5 days is less than 0, as shown inFig. 5, where CheckInLastSuccessfulTimestamp was extracted from the times-tamp saved as CILST in the net.corethree.lothianbuses preferences.xml

file, as shown in Fig. 6 (see line 4).

1 <?xml version ='1.0' encoding='utf-8 ' standalone='yes ' ?>2 <map >3 ...

4 <string name="CILST">2020-03-02 14:47:50Z</string>

5 <string name=" ShowVouchersDownloadedNotifications">True </string >6 <string name="NSSC">b0cc9f95ba012d9c3cca728af8379307 </string >7 ...8 </map >

Fig. 6. Excerpt from XML file containing m-tickets app preferences.

However, the app does not check whether CILST is larger than the currenttime, meaning that an attacker can set the CILST to year 2030, and the exploitwould work for the next 10 years.

Finding: By restoring the application state prior to ticket activation andmodifying the XML file containing the app preferences, an attacker can reacti-vate expired tickets, which stay valid for any specified duration.

5.3 Modification of Tickets

Being able to re-activate tickets, next we explore the different type of tickets theapp offers and whether these could be modified by an adversary. Excluding thefact that the app offers different tickets for different routes, there are 2 main

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 11

1 ...2 "Name":"Adult SINGLEticket",3 "Subtitle":"Purchased Wednesday, 19 February 2020",4 "SortOrder":"0",5 "TTL":"3600",6 "Language":"",7 "TimeStamp":"2020 -02-19T19:41:49 .436Z",8 "CommonChildType":"Node",9 "AncestorIDArray":[" pXTloFK","tgadTUCW_paymentsuccess "],

10 "ComparisonHash":"3 f484560fc614c438f194b5f419b88be",11 "Lifetime":5,12 "Interval":0,13 "Tags":{" Voucher.TypeID":"792 c-56f8-403d-aed1-8e11af0",14 ...15 }

Fig. 7. JSON fragment of an Adult Single ticket.

type of tickets: Single-Adult and All-day tickets. We purchase both types andactivate them on the same day, to understand the technical difference betweenthem. Perhaps unsurprisingly, the two are virtually the same, except that a userhas 5 mins to use a Single-Adult, whilst the All-day ticket can be used for 24 hrs.

Knowing this, we analyse how the app identifies and stores different typeof tickets, and find that the majority of ticket data is stored in the data.json

file. The file is relatively large, containing information such as the app’s layout,user tokens, URLs from where to download images and, most importantly, thecharacteristics of purchased tickets, as exemplified in Fig. 7.

Examining Fig. 7, note that tickets are defined by a JSON structure, whichencompasses their characteristics. Therefore, our first attempt is to change thevalues of a Single-Adult ticket to those of an All-day ticket. However, aftermodifying data.json, the app would not open without an Internet connection,suggesting a security provision was implemented to prevent this exploit. Wethen use the Frida framework to trace precisely what happens internally whenthe app blocks the modified data.json. The trace reveals that both data.json

and lothianbuses preferences.xml are opened at program execution start.Reviewing the code again and identifying where these files are being used, it ap-pears data.json is hashed with ContentRoot and the devices GUID, which aregiven in the lothianbuses preferences.xml file. The hash is then comparedwith the value stored into NSSC (line 6 in Fig. 6). This procedure is illustratedin Fig. 8. Therefore, an attacker aiming to modify anything in the app, shouldchange the hash stored in NSSC for a new one that passes the checks.

1 function onStart(context){2 content_root = extract_from_preferences (" ContentRoot ");3 nssc = extract_from_preferences ("NSSC");4 data_json_str = read_file ("data.json");5 md5 = MD5(data_json_str + "|" + content_root + "|" + context.guid);6 if (md5 == nssc){ parse_tickets (); }7 else{ delete_history (); }8 }

Fig. 8. Pseudocode of procedure implemented by the m-tickets app to avoid modifi-cation of ticket characteristics. By reversing the hashing applied and retrieving keyvariables stored by the app, this can be circumvented.

12 J. Sanz Maroto et al.

1 salt = "3497788798 ffff545zhif8 ";2 shared_secret = "b70f578f -974d-4efd -a93a -43 c8b4f6cd9d ";3 function encrypt(plaintext){4 prs = HMACSHA1(shared_secret , salt); # pseudo -random string5 key = prs[: key_size / 8];6 IV = prs[: block_size / 8];7 cipher = AES(IV, key , plaintext);8 ciphertext = base64_encode(cipher);9 return ciphertext;

10 }

Fig. 9. Encryption logic implemented by the m-tickets app.

Since the hash is crafted based on values that we already have, we can writea small C# script to replicate the creation of the hash and use it to modifythe app. We are now able to change any of the characteristics of a ticket. Forexample, we could make a single Adult ticket last for months, if we changed theticket’s “Lifetime” property.

Finding: By replicating the hashing mechanism applied to the tickets datastore and overwriting key variables in the m-tickets preferences file, an attackercan extend the lifetime of tickets at will.

5.4 Hard-coded Keys and Tokens

After decompiling the app, we notice that some of the information being stored isencrypted, since the developers included custom cryptography classes in additionto imported C# crypto libraries. Although our proposed attacks do not exploitany encrypted information, it is still worth analysing the encryption algorithms,so as to understand if any potential weakness may exist once new functionalitiesor features are integrated into m-ticket.

The app adopts the Advanced Encryption Standard with Cipher Block Chain-ing (AES-CBC), a block cipher encryption scheme commonly used to providestrong confidential guarantees [4]. This algorithm uses three key instruments toensure secrecy: a salt, an Initialisation Vector (IV), and a key. The salt is usedto avoid brute-force attacks against the resulting cipher-text, the IV ensuressemantic security, and the key is used to encrypt the actual plain-text. Thisalgorithm by design is robust against both passive and active adversaries, butunfortunately, our analysis reveals that it is not utilised correctly, resulting inpossible information leakage.

As shown in Fig. 9, both the key and IV are derived from a salt and a sharedsecret, which turn out to be hard-coded right above the encryption function(lines 1–2). That is to say, as long as an attacker obtains these strings, anyencrypted information can be easily deciphered on Android phones. Whilst it isobvious that the seeds and secrets have to be stored locally for the program towork in an offline environment, the developers should have been mindful of howeasy it is to decompile apps.

Finding: Although state-of-the-art encryption is adopted, key elements aimedat ensuring secrecy are hard-coded in the m-tickets app. Hence cipher-text isstraightforward to reverse.

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 13

5.5 Root Checker Bypass and Enabling Screenshots

A key step in exploiting the re-activation and modification of tickets is the abilityto have full control of the phone (root access), while maintaining full use of theapp. For this reason, checking whether the app has a root checker was one of ourfirst priorities after decompiling. Corethree implement a root checker functionthat looks for certain files or binaries, denying access to the app if found, asrevealed in Fig. 10. Unfortunately, having a rooted phone, the system is not tobe trusted. In this case the app asks the system to look for certain files, butsince an attacker controls the system, they can manipulate the response statingthat the relevant files do not exist. To showcase this, we use Magisk hide, amodule of the Magisk manager,8 which hides the root files from whatever appit is instructed to.

1 public bool isDeviceRooted(Context context)2 {3 return tags.Contains (" test-keys ") ||4 File.Exists ("/ system/app/Superuser.apk") ||5 executeCommand(check_su_binary) != null ||6 isPackageInstalled ("eu.chainfire.supersu ") ||7 findBinary ("su");8 }

Fig. 10. m-tickets root checker function.

Another feature Corethree implemented in the app is the inability to takescreenshots whilst the app is in use, so as to prevent users from sharing screen-shots of purchased tickets. However, if an attacker has root access to their phone,they can disable the permission granted to apps to block screenshots. In our casewe used the smali patcher module from the Magisk rooter.

Finding: The app root checker can be bypassed, thereby enabling reverse-engineering and modifying of the original app functionality.

5.6 Password Reset Issues

The majority of vulnerabilities found up to now were in the app source code.However, one part of the ticketing ecosystem we do not have access to is thesource code of the server logic. Hence, we carry out a “black box” analysis,by which we intercept the network traffic towards/from the server and seek tomake sense of the back-end. In particular, we uncover two main problems withthe password reset procedure.

To understand the vulnerabilities, let us first examine the standard behaviorof a password reset. After requesting a password rest, the user would receive aURL of the form https://passwordreset.corethree.net/<11upper-lower-

casecharacters>. This link would expire within 75 min after the reset request.However, it appears the user could request a password reset as may times asdesired and the server would send a new link to reset the password, without

8 Magisk, https://magiskmanager.com/

14 J. Sanz Maroto et al.

invalidating the old one. This means that an attacker could request many re-sets and increase the probability of guessing the victim’s password reset link.Arguably, the probability of brute-forcing a valid URL online is relatively small.For instance, assuming a brute-force rate of 105 attempts/sec and a reset pass-word rate of 105 requests/sec, the probability of guessing a valid URL is

pguess =(105 × (60× 75))2

5211= 2.69× 10−4.

However, any further increase in compute power could lower the work factor.Aside from this threat, the fact that the server allows a user to request as

many password resets as desired, creates an opportunity for malicious actorswho may exploit this weakness to launch Denial of Service (DoS)/Email floodattacks towards other companies or individuals, using the Lothian Buses serverresources, further damaging the transport operator’s reputation in the process.

Finding: Poorly implemented password reset mechanisms lowers the barrierto brute-forcing user credentials and launching DoS/Email flood attacks usingthe transport operator’s computing infrastructure.

5.7 Availability

The main purpose of an e-ticket app for public transport is to enable users topurchase tickets and use them at any point in time. The service must be thusavailable at all times. Following recent reports about app availability issues [5],we decide to run a network test and analyse the Internet connection needed torun the app and amount of data exchanged over this. Unsurprisingly, during 10tests whereby we open and close the app, the average amount of data consumedis 45kB and the time required to load the app did not vary with download speedsof 19kB/s and above. However, examining the source code again, we notice thatwhenever the app is opened and any error occurs for whatever simple reason, theapp closes and all information is erased, as when a tamper attempt is detected. Asa result, the app has to re-download all data and validate it before displaying itto the user when re-opened. This leads to a 400kB increase in data consumptionand approximately 12s boot-up time with an un-throttled connection.

To avoid this nuisance, modern programming languages force the user toimplement try-catch statements, which permit a program to continue executingeven if a small part of it encounters an exception. However, the m-tickets app ispeppered with try instructions that are not followed by an appropriate catch

logic. This leads to frequent occasions where the program crashes or gets stuck.Findings: A combination of aggressive error handling practice and inappro-

priate use of try-catch statements leads to a history of poor app availability.Occasional users will always be forced to have an Internet connection.

6 Recommendations

Given the security vulnerabilities identified in the m-tickets app, we proposea set of solutions that can be deployed to address the exposed problems. Wealso explain why some of the implementation decisions made by Corethree areinsecure, and suggest simple alternatives.

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 15

6.1 Tickets

Clearly, the whole purpose of the app is the secure purchase and use of tickets. Se-curity is largely an abstract concept that is not straightforward to measure [17].However, in essence it should reflect how hard it is for an attacker to read ormodify information they are not authorised to. Taking a look at the currentdesign of an e-ticket in the m-tickets/Lothian Buses app and the weaknesses de-scribed in Sec. 5–5.3, to begin with, the validation of a ticket should not rely onthe bus driver. This is because the process is prone to error, as the driver may failto recognise the difference between a valid and a crafted ticket. Indeed, previousstudies show that humans are the weakest link in information security [3].

Secondly, users can be selfish and app decompiling is increasingly accessible.Therefore, the process of ticket generation should not be client-side, to avoidusers tampering with it in order to circumvent payment. Instead, this processshould be entirely server-based, whereby the user receives a valid ticket uponpurchase, but remains unaware of how it was created.

Thirdly, there is currently no way of knowing whether active e-tickets arebeing re-used. The task of deleting a used ticket is handled by the app, yet asshown in Sec. 5.2, a user can control the app’s behaviour on their phone. Thesame applies to the illicit modification of the characteristics of tickets (Sec. 5.3).Once again, to circumvent these problems, the user should be provided with aticket generated on the server side and which cannot be modified by the app.

Fig. 11. Blueprint of proposed secure alternative ticketing system.

Alternative ticketing system: Strengthening the ticketing system mayrequire a complete redesign. In what follows, we propose a simple alternative,which although arguably not flawless, mitigates the vulnerabilities identified.The proposed system consists of (1) a QR code validation protocol that sub-stitutes driver-based visual validation; (2) an additional private app that busdrivers would use to validate tickets; and (3) an RSA signature algorithm tosafely maintain the tickets.

16 J. Sanz Maroto et al.

We illustrate the envisioned alternative ticketing system in Fig. 11 and sum-marise its operation below.

Step 1: User sends a payment for some amount of tickets of certain type, whichthey want to purchase.

Step 2: Server crafts each ticket in JSON format, which contains all the infor-mation needed to identify the ticket, including a Unique id to avoidticket reuse; Ticket type to specify if the ticket is Adult Single, All day,etc.; an Expiry date to verify that the ticket is still valid. Once theJSON is crafted, the server would use a private key kprv to sign theJSON and send the result to the app.

Step 3: When the user wants to activate a ticket, the app builds a QR repre-sentation of the encrypted ticket and displays it on the phone’s screen.

Step 4: The bus driver uses their app to scan the QR code. The app containsa public key kpub, which is used to verify that the ticket has not beentampered with. It also checks that the unique ID was not used in thepast. If the ticket appears valid, the app indicates approval and storesthe ticket’s unique ID.

Step 5: Periodically, the bus driver’s app connects to the server and sends theunique IDs that were scanned. At the same time, it is updated with in-formation of other valid/invalid unique IDs that have changed recently.

The downside to this system is that every bus driver must have a smartphone,which increases CAPEX. The advantages might out-weight the cost, since (1) theuser only holds signed tickets and cannot craft tickets while subverting payment;(2) the public key could be made available to anyone, since it only serves inverifying if a ticket was tampered with; (3) the ticket duplication weakness isremoved, since an attacker would have almost no time to use a copy of a ticketdue to the unique IDs; and (4) modification of tickets becomes infeasible, sincedigital signatures are proven to be secure [8].

6.2 Hard-coding and Availability

Having a flawless program is almost impossible. However, historically communi-ties have come together to create standards, so that users/developers have themeans of checking the correctness of their programs. A widely-known securitystandard is the OWASP Secure Coding Practices [10], which lays out practicesdevelopers should follow to make a program secure. Hard-coding and Availabil-ity issues we found in the m-tickets app are covered in these standards. Hencewe recommend following these checklists when developing future versions of theapp, to avoid the same or other pitfalls.

6.3 Password Reset

Not limiting the number of password resets a person can request has implicationon (1) user account security (as it simplifies brute-forcing); (2) can facilitate DoSattacks towards third parties; and (3) can damage the reputation of the appprovider. To avoid these, developers could enforce, e.g. a 10-second restriction

On the Struggle Bus: A Detailed Security Analysis of the m-tickets App 17

between each password reset. This would be unnoticeable to the user, since itis roughly the time it takes to check email, while adversarial actors would beunable to perform any of the attacks discussed in Sec. 5.6. Additionally, it isgood practice to disable the last password reset link after issuing a new one forthe same account.

7 Conclusions

In this paper analyse the security and robustness of the m-tickets system usedby Lothian Buses, a leading UK transport operator. We identify a range ofvulnerabilities pertaining to ticket generation and life-cycle, app functionality,and back-end logic. To mitigate these, we provide design recommendations whichCorethree, the developer, should implement, especially given that parts of olderhighly-vulnerable versions of the ticketing app remain in use and suggest otheriterations of the system might be at risk. This includes those sold to othertransport companies in the UK. Lastly, we present the blueprint of an alternativeticketing system, which should help in the development of future secure appssupporting public transport worldwide.

References

1. Corethree website. https://www.corethree.net/2. Unpacking Xamarin mono DLL from libmonodroid bundle.app.so. https://

reverseengineering.stackexchange.com/a/173303. Accenture: Why humans are still security’s weakest link (May 2019)4. Doomun, R., et al.: AES-CBC Software Execution Optimization (Aug 2012)5. Edinburgh News: Edinburgh commuters face more ticket app failures (Sept 2018)6. Edinburgh Trams: TfE mtickets. https://edinburghtrams.com/news/tfe-

mtickets (Aug 2018)7. Google Play Store: Lothian buses m-tickets8. Lindenberg, C., Wirt, K., Buchmann, J.: Formal Proof for the Correctness of RSA-

PSS. IACR Cryptology ePrint Archive (Jan 2006)9. Lothian Buses Limited: Consolidated Financial Statements 2018. First edn. (2019)

10. OWASP: Secure coding practices. https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf

11. Reddit: Activists release code to generate free public transportation tick-ets. https://www.reddit.com/r/manchester/comments/cyefu5/activists_

release_code_to_generate_free_public/ (2019)12. Statista: Number of smartphone users worldwide from 2016 to 2021. https://www.

statista.com/statistics/330695/number-of-smartphone-users-worldwide/13. The Business Research Company: Transit and Ground Passenger Transportation

(Public Transport) Global Market Briefing 2018. First edn. (2018)14. The Telegraph: Public transport apps hacked to create free tickets and defraud

operators (Sept 2019)15. Wired: Hackers Crack London Tube’s Ticketing System. https://www.wired.com/

2008/06/hackers-crack-l/ (Jun 2008)16. Xu, Q., Erman, J., Gerber, A., Mao, Z., Pang, J., Venkataraman, S.: Identifying

diverse usage behaviors of smartphone apps. In: ACM SIGCOMM IMC (2011)17. Zalewski, J., et al.: Can we measure security and how? In: Proc. Annual Workshop

on Cyber Security and Information Intelligence Research (2011)