servicing a connected car service - diva portal829730/fulltext01.pdf · 2015-06-30 · servicing a...

Thesis no: MECS-2015-04

Servicing a Connected Car Service

Evaluating the Security of Connectivity

Benjamin SvenssonKristian Varnai

Faculty of Computing

Blekinge Institute of Technology

SE-371 79 Karlskrona Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in

partial ful�llment of the requirements for the degree of Master of Science in Computer Science.

The thesis is equivalent to 20 weeks of full-time studies.

Contact Information:Authors:Benjamin SvenssonE-mail: [email protected] VarnaiE-mail: [email protected]

External advisor:External company personnel

University advisor:Prof. Stefan AxelssonDept. Computer Science & Engineering

Faculty of Computing Internet : www.bth.seBlekinge Institute of Technology Phone : +46 455 38 50 00SE-371 79 Karlskrona, Sweden Fax : +46 455 38 50 57

Abstract

Increased wireless connectivity to vehicles invites both existing andnew digital methods of attack, requiring the high prioritisation of se-curity throughout the development of not just the vehicle, but also theservices provided for it. This report examines such a connected carservice used by thousands of customers every day and evaluates it froma security standpoint. The methods used for this evaluation includeboth direct testing of vulnerabilities, as well as the examination ofdesign choices made which more broadly a�ect the system as a whole.With the results are included suggestions for solutions where neces-sary, and in the conclusion, design pitfalls and general considerationsfor system development are discussed.

Keywords: Systems security, Network security, Distributed systemssecurity, Penetration testing.

i

List of Figures

2.1 Feature layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Request �owchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ii

List of Tables

2.1 User functionality table . . . . . . . . . . . . . . . . . . . . . . . 10

5.1 Test result table . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

iii

Contents

Abstract i

1 Introduction 11.1 De�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 52.1 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Users and Clients . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Client server . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.5 Vehicle Connection Gateway . . . . . . . . . . . . . . . . . 132.1.6 Telematic Control Unit . . . . . . . . . . . . . . . . . . . . 142.1.7 Third party components . . . . . . . . . . . . . . . . . . . 15

2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.1 Con�dentiality . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Problem description and problem statement 19

4 Method 204.1 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Organisations and Standards . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 ISO/IEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2 OWASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.3 SANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.2 Test procedure . . . . . . . . . . . . . . . . . . . . . . . . 25

iv

5 Result analysis 285.1 Brute force attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 System Structure Fingerprinting . . . . . . . . . . . . . . . . . . . 305.3 Session reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . 315.5 Cross-site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Discussion and conclusion 336.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1.1 Car worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.1.2 GSM Sni�ng . . . . . . . . . . . . . . . . . . . . . . . . . 37

References 38

v

Chapter 1

Introduction

The term telematics is used to describe integrated telecommunication devicesinside other technologies; it can be used to send, receive and store data to controlor gather information about remote devices. Mobile phones and GPS (GlobalPositioning System) devices are two examples using this technology; they receiveand transmit radio signals in order to function as expected, and without thetelematic unit inside they would be useless in terms of communication.

As vehicles today move farther away from the classic mechanical design ofold and into the digital domain of computers, they are out�tted with telematicunits which provide functionality similar to that of a smartphone. This changeintroduces the possibility of wireless connectivity to and from vehicles, somethingwhich has increased steadily to facilitate the ease of use and interaction for theuser.

Cars equipped with this technology can (amongst other things) be unlocked,located, or polled for the amount of petrol left, remotely via a mobile applicationfrom the manufacturer. Functionality such as this requires an intermediary, notjust to forward communication, but to keep crucial information such as user ac-counts, as well as providing assistance for its customers. These systems, togetherwith mobile phones and the cars themselves, provide us with many previouslynon-existent, remote points of attack. This newfound ability to target vehicleswithout the requirement of any physical interaction with them is a worrisomedevelopment.

The dangers faced are numerous and can target anything from the car, tosensitive information, as well as plain sabotage of regular use, be it a serviceor the vehicle itself. An attacker could potentially do anything a user might doremotely and more, whether that user be the owner of a car or an employee withadministrative privileges. The range of possible attacks include acquiring thelocation of and unlocking the vehicle, tracing of a vehicle's routes, impersonationof a vehicle, and acquiring or modifying your personal information.

Locating and unlocking the vehicle might not only result in a classic, physicalcar theft, but betrays your position. This could be devastating if the transporta-tion of important cargo is involved or in the extreme cases where kidnapping is arisk or a person's life may be in danger.

1

Chapter 1. Introduction 2

Similarly, tracing a vehicle's route may reveal sensitive information both aboutthe average citizen, as well as companies or law enforcement. Knowledge ofcommon routes, schedules and frequented locations can easily form the stepping-stone to more serious attacks or violations of privacy.

Impersonating a vehicle could cause much havoc and spread false information.Attention could be diverted from the real location of stolen vehicles; emergencyservices could be summoned needlessly, wasting their time and resources that maybe required elsewhere; and false proof could be created to substantiate claims ofa person's location.

The severity of attacks such as those mentioned shows that implementingproper security in these types of services is paramount. This report will examinean existing service and aims to show the possible vulnerabilities, what they maylead to if not �xed and what the current state and understanding of security is inthe companies that provide us with and maintain these systems. It aims to raiseawareness among the companies developing this technology and show them theimportance of a security focused approach.

The examination of the system in question will be limited to the intermediarycore service which supplies the communication between client and vehicle, andwill not look at the possible attacks on the clients or vehicles themselves. Mainfocus will be given to the web level security and the attacks it invites as this sideof the system is an open point of approach from the internet and is therefore themost easily accessible to anyone, with or without malicious intent.

Multiple standards and processes exist for the purpose of both examining andmaintaining the security of a system. This report will touch upon the ISO/IECstandard called Common Criteria [5], which is used throughout all stages of de-velopment to ensure security, and the process of examining the system will followa penetration testing ruleset written by SANS [31], which focuses exclusively ontesting the security of an existing system.

This report is separated into six parts, where chapter two presents the back-ground and will describe the general design of this particular service and givean in-depth explanation of each part of the system. Chapter three will give anexplanation of the problem and importance of the subject, followed by chapterfour, which will show the method used to investigate the problem described inchapter 3. In chapter �ve the results are presented, both successful and unsuc-cessful, together with their suggested solutions, while the last chapter discussessecurity concepts that do not �t in chapter �ve, and presents the conclusions andfuture work, the latter which consists of unproven theoretical attacks.

1.1 De�nitions

� Client - A smartphone or a web browser


� VIN - Vehicle Identi�cation Number

� VCG - Vehicle Connection Gateway

� TCU - Telematic Control Unit

� REST - Representational State Transfer

� RESTful - Web service implementing REST architecture

� API - Application Programming Interface

� SQL - Structured Query Language

� APN - Access Point Name

� ASN.1 - Abstract Syntax Notation One

� GSM - Global System for Mobile communication

� CSRF - Cross-Site Request Forgery

� XSS - Cross-Site Scripting

� Java EE - Java Enterprise Edition

� GPS - Global Positioning System

� MNO - Mobile Network Operator

� BA - Basic Authentication

� CC - Common Criteria

� ISO - International Organisation for Standardization

� IEC - International Electrotechnical Commission

1.2 Related work

The modernisation of cars with telematics is still at its infancy and the publicisedwork done is scarce. Focus has mostly centered around the reliability of in-vehicle networks, with less attention being paid to the security aspects thereof.Even when security has been given attention, little work has focused on remoteattacks or on the system as a whole, instead concentrating on the car itself andits internals.

Some of the issues with the internal security of vehicles was demonstratedby Dr. Charlie Miller and Chris Valasek [23], who through minimal physical


access were able to gain control over and monitor vital features in a vehicle, suchas the engine, brakes, and steering. Meanwhile, a similar degree of control waspresented by Stephen Checkoway et al. from the university of California, SanDiego together with Karl Koscher et al. from the University of Washington in anarticle describing the di�erent possible attack vectors, both physical and wireless[3].

Hendrik Schweppe and Yves Roudier proposed a security framework in [32];its intended purpose was to control the information sent across the network,however it was proven too slow for practical implementation in current vehicles.A similarly unimplemented security concept called Data Protection Frameworkwas devised by Sastry Duri et al. [7]. This solution would verify to the userand Telematic Service Provider the trustworthiness of the data to and from theTelematic Control Unit (TCU) and is meant to provide a measure against theexecution of malicious code.

While most work has centered around the technical aspects of the cars them-selves, Nitesh Dhanjani [6] touches upon the weaknesses of the systems that keepthese cars connected. Similarly to this paper, Dhanjani shifts focus to the impactan attacker might have without ever even interacting with the car itself, physi-cally or otherwise, as well as raising concern about the design of these systemsand awareness of their importance, which is easily lost when most think only ofthe car.

