Security Test of iZettle's Reader 2: A card terminal for safe payments?

(1)

IN

DEGREE PROJECT COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS

STOCKHOLM SWEDEN 2020,

Security Test of iZettle's Reader 2

A card terminal for safe payments?

DARIA GALAL

MARTIN TILLBERG

(2)

(3)

Security Test of iZettle’s Reader 2

A card terminal for safe payments?

DARIA GALAL

MARTIN TILLBERG

Bachelor’s Degree Program in Computer Engineering Supervisor: Pontus Johnson

Examiner: Robert Lagerström

School of Electrical Engineering and Computer Science (EECS) Swedish title: Säkerhetstest av iZettle’s Reader 2

Swedish subtitle: En kortterminal för säkra betalningar?

(4)

(5)

Abstract

Ethical hacking and penetration testing are two methods often used when organizations and companies want to measure their level of information security, and find out if there are additional steps that can be taken in order to increase the security. This report describes a security test of the card terminal iZettle Reader 2, with the intention to examine its level of security based on the device’s frequent appearance in the society. The implementation is divided intro three phases: prestudy and threat modelling, penetration testing and evaluation and conclusion of the security. The threat model was created using the two established models STRIDE & DREAD, which purpose is to identify the device’s various threats and attack vectors. From the threat model, a couple of attack vectors were selected to be penetration tested. By using conventional models and obtaining knowledge of common attacks such as Man-in-the-middle, Spoofing and Replay, the device and the payment solution could be tested with a systematical and reliable approach. A selection was made of the most prominent attack vectors, of which these were later tested; Man-in-the-middle of Bluetooth and HTTPS, and Reverse Engineering of the associated mobile application "iZettle Go". The result of the penetration tests indicated that the security around the device and surrounding systems is strong, but that it can be further supplemented with a couple of actions like certificate pinningand mutual authentication when communicating with TLS, as well as a more tamperproof software regarding the mobile application.

Keywords

izettle reader, ethical hacking, threat modelling, penetration testing, bluetooth, https.

(6)

(7)

Sammanfattning

Etisk hackning och penetrationstestning är två metoder som ofta tillämpas i sammanhang när organisationer och företag vill mäta sin nivå av informationssäkerhet, samt även ta reda på om eventuella åtgärder kan tas för att stärka säkerheten. Denna rapport beskriver ett säkerhetstest av kortterminalen iZettle Reader 2, med syftet att undersöka dess nivå av säkerhet grundat på enhetens frekventa uppträdande i samhället. Genomförandet är uppdelat i tre faser: förstudie och hotmodellering, penetrationstestning samt utvärdering och avgörande av säkerheten. Hotmodellen skapades med hjälp av de två vedertagna modellerna STRIDE & DREAD, vars syfte är att identifiera enhetens olika hot och attackvektorer.

Utifrån hotmodellen valdes några attackvektorer som sedan penetrationstestades. Genom att använda etablerade modeller samt erhålla kännedom om konventionella attacker såsom Man-in-the-middle, Spoofing och Replay, kunde man testa enheten och betallösningen med ett systematiskt och pålitligt tillvägagångssätt. Ett urval gjordes av de mest lovande attackvektorerna, varav dessa senare testades; Man-in-the-middle av Bluetooth och Wi-Fi samt Reverse Engineering av den tillhörande mobilapplikationen "iZettle Go". Resultatet av testerna påvisade en stark säkerhet gällande enheten och dess omgivande system, men att säkerheten kan kompletteras ytterligare med ett par olika åtgärder som certificate pinning och mutual authentication vid kommunikation med TLS, samt manipuleringssäker mjukvara med avseende på mobilapplikationen.

Nyckelord

izettle reader, etisk hackning, hotmodellering, penetrationstestning, bluetooth, https.

(8)

(9)

Preface

This thesis report refers to the Bachelor’s degree project with the title "Security Test of iZettle’s Reader 2 - A card terminal for safe payments?", carried out by the students Daria Galal and Martin Tillberg at the Division of Network and Systems Engineering (NSE), in Spring 2020. The degree project lies within the scope of the course II142X Degree Project in Computer Engineering, First Cycle(15.0 credits) held at the School of Electrical Engineering and Computer Science (EECS), in which the students shall "apply and deepen knowledge, understanding, abilities, and approaches within the contexts of the education"

[1] . The purpose of the degree project is to let the students "demonstrate the knowledge and skills required to work autonomously as a graduate engineer according to the national goals" for engineers in the Higher Education Ordinance[2], thus the degree project "should be carried out at the end of the education and imply a specialised study and synthesis of earlier acquired knowledge"[1].

During the first week of the thesis work, all KTH campuses closed down and student access to university facilities was denied due to the outbreak of the corona virus Covid-19 in Sweden. In the form of report writing, this did not impede us in any sense since the report is written in L^ATEX using Overleaf, which facilitated us greatly. Nevertheless, the situation might have had an impact on activities concerning hacking and penetration testing, due to the fact that we only had one copy of the iZettle Reader 2 and the two students working remotely.

Acknowledgements

We would like to thank professor Pontus Johnson and associate professor Robert Lagerström at NSE for their support and participation as supervisor and examiner respectively, for this bachelor thesis project.

We would also like to thank PhD student Fredrik Heiding, who could quickly help provide us with the iZettle demo account and managed the coordination of hacking tools and other equipment.

(10)

(11)

CONTENTS

Acronyms

AC Advertising Channel.

AC-PDU Advertising Channel Protocol Data Unit.

API Application Programming Interface.

BLE Bluetooth Low Energy.

CRC Cyclic Redundancy Check.

DC Data Channel.

DC-PDU Data Channel Protocol Data Unit.

DOS Denial of Service.

FHS Frequency Hopping Synchronization.

GAP Generic Access Profile.

GATT Generic Attribute Profile.

HSM Hardware Security Modules.

HTTP Hypertext Transfer Protocol.

HTTPS Hypertext Transfer Protocol Secure.

IEEE Institute of Electrical and Electronics Engineers.

IETF Internet Engineering Task Force.

IoT Internet of Things.

LAP Lower Address Part.

LLID Link Layer ID.

MIC Message Integrity Check.

MITM Man-in-the-Middle.

(14)

Acronyms

mPOS mobile Point of Sale.

mTLS Mutual TLS.

NAP Non-significant Address Part.

NESN Next Expected Sequence Number.

NFC Near Field Communication.

OUI Organizationally Unique Identifier.

OWASP Open Web Application Security Project.

PCI DSS Payment Card Industry Data Security Standard.

PCI SSC Payment Card Industry Security Standards Council.

PDU Protocol Data Unit.

PTS PIN Transaction Security.

RSSI Received Signal Strength Indication.