Chapter 2

Background

This chapter will describe the workings of a connected car service, starting witha summary of what such a service is, followed by an anonymised review of theparticular service on which this report is based. Due to the nature of this paper,the information presented here, while accurate, has been generalised (as requiredby a Non-Disclosure Agreement), so as not to reveal any information that mayallow for the identi�cation of the company in question.

A summary way to describe a connected car service is that it is a systemwhich leverages the power and capabilities of modern phones to provide a carowner with both easier and greater remote control of their own vehicle. A userof this type of service could, for instance, check how much petrol is left in theircar, or start the vehicle's engine, by simply choosing the option for it on theirsmartphone.

From the perspective of the average customer, this service can be seen dividedinto three main, clearly recognisable parts: the client, the car, and the interme-diary system. The client is for most customers simply a phone. While it could beanything capable of the required communication, such as an ordinary computerwith a web browser, the service is designed with a smartphone in mind for regularuse. To make use of this, a customer would download an application, providingthem with all the necessary interactions with their vehicle. The vehicle, whetherit is a regular car, a truck, or anything else similar, needs to be built speci�callyto support the target service. Lastly, the intermediary system acts as the gluewhich holds the service together. It is the part of the system through which allrequests have to go and it is responsible for processing them, authenticating users,storing and retrieving data, and much more.

The rest of this chapter will cover these parts in more depth, starting withan overview of the system as a whole and moving on to individual descriptionsof the various parts found within. Finally, a section can be found describing thesecurity of this system.

5

Chapter 2. Background 6

2.1 Design overview

Figure 2.1: Feature layout


Figure 2.2: Request �owchart


The model in �gure 2.1 shows a system with a core divided into three logicalparts: Client Server, Business and Vehicle Connection Gateway (VCG). Theseparts do not have to be separate; they can all be one single server, but they couldalso be divided across several ones. Their functionality can be summarised as:

� Client Server: Translates communication between clients and Business.

� Business: Processes the data sent and does the actual work such as authen-tication, updating a user account, database lookups, calculations, etc.

� Vehicle Connection Gateway: Is to the vehicle what the Client Server is tothe clients. It translates communication to and from Business.

A simpli�ed representation of a typical request to the car can be seen in �gure2.2. It shows the data �ow through the three main logical layers mentioned above,starting with a client sending a request to the client server. The server translatesthis into a format understood by the business layer, which in turn will attempt toauthenticate the user and if successful process the request. Once any necessarywork required for the request has been successfully executed, the business layerforwards the information to the VCG, which translates it yet again, locates thecorrect destination, and delivers the request.

2.1.1 Users and Clients

The groups required to initiate interaction with the vehicle are divided into usersand clients. While seemingly interchangeable, there is an important distinctionbetween these two classi�cations, which serves to separate software from the in-dividual using it.

A client is the software that is required to communicate with the system.Although this could be any software, or even hardware built speci�cally for thiscommunication, the system is built to be easily accessible and portable and thusmakes use of the structure of a web service. This results in two main clients forwhich the system is aimed at.

The �rst and foremost of these clients is the one which the system was designedto provide a service for: the smartphone. This takes the form of the applicationused on the phone to communicate with the vehicle and uses the standard secureprotocol of the web (HTTPS, see subsection 2.2.1), the same as a browser would.The other client of focus is the aforementioned browser, which thanks to the webbased design of the system can be any of the common browsers found on mostcomputers (e.g. Firefox, Opera, Safari, Internet Explorer, etc.). This client isused for the tasks not related to the application on the phone, mainly managinginformation and administration.

A user is the individual using the client and they are divided into two maincategories: customer and personnel. A customer is a user with an account for


their car service; they have no administrative access and may only change oruse the functionality tied to their own account, whether through a browser ora smartphone. Excepting those who fall into both main categories, a customerdoes not work for or with the company providing the services and has no internalaccess to the systems.

The category of personnel are those who work either for or with the provider ofthe car service and they can be further divided into two subcategories of internal orexternal personnel. Those in the external category have moderate administrativeprivileges to make changes to customer accounts, but they lack the privilege offull access to the services of other customers' cars. The part of the system theyhave access to is exposed to the outside world and can be accessed through theinternet.

The internal personnel work on site within the company and have full admin-istrative privileges, including those of the external personnel and more. They notonly have access to modifying customer accounts, but are also capable of sendingrequests for the car services of customer accounts. Their part of the system is,as the name of the group suggests, internal and cannot be accessed directly fromoutside the company.

The following table presents which functionalities the di�erent users have ac-cess to. The di�erence between a veri�ed and an unveri�ed customer with respectto a vehicle is that either they or the internal personnel have added a vehicle re-lation for it to the customer's account, but it has yet to be veri�ed.


Functionality Veri�edcustomer

Unveri�edcustomer

Externalpersonnel

Internalpersonnel

Manage account informa-tion

3 3 3 7

Delete vehicle relation 3 3 3 3

Lock/unlock doors 3 7 7 3

Start/stop engine 3 7 7 3

Get position of vehicle 3 3 7 3

Assistance call 3 3 7 7

Trip information 3 3 7 3

Get attributes 3 3 7 3

Enable/disable services 3 7 7 3

Activate/deactivate telem-atics unit

7 7 3 3

Manage a customer PINcode

7 7 3 3

Edit customer information 7 7 3 3

Table 2.1: User functionality table3 Included

7 Not included

Manage account information Changing password, email or personal infor-mation of an account.

Delete vehicle relation Removing the vehicle relation status of a vehicle froman account.

Lock/unlock doors Remotely locking or unlocking the doors of the vehicle.

Start/stop engine Remotely turning the vehicle's engine on or o�.

Get position of vehicle Receiving positional data from the vehicle.

Assistance call Noti�es the internal personnel to contact the rescue assistancewith positional data and send a rescue team to the given location.

Trip information Collecting information about trips, such as start or destina-tion coordinates, or mileage of all the trips made with the service.


Get attributes Get information about the vehicle, such as the engine code,VIN, gearbox code, fuel type, year model, vehicle type, supported services andregistration number.

Enable/disable services Turns the use of active services on or o�. Activeservices are those which make the car actively do something, such as locking orunlocking the door. Passive services which only fetch information or only a�ectyour account information are not a�ected.

Activate/deactivate telematics unit Manage if the service will be onlineand accessible to the customer or o�ine and inaccessible.

Manage a customer PIN code Send a new PIN code to the customer.

Edit customer information Change customer data, for example: address,�rst name, surname, phone number or email address.

2.1.2 Client server

The client server provides the �rst step in the process of successfully making arequest of the service. It can be thought of as a translator, ensuring that the twoparties that would otherwise be unable to communicate understand each other.In this instance the two parties are the client and the business layer of the service.

The client server is the part of the system which implements the RESTfulservice API, which is a service that makes use of the Representational StateTransfer (REST) architecture [8]. This architecture speci�es the foundationsof the Hypertext Transfer Protocol, which simply means that the client servermakes use of HTTP to communicate. This is a text based, thus human readable,protocol, which uses stateless messages (each is a self-contained unit, not part ofthose that precede or follow) divided into a target for the request or a status fora response, a header for metadata, and a message body for data to be sent [14].To determine what type of interaction should be done with a resource, it de�nesdi�erent methods. The two most common examples of these would be the GETmethod, which is designed for simply retrieving a resource, and POST, which isdesigned to also send data. HTTP is, however, not an inherently secure protocoland is therefore layered with SSL/TLS to result in what is known as HTTPS,further described in section 2.2.1.

Whenever a user wishes to make a request of the service, they establish aconnection through their client, which the client server accepts and prepares toaccept incoming information. The client will then proceed to send the informationin the proper format dictated by HTTP. The client server receives this informationbut does not actually perform any of the logical work asked by the request. It


will instead continue by ensuring the syntactical correctness of the HTTP used,followed by translating it to the format used by the business layer, in this case aJava object ready to be processed.

2.1.3 Business

Once the information of a request is in a format understood by the business layer,the processing of it begins. The business layer is the largest and most critical partof the system and does the logical work required to satisfy the requests of a user.

The �rst step in the process of ful�lling the request is to identify and authorisethe user if required. A very limited part of the service is available to users withouta need to identify themselves; these parts are either ones where you could notpossibly have been authenticated yet, such as the very �rst login, or those whereno sensitive or user speci�c information is exchanged, such as sending a pingrequest to verify the availability of the service. Every other part of the systemrequires the user to properly identify themself, which comes in two main formats,either simply an identi�er or a combination of an identi�er and a secret.

The type of authorisation used depends upon which part of the system is beingaccessed, whether it is the vehicle service or administration through a website.The most prevalent form is that of the combination of both an identi�er anda secret. This takes the shape of a username and password/PIN, where theusername acts as the identi�er and the password/PIN as the secret, and is usedthroughout communication with the vehicle from the mobile application, but alsofor the website login.

When used from the mobile application, a format known as Basic Authen-tication (BA) [13] is used, which requires the user information to be submittedin a format known as Base64 [12]. Although often mistaken for an encryption,Base64 is, in fact, simply an encoding scheme. This di�erence is crucial, due tothe fact that as an encoding, no security is provided and the user information,if acquired, could be easily decoded by anyone who can recognise it for what itis. The encoding is used merely to provide a transformation of the informationto a limited set of characters so that special characters speci�c to the HTTPsyntax can be present in the user information. An important note to take intoaccount about BA, which di�erentiates it from the other form of authenticationused within the system, is that it requires the user credentials to be sent everytime a request is made. This has certain security implications, the most obviousone being that any request captured by a malicious third party would give awayinformation that is critical to the user. For this reason, the use of BA is done inconjunction with HTTPS to provide it with the security that BA cannot. An-other security issue is that since it is not user friendly to prompt a user to submittheir information every time a request is made, the smartphone application hasto cache it for reuse. Exploring the problems of this is, however, outside the scopeof this report.


Authentication for the website utilises a di�erent method; instead of sendingthe identi�er and secret each time, it is only supplied at login and the businesslayer will create a session identi�er which it responds with. This identi�er isstored for an arbitrary amount of time by both the client and the business layerand is a shared secret between them, taking the role both of identi�er and secret.This method ensures that sensitive data such as the username and passwordcombination used by BA is not sent every time and is thus the preferred methodto use due to its damage mitigation in the event of a communication leak.

Once authentication has been successfully concluded, the business layer willbegin handling the request itself. It is at this stage that all of the logical workrequired will be executed, including veri�cation of the sent information to ensurethat it is in a correct format, e.g. dates, email addresses, maximum characterlengths, etc. With the exception of the VCG fetching the TCU information,all database communication, both third party and local, occurs in the businesslayer throughout its di�erent stages. Access to these databases might be requiredduring the processing of the request itself, whether to get information or writechanges to an account, but it is also required for accessing user information duringlogin or when the same has not been cached yet for BA.

In the common eventuality that a user sent a request targeting the vehicle, thenext step simply builds another request as appropriate, passes it on to the VCGand awaits a response where required. After all the necessary work is �nishedand any expected replies from the VCG have been received, the business layerconstructs its response to the client and hands it over to the client server fortranslation and �nal delivery.

2.1.4 Cloud

The cloud is a third party service for handling data storage, retrieval and vehicleconnections from the VCG. The retrieval and storage of data is simply done withthe use of a database; this is where user speci�c information is kept such as user-names, emails, vehicle relations and more. However, vehicle speci�c informationis kept in a separate local database outside the cloud.

Its other use mentioned above is that of handling vehicle connections, meaningthat it acts as a gateway for the data sent from the VCG when necessary. This isrequired when the VCG is communicating with a vehicle which is using a publicAPN (see section 2.1.6).

2.1.5 Vehicle Connection Gateway

The Vehicle Connection Gateway is responsible for handling the communicationbetween the business layer and the vehicle. When delivering a request, it �ndsthe necessary information to construct the message, decides on the proper route,encrypts it and sends it.


Though similar in functionality to the client server, one of the di�erences liesin the protocol used for the communication. Unlike its counterpart which trans-lates between Java objects and HTTP, the VCG has to translate between Javaobjects and Abstract Syntax Notation One (ASN.1) [35]. This notation is widelyused within telecommunication and is designed to ensure short yet hardware in-dependent messages, utilising a variety of encodings ranging from very short butneither very �exible nor human readable, to �exible and human readable, butbulky.

To be able to construct a proper message, the VCG will have to fetch thevehicle's information from a local database to acquire their shared encryptionkey, but also to determine where to send it. This is of importance not just for thepurpose of determining the destination, but also to establish the route to send it,whether that is directly to the vehicle's TCU or the cloud. For the reason for thisdi�erence, see section 2.1.6. The above mentioned encryption key is necessarybecause the message may not be sent without �rst being properly encrypted.For this purpose, the Advanced Encryption Standard (AES) algorithm is used inconjunction with Galois/Counter Mode (GCM) (for a more thorough description,see section 2.2.1).

Once the data has been properly translated, encrypted and the route decided,the message is sent on its way to �nally end up at the TCU of the vehicle. In theevent of receiving a message from the vehicle, the same process will, of course,take place in reverse and be passed on to the business layer.

2.1.6 Telematic Control Unit

The endpoint of a request is the Telematic Control Unit (TCU) located in thevehicle and available to those customers who ordered the service. As with regularmobile devices, the TCU uses a SIM card for its communication, each unit havinga phone number used to identify and reach them.

When a mobile device wishes to make a data connection, it connects to anAccess Point, with an Access Point Name (APN) as an address, which acts asa gateway between the mobile network and another, such as the internet. Bydefault the TCU is equipped with its own SIM card speci�cally con�gured tocommunicate with a private APN, which in turn speaks directly with the VCG.A customer may wish to use a SIM card of their own choosing to allow formaking phone calls directly from the car; however, since these cards lack thecustom information of those supplied, they will be unable to directly contact theprivate APN. Instead, the communication will go through a public APN, whichin turn has to �nd the VCG; for this, the Cloud will act as a public entrypointand forward the messages to the VCG, allowing for connections to be properlyestablished regardless of what type of SIM card is in use.


2.1.7 Third party components

With the Java programming language as its foundation, several third party com-ponents are used throughout the system. Centered mainly around HTTP servercapabilities, they provide developers with a �exible and easy to use environment,as well as readily available and tested functionality required by a web based ser-vice. A list of the various components follows, together with a brief description ofeach; due to the cloud being a third party service, details about their componentsare unknown and will not be mentioned here.

� Java Enterprise Edition: A platform from Oracle [1] which provides a JavaAPI and a Java runtime environment.

� JBoss: Now called WildFly, is a free and open source software applicationserver written in Java [37].

� Spring framework: An open source framework which core functions canbe used by any Java application and includes extensions for building webapplications on top of Java EE [20].

� Apache (mod_rewrite): As an HTTP server, the open source Apache HTTPserver project is used with the mod_rewrite module to provide URL rewrit-ing on the �y [19].

� Oracle Database: The type of database used within the internal network ofthe system [24].

2.2 Security

Within the industry of information security there exists a well known model whichdivides security into three main principles: Con�dentiality, Integrity and Avail-ability (CIA). This section will describe the security of the service by groupingthem in accordance with these aspects.

2.2.1 Con�dentiality

The principle of con�dentiality describes the concept of protecting sensitive datafrom being gathered, whether read or inferred, by a malicious source. This areacovers the most generally familiar aspects of information security, including au-thentication and encryption.

Although many di�erent methods for ensuring con�dentiality are used through-out the system, the most notable and recurring one is encryption. This includesnot just the generally known concept of encryption which can then be decryptedwith the right key, but also one way encryption, also known as hash functions,


which cannot be decrypted. The various encryption algorithms used are: Ad-vanced Encryption Standard (AES) [2], Transport Layer Security (TLS) [16] andSecure Hash Algorithm (SHA) [18].

TLS is an encryption protocol made use of during web communication toprovide a layer of security for the otherwise insecure HTTP, by the use of bothasymmetric and symmetric forms of cryptography. Asymmetric cryptographymeans that the key used to encrypt a message is not the same as that whichis used to decrypt it. This results in the ability to send what is known as apublic key to encrypt a message with without also giving out the key to retrievethe information, thus it is also known as public key cryptography and is used tosafely exchange the information necessary to produce the requisite session keys.These keys are in turn used for symmetric cryptography, which is the opposite ofasymmetric, meaning that the key used for encryption will be the same used fordecryption. Once generated, these keys are used for the rest of the session. TLSfurther uses what is known as an X.509 certi�cate [36] to ensure the authenticityand trustworthiness of the server; this is achieved through a system of establishedcerti�cate authorities, which are trusted third parties. Other security measuresincluded in the TLS protocol is the use of a Message Authentication Code, thepurpose of which is explained in further detail in section 2.2.2.

A version of AES implementing the Galois/Counter Mode (GCM) [17] is usedto secure the communication with the TCU. AES is a symmetric key (see previousparagraph) block cipher, which means that the content of a message will bedivided into groups of bits of a predetermined and �xed length, called blocks,which are then transformed with the help of the key into the encrypted message.A method is required to describe how to securely use these blocks repeatedly whenencrypting; this is what GCM is used for, and it is preferred to other solutionsdue to its power of e�ciency. Lastly, the issue of key exchange has to be dealtwith, but this is not a problem in this instance. The key used is stored uponmanufacturing the vehicle in both the vehicle, as well as in a database within theintermediary system of the service; this allows both parties to forgo the exchangeof keys, as it is already known, and in turn results in no risk being posed forleaking a key when establishing communication.