SAP Significant Address Part.

SIG Special Interest Group.

SSL Secure Socket Layer.

TLS Transport Layer Security.

UAP Upper Address Part.

UART Universal Asynchronous Receiver Transmitter.

WLAN Wireless Local Area Network.

14

(15)

1 INTRODUCTION

1 Introduction

Ethical hacking is a method that generally is practiced when an organisation wants to measure and ensure their level of information security, to prevent potential cyber attacks and malicious activities. Typically, an external party is hired with the aim to break into and/or exploit company systems, resources or personnel (by social engineering), in order to detect vulnerabilities and consequently prevent breaches or data from being stolen and possibly abused as a consequence. The International Council of Electronic Commerce Consultants [3] explains that a favorable side-effect when taking such precautions, is the increase in confidence and reliability amongst customers and investors to the organisation’s business, services and or products.

The need for penetration testing and ethical hacking has increased significantly in recent years. One of the major reasons of which being the powerful technological revolution that the society is currently experiencing, with the acquisition of new technologies such as artificial intelligence, cloud services and the fifth generation of wireless communication technologies for cellular data networks [4]. As a result, new products and services are being developed, potentially by startups focusing on to deliver what they promised their stakeholders. In some cases these companies provide inadequate knowledge or low priority in cyber- & information security. A veritable assumption could be that the first generation of these novel assets will accommodate a whole new set of vulnerabilities and attack vectors, meaning that the number of threats and eventual attacks will substantially increase. Given the rapid development of technology, a lot of companies nowadays are also in the process of upgrading and transforming their obsolete information systems, which involves certain risks like negligence and uncertainties. This is something that also increases the amount of vulnerabilities and harmful exposures in companies information security.

The Swedish Ministry of Justice pronounces in a communication to Sveriges Riksdag (the parliament) [5], that the "Digital transformation is a global phenomenon" and the need to enlarge the cyber security in Sweden is of great interest. The demand of cyber security increases with an accelerating pace, and even though changes like the use of new technology and innovations gives us major opportunities, it also makes threats more difficult to detect and risks more difficult to assess. In the end our open democratic society needs

(16)

1 INTRODUCTION

to be protected, and such a society is "dependent on the ability to maintain the desired confidentiality, integrity and availability" when handling information. Accordingly, both the systems that are used to store and transfer information, and the information itself must be protected.

The swedish Ministry of Justice further explains that not only does the level of awareness and knowledge need to be increased, but a general strategy needs to be developed to "support the efforts and engagement that already exist in society for enhancing cyber security"[5]. Since cyber security concerns everyone, so must everyone take responsibility and collaborate in order to achieve a secure management of information. For this reason, but also given the interest and curiosity in ethical hacking that the students have received from their education, a security test will performed to deepen their knowledge and support the society’s current demand for information security.

1.1 Goals and objectives

The aim of the thesis project described in this report is to make an evaluation of the security of the card terminal iZettle Reader 2. Regardless of which results and outcomes given by the work to be performed, a credible evaluation can still be made in order to answer the following scientific question:

– Is iZettle’s payment solution a platform for safe payments?

In order to evaluate the security of the chosen product and thereby formulate an answer to the question above, a security test will be conducted consisting of three main elements:

exploration of the system, penetration testing and evaluation of the result. The methodology to be applied is described more thoroughly in section 3 Methodology, see page 31.

Additionally this work will provide beneficial value to the customers using the card terminal as well as the society at large, since the conclusion and result of the security test is expected increase the public impression regarding the security and reliability of the card reader and similar products.

16

(17)

1 INTRODUCTION

1.2 Delimitations

To keep the thesis project within a reasonable scale, a couple of limitations has been formulated:

1. The students intend to study the iZettle Reader 2, the communication between the card terminal and the sales/checkout system provided by the iZettle Go mobile application, and the communication between the application and iZettle’s servers.

2. The students do not intend to study the card terminal from a hardware perspective, since this is not part of the scope of their education.

3. The students intend to obey the following Swedish laws and regulations which concerns security- and penetration testing (but of course also all other laws and regulations in Sweden):

Brottsbalk (1962:700); kapitel 4, 9c § "Den som olovligen bereder sig tillgång till en uppgift som är avsedd för automatiserad behandling eller olovligen ändrar, utplånar, block- erar eller i register för in en sådan uppgift döms för dataintrång till böter eller fängelse i högst två år. Detsamma gäller den som olovligen genom någon annan liknande åtgärd allvarligt stör eller hindrar användningen av en sådan uppgift."[6]

Brottsbalk (1962:700); kapitel 4, 8 §: " Den som olovligen bereder sig tillgång till ett meddelande, som ett post- eller telebefordringsföretag förmedlar som postförsändelse eller i ett elektroniskt kommunikationsnät, döms för brytande av post- eller telehemlighet till böter eller fängelse i högst två år."[6]

Lag (1960:729) om upphovsrätt till litterära och konstnärliga verk; 2 §: "Upphovsrätt innefattar, med de inskränkningar som föreskrivs i det följande, uteslutande rätt att förfoga över verket genom att framställa exemplar av det och genom att göra det tillgängligt för allmänheten, i ursprungligt eller ändrat skick, i översättning eller bearbetning, i annan litteratur- eller konstart eller i annan teknik."[7]

Lag (2018:558) om företagshemligheter; 1 §: "Lagen innehåller bestämmelser om skadestånd, vitesförbud och straff vid obehöriga angrepp på företagshemligheter."[8]

(18)

(19)

2 BACKGROUND

2 Background

With the help of the digital transformation, products and services can become more refined and effective, and in most cases also simplified. Something that we likewise can perfect are different types of processes and use cases, for example the payment process; How can businesses and merchants refine their process of receiving payments, and which tools can they use in order to do so? The mobile Point of Sale (mPOS)1 systems has become increasingly popular during the last decade and has completely altered the market. Not only can existing businesses take advantage and be enhanced. The opportunities that opens up for new companies and entrepreneurs are immense, especially for street-vendors and other small businesses.

The fintech company GoCurrency explains in an article on Medium[9], how mPOS systems has become a great asset particularly for companies "on the move". The modern payment solution obtains the same functionality as traditional cash registers, but runs off a smart device connected to the internet making them very light and portable. As previously said, this is a game changer for businesses that typically do not operate out of permanent stores or locations. This is merchants who trade their products and services out of a moving store such as a food truck, or at farmers market and street fairs. With the progression of the digital era, products and services are also getting cheaper and more inexpensive because of the recent innovation and development of new technologies. This favors merchants with lower funds, who now can spend more money on goods and the business itself.

2.1 The card terminal