Complimenting the various forms of encryption is authorisation. As is com-monplace, every user has a personal account with an associated password to iden-tify them and keep those unauthorised from accessing their personal informationor use vehicle related services. Furthermore, two more forms of authorisation arerequired when attempting to tie a vehicle to an account. The �rst occurs at thepoint of adding the vehicle to an account, a customer doing so would require aPIN code in order to complete the process. The second form appears when ver-ifying such an addition, at which point physical access is required to the vehiclewhere user interaction is necessary to validate the request for veri�cation.

Further security aspects show themselves through the design and program-ming of the system. While well written code is always important, three general


practices can be highlighted. The one a�ecting most of the system is the choiceof language; being a very high level language means that Java gives no direct ac-cess to manipulating computer memory, which in turn provides a solid mitigationagainst memory based attacks such as bu�er over�ows [29]. The second practicepertains to databases and the handling of data from outside sources. Whenevera variable form of data is used in database communications, prepared statementsare used; these isolate the data from the rest of the request as a separate logicalunit, disallowing the manipulation of the request itself. Lastly, as has becomecommon practice, anytime a PIN code is required, a limit has been set to themaximum number of failed attempts allowed. Once reached, more attempts arenot allowed until the customer contacts the internal personnel to unlock whicheverservice was closed o�.

2.2.2 Integrity

Integrity is the principle encompassing the prevention of illicit or unwanted changes,whether purposeful or accidental, to existing data. Both authentication and en-cryption are revisited, albeit the latter playing a lesser role than within the prin-ciple of con�dentiality.

Although the very act of encrypting a message makes it extremely di�cult tomake modi�cations with precision which decrypted outcome can be foreseen, itdoes not help against changes being made or detected. Therefore, an additionalform of encryption is used within the TLS protocol mentioned prior. To verifythe integrity of a sent message a Message Authentication Code (MAC) [15] isused, which is a one way encryption similar to that of a hash function. It is ahighly unpredictable and volatile code generated based upon the sent message;due to these properties, any changes to the data will result in a radically di�erentMAC and indicate a tampering with the information. Once a message is received,the client server will generate its own MAC and compare it to the one which wasreceived. In the event that they di�er, the client server knows that the datacannot be trusted and will take appropriate action, most likely discarding it andattempting again.

Other parts found within the category of con�dentiality that have clear prop-erties pertaining to integrity are authorisation and the use of prepared statementsfor database communications involving user supplied data. Due to the servicesnot only giving access to reading data, but also occasionally the modi�cationthereof, proper authorisation also plays a critical role in ensuring proper dataintegrity. Similarly, improperly handled statements to a database could not justresult in arbitrary data being read, but also modi�cations being made. For amore thorough description of these see section 2.2.1.


2.2.3 Availability

The third and �nal principle, availability, describes the area of ensuring functionalservice with as little interruption as possible. While the prevention of purely soft-ware based tampering that could intervene with availability has to be addressed,this principle focuses heavily on the physical aspects of the system.

Due to the fact that security measures and code optimisations are limited intheir e�ectiveness, the raw power of hardware plays a highly important role andmust also be of su�cient standard. The machines running the service are hostedby a company with the capacity to handle emergencies such as blackouts, �re oreven �ooding with minimal e�ect on the system. The machines are located awayfrom ground �oor or basement levels in the event of �ood and have the abilityto be completely sealed, non-conductive �re suppression is used in the event of�re and a backup power source exists in case of a blackout. In addition to thesafety precautions given, the physical machines are located in several di�erentdata centers to ensure availability in the event that an issue would arise whereany of these would fail.

Load balancing is used to mitigate large quantities of incoming data, separat-ing it to lighten the load that would occur in the event of only one route beingavailable for connections. Furthermore, the distribution of the server over severalmachines allows for several requests to be handled at once and lessens the amountof work any one machine would otherwise have to do, providing high availabilityfor the users and mitigating the impact of potential Denial of Service attacks [22].

Mitigations within the software includes another revisit to concepts discussedin section 2.2.1 (con�dentiality), namely the choice of language and preparedstatements. Both of these help prevent the execution of arbitrary code, whetherthat be machine code, which are instructions executed directly by a computer'scentral processing unit, or Structured Query Language (SQL) [11], a languageused for managing data in databases. Were an attacker able to execute codehowever they wish, they could erase not only data, but possibly also the systemitself. However, even in such an eventuality, regular backups of the databases arecreated, from which data can be restored, minimising the e�ect that the removalof database tables (or even the system itself) could have.

Lastly, the possible issues that could be caused by software that is still beingdeveloped, as well as that being tested, are taken into consideration. A sepa-rate environment for conducting tests exists to leave the live services that arein use una�ected in the event that testing would cause crashes or other systemmalfunctions.

Chapter 3

Problem description and problemstatement

This report aims to examine the state of and practices within a typical connectedcar service from a security perspective. As connected cars become increasinglypopular and widespread, so does the interest in exploiting them grow, warrantingconsideration and investigation of the current risks, vulnerabilities and the e�ortsimplemented to mitigate these. Making the service, and by extent the customers'vehicles, accessible from both the internet and the common mobile device foundin most homes, exposes both companies and consumers to a whole new world ofpotential attacks.

While the vehicles themselves are the most immediately obvious candidatesfor attack, other major targets emerge with this new interconnectedness. One ofthese is the system tying the service together, providing attackers with not onlynew targets, but also types of access never before encountered in conjunction withvehicles. The systems behind such a service give attackers a centralised point ofinformation and control, which when compromised could endanger many or allusers and allow the targeting of personnel with administrative rights, presentingan issue past the compromise of a single vehicle.

The newly opened points of attack are of major concern not merely for addinga hitherto nonexistent amount of risk, but also because of the potential lack ofthe necessary expertise required to deal with such mediums in a safe manner.Companies that are used to mainly developing machinery may struggle to �ndproper footing in the areas that are new to them. The very fact that this type ofservice is still in its infancy carries the inherent risk of major issues arising, bothfrom a security perspective and otherwise. Furthermore, the pressure to developnew functionality instead of perfecting and securing that which exists is an everpresent issue that is even stronger when something is still new.

19

Chapter 4

Method

This chapter is presented in two parts, beginning with a listing and explanationof some of the main standards and guides for approaching a security evaluationof a technical system. This is followed by a description of the methodology andapproach used when evaluating the security status of the connected car servicein this report.

4.1 Case Study

A case study is de�ned by M. Berndtsson et. al. [21] as an in-depth explorationof a phenomenon in a natural setting. It can be a study of an animal in itsnatural environment, as well as a system in its working environment that a studyaims to explain and understand. This work considers the case of a connected carservice and aims to understand the existing vulnerabilities in the named systemby studying the environment, features and included technologies that are behindthe expected functionalities.

4.2 Organisations and Standards

For the purpose of ensuring the validity of a security evaluation, standards orother guidelines, issued and maintained by trusted organisations, can be fol-lowed. There are four organisations considered in this report. These are theInternational Organisation for Standardization (ISO) and the International Elec-trotechnical Commission (IEC), which issue global standard documents; the OpenWeb Application Security Project (OWASP), which focuses on improving securitywithin software; and SANS Institute, a global security research and educationalorganisation.

4.2.1 ISO/IEC

A technical standard establishes a formal approach or set of rules for processes,methods or technical criteria of a speci�c area. Responsible for the creation and

20

Chapter 4. Method 21

maintenance of these standards are speci�c standards organisations, of whichthere are many di�erent kinds, both national and international. As implied bythe names, the scope and limitations of the former is the issuing of standardswhich might be speci�c to the nation they are operating from, but not globally;contrarily, organisations such as ISO [9] and the IEC [4], which are composed ofrepresentatives from several national organisations, de�ne standard documentsto be adopted internationally. While the IEC issues standards regarding elec-trotechnology, ISO publishes industrial and commercial standards. For standardsfalling within the areas of both of these organisations, a joint committee betweenthem called ISO/IEC was established.

A well known standard published by the ISO/IEC committee is ISO/IEC15408, also known as Common Criteria (CC) [5], which was developed for per-forming thorough security evaluations of an IT system already in use or underdevelopment. Topics covered within are the design process, development method,vulnerability handling, testing, etc. Whenever the possibility exists, it is goodfor a business to adopt a global security standard, such as the mentioned CC;this provides the customer with an assurance that the product or service's secu-rity features have been implemented and tested in accordance with a strict andwell de�ned global ruleset. Furthermore, it also gives developers, both experi-enced and inexperienced alike, a starting point, as well as a solid foundation fordevelopment with security in mind [10].

4.2.2 OWASP

Despite not creating o�cial standards, OWASP [26] is a well respected and knownorganisation with the focus to further security within computing, specialisingmainly within web applications. This group created both the OWASP DevGuide[28] and the OWASP Top Ten [27]. Their DevGuide was created as a rulesetproviding a tool for the development of web applications, with a focus on security.Meanwhile, their Top Ten project documents the ten most commonly found webbased vulnerabilities, as well as provides a detailed description of the problemtogether with potential approaches to �xing them.

4.2.3 SANS

To evaluate the security of an existing system, a penetration test can be per-formed, whereby trusted computer security professionals act as attackers andattempt to �nd vulnerabilities. Once the attacks have been carried out, the re-sults are documented and presented. This allows companies to test how well theirsystems would stand against an attack without exposing them to the danger ofpurposeful sabotage, and any resulting vulnerabilities can thereafter be corrected.A description of this process is outlined in detail by SANS, a well known institutefor research and education focusing on security [31].


4.3 Approach

Due to the sizable nature of the system, the thorough standard of CommonCriteria is the most recommended to follow for the evaluation of security. Itwould cover many aspects of the service and development, which other methods,such as DevGuide or a penetration test, would not touch upon. However, due tothe scope of this report being limited to only a part of an already existing systemand not other aspects surrounding it (e.g. testing or development), as well aslimited time and resources, penetration testing will serve as the main foundationin accordance with the SANS guidelines.

As de�ned by SANS, the initial step of a penetration test on an organisationconsists of a meeting with the purpose of establishing the foundation for thetesting to come. It is important to note that this meeting is not meant to coverevery detail of the upcoming testing, as the model described by SANS is of a�exible nature, allowing things to be changed as need arises. The base topics itaims to resolve are: scope, resources, objectives, involved parties, duration andde�ning the required legal documents protecting both parties involved.

In accordance with the �rst step, the previous points were de�ned in a seriesof short meetings with a representative of the company in question, as well asnecessary contacts being established for future inquiries. The scope when work-ing with a connected car service could at its broadest encompass three majorparts: the vehicle, the client device, and the intermediary system. This was,however, narrowed down to not include the end devices (client and vehicle) dueto various restrictions, the most prominent one being that it would be infeasibleto tackle all three of the major components of the system in the allotted time ofsix weeks. Other reasons for this decision includes the lack of vehicles availablefor testing, as well as the variable nature of the client devices. What this meansis that client devices are not part of the system, only the software on them wouldbe, thus working on them would shift the focus away from the service itself; e.g.�nding vulnerabilities in a phone that might in turn lead to issues for the servicewould focus on the phone, not the service itself. The decision of the scope hav-ing been made, allowed for speci�cation of the necessary resources to be madeavailable. The main concern to be solved was how to allow testing without ad-versely a�ecting the system; for this purpose, an already available environmentcreated speci�cally for the purpose of testing and made to mimic the live system,was made available. Other resources granted to facilitate testing were: the fullsource code of the system, documentation, necessary user accounts, and companylaptops with any software required for secure communication with the system.

Following the meeting, the actual process of �nding vulnerabilities in the sys-tem will begin. SANS divides this into three key steps: information gatheringand analysis, vulnerability detection, and penetration attempt. Due to the read-ily available source code, documentation and contacts, the process of gatheringinformation was not a hindrance and traditional exploratory attempts on the


system could be kept to a minimum. In addition, the limitation of the scopeto the intermediary web service meant a solid foundation of potential commonweaknesses could be used. These circumstances gave rise to a mixture of bothknown, common security issues, and a code audit being used to populate the listof test cases seen below in section 4.3.1. This list includes items from the OWASPTop Ten and potential issues found when analysing the source code. During thisaudit, the �rst step was to �nd the points of entry for the information sent to theservice and to then proceed with following how this user supplied information wasprocessed, expanding the list of test cases with any peculiarity found. A �exibleapproach of the steps presented by SANS allowed for such additions to the listeven after other points had already been resolved, resulting in testing tailoredclosely for the system.

4.3.1 Test cases

Following is the list of attacks that were tested, giving both names and a descrip-tion of what each exploit encompasses. For a summary of how vulnerability foreach attack was determined, see section 4.3.2 below.

Brute Force By locating the �elds taking a secret, for example a PIN code ora password, as an input, an attempt of providing the �eld with all of the di�erentcombinations can be made. This attack can be very time consuming dependingon the number of characters used for the secret, and as such, the areas takinga PIN code became the main focus due to the limitations of a PIN's structure,which is often very short and contains only numerical characters.

SQL Injection If a user can supply data for an SQL query, such as whenentering their username, and the supplied data is improperly handled, it couldinterfere with the language used to communicate with the database. An attackercould use this to craft valid SQL statements for their own purposes to be executedby the database; this could potentially be anything from simply fetching data, tocreation or modi�cation of information, or the erasure of the entire database.

SQL Wildcards An SQL wildcard is a single character which during text com-parison tells the comparison function to accept one, or possibly more, charactersregardless of what they are. In certain circumstances this could be exploited byan attacker if wildcard characters in user supplied text strings are not properly es-caped. If wildcards are allowed when matching a username to those in a databaseduring login, it would allow an attacker to tell the system to accept any username,e�ectively only matching secrets and granting access to an account where a matchoccurs. This would mean that as long as a secret exists, an attacker would beable to access the account of a user which uses that secret.


Email Header Injection If user supplied emails are not properly �ltered todisallow characters, such as those creating new lines, this could be exploited toinject valid meta information used by the mail protocol, to manipulate the �owof communication according to an attacker's needs.

System Structure Fingerprinting If an attacker can determine the speci�csoftware, and in the worst case scenario even the version which is in use, it canbe used to �nd known vulnerabilities speci�c to that software.

Session Reuse When communicating with a web service, a token is often usedto identify a speci�c user, this helps in avoiding the need for authentication withevery user speci�c request to the service. Loose or nonexistent restrictions regard-ing the use of these tokens, such as simply accepting them as is for identi�cation,means that if an attacker manages to acquire such a token they could start usingit themselves and thus identify as an authenticated user, with all the privilegesthis entails.

Cross-Site Scripting Any user supplied data that may at some point beviewed through a web browser has to properly take into account the possibleoccurrence of metacharacters which a browser uses in its syntax and either re-move or escape them in some way. Failure to do so would mean that a malicioususer could supply data that is valid code for a browser to interpret, causing it toexecute upon viewing.

EL Injection Certain versions of the Spring Framework [20] allowed for Expres-sion Language [25] (EL) code to be interpreted twice when a �rst interpretationreturned valid EL code. If this is allowed, an attacker could supply their owncode and have it execute when the server is attempting to produce the webpage.

Account Overwriting A rare set of circumstances could allow for existingaccount information to be overwritten. This would require either no checking tobe done for existing accounts with the supplied name upon account creation, orfor the string matching to not recognise a match which the database recognisesupon inserting the new data. Furthermore, it would need the database to be setto overwrite when encountering an existing account name. As mentioned, thesecircumstances are very rare, but if present would allow for an attacker to overwritean existing account, but keep all other data associated with it, e�ectively gainingaccess to things such as the vehicles bound to it.

Cross-Site Request Forgery Whenever a browser attempts communicationwith a web service, any existing session identi�ers will be used. This fact canbe used by an attacker to force a victim's browser to request a certain resource


from a web service. If this resource is requested, whether or not the results willbe visible, the actual logical work expected by the server for this resource will bedone. If the victim has already authenticated themself to this web service, therequested action will be exectued as if they had done it. This can be used by anattacker to make a user do things without their knowledge, and does not evenrequire a direct vulnerability on the target service, as any third party websitecould ask a browser to request a certain resource over the internet.

Session Activation An attacker can set an inactive session token in a urlreferenced to a user, targeting a resource on a web service which requires authen-tication. When the user makes a successful login, the inactive token will becomeactive and since the attacker set it to begin with, they know its details and cannow use it to identify themselves as the authenticated user, provided that thesession reuse vulnerability is also present.

Improper Session Destruction If a session is not properly terminated, it willstill be valid after the user logs out. By acquiring the token for the session, itcan be reused by another user without the need to login, despite the original userhaving requested a termination of the session.

4.3.2 Test procedure

Because issues found during code analysis also fell into the category of vulnera-bility detection, and vulnerability detection through testing most often equaleda penetration attempt, there was a consistent overlap between the stages de-scribed in SANS [31], leaving no clear division of the steps. The following listexplains how the previously mentioned test cases were tested or examined, wherethe availability of source code occasionally resulted in little to no testing beingrequired.

Brute force This was tested by reviewing areas in the source code regardinglogin or other authentication attempts, checking whether or not the number oflogin attempts is below a preset number. Main focus on PIN codes due to thelimitations of their structure.

SQL Injection Checking the source code for database lookups connected withthe user interfaces. Identifying how the developers manage database queries andif a user's input is �ltered successfully to prevent SQL injections.