The iZettle Reader 2 is a wireless card terminal produced and supported by the company iZettle[10], enabling small businesses and merchants to offer chip & PIN, and contactless payments. iZettle was originally a Swedish company until 2018 where it got sold to Paypal, a multi-billion dollar online transaction solution company. The card reader is the latest product in iZettle’s range of card readers, and is said to be the newest and improved version of their bestseller and previous version, the iZettle Reader. The card terminal is connected to a smartphone or tablet which maintains the sales- and checkout system in shape of the iZettle Go mobile application, and together they form the mobile point of sale. The

1Point of sale. The point in a store where transactions are made, i.e. the checkout counter/cash register.

(20)

2 BACKGROUND

communication between the card terminal and the mobile device is managed by Bluetooth Low Energy, which is an extension of the original Bluetooth technology but with a lower power consumption (see 2.3 Bluetooth Low Energy, page 22).

To be able to use the card terminal, the merchant (i.e. the "direct" user of the system) must have a registered company as well as an account registered with iZettle. The seller logs on to the iZettle Go app, and is required to fill out their bank account details so that they can start to receive payments from their customers (the "in-direct" users). The application is free to download from the Apple App Store & Google Play, and can be used on both smartphones and tablets. The application is a crucial part of the whole payment solution and obtains typical back-office features which may be used in stores and by retailers such as a product library, management of inventory, creating receipts, making refunds, selling gift cards and much more[11]. In that regard the application provides more of a sales- or business system than just a simple checkout system to the direct user, even though the system looks to be adapted for ease of use.

iZettle pronounces that they adhere to PCI PTS 4.1, which means that their card readers obtain the Payment Card Industry Security Standards Council (PCI SSC) PIN Transaction Security (PTS) device approval by obeying certain directives and requirements. The PCI Security Standards council is a global forum that brings together the payments industry stakeholders, with the mission to "enhance global payment account data security by de- veloping standards and supporting services that drive education, awareness, and effective implementation" [12]. iZettle explains that this ensures their card reader’s hardware and software to be tamperproof. For instance, the Reader 2 is said to "self-destruct" if someone messes with its hardware. Data concerning credit cards is encrypted according to the high- est and strictest standards by Hardware Security Modules (HSM), to prevent information from being compromised. Thales, a company that produces HSMs, describes the module as a "hardened, tamper-resistant hardware device" primarily used by the banking industry to

"provide high levels of protection for cryptographic keys and customer PINs" used during processing of card payment transactions[13].

By reading iZettle’s website you get the perception that security is something they take seriously and works strongly with, almost depicted as an unique selling point for their products. They mention that one of their tasks is to protect and promote their costumers

20

(21)

2 BACKGROUND

companies, and to make their customers feel safe and secure. Furthermore, all of their software is developed according to the best practices and strict industry standards of for example the Open Web Application Security Project (OWASP) & the Payment Card Industry Data Security Standard (PCI DSS). With advance systems monitoring all transactions the company is said to prevent fraud, and all traffic is observed and logged with the purpose to detect unusual and malicious activity. If any of iZettle’s services are used incorrectly or strange deviations are made, the user’s account is shutdown immediately to prevent further abuse.

Unlike the first version of the card reader, the second generation does not accept magnetic stripe cards which was removed for security reasons. The older type of cards maintains low security, due to the fact that the magnetic stripe is just a collection of static data that easily can be read and replicated. Chip cards is the latest security standard developed by the companies Europay, Mastercard and Visa. The so called EMV cards includes a microchip that supposedly protect customers and merchant against fraudulent transactions, and has now been around for over a decade. Data stored on the chip is constantly changing, and is more difficult to access than on a magnetic stripe. Communication between EMV cards and card terminals is also encrypted, making the solution far more secure and less vulnerable.

FIGURE 1: iZettle

Reader 2[14] FIGURE 2: iZettle Go[15]

The front of the card terminal consists of a smaller LCD-screen, 4 separate LED-lights, a numeric keypad with accept & reject buttons, and a location for where to put your card when performing contactless payments. At the top of the Reader 2 is a micro-USB port (initially for charging) and a power button, and at the bottom there is a card slot.

(22)

2 BACKGROUND

2.2 Previous work

Earlier versions of iZettle’s card terminal has been successfully exposed by different hacks and exploits. In a Forbes article from 2018[16], it is written that the cyber security company Positive Technologiesmanaged to hack an iZettle card terminal, altering the amount charged to a customer, different to what was displayed on the screen of the reader. This could be done by intercepting encrypted traffic going between the reader, the mobile device and the server managing payments. Something that is important to consider is that the hacker might not always be a third party, but in this case a fraudulent merchant.

Several articles shows that mPOS devices, including iZettle amongst others manufacturers, provides a high risk and can be hacked easily. Researchers from the company MWR Labs reported at the SyScan security conference[17]in Singapore 2014, that they were able to take control of an iZettle card terminal to for example play a version of the popular game Flappy Bird. The researchers further demonstrated at the conference the possibility to comprimise mPOS terminals with "multiple attacking techniques using micro USBs, Bluetooth and a malicious programmable smart card", and mentioned that one of the security flaws being how an attacker is able to collect PIN and credit card data from paying customers. One of the security researchers from MWR pointed out that mPOS "is a promising technology with a growing market uptake, well suited for use in modern payment systems, but current implementations are not well designed from a security perspective. It is critical to get security right early as there is a huge potential for fraud around the world".

2.3 Bluetooth Low Energy

Bluetooth Low Energy (BLE) is a Wireless Personal Area Network technology, developed by the Special Interest Group (SIG), that communicates over the 2.4GHz radio frequencies [18]. The main difference between BLE and its predecessor classic Bluetooth, is the lower energy consumption. This makes the updated technology optimal for Internet of Things (IoT)2 devices that rely on connectivity and communication with multiple other devices, with a need of low battery consumption. Because of the lower cost, energy consumption and complexity that is provided by BLE, more and more devices has adapted to it[19].

2Things and objects with embedded electronics, sensors and internet connection that produces and ex- changes data.

22

(23)

2 BACKGROUND

Every Bluetooth enabled device (including the Reader 2) has a unique 48-bit (6-bytes) MAC-address used for indentification, the so called BD_ADDR (looking like for example 00:11:22:33:FF:EE or 11:22:33:44:55:66)4[20]. The most-significant bits (24-bits) are the Organizationally Unique Identifier (OUI) and identifies the manufacturer and its configu- ration of the technology on the device. The rest of the 24-bits are the Lower Address Part (LAP) and is used to uniquely identify the device[20] [21]. The OUI consists of two parts, Non-significant Address Part (NAP) and Upper Address Part (UAP). The NAP consists of 16-bits and defines the Frequency Hopping Synchronization (FHS). The UAP is the remaining 8-bits of the OUI and defines various Bluetooth specification algorithms. Lastly, the UAP and the LAP make up the Significant Address Part (SAP) of the Bluetooth Address [22].