SQL Wildcards Examining the source code for proper SQL wildcard usage orescaping. It was further tested by using SQL Wildcards to attempt logins.


Email Header Injection The source code was consulted for any �ltering ofemails. Any �lters found were replicated and tested for their extensiveness.

System Structure Fingerprinting Observing server responses to various re-quests helps determine both software and structure of the client server.

Session Reuse To check if a valid cookie could be reused without restriction asuccessful login was made and the cookie shared to be used on another computer.A minimum di�erence of di�ering outward IP addresses for the two computersis required. To ensure a maximum diversity of the connections, the two separatemachines were located on di�erent networks, had di�erent operating systems andused di�erent browsers. In the event that the second user, through the use of theshared cookie, is considered logged in as the user which the �rst user authenticatedas, the test is considered successful.

Cross-Site Scripting Valid JavaScript code was used for user supplied infor-mation where possible. If at any point a page containing this information executesthe code, the test is successful.

EL Injection Testing is essentially the same as that done for Cross-site script-ing (XSS) but instead uses valid jsp code. If the information when accessed atany point displays the interpreted results of the code instead of the code itself, itis considered successful.

Account Overwriting Improper handling of upper- and lowercase letters inthe user's identi�cation (email) when comparing for existing accounts may inconjunction with improper table settings in the database result in existing accountinformation being overwritten with that of an attacker's choice. Using an emailidentical to an existing one except for the cases of the letters and not receiving anerror for the account already existing would be considered potentially dangerous,but the test would not yet be deemed successful. If this occurs and a valid setup isdone, changing the existing account information, the test is considered successful.

Cross-Site Request Forgery A local page unrelated to the service is createdwhich will connect to a resource that will execute something noticeable (such aslogout or disconnecting a car from an account). A user performs a successful loginthrough a browser and then with the use of the same browser accesses the testingpage. If the request is successfully executed and the e�ects from the request canbe seen, the test is successful.


Session Activation The service which uses sessions is contacted through aURL with a nonexistent session cookie already set at the end by the attacker. Asuccessful login is made from that page and if the attacker using the same sessionidenti�er as previously supplied in the URL is considered logged in, the test issuccessful.

Improper Session Destruction An active session cookie is copied, and af-terwards the user logs out. If the use of the cookie afterwards will still show theuser as logged in, the test is successful.

SANS describes two additional steps for penetration testing once the testing it-self is �nished. These steps are called analysis and reporting, and cleaning up.Analysis and reporting for this report takes place in the chapter Result analy-sis, where the outcome of the tests are documented and described together withsuggestions on how to mitigate any found vulnerabilities, as well as the chapterDiscussion and conclusions, where additional security concerns not �tting the listare voiced, together with a more in depth discussion. The step of cleaning upconcerns the removal of any unwanted changes made during testing. Due to atesting environment separate from the live system having been used, combinedwith careful and precise testing, clean up consisted of no more than the removalof super�uous accounts.

Chapter 5

Result analysis

The security concerns and possible solutions thereof are described in this chapter.Table 5.1 will provide an overview of the vulnerabilities outlined in the previoussection (refer to section 4.3.1) and their respective results, followed by a morein-depth description providing potential solutions where deemed necessary.

28

Chapter 5. Result analysis 29

Name Result CommentBruteforce* 3 -SQL Injection 7 Consistent use of prepared

statements.SQL Wildcards 7 Use of the = operator with

proper escaping.Email HeaderInjection

7 Regex properly prevents un-wanted values.

System Struc-ture Finger-printing

3 Can map application andweb server software (typeand version).

Session Reuse 3 The external personnel plat-form was found to haveno mitigation against stolencookies whatsoever.

XSS 3 In the external personnelplatform the name and sur-name �elds are output with-out any escaping performedon the data.

EL Injection 7 -Account Over-writing

7 -

CSRF 3 Main risk exists in the ser-vices designed to be accessedthrough a browser (exter-nal personnel services); ser-vices designed to be accessedthrough a mobile device areunlikely as a viable target,but not impossible.

Session Activa-tion

7 -

Improper Ses-sion Destruction

7 -

Table 5.1: Test result table3 Success

7 Failure

* See appropriate section below for further details about result.


5.1 Brute force attack

When attempting to add a vehicle relation to an account, previous attempts werenot taken into consideration. Since only a PIN code with four digits is requiredfor authentication when creating an unveri�ed relation, it was highly reasonableto traverse the entire sample space due to its limited size of only 104 = 10000combinations and establish such a relation. This would result in access to all thefunctionalities available to an unveri�ed user, such as gathering positional dataand trip information.

It is always recommended to limit the number of attempts a user can makefor establishing veri�cation; this can be done through the simple act of trackingthe number of failed attempts that have been made. While the issue describeddid exist when testing, by the time of writing it had been �xed with the describedmethod and is no longer an issue.

5.2 System Structure Fingerprinting

When attacking a system, it is always good to know what it is made of and whatthe structure is. In the case of this system, obtaining information about it is notdi�cult. Most software will by default reveal what and which version it is whenestablishing communications, most often within the headers being sent, wherethe metadata belongs. Software such as JBoss is not only recognisable by its verydistinct style for its default and error pages, but also proudly displays its nameon the pages themselves. Even the structure of the servers used could, in thiscase, be established due to Apache's rewrite rules disallowing certain requestsaccess completely. Subtle modi�cations of the requested path would thus revealthe existence of an Apache server between the client and the client server, due totheir distinct and di�ering error pages.

Minimising information leakage is a di�cult matter to combat. Sometimesit is not even possible, when software has speci�c issues that cannot simply bechanged in con�guration �les. Most software, however, can be con�gured toreveal as little as possible about itself. Doing so will mitigate the easiest way to�ngerprint a system. An easily missed, and also di�cult, thing to do is to unifythe way the system as a whole reacts to errors. Since even just one software mightreact very di�erently to di�erent types of errors, this is not an easy task, and itis why �ngerprinting a system through causing errors often works very well, asan error page that was forgotten might reveal sensitive information.

Unfortunately, no exhaustive, general guide to the prevention of system �nger-printing can be presented, as it is highly dependent on the software in question.Header and error information are merely the most common ways of accomplishingit, but anything that is unique to a system, or unique enough to narrow it down,can be used.


5.3 Session reuse

When a web service establishes a session, it uses what's known as a cookie asa unique identi�er. Without the proper additional restrictions in place, thesecookies, if obtained by some means, can be used to impersonate the user whoestablished the session. For the purposes of session hijacking, how a cookie isobtained is irrelevant as there are numerous ways to do this; the only thing thatmatters is mitigation of how freely a cookie can be used if an attacker acquires it.While being recognised as the originally authenticated user, the attacker has thesame rights as said user and can thus perform the same actions (assuming that noadditional authentication for said actions is required). Depending on the user'sprivilege, for example if the compromised user is an administrator, an attackerwill be able to perform actions with very loose restrictions.

Protection against session hijacking can be done through saving data aboutthe user when the �rst login takes place. The main candidates for importantdata to be saved are the user agent, the user IP or both. Subsequent attemptsto use the service would compare the information to that which has been savedand if they do not match, action may be taken as deemed necessary, most likelyinvolving the treatment of the query as if an unveri�ed user (one which has notyet completed a successful login) had attempted it.

5.4 Cross-Site Request Forgery

When a browser requests a web service, it will use the cookies tied to that websiteif any are present; when a server receives a request for a resource, the actions tiedto that resource will be executed, whether the results are seen by the user or not.CSRF is not a direct attack as most others are, but instead uses this functionalityas it is meant to be used and relies on the lack of additional veri�cation from theserver when an action is requested (such as logout, disconnecting a car from anaccount, changing information, etc.). This means that without extra veri�cationof the source by the server, any third party site could contain a URL for thebrowser to fetch, directed at whatever action an attacker wishes to take and it willbe successfully executed as if the authenticated user had done so. The potentialconsequences from this attack are essentially identical to those of session hijacking(see 5.3), the main di�erence being the di�culty of the attack and the fact thatsince the requests involved come from the victim's client, tracking a source afterthe fact is much more di�cult.

To prevent CSRF a token will have to be sent in addition to the cookie,embedded directly into the page source as a value to be sent when requestingan action. The same token will be saved on the server and is used to verify anyaction taken since only cookie information is automatically tied to a website andsent upon every request, meaning that a third party cannot supply an unknown


value embedded directly into the source of the page sent. This token can begenerated at the start of session and reused throughout, which retains �exibility;alternatively, it can be recreated for every page request, making the web site farstricter and more secure, but restricts it to linear and in�exible use.

5.5 Cross-site Scripting