FIGURE 3: The Bluetooth LE Address

The Bluetooth technology is built up by a certain stack or architecture consisting of both software and hardware. The stack describes the different layers and protocols that is used to establish a connection and communicate between two devices, in this case the communication between the card terminal and a smartphone with the iZettle Go application.

A Bluetooth module can be configured to a certain profile depending on the purpose of the Bluetooth device. A profile is the module’s preset specifying the behaviour of the device, which services it provides, security rules and so on [23]. Generic Access Profile (GAP) is a fundamental profile for all other profiles. The GAP enables the ability to discover and establish connections between another Bluetooth system. Bluetooth modules have a custom set of services, also called Generic Attribute Profile (GATT) services, and characteristics which defines the behaviour and what operations it can do. The operations can be almost

(24)

2 BACKGROUND

anything between glucose dispenser to sensor location, it all depends on the purpose of the Bluetooth module and its designer. For each profile a number of services is encapsulated, for each service a number of characteristics are encapsulated. A characteristic is a single logical value which can be read or written from. The rovides a table of the different supported services and characteristics in Bluetooth modules[24] [25].

Similar to Institute of Electrical and Electronics Engineers (IEEE) 802.11 Wi-Fi, Bluetooth communicates over radio frequencies by transferring data packets. It is through these packets that the interconnected devices can understand and communicate with each-other, by transmitting and receiving data [21]. The Universal Asynchronous Receiver Transmitter (UART) interface is a part of the Bluetooth module that specifies the data format and trans- mission speed of the packets, which is capped at 20 Bytes per second. Data is transmitted and received in a serial manner, meaning that it takes Bytes of data and sequentially trans- mits individual bits. The packet itself comes in a specific format as depicted in Figure 4, including a description of each part. [26].

FIGURE 4: Bluetooth Low Energy Packet Format

• Preamble - Defines the synchronization (time and frequency) between two connected devices.

• Access Address - Specifies the unique connection/channel between two devices.

• PDU - There are two different types of Protocol Data Unit (PDU) depending on the use, there is AC-PDU and DC-PDU.

• CRC - Cyclic Redundancy Check (CRC) is an algorithm which purpose is to ensure that there are no unwanted changes in the received data.

24

(25)

2 BACKGROUND

• AC-PDU - Advertising Channel Protocol Data Unit (AC-PDU) is transmitted when the unit is discovering/searching other Bluetooth units.

• DC-PDU - Data Channel Protocol Data Unit (DC-PDU) is for data transmissions when two Bluetooth devices are successfully connected.

• Header - Houses data information regarding type, flow, ACKs etc.

• Payload - Houses the actual data to be processed as well as the unique BD_ADDR which was mentioned earlier.

• MIC - Message Integrity Check (MIC) is an encryption that is designed to protect the payload and the header from being tampered. This is an optional field and it is part of the payload field.

Bluetooth is operating on the 2.4GHz radio frequency, divided into 40 different channels ranging between 2400MHz and 2480MHz. There are two types of channels - Advertising Channel (AC) and Data Channel (DC), 3 of the 40 channels are dedicated to AC and the rest of the 37 channels to DC. The advertising channels, as the name suggest, is used to advertise the units existence - device scanning and discovery, connection establishment and broadcast transmissions. The data channels are dedicated to the actual data transfer between two connected devices[27]. Data channels utilize a frequency hopping algorithm which purpose is to avoid collision and interference between other radio devices that utilize the same radio frequencies, mainly other Bluetooth enabled devices. The algorithm jumps between the different channels many times on a set pattern. Each Piconet has its own unique pattern and only occupies a channel for a very short time before hopping to the next channel [27].

The Bluetooth network is built up by nodes or Piconets - masters and slaves. A master node can establish a connection to one or more slaves whilst a slave node can only be connected to one master. Thus, when a master and a slave is connected, creating a Piconet.

Having this network model enables the master to control the incoming and outgoing data [28]. Coordinating the flow of the data is needed due to the master having the ability to be connected to several slaves. The iZettle Reader 2 is no exception, where the Reader 2 being the slave connected to a master, i.e a smart phone.

(26)

2 BACKGROUND

FIGURE 5: Bluetooth Message Exchange Diagram

Before a Bluetooth enabled device can establish a connection, a series of messages needs to be exchanged between the devices. As depicted in Figure 5, a smartphone can scan the area for available Bluetooth units by listening in on other device’s advertisements - ADV_IND: Ch37-39. The iZettle Reader 2 is the unit that advertises whilst the smartphone is scanning. A connection is established as soon as the CONNECT_REQ packet is sent and received. The one sending that packet becomes the master and the one accepting the connection becomes the slave. The content of these packets can be seen in Figure 4[28].

26

(27)

2 BACKGROUND

2.4 Common attacks

Devices in the Internet of Things spectrum are generally known for being under threat by cyber attacks. Depending on the technologies used, typically Bluetooth and or Wi-Fi, attacks such as Denial of Service, Man-in-the-Middle and spoofing are known to take place and has been documented[29]. Since the iZettle Reader 2 is utilizing BLE as its main communication technology, the existing vulnerabilities in BLE, presumably, comes along with it. There are several tools and techniques available that exploit the existing vulnerabilities, such as Ubertooth which is an open source project for Bluetooth experimenting[30]and SwaynTooth which just recently emerged. SwaynTooth is a software that, together with a Bluetooth dongle, exposes different vulnerabilities in BLE to trigger, for example, crashes, dead-locks and security bypasses on some Bluetooth enabled devices[31].

2.4.1 Denial of service

Denial of Service (DOS) is a name of an attack with the purpose to render the attacked machine or network out of its intended or normal use, and thus disrupting the service.

Generally this is done by flooding the overlying network with redundant requests to ultimately congest the involved systems[32]. Although the definite goal with an attack of this sort might be to bring the service to a halt, the attacked service’s ability to communicate with genuine clients can be significantly decreased during a period of time, depending on potential cyber attack protection systems as well as the magnitude of the attack. This could be more harmful than some people think, where for instance a noticeable consequence for a company could be a loss of revenue. Peter Gullberg from Gemalto Digital Banking wrote, 2016, a paper[32]on denial of Service attack on Bluetooth Low Energy and suggested that such an attack is possible and demonstrated it using Ubertooth to disturb the communication on the protocol level.

2.4.2 Man in the middle

Just as the name suggests, a Man-in-the-Middle (MITM) attack is when the attacker becomes a malicious middle-man between two or more systems. The attacker’s intention is to take part of the traffic between the systems to ultimately alter or exfiltrate information of the incoming and or outgoing data [33]. This means that the attacker in some cases (depending on the transport layer security and data encryption) could for instance tamper the information sent