Whenever user supplied data is presented on a page, care has to be taken thatit does not interfere with what a browser can interpret as directions. Since abrowser relies entirely on interpreting text without clear separation of instruc-tions and data, an attacker can supply language speci�c syntax which a browserwill interpret and execute. If the attacker can supply valid data for a scriptinglanguage capable of advanced features, such as JavaScript, major security issuescan arise. These issues can be numerous, but most commonly belong to thecategories of content modi�cation, general annoying behaviour for the user, andstealing a user's cookies, potentially giving them access to the user's session andany other information that may have been contained therein.

Prevention of cross-site scripting is a simple case of encoding characters whichmake up the core part of syntax understood by the browser. Proper encodingchanges these characters into a format which the browser will recognise and whichtells it to output the represented characters; these formats come in two variantsand are known as numeric character reference or character entity reference. Thejsp used in this service already provides built-in support for this in its standardoutput tag, which is heavily used throughout the vast majority of the code.

Chapter 6

Discussion and conclusion

The previous two sections presented a list of potential security issues in a systemsuch as this; furthermore, it was shown that some of these issues were presentin the system at hand. A few of these vulnerabilities were even commonplaceenough to be found in the OWASP Top Ten. There is, however, more to thesecurity of a system than merely ticking o� a list of attacks that can be tested;whether it is a missing feature or an unfortunate choice of the system's design, ifit impacts the security, it has to be scrutinised and discussed.

When creating a system, the use of third party software is expected during theprocess. In all but the most extreme cases, it would be unreasonable to expect thedevelopment of core, underlying parts such as the operating system, a compileror an interpreter, and to some extent, a server. While the creation of custombuilt server software is a perfectly valid option in the case of a system such asthis, a third party supplying other components will lighten the workload andease the process of development. Certainly, existing software might already havethe capabilities required and would lessen the amount of work the programmershave to do to implement any one feature. This is the positive side of third partycomponents.

Unfortunately, there is also a negative side to it. This system uses not one,but two di�erent servers; the core language is extended with the use of a di�erentplatform than the standard, and a framework is used, as well as other minor thirdparty additions. This presents an issue not just from a development standpoint,but also maintenance.

Development involving this many additional third party components adds anunnecessary learning curve for every programmer, as they have to wrestle withthe functionalities provided by all the additional software. In addition, this meansless control over what can be crucial parts of the system when third party softwareis relied on to handle them in their entirety. If these parts are security heavy, suchas authentication, it can be very problematic not to know what exactly happensin the background. Furthermore, the fact that third party software is more oftenthan not meant to be reusable across many systems, means that it has to begeneric and bloated as it has to accommodate for many scenarios.

This leads to the most important part about the use of third party software:

33

Chapter 6. Discussion and conclusion 34

every third party component added means one more part that can cause issuesand contain security bugs to be exploited. When a third party is relied on tohandle a part of the system, they are also relied on to take care of the security ofit, leaving the developer with little to no control over what is a very importantaspect. Additionally, this also means that more software has to be kept up todate, some of which might end up incompatible with other parts of the systemthat cannot be updated, or they might require additional third party components,which in turn come with the same issues. This can lead to a partially or entirelyout of date system with third party security issues that cannot be �xed by thedevelopers, and cannot be patched due to other components disallowing such.

Overuse of third party software can largely be mitigated by two things: a solidand well understood initial design of the system, as well as picking a languageappropriate for it. Although tempting to simply decide on the language whichmost know or like the best, or the most popular one, these are not valid ways togo about the issue. No one language can do everything and the lead programmersmust have a healthy knowledge of several programming languages and the abilityto identify the candidates which �t the needs of the project the best. A languagemore closely tailored to the problems present and the design of the system willcut down on the amount of third party elements required, leading to a smallerrisk of third party security issues being introduced, as well as easier maintenance.It could further improve a project by providing an easier and more intuitivestructure to work with, as well as an increase in the system's performance.

Picking the optimal language is, unfortunately, not always a possibility. Whetherit is because of a lack of expertise or a poor grasp on the design, the choice couldend up being suboptimal for the system's requirements. Not having people withthe required knowledge of the optimal language to be relied on for programming,is a very real eventuality; in such a case, there is not much that can be done andthe project becomes crippled before any code has been written. This is the worstcase of the two scenarios, as a misunderstanding of what is required when design-ing the system could, with some luck, be caught early on and recti�ed before theproject moves too far.

Whether an optimal language has been chosen or not, when using third partysoftware, each foreign component must be handled in a security conscious man-ner. Before a component can even be decided on to be incorporated into thesystem, two important steps have to be passed. Firstly, the security standardsand practices used in the development of the software have to be scrutinised andapproved, wherein they have to live up to those existent in the project they willbe a part of. Unfortunately, this might not even be accessible if the third partycomponent is proprietary software, resulting either in having to not use it or do-ing a leap of faith, depending on how vital it would be to use the componentin question. Secondly, the third party software has to either be in development,or at the very least still be maintained. Only in very select, rare occasions canabandoned software still be relied on to supply the needs of a project.


Once the screening process of a third party component is over and it hasproperly ful�lled them, continuous maintenance is required. A minimal level ofinvestment into the development of the component has to be made, at the veryleast so far as to keep up to date on the reported bugs, �xes and changes. Howthis is achieved varies between products and depends on what the developers havegiven access to. Popular avenues of access are often given in the form of mailinglists, bug trackers or forums. These, together with third party sites that tracksecurity vulnerabilities of various softwares have to be monitored for anythingimportant that could impact one's own project.

Lastly, updates of third party components have to be handled properly as well.Every update requires the system to be tested anew. This either results in everytest having to be run on the entire system, or requires additional maintenance inthe form of tracking the points of use of the third party software to allow for onlythe a�ected parts of the system to be tested.

All of the aforementioned steps have to be done for every third party compo-nent included if it is to be considered securely handled. This results in a lot ofadded maintenance, and is another reason as to why one wishes to establish anappropriate language for the system, and why a good design and understandingthereof is important.

As previously mentioned, a good design of the system is highly importantand lacking in this aspect can a�ect the system in several ways. Sometimes it isthe simple act of overlooking an optional, but welcome, security feature. Whileinvestigating the service used as the basis for this paper, one such missing fea-ture became apparent; namely the fact that there is no linking of a device to anaccount, and consequently no necessity to verify a device at �rst time use. When-ever a user's �rst attempt at a login is made on a particular installation of thedigital distribution platform Steam's [33] client software, additional veri�cationis required. This veri�es the installation as a trusted source for the individualto login from and adds it to a whitelist. A similar procedure should exist tomitigate the damage in the event of stolen account information by limiting use ofthe service to devices veri�ed by the user. One way to perform this veri�cationwould be to require the use of the customer's PIN code upon �rst time use ofan application, verifying it for their account for future use. This would be ane�ective, yet user friendly implementation, but is sadly not in use.

At other times the design issues might lie in the lack of knowledge about howa particular service ought to work, which can manifest in performance issues, butalso interesting security problems. These types of design �aws are much moreserious and if not found early, might result in a lot of wasted time and e�ortas large chunks of the system have to be rewritten. One such �aw was foundin the platform for external personnel; this design �aw does not pose a directrisk to security from outside attackers, but instead puts the system at risk fromunintended consequences from regular user interaction.

The issue itself stems from treating a web service the same way as one would a


standalone application where one has strict control of the �ow of the program andthe order in which user actions can be taken. In this service the system would savethe latest choices of a user and when an action related to such a choice was made,it would simply assume that this last choice is the one to pair with the action.To clarify with an example: when a pro�le is visited for editing, this choice issaved; when data is subsequently edited and saved, it is assumed that it is thedata of the last visited pro�le. This could cause serious issues if another pro�leis visited for editing in-between, as it would assume that changes are to be madefor this last visited pro�le, while to the end user it appears as if changes are beingmade to the former. While this design �aw is, as previously mentioned, an issuewhich would most likely result in non-malicious consequences, it is nonethelessa security problem. Although exploiting such a bug would be di�cult, it is notoutside of the realm of possibility through the use of social engineering.

The concept of social engineering is for an attacker to make a target do some-thing according to the attacker's wishes through social interaction alone; in short,it is the manipulation of others. Unfortunately, this is very di�cult to protectagainst, as it not only exploits our regular behaviour as people, but can alsotarget customers, thus making strict company policies useless in the latter case.The area of social engineering is enormous and outside the scope of this paper;however, it is worthwhile to bring some attention to it, as it is a method of attackworth being aware of.

An example where social engineering poses a problem is within the identi�ca-tion to the customer service. By only using a four digit PIN code to identify asthe car owner it reduces the amount of information needed by an attacker to askthe customer service to perform remote actions on a vehicle. Two possible solu-tions are presented for this problem, each with its own trade-o�s in security andusability. The �rst approach to solving this is to use multi factor authenticationwhich include two or more factors of authentication, for example requiring thecustomer to answer a secret question in addition to the PIN code. The secondway of dealing with it is to remove the possibility for the customer service per-sonnel to perform remote actions towards a vehicle. The initial solution retainsthe service of remote actions, however by adding additional factors for authenti-cation, a customer may �nd the process overly long and unwieldy. Furthermore,the factors either end up being complicated, which may make the process of iden-ti�cation more di�cult for the customer, or they will use easy to remember data,such as personal information, which in turn can be more easy to guess or obtainby an attacker. However, as this solution adds more complexity for the customer,the most preferable choice of the two would be to remove the service completely.While it is de�nitely an extreme approach, the removal will not only be a solutionto reducing possible attack vectors, but also reduces the amount of work requiredfrom the developers and customer service personnel to maintain the service.

This example serves to show the di�culty in handling the issues that socialengineering poses. Solutions often become di�cult to enforce, unreliable or sub-


optimal. While the problems posed by social engineering are certainly of concernand issues such as the one given in the example should be kept in mind whendesigning the system and the security solutions therein, they will, as previouslymentioned, be discussed at no more length in this report.

As this chapter has shown, there are a variety of problems to be found in thetested system, and it would not be a stretch to assume that similar issues canbe found in services of this kind developed by other companies. It is hopedthat the results and discussion presented will invite companies to shift morefocus to the security aspects of development. Although it is tempting to rapidlydevelop products and services to become more automatic and provide greaterfunctionality, it is worth to stop and examine the security of that which is beingcreated, for every new feature and every change carries the risk of opening upboth new, as well as old, ways of attack. Security is a critical part of manysystems, especially the ones where at the end is a vehicle, with a human beinginside.

6.1 Future work

By connecting a vehicle to the internet and moving its inner workings closer tothat of a standard computer, existing issues and vulnerabilities from the computerworld might end up a�ecting it. This section provides examples of two techniquesworthy of exploring, that could prove to be of serious concern when a vehicle isprovided with internet access.

6.1.1 Car worm

Due to the simple fact that a modern car can both send and receive data, as wellas the likelihood of a vehicle's standard wireless capabilities increasing, it is astrong possibility that a worm could be developed speci�cally for vehicles. Thiswould result in the ability of a car infecting other cars without an attacker havingto actively target them, and could give a malicious user access to the vehicle'scontrols, functionalities and data.

6.1.2 GSM Sni�ng

With the correct hardware, an attacker can eavesdrop on GSM tra�c and acquireinformation from the vehicle, such as the encryption method used, address to thevehicle, address to the server it communicates with, VIN, etc. However, the TCUwill only switch to GSM when the 3G network is unavailable, which could provedi�cult for an attacker to predict. Furthermore, this type of attack would requirea lot of knowledge about mobile networks and radio communications, and requireshardware with a price range of 100 [34] to 7000 [30] USD.

References

[1] Java enterprise edition. http://www.oracle.com/technetwork/java/javaee/overview/index.html, 2014-03-22.

[2] Federal Information Processing Standards Publication 197. Announc-ing the advanced encryption standard (aes). http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, 2014-09-15.

[3] Stephen Checkoway and Karl Koscher et al. Comprehensive experimentalanalyses of automotive attack surfaces. University of California, San Diego

and University of Washington, 2011.

[4] International Engineering Consortium. http://www.iec.org, 2014-08-16.

[5] Common Criteria. Common criteria for information technology security eval-uation. http://www.commoncriteriaportal.org, 2014-09-15.

[6] Nitesh Dhanjani. Cursory evaluation of the tesla model s: We can't protectour cars like we protect our workstations. http://www.dhanjani.com/blog/2014/03/curosry-evaluation-of-the-tesla-model-s-we-cant-

protect-our-cars-like-we-protect-our-workstations.html, 2014-04-01.

[7] Sastry Duri et al. Framework for security and privacy in automotive telem-atics. IBM Thomas J. Watson Research Center, 2002.

[8] Roy Thomas Fielding. Architectural styles and the design of network-based software architectures. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm, 2014-09-19.

[9] International Organization for Standardization. http://www.iso.org, 2014-08-16.

[10] International Organization for Standardization. Bene�ts of standards. http://www.iso.org/iso/home/standards/benefitsofstandards.htm, 2014-08-16.

38

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

http://www.iec.org

http://www.commoncriteriaportal.org

http://www.dhanjani.com/blog/2014/03/curosry-evaluation-of-the-tesla-model-s-we-cant-protect-our-cars-like-we-protect-our-workstations.html



http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.iso.org

http://www.iso.org/iso/home/standards/benefitsofstandards.htm

http://www.iso.org/iso/home/standards/benefitsofstandards.htm

References 39

[11] International Organization for Standardization. Information technology �database languages � sql � part 2: Foundation (sql/foundation). http:

//www.iso.org/iso/catalogue_detail.htm?csnumber=53682, 2014-09-19.

[12] The Internet Engineering Task Force. Rfc 4648. https://tools.ietf.org/html/rfc4648, 2014-08-07.

[13] The Internet Engineering Task Force. Rfc 1945. http://tools.ietf.org/html/rfc1945#section-11, 2014-08-11.






[19] The Apache Software Foundation. https://www.apache.org/, 2014-09-29.

[20] Spring Framework. http://spring.io/, 2014-08-30.

[21] M. Berndtsson J. Hansson B. Olsson B. Lundell. Thesis Projects, A Guide

for Students in Computer Science and Information Systems. Springer, 2008.

[22] Charalampos Patrikakis Michalis Masikos and Olga Zouraraki. Distributeddenial of service attacks. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html, 2014-09-19.

[23] Charlie Miller and Chris Valasek. Adventures in automotive networks andcontrol units. 2013.

[24] Oracle. Database. http://www.oracle.com, 2014-09-08.

[25] Oracle. Expression language. https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html, 2014-10-23.

[26] OWASP. https://www.owasp.org, 2014-02-20.

[27] OWASP. Owasp top ten 2014. https://www.owasp.org/index.php/Top_10_2013-Top_10, 2014-02-20.

http://www.iso.org/iso/catalogue_detail.htm?csnumber=53682

http://www.iso.org/iso/catalogue_detail.htm?csnumber=53682

https://tools.ietf.org/html/rfc4648


http://tools.ietf.org/html/rfc1945#section-11

http://tools.ietf.org/html/rfc1945#section-11











https://www.apache.org/

http://spring.io/

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html

http://www.oracle.com

https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html

https://docs.oracle.com/javaee/6/tutorial/doc/gjddd.html

https://www.owasp.org

https://www.owasp.org/index.php/Top_10_2013-Top_10

https://www.owasp.org/index.php/Top_10_2013-Top_10

References 40

[28] OWASP. Devguide. http://owasp.com/index.php/OWASP_Guide_Project,2014-09-12.

[29] OWASP. Bu�er over�ow attack. https://www.owasp.org/index.php/Buffer_overflow_attack, 2014-11-03.

[30] Ettus Research. Usrp x series. https://www.ettus.com/product/category/USRP-X-Series, 2014-07-16.

[31] SANS. Conducting penetration test on an organisation. http:

//www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67, 2014-09-19.

[32] Hendrik Schweppe and Yves Roudier. Security and privacy for in-vehiclenetworks. IEEE, 2012.

[33] Steam. Steam guard. https://support.steampowered.com/kb_article.php?s=8524b826f4259bc0ad5408a48033ff46&ref=4020-ALZM-5519, 2014-07-11.

[34] Sysmocom. Tv28 (rtl2832u + r820t). http://shop.sysmocom.de/products/tv28-r820t-bulk, 2014-07-16.

[35] International Telecommunication Union. Information technology - abstractsyntax notation one (asn.1). http://www.itu.int/ITU-T/studygroups/com17/languages/, 2014-09-03.

[36] International Telecommunication Union. X.509:information technology -open systems interconnection - the directory: Public-key and attribute cer-ti�cate frameworks. http://www.itu.int/rec/T-REC-X.509-201210-I/en,2014-09-17.

[37] Wild�y. http://wildfly.org/, 2014-08-02.

http://owasp.com/index.php/OWASP_Guide_Project

https://www.owasp.org/index.php/Buffer_overflow_attack

https://www.owasp.org/index.php/Buffer_overflow_attack

https://www.ettus.com/product/category/USRP-X-Series

https://www.ettus.com/product/category/USRP-X-Series

http://www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67



https://support.steampowered.com/kb_article.php?s=8524b826f4259bc0ad5408a48033ff46&ref=4020-ALZM-5519



http://shop.sysmocom.de/products/tv28-r820t-bulk

http://shop.sysmocom.de/products/tv28-r820t-bulk

http://www.itu.int/ITU-T/studygroups/com17/languages/

http://www.itu.int/ITU-T/studygroups/com17/languages/

http://www.itu.int/rec/T-REC-X.509-201210-I/en

http://wildfly.org/

servicing a connected car service - diva portal829730/fulltext01.pdf · 2015-06-30 · servicing a...

Documents