(28)

2 BACKGROUND

in packages between the sender and recipient without neither their consent nor knowledge.

MITM attacks are not uncommon around Bluetooth enabled devices such as between the Reader 2 and a smartphone. A report from 2018 written by Tal Melamed [34], suggested that Bluetooth is insecure and vulnerable against passive eavesdropping which involves malicious software, a virus installed one of the victim systems that listens on the Bluetooth communication. Doing this enables an MITM attack to be able to both listen in on the communication but also intercept and manipulate the data.

2.4.3 Spoofing

Spoofing refers to the event when an attacker impersonates typically a person, company, program or host with the purpose of accessing information or to end up in a position where further frauds or attacks can be carried out. There are several types of spoofing attacks, but the most widely known are e-mail address spoofing and web address counterfeiting.

Although there are a lot of precautions and countermeasures that can be taken in order to protect against spoofing attacks, the most essential action is to authenticate the sender and recipient to ensure that consignments and information is genuine and end up in the right hands.

2.4.4 Replay

A replay attack refers to the act of sniffing packets between two systems or devices, just like a man in the middle, and keeping them for later transmit. This means that captured or tapped packets can be repeated or delayed maliciously. For instance, if you could intercept or tap packets that is sent as a result of authorized actions, and would be able to manipulate the data transmitted, you would indirectly have authorized access to the recipient system or device. This means that an attack of this sort enables for impersonation and fraud. An example in the case of iZettle would be to replay or delay packets that is sent to the card reader concerning card payments, and see how the system would react and behave.

28

(29)

2 BACKGROUND

FIGURE 6: Man in the Middle attack

FIGURE 7: Spoofing attack

FIGURE 8: Replay attack

(30)

(31)

3 METHODOLOGY

3 Methodology

The methodology for the project is divided into three major phases, to systematically and convincingly conduct the security test of the iZettle Reader 2. The first phase consists of literature studies and threat modeling; accomplished to fully understand the system at hand, its underlying technologies and the threats it faces. The second phase processes penetration testing of the most promising attack vectors derived from the first phase, to distinctly test the security of the product. The purpose of the last phase is to evaluate the results from the penetration tests, so that a conclusion can be made regarding the security of the product. With the implementation of the three phases that each have their own purpose and objectives, we can ensure that the conclusion and result of this security test is fair and has been produced in a correct manner.

3.1 Threat modeling

Threat modeling is an important part as it is the first stepping stone in penetration testing.

There are many types of threat models and attack graphs that describes the different attack vectors and hack procedures respectively. To find a common ground for all types of attacks and threats is a current research area where domain specific languages is of consideration such as the vehicleLang presented by Soitirios Katsikeas who did a reasearch on probabilistic modeling and simulation of vehicular cyber attacks[35]. As the name vehicleLang suggest, it is a meta language developed for vehicle cyber attacks. In order to fully comprehend the process and execution of threat modeling, as well as its contribution to the security test, a reference is made to the OWASP article "Application Threat Modeling"[36]which provides a detailed and informative description of threat modeling and what to take in mind. OWASP describes threat modeling as a common tool and practice for identifying, understanding and assessing different threats and attack vectors, usually in a context of protecting or securing a chosen product or system in mind. In this case, a system such as the Reader is small enough for it to be modelled as such. However, for future research and continuation of this work, a more formal approach could be used such as the Meta Attack Language[37]or pwnpr3d which utilises an attack-graph-driven probabilistic threat-modeling approach[38]. A threat model is often developed to answer which improvements and countermeasures can be taken in order to increase the security of a specific system. The more exceptional purpose of our application of threat modeling however is to oversee the most promising attack vectors

(32)

3 METHODOLOGY

for us to perform penetration testing on, as ethical hackers. In general, most of the threat modeling techniques that are available are done manually and lack a common ground as evaluated by Robert Lagerström and Wenjun Xiong in a report on systematically reviewing threat models[39].

During the threat modeling phase, the product under testing is described and explored superficially so that a categorization can be made considering all possible threats and attacks vectors. By applying the two established models STRIDE and DREAD, we can ensure that the majority of all possible attacks are reviewed and assessed for their respective risk, potential impact and probability of a successful breach or exploitation. The two models that were utilized are explained further down in this section.

3.1.1 STRIDE Model

The STRIDE model provides a mnemonic for the different types of security threats, and was applied to identify and differentiate threats and attack vectors against the iZettle Reader.

STRIDE is an acronym for a set of categories which threats can be organized into, and reminds the user of all different types of exploits and attacks. Microsoft provides a good explanation for each type (or letter) in STRIDE[40]:

• Spoofing identity. Illegally accessing and utilizing another user’s information for au- thentication (for example username and password).

• Tampering with data. Malicious altering of data, that is unauthorized modifications or addition of data for example sent between devices or in a database.

• Repudiation. Performing illegal operations in a system without the ability to observe or trace prohibited operations.

• Information disclosure. Exposure of information to unauthorized users. The ability for individuals to access data sent between two devices or in a file which they should not have access to.

• Denial of service. Deny the service of a product by making it unavailable or unusable.

• Elevation of privilege. Escalation of privileges, making unauthorized users get sufficient privileged access to compromise or exploit a system.

32

(33)

3 METHODOLOGY

The threats and attack vectors that were identified can be found in section 4.2 Identifying threats, see page 41.

3.1.2 DREAD Model

The DREAD model is used for risk assessment which provides a rating system for threats and attack vectors. Similarly to STRIDE, DREAD is also an acronym which makes up the criteria of what each threat is assessed from, scaling between 1 (low risk) and 3 (high risk). Following is an explanation by Microsoft[41], of the criteria for assessment using the DREAD model:

• Damage - "Assessing the damage that could result from a security attack is obviously a critical part of threat modeling. Damage can include data loss, hardware or media failure, substandard performance, or any similar measure that applies to your device and its operating environment".

• Reproducibility - "Is a measure of how often a specified type of attack will succeed. An easily reproducible threat is more likely to be exploited than a vulnerability that occurs rarely or unpredictable. For example, threats to features that are installed by default, or are used in every potential code path, are highly reproducible".

• Exploitability - "Assesses the effort and expertise that are required to mount an attack.

A threat that can be attacked by a relatively inexperienced college student is highly exploitable. An attack that requires highly skilled personnel and is expensive to carry out is less exploitable. In assessing exploitability, consider also the number of potential attack- ers. A threat that can be exploited by any remote, anonymous user is more exploitable than one that requires an onsite, highly authorized user".

• Affected users - "The number of users that could be affected by an attack is another important factor in assessing a threat. An attack that could affect at most one or two users would rate relatively low on this measure. Conversely, a denial-of-service attack that crashes a network server could affect thousands of users and therefore would rate much higher".

• Discoverability - "Is the likelihood that a threat will be exploited. Discoverability is difficult to estimate accurately. The safest approach is to assume that any vulnerability

(34)

3 METHODOLOGY

will eventually be taken advantage of and, consequently, to rely on the other measures to establish the relative ranking of the threat.".

In order to make a risk assessment for each threat that was found using the STRIDE model, we applied and adapted the DREAD rating system (see Table 1 and 2) from Infosec.

According to Infosec’s article on Risk Management [42] the different threats are assessed according to the DREAD rating system, which produces a score that shows the risk rating of the assessed threat. The assessments can be found in section 4.3 Rating threats, see page 43.

Rating High (3) Medium (2) Low (1)

Damage The attacker can get full access, operate in a privileged context or upload/download content.

Sensitive information

can be leaked. Little to none sensitive information can be leaked or lost.

Reproducibility The attacker can successfully pass through or circumvent the control or device every time to advance towards the target.

The attacker can successfully pass through or circumvent the control or device only when certain conditions exist.

It is very difficult to pass through or circumvent the control or device.

Exploitability Requires little skill. Requires moderate skill.

Requires high skill.

Affected Users All users or customers are affected. Critical processes are

significantly affected.

Some users or

customers are affected.

Critical processes are operational but impeded.

Little or no impact on users, customers nor critical processes.

Discoverability Adequate detection control does not exist.

Insufficient logs or in- trusion detection systems. Requires significant manual review.

Existing and fully func- tional logs and intru- sion detection systems.

TABLE 1: DREAD Rating System

Result 12-15 8-11 5-7

Risk Rating High Medium Low

TABLE 2: DREAD Risk rating table

34

(35)

3 METHODOLOGY

3.2 Penetration testing

After the threat modeling phase follows the penetration testing stage, where a set of concrete penetration tests are conducted concerning the most promising attack vectors. The threats identified in the threat modeling phase can be divided into three different types of attacks, denoted in section 2.4 Common attacks, see page 27. Having that said, with a reliable approach this phase would consist of penetration tests with the intention to test every type of attack, where only a handful of the found threats will be taken into consideration. The conducted penetration tests are described in section 5 Penetration Testing, see page 45.

3.2.1 Reconnaissance

Initially during any penetration test, thorough reconnaissance is conducted to extract neces- sary information in terms of available attack vectors, but also to get a better understanding of the system and its behaviour on protocol level. It is an ongoing process where new findings can arrive when not expected, especially for a system such as this where safety and secrecy is of importance. As previously mentioned, the Reader 2 utilizes BLE meaning that one of the methods to interact with the card reader is through Bluetooth. The other method is through Wi-Fi as the Reader 2 is connected to the iZettle Go application on a Smartphone which in turn sends and receives information from iZettle’s servers over the internet. Gathering information about a system and understanding its behaviour can be hard in terms of completeness and validity - "Have we considered all possibilities?", "Are the findings reliable and legitimate?". For a system such as the Reader 2, finding specific information about its behaviour on the protocol level can be hard, thus using specialized tools to analyze the device and its communication is needed. The tools used are also part of the methods used for the penetration testing, such as packet sniffing on both Wi-Fi (HTTPS) and BLE by using Ubertooth One and Fiddler respectively.

Analyzing these packets gives a better understanding on what goes on between the three main modules - the card reader, the mobile application and iZettle servers. The findings can be found under Penetration Testing. These are the first steps towards conducting the penetration tests and unveil any undiscovered attack vectors.

(36)

3 METHODOLOGY

3.2.2 Exploitation

Given that thorough reconnaissance has been conducted and satisfying knowledge about the system has been obtained, a set of experiments are now conducted aimed at exploiting the found, possible, vulnerabilities in the system. We are able to test, through suitable tools, and exploit the findings in the system and eventually assess whether or not the system is vulnerable through these attack vectors. These tools were chosen based on recommendations and previous reports where the same tools were used in conducting similar penetration tests. Tools such as the two mentioned above, Ubertooth One and Fiddler, were used for both packet sniffing which gives a better understanding of the system but also enables for conducting MITM-, DoS- and Replay-attacks. As mentioned above and in earlier sections, the Reader 2 together with the iZettle Go application utilizes two radio technologies - BLE and 802.11 Wireless Local Area Network (WLAN) for communication between the three modules. There is an ocean of known exploits and experiments available and it would be very impractical to try them all, hence the limited selection of attacks from the threat model. Based on the findings, two main attack methods were considered. Man- in-the-middle attacks on both Wi-Fi and BLE and lastly Wi-Fi Server Spoofing. The reason behind choosing these are due to having limited information about the system which limits the attack vector as well. They are common attacks and can have a large impact in case the result is successful. Lastly, we have to act within the border of the Swedish laws, meaning that some attacks that exploits the iZettle servers are off limits. However, these attacks, if successful could lead to other attacks such as DOS and Replay which could further lead to an even deeper control over the system. The following table gives a brief overview on the different attacks and the tools used to conduct them.

Attack Protocol Tools

MITM BLE Ubertooth One, Gattacker & Bettercap MITM 802.11 Fiddler, Owasp-Zap & Burpsuite Server Spoofing 802.11 Burpsuite & Owasp-Zap

TABLE 3: Different attacks and tools used based on the protocol

36

(37)

3 METHODOLOGY

3.3 Evaluation and conclusion

During this phase an evaluation will be made using the results of the penetration tests as well as all knowledge and perceptions we have managed to obtain throughout the prestudy and penetration tests, in order to come to a conclusion regarding the security of the card reader. For the actual evaluation and conclusion of the security, see section 6 Discussion and conclusionon page 63.

(38)

(39)

4 THREAT MODEL

4 Threat model

In order to identify and assess the possible angles of attacks of the iZettle Reader 2, an elaborate threat model was developed. This was accomplished in three steps; identifying the assets, identifying- and evaluating the threats (thoroughly explained in section 3.1 Threat modeling, see page 31). Moreover, a visual diagram was created showing an architectural overview (see Figure 9) on the card terminal, to give a better understanding of its area of use.

4.1 Identifying assets

A good start on the way to identify threats and find attack vectors is to explore the system in consideration and its assets, as well as to examine its use cases and different types of applications.

4.1.1 Architectural overview

FIGURE 9: Architectural overview

1) iZettle Reader 2: The card terminal which the customer interacts with when making card payments.

2) iZettle Go: The mobile application which the merchant interacts with when creating payments. An interface for managing sales and other back office features.

3) iZettle servers: Authorizes payments, logs actions, sends receipts etc.

(40)

4 THREAT MODEL

4) BLE Module: Main vector of communication between the Reader 2 and iZettle Go.

5) Near Field Communication (NFC) Sensor: Makes it possible for contactless card (including digital wallets) payments.

6) Micro USB Port: Used for charging the batteries of the Reader 2.

7) EMV Chip Reader: Module for reading credit card chips.

8) Customer: The actor interacting with the Reader.

9) Merchant: The actor interacting mainly with the iZettle Go application.

The most commonly occurring use-case (including the card terminal and mobile application) is reasonably when a customer wants to make a purchase of one or more products, seen in Figure 10. As described, use-cases could give further support to the identification of threats and attack vectors.

FIGURE 10: Typical checkout/payment use-case

40

(41)

4 THREAT MODEL

4.2 Identifying threats

After that all assets and technologies of the card terminal has been identified, an identification of threats and attack vectors was carried out. The reason of which is to distinguish which penetration tests are going to be conducted later on, so that the security can be evaluated.

4.2.1 The STRIDE model

The STRIDE model was applied to identify security threats (see 3.1.1 STRIDE Model), which sorts the threats into six categories:

• Spoofing identity

– Hosting a malicious server that mimics iZettle’s server, which becomes the recipient of the communication sent from the iZettle Go application.

• Tampering with data

– Tampering with the content of Bluetooth packets sent between the card terminal and the device.

• Repudiation

– Could not find any appropriate threats.

• Information disclosure

– Disclosure of information sent between the device and the card terminal.

• Denial of service

– Obstruct the communication between the device and the card terminal by capturing and rejecting packets.

– Perform a denial of service attack towards the card terminal to keep it occupied from communication with the device.

– Perform a denial of service attack towards the card terminal to cause a battery drainage.

• Elevation of privilege

– Could not find any appropriate threats.

(42)

4 THREAT MODEL

4.2.2 OWASP’s Top 10

The OWASP Foundation has a couple of documents called OWASP Top 10 that lists "the most critical security risks" [43] concerning different applications and platforms. The purpose with the lists is to increase the awareness around the different threats and risks, but also to propose to companies which risks should be prioritized and minimized. By using these lists, we identified additional risks and threats that concerns the iZettle Reader 2 and surrounding systems:

• Reverse Engineering

– Having access to the target application, decrypt and analyze it through tools.

• Code Tampering

– Modifying said application and customizing it for the benefit of the attacker.

• Insecure Connection

– Data exchanged between client and server can be intercepted and analyzed, exposing sensitive information.

Attack vector diagram

FIGURE 11: Attack vectors

42

(43)

4 THREAT MODEL

4.3 Rating threats

The following tables show the risk assessment of each threat using the DREAD rating system, explained and shown in 3.1.2 DREAD Model, see page 33.

Threat ID Description D R E A D Rating

1 Tampering with the content of Bluetooth packets sent between the card terminal and the device.

3 2 2 2 1 10 (Medium)

2 Disclosure of information sent between the device and the card terminal.

2 2 2 1 3 10 (Medium)

3 Obstruct the communication between the device and the card terminal by capturing and rejecting packets.

3 2 2 3 2 12 (High)

4 Perform a denial of service attack towards the card terminal to keep it occupied from communication with the device.

3 3 2 3 2 13 (High)

5 Perform a denial of service attack towards the card terminal to cause a battery drainage.

3 2 2 3 2 12 (High)

(44)

4 THREAT MODEL

6 Reverse Engineering, decrypt and analyze the application source code in order to add malware or similar.

2 2 1 2 3 10 (Medium)

7 Tampering with the source code to redirect API calls or similar.

2 2 1 2 2 9 (Medium)

8 Exploiting the connection between client and server to extract sensitive data

2 2 2 2 3 11 (Medium)

The DREAD assessments shows that all threats represents either a medium or high risk and thus could be very harmful to the information security of the card terminal.

44

(45)

5 PENETRATION TESTING

5 Penetration Testing

In this section, a number of conducted penetration tests is presented including explanations of what the tests tries to accomplish, how they were conducted, and the results and evaluation.

The penetration tests are the ones mentioned earlier and depicted in Table 3. The penetration test seems insufficient and few at first, as they mostly aim for MITM attacks. However, due to the system at hand where possibilities and attack angles are few, MITM attacks looks the most promising in terms of hijacking the system further.

5.1 Man in the middle and replay of Bluetooth traffic

As mentioned before, the card reader’s and the mobile application’s main vector of attack is through its communication technologies BLE and WLAN, where WLAN is only used for communication between the mobile application and iZettle servers and BLE for the mobile application and the reader. Both of these technologies rely on transmitting and receiving packets which is where most of the sensitive information is contained. In a situation where an attacker could conduct a successful MITM attack, further attacks such as DOS, replay attacks and various types of spoofing are possible. Thus, this is the main reason to why the following tests aims to take MITM position at first.

5.1.1 Gattacker

Gattacker is a tool used to conduct BLE MITM attacks by impersonating the Bluetooth slave device and tricking the user to connect its Bluetooth master unit to the "false" device.

Gattacker utilizes a "central" device which purpose is to interact with the Bluetooth master unit, in this case the smartphone, and the "slave" device, the card reader, which acts as a proxy for the Bluetooth traffic. If successfull, Gattacker has the ability to register each packet sent between the smartphone and the reader making it possible to conduct replay attacks or alter the content/data in the packets transferred between the Smartphone and the card reader. Two computers running Kali Linux were used, one acting as the "central"

device and the other as the "slave" as illustrated in the Figure 12 below. The central- and the slave computer communicate over the Local Area Network whilst the rest of the connection is done through BLE.

(46)

FIGURE 12: Gattacker Setup

The commands are issued through the central computer, starting with scanning for Bluetooth advertisements and saving the found peripheral addresses (MAC) which is done by issuing the command sudo node scan.js. The successful result can be seen in the Figure 13 below, displaying that the Reader 2 has been discovered by displaying its MAC-address D1:47:95:23:DC:f6and its display name 302. The output is then saved to a local folder for future use.

FIGURE 13: Gattacker: Found advertisement from the Reader 2

Next step is to analyze the card reader’s characteristics and services so that Gattacker can impersonate the unit and offer the same services. To scan for the its services, a new scan command has to be issued along with its found MAC-address, sudo node scan D1479523DCf6.

The slave computer starts analyzing the card reader for its services and sends them to the central computer which then saves the services in a JSON-file for later use. A successful output can be seen below.

The two key JSON-files are now obtained - advertisement and services for the Reader 2.

46

(47)

FIGURE 14: Gattacker: Found services and characteristics of the Reader 2

Through these, Gattacker can initialize it’s attack by impersonating the Reader 2. This is done by issuing the command sudo node advertise.js -a

devices/d1479523dcf6_302.adv.json -s devices/d1479523dcf6.srv.jsonwhere the -a flag specifies the Reader’s advertisement and -s its services. Gattacker will now advertise itself as the Reader 2, waiting for the Smartphone to connect to it and finally become the man in the middle. To verify that Gattacker has successfully impersonated the Reader 2, a simple scan on the iZettle Go application will suffice as two identical devices are now displayed and ready for connecting.

FIGURE 15: Gattacker: Successfully initialized & impersonating Reader 2

One of the devices seen in Figure 16 is the real card reader and the other one is Gattacker, impersonating the reader. There is no way of telling which one is the real card reader other than trying to connect to them one by one. Fortunately, the iZettle Go application was unsuccessful in pairing with the impersonated card reader as upon pairing the application rejected it and discarded its advertisements from the list - leaving the advertisements from the real device as the only available Reader 2. No anomalies were discovered when pairing up with the real card reader before or after trying to connect to Gattacker.

(48)

FIGURE 16: iZettle Go: A Malicious Reader available for connecting

The reason behind the unsuccessful pairing lies within the fact that the Reader 2 and the iZettle Go application use an encrypted connection which Gattacker has no support for, at least for the time being. In order for the application and the card reader to pair up, a "handshake" is conducted by displaying a six-digit number on both the reader and the application. If the digits match and are accepted, the two can then pair up and create a piconet.

48

(49)

5.1.2 Ubertooth

In order to understand the behaviour of the card reader, the tool Ubertooth One is used to sniff the communication between the reader and the smartphone. The communication that is sought after is the one depicted earlier in Figure 5. Doing this ensures us that the Ubertooth has the ability to locate the card reader and sniff on the established connection between the device and a smartphone running iZettle Go. A powerful feature of the Ubertooth One is that it can home in on a specific MAC-address, making it easier to sniff a certain device in an environment where there can be many active Bluetooth devices advertising. To retrieve the MAC-address from the card reader, one can utilize the bluetoothctl command, available in Linux systems, to enter the main command view for configuring Bluetooth devices.

Through there, a scan can be performed to discover nearby, active Bluetooth devices.

FIGURE 17: BLE Discovery

As seen in the Figure 17 above, the iZettle Reader 2 (named 302) has the MAC-address D1:47:95:23:DC:f6. With this, the Ubertooth can follow Reader 2’s connection until it establishes a connection with the Smart phone. This is done with the command ubertooth-btle -f -t D1:47:95:23:DC:f6where -f flags to follow connections and an optional flag -t<MAC-address> that specifies which MAC-address to follow.

Initially, before connecting the Reader 2 to the smartphone, a decent amount of ADV_IND packets were collected, indicating that the card reader is advertising its existence. The information collected from this packet reveals a handful of information such as the maker of its Bluetooth module, the frequency, channel index and data.

When the card reader and smartphone is pairing, the Ubertooth picks up a new type of

(50)

FIGURE 18: Reader 2’s BLE Advertisement

FIGURE 19: Connection Request between the Reader 2 and Smart Phone

packet, CONNECT_REQ which is a key packet for confirming that the two devices are about to pair up. It is through this packet that the Ubertooth can start listening on the data channels and display the data packets as seen in Figure 19.

The output shown in Figure 20 displays each packet caught in the piconet. It displays at which frequency the packet has been transmitted on, the Received Signal Strength Indica- tion (RSSI), the type of packet (data) and its size in bytes, the channel index which is a Data Channel. It also displays some details about the Link Layer ID (LLID) and the Next Expected Sequence Number (NESN). At the bottom the data is displayed as hexadecimal values along with its CRC.

50

(51)

FIGURE 20: Data Packets sent/received between the Reader 2 and the Smart Phone

The goal here is to output the data to a file and analyze the data in these packets to ultimately find sensitive information that can be exploited. The data is encrypted and can, supposedly, be decrypted with tools such as Crackle. However, Crackle requires specific types of packets to be able to analyze the encryption algorithm which either Ubertooth failed to pick up or Crackle failed to analyze. As seen in Figure 19, the connection packet CONNECT_REQ exists but according to Crackle it is unable to find it as seen in Figure 21. Nonetheless, this resulted in an unsuccessful decryption of the data packets.

FIGURE 21: Unsuccessful decryption with Crackle

(52)

Upon further investigation, requested packets such as LL_ENC_REQ and LL_ENC_RSP were nowhere to be seen in the Ubertooth output which indicates that Ubertooth failed to pick of these types of packets. The reason for this could be that either the Ubertooth was unsuccessful in finding the right frequency and channel for those packets or that the card reader is using a modified Bluetooth profile. Both hypothesis could be true as Ubertooth, even according to its community, can be very unreliable and requires many tries before the Uber- tooth is successful, if it is successful. The idea of the Bluetooth profile being customized is plausible due to the fact that the card reader is only, as far as our knowledge, connectable through the iZettle Go application. This means that the profile settings could be unkown for the Ubertooth to determine thus not recognizing the packets needed for Crackle.

Worth noting is that Ubertooth has other command and options to utilize such is interference- mode and promiscuous-mode which, in short, were unsuccessful against the card reader as the output generated from the Ubertooth were nonexistent. The reason behind this could follow the same reason why Ubertooth could not pick up vital packets for Crackle or that the reader has underlying technologies that complements its Bluetooth-module - making it more secure against interference.

5.1.3 Bettercap

Bettercap is described as a swiss army knife for both BLE and Wi-Fi. It is a tool used for hijacks and MITM attacks as well as reconnaissance. The aim is to analyze the card reader for its services and characteristics and exploit the read/write privileges of said services. It starts of by analyzing the Bluetooth network with the command ble.recon on which will passively scan the network for advertisements and save them.

FIGURE 22: Bettercap advertisement discovery

52

Security Test of iZettle's Reader 2: A card terminal for safe payments?

Security Test of iZettle's Reader 2

A card terminal for safe payments?

DARIA GALAL

MARTIN TILLBERG

Security Test of iZettle’s Reader 2

A card terminal for safe payments?

DARIA GALAL

MARTIN TILLBERG

Abstract

Sammanfattning

Preface

Contents

Acronyms

1 Introduction

1.1 Goals and objectives

1.2 Delimitations

2 Background

2.1 The card terminal

2.2 Previous work

2.3 Bluetooth Low Energy

2.4 Common attacks

3 Methodology

3.1 Threat modeling

3.2 Penetration testing

3.3 Evaluation and conclusion

4 Threat model

4.1 Identifying assets

4.2 Identifying threats

4.3 Rating threats

5 Penetration Testing

5.1 Man in the middle and replay of Bluetooth traffic