Hey, hey, hey, everybody. I just wanted to take a second here to announce the section
that we're going to be talking about today, Abusing Smart Cities in the Dark Age of Modern
Mobility. This is an especially interesting topic for me as I live in a city that is still
stuck in the dark ages in Texas. I also want you to be aware of the fact that we've got
full Mateo redundancy in this presentation. Well, not one, but two of them in case one
of them breaks. So, I'm going to turn it over to them. So, thank you everyone for coming and
thank you for your time. We are going to steal you just one hour, so. Okay, um, I'm Mateo,
Mateo, the one Mateo, Mateo Beccaro. Uh, I work as a, in the security field as a CTO of a small
company in Italy and we do offensive physical security. Uh, that's my Twitter and if you want
to just give feedback at the end of the talk, I'd be happy to, to reply to that. And, there's
me. I'm, uh, Mateo Collura and, uh, I got a bachelor just two weeks ago and I'm still a student
studying now in the field of nanotechnologies, uh, for ICTs. So, if you want my Twitter as
well, you'll find here my personal information. And, uh, starting from May, uh, I'm going to
give a talk, I'll be, in the right position for the day. Uh, uh, I think I have a good
start. I'll introduce myself in a second. One moment. Um, and this is uh, that's our
presentation. Despite a very short time it could be picking off a bunch of Jeremy Gianco
comments in the comments and so, here we are currently. We uh, we could, uh, uh,
fairly quickly really give a intacks of what's going to happen. Uh, will first I want to
pick off the questions that um, uh, that's been popped into the chat. Um, and uh, the
next question was, why haven't you been teaching CTO creative functions yet in c.th? Well,
it's up to you guys sprand and brain Bay. Sprand's a how do you still feel about
overview about what a smart cities is. Then we focus on a
transportation system, smart transportation system. And what
we want to do is like introduce a methodology for assess those
kind of systems. And doing so we also have uh three different
case studies. One for each uh infrastructure in a smart
transportation system. And we uh we apply our method to these uh
to these case studies. And then we see what's up next. So let's
start with uh what is a smart cities. So a smart cities is
usually composed by several uh critical infrastructure. As for
example um you know energy management, surveillance
systems, water management, transportation system, and waste
management. So for a city to become smart usually those
infrastructures are the ones that are the most important.
The infrastructures have to be connected in some way. They can
be connected to some central system or connected to each
other to communicate and you know better manage the
resources. Uh in this presentation we are going to
focus on uh transportation system. So let's focus on smart
transportation system. And uh smart transportation system
itself is divided in a several infrastructure. And we may have
traffic control. We may have a smart parking system. We may have
a street lighting, smart street lighting systems and public
transportation system. So it's pretty complicated to work in
this kind of environment because we have multiple layers,
multiple infrastructure. Each one communicate with the others
in uh unknown protocols. So what we are doing is trying to define
a method to assess the system to better to easily do it doing so
because that's what we do for jobs. So we have to you know do it as quickly
as possible and the best way we can. So let's see quickly how is
our smart transportation system is usually composed. We have two
methods, uh sorry two different kind of systems. The first one
uh in which every element so for example uh traffic system,
traffic control system, smart lighting control, smart parking
and transportation communicates with uh some central system. Each
central system then communicate to a more central system. And that's a
central system uh aggregate the data from all the other systems and
communicate information usually useful information to the citizen.
Like with what she what is the best road to go to work. Where is
the more uh where is the less traffic today and so on. And uh
another kind of system is where each of the macro system uh
communicates directly to the user and sometime also directly to
each other. So there is no need of a more central control system.
Uh usually the the central point of a smart city is always the
citizen. So all the infrastructure are for to be helpful to the
citizen. Okay let's go even more in details. So smart
transportation system. We have private transport, shared transport
and public transport. With the private transport we mean like smart
parking. With the public transport we mean
metro, bus, tram, trains, you call it. And with shared transport we
mean the new transportation economy like bike sharing, car sharing,
etc. I drink a lot so sorry for these interruptions. Okay that's
one of the method, one of the uh uh uh uh uh uh uh uh uh uh uh uh uh
the architecture use to assess the system. So we try to reduce every
infrastructure to this schema. In which we have an edge domain and
inside the edge domain there is the edge device. Uh that take data from the
physical world and send this raw data to our cloud domain. The cloud domain is like the
brain of our system and it you know analyze the data and send commands back to the
to the device or send information to the client domain
which can be like mobile application for the citizen and
etc. So the communication usually is always bilateral so
the edge devices can both uh send the send send data and
receive commands. So they can act properly about the data
they are sending. So for example if there is no traffic
the traffic light is always green. Okay. That's uh our
first that's a little bit introduction. Now let's go to
our first case study. Uh smart parking meter system. Um we will
show some vulnerabilities about that. Okay. So uh the
device. Um let's make a little bit of introduction about how
the device work. Uh so the device is um both by the user uh
at some shop. And then the device can be recharged. So you
can store credit on the device and you can do it uh on both
online uh from your home. So you connect the device to your
computer. Register on the website of the of the of the
company and then using your credit card or your uh your
PayPal or whatever you can charge credit on the device that
can be used later. Or you can do the same procedure at some uh
com at some shops. So you go to the shops you gave the device
you pay in cash and the and the guy can charge your can charge
your device. Uh once once the device has some credit you you
can park your your car and then turn on the device. Uh you then
have to select the proper location because this device is
available for more than 40 cities in the United States.
In Italy. Actually I didn't I I shouldn't say Italy. Okay. In
more than 40 cities worldwide. And it it is growing. So you have
to select the correct cities because each each city has
different fare zone. So and once that you select the city you
have to select the proper uh fare zone and activate the
device. For for that for now on uh every minute uh every second
sorry the device automatically calculate the the fee you are
paying and reduce that amount from your from your credit. So
actually the benefit for the user is that the user doesn't
have to bring like coins and cash to pay the the park the
parking and he just get just pay for the exact time he's he's
parking and not for like half an hour uh or one hour over. So
these are some of the interfaces we found on the device. So there
is a display port which is for uh showing some information we
we'll see later. There is the USB port. There is the USB port
which is used to connect the device through the so called
gateway which is our computer that uh connects the device to
the cloud system. And then we have our our MCU. And all those
interfaces uh uh have some vulnerabilities. We will show
them uh in a few. I just need to drink again. At Defcon
there is a um I'll say the first time you speak to the
public at Defcon they usually bring you shots of alcohol. They
didn't do that uh this uh this year. I don't know why. This is
uh. Ask yourself. Yeah. Anyway. The first analysis we pre we did
on the on the device um was a firmware analysis in which we
found that there were no integrity checks. The the
firmware can be easily obtained in two different methods. We can
intercept the communication between the gateway. So our PC
and the backend system during an uh OTA update. So we can uh
intercept the firmware or we can extract the firmware directly
from the MCU. Uh in both case uh the the um the unpacking the the
firmware was easy. And no integrity checks were present.
No encryption in the firmware were present. No obfuscation.
And no uh authenticity is is also authenticity checks is
present during the firmware upgrade analysis. So the result
is that attacker can upload a malicious firmware. For example
removing the reducing of the credits part. So you can see
you can turn on the device device acts as uh it always been
but at the end of the at the end of the at the end of the day you
have always the same credit on the device. As I said before
there is some uh debug interface sorry there is some debugging
interfaces present on the on the device. We use the JTAG port
and the SWD port to extract for example the firmware. Uh there
are also other debug traces uh for all the components. So for
each component you have to have a JTAG port and a SWD port to
extract for example the firmware. Uh so this uh uh
on the device it can uh you can actually un intercept the
data the you can actually un intercept the data uh exchange it
and in inject other data. So let's try to reconduce our our
device to the uh schema I show you before. So for the edge
domain we have the parking meter. Which is connected via
USB to our gateway and to the cloud domain. Uh the cloud
appliance is used for like remote charging the device
to create invoice based on uh where you park and how time
you how time your parking and so on uh. So if you uh uh
park for example for expensive for the company etc and do OTA
updates. So the cloud domain then communicates to our client
application which is uh gave to the inspectors uh the inspector
can use the application to check if you are paying the correct
fee for your staying if you are paying correctly. Um another
thing the inspector can usually the inspector check if you are
paying correctly just by looking at the display of the
device. But there is also an NFC interface uh that they use
that the inspector can can use to access uh memory of the on
the device. So we did an uh communication security analysis
and the result where the there is no data validation between
the edge edge device and the cloud domain. So we can both
modify the data send from the cloud to the to the device and
to the the from the device to the cloud. And moreover
the all the trust in the if you are paying or not is in the
device itself. So the inspector can actually check only if you
are paying by looking the device or accessing the memory on the
device. You cannot check if you are paying correctly uh using
the cloud the the cloud data. Because the device it's not it's
not updating its status in real time. So as I said there is no
no integrity check, no encryption, no authenticity
checks. So the uh the uh the uh the uh the uh the uh the uh the uh the
so this is a sample uh request we we intercepted and from that
you can see I don't know if you can see but it's there is some
parameters which are very useful and this is a configuration
file. So every time you connect your device to the to the
gateway uh the the cloud appliance send a new
configuration files for updating like fee zones et cetera. Uh if
there are any new cities uh and we can modify that
configuration file. Okay so uh the uh the uh the uh the uh the
So reversing the the firmware, analyzing the communication,
and uh using some uh debug interface to understand better
the data. We finally found what is the formula used by the
device to calculate the fee. That's the formula. So we have
the price per time unit, then we have the fare frequency because
in some cities you you may have uh to pay every half an hour and
not an hour so it's another parameter. Then we have the time
the seconds uh later than the current time units. So this is
apps from when you turn on the device and then you divide ev-
all of this for one hour because usually it's one hour. And then
we have to add the minimum fee because in some park uh in some
parking you have to pay at least uh one hour of parking even if
you stay just for like 10 minutes. So as I said before
when you turn on the device the display show you the price you
are paying and the ta- the time you turn on the device. So
even if we modified the the configuration files so we con-
for example if we put at zero the price per time unit that zero
is displayed it is displayed by the device. So the inspector can
actually see you are you are committing a fraud. So that's
not good. The minimum fee in all the cities uh at the moment is
usually set to zero. So we don't have to care about that. So
what's the only parameter we have to to change to tell
if we set the multiplication to zero because that's what we
want. If we set the multiplication to zero then our
fee is zero. So if you can change the fra- the fare
frequency to zero all the q- all the formula is then zero so
we don't pay anything. Even if the correct configuration files
is displayed because price per time units we just set the the
correct one and it's the second we don't modify that. The fair
frequency is not displayed so we can change it easily to
zero from the configuration files so we intercept the
configuration file change the the value to zero and then the
old formula becomes zero. So that's why we call our formula
our CentoGral. And using this vulnerability this vulnerability
is pretty easy to to exploit. We actually wrote a little script
that can allow you to like do everything automatically. So you
can just plug the device to the computer and like I don't know
maybe three or four seconds.
Uh your device is like every city present in Italy or not.
Uh actually you pay zero for parking. Uh moreover we also
develop a firmware which in which uh the the fee payment is
removed. So we display the correct uh information but we
don't uh remove the the credits from the memory. So multiple
vulnerabilities allow you to actually not pay for parking.
That's a good thing right?
Yeah.
Okay. I'll now leave my the award to my colleague which will
talk about the next two case study.
Okay.
Whoops. Okay. Spoiler. Yeah. A little spoiler but. Um we will
go on speaking now about uh shared transport. Uh so uh we
will talk about shared transportation systems and in
particular we will speak about bike sharing. Well our case
study uh was divided into three steps essentially. The first
step is the one in which you go to the station where all the
bikes are located and uh you unlock yours. The second step is
the funniest, you ride the bike. And the third one is when you lock
it again and you walk away. So let's go step by step. From the
first one. The first one um show the picture shows that uh the
ways to unlock your bike are essentially two. Uh the first
one is say more physical. You need uh NFC card and um the NFC
card um will be checked uh here we will see how. Uh will be checked and will unlock the bike.
The other way to unlock is by using a mobile application on
our mobile device. So um the station is speaking with the
cloud over the back end that authorizes the unlocking of the
bike. Let's see more in detail. This is one of the stations. And
as you can see on the top there is uh NFC reader for the for the card. And uh as I said before
there are those two accessible methods in order to unlock the bike. Let's focus on the
first one. So the mobile application. So at first we we
compiled the app. And we found that there is no obfuscation on the code. And so that
helped us a lot in order to understand how the whole procedure works. But moreover one of the
critical points is that there are the vendor credentials are coded. And uh you can see that the
vendor credentials are coded. And obviously we obfuscated them here because we don't want to
say the name of any company here. And uh the the critical point is that with those credentials
you are allowed to create new users. Uh charge some credits on those users. Activate the users.
And unlock a bike in real time. Wherever it is. So it is
quite dangerous I mean. And moreover uh there are some APIs here and that are vulnerable to
SQL injection. And uh of course for legal reasons we did not make any attempt to exploit them.
So I will skip this part. And uh let's move. There is a private Q and A session later.
Let's move to the card analysis. Uh okay. I hope you don't recognize the city. But um it's uh
okay. Let's go on. It's in Italy but you said before. And that's the second uh the second
mistake. Okay. It's a ultralight uh NFC card. So we all know that ultralight uh is a card that
does not have any um encrypted uh data on it. Uh well uh the protocol is not um it's not
encrypting the data inside. So each one can read it easily. And there is no authentication
while uh uh reading the card. So if I can get one of those cards I can easily read my with my
smartphone or another reader. And uh the only identification uh parameter here is uh the
UID uh unique uh unique uh identification parameter is the UID. Which identifies one and
only one user. So that is the sensible all the sensible information relies in the UID to unlock
the bike. And uh if you look close to that card just look inside that rectangle. I don't know
if you see the that number. Uh please raise raise your hand if you guess what uh card is. Uh uh
that number is. Please do. Yes, you're right. It is the UID but in reverse way. So, don't
know who, who decided to put in that place the UID. Well, of course it is simple to read it by
a reader but, uh, they ease you this procedure. Let's go further and analyze the, the other
steps. Well, there is a physical issue we found in the stations because the only way the
station, um, is able to understand if the bike is properly locked or is inserted is by a, a
sensor inside the, that, uh, little piece of metal you see in the, yeah, in the hole. And, um,
if you slightly remove the, the bike as soon as you're locked, uh, the, the sensor will
not, well, the station is not going to understand that the bike has been removed. And so
after a minute or 30 seconds, I don't remember, uh, the unlocking process goes in time
out. And, uh, the station locks again the, the bike. The point is that the bike has
slightly been unlocked. So, the lock is not locking actually the bike. Uh, the, the
central system is not locking. So, uh, you, you, you, you, you can, you can, you can, you can
extract the bike and, uh, station will feel, uh, as if the bike has not, uh, been unlocked.
And, um, the point is that the central system can detect this issue in two ways. Uh, the first
one is that uh you you leave the bike in another station so
the central system will see okay I have the bike number one
two three in station one and at the same time in station two so
there is something wrong and uh the other critical point is if
there is another bike that is going to be uh left in in that
station the central system will uh understand that there are two
bikes in the same location so it is actually a problem and
that's all for the shared transportation systems and what
about the public transportation systems we defined uh two
different architectures uh the first one we called offline
system because uh each of the bus metro tram however they um
they are speaking with a
uh
uh
the back end and the back end is unilaterally speaking with a
UID blacklist or a database which is uh recording all the
possible tickets that are run out or banned I don't know and
the other architecture is uh we call the online system because
the difference is that the UID blacklist can interact um with
the stamping machines that are located
on the bus or metro or whatever so let's start with uh the first
architecture we spot out uh two main vulnerabilities the first
one is called uh lock attack and um actually it's quite easy to be
understood because the the sector where the rights are located that
is the OTP one can be made breed only if we set one bit in the lock
bytes uh to one so it's quite easy hack let's say and uh no rights will be removed
when you stamp your ticket because it is read only so essentially it's quite
easy to also be uh fixed this vulnerability but uh it will work essentially well it
was working and uh the second one we are talking about is the time attack and uh this is a
nicer because you don't have to make any any modifications to the lock set lock
sector and to the OTP so you leave essentially all the rights as they were
and you find the place where the timestamp of the last validate last
validated ticket is stored so the only the only task is to reverse to reverse
the timestamp and find the initial time when they start counting the minutes so
as soon as we reversed those data for example here we we put a rectangle a red
rectangle around the that area and we found the initial date was something
around 2005 and remember first January
and
we found that and so that way we are able to forge our our own timestamp and
validate our ticket without touching the rights because the ticket is valid for
some minutes 90 minutes or whatever and so you you will have always a valid
ticket and what about the online systems
this those kind of systems are not vulnerable to the previous but vulnerable
to the replay attack. Well offline systems are also
vulnerable to replay attack but I will explain now. And uh by
replay attack you have a lot of possibilities and will be a
serious problem. Because if you use some emulators or clone
tickets the one from China for example the there are no rules
they act like uh Mifare ultralight but they are not or
other Mifare maybe classic et cetera but they are not
following the standard rules and the protocols. They are
completely erasable and changeable. So you are allowed
to change the UID, forge new UIDs with uh a valid structure
because you have uh you can clone your ticket with uh a
valid structure even if it is encrypted you change the UID and
then you can stamp it and uh bypass any software
encryption and then you can change the UID and then you can
change the encryption because the the validating machine
makes everything uh by itself. And uh moreover you can also use
the same ticket to you clone it on your clone one you increase
one ride and you stamp the clone one and then you come back
to the the previous ticket the original one copying all the
data sectors and whatever you have so it will be perfectly um
indi indistingu- indistinguishable from the the
previous one and it is valid. And the the problem is that uh
the implementation of a whitelist would be uh a problem in our
systems because the whitelist must be must be updated on all
the stamping machine in real time. Think about uh if you go to
buy a new ticket from a shop that ticket must be usable immediately.
Uh as soon as you buy you buy it. So the implementation of a
whitelist is a serious problem. And it will mean well you will
need to uh build a completely new infrastructure if you
already deployed one to implement such a thing. So it
will be a very very difficult task. As regards future works
what's next? Well we studied uh uh uh uh uh uh uh uh uh uh uh uh
this is the picture we show we see before. And um we spoke
about uh energy management, surveillance systems, water
management. So let's start with uh smart cities uh uh
surveillance. And those kind of cameras can be used for well
they have multiple uses. One of those uses can be um for
policemen to charge people maybe uh going with the uh with the
their car in uh uh restricted areas. For example limited
traffic uh areas. And they can uh snap a picture of your of your
plate and uh um sending you a fine for entering that. But how
the how is the connection made between those cameras and the
main uh back end? Well we we still have to understand how. And
uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
then we have something on water management. Maybe there are some
counters that are revealing how much water each one of us is
using. And uh um applying a charge for each cube meter of
water. I don't know if you use here those kind of units of
measurements. But uh the amount of water. Yeah imperial is
different from metric. But I hope it is clearer.
You can see the same way and uh uh and so those kind of systems
have to be interconnected between a central infrastructure that
uh evaluates the right fee to be charged at each user. But what
about for example the smart city lighting system. And uh this
way we are going to illustrate for example how the the lighting for
uh a street. Maybe what kind of traffic these people have. It's just
or some buildings how to uh save money be in uh turning on or off lights when uh when it is not
necessary so uh what is the what is the algorithm a central system can use to turn on or off those
kind of lights that it will be a central point for future works and finally the smart traffic light
system um some new technology is about uh making the green light last longer if the the road is
quite crowded and uh maybe preventing from turning it red if there is no car in the crossing road and
uh but if those systems are interconnected and badly let's say say badly and the connection is
not secure maybe um a limitation at you
user can turn red on and well the green on and the green on the other side could be a mess yeah
the there was a a paper published by caesar cerrudo about traffic system you can check about
that yes interesting thing on securing the smart yeah securing smart cities yeah and finally one of
the okay we can test all all those infrastructure but our final challenge would be hacking a whole
city
yeah so as you saw we have like material for for you or for defcon so a good well you can see us in
the next year probably sure and if you have some yeah you would recommend some cities to be hacked
yeah we are to sponsor us we are yeah we just need to play the flight a five-star hotel and then
we can work something out no problem uh you you forgot the suite yeah five stars sweet enough
i started i'm sorry
yeah one each we don't share this okay just to be clear yeah yeah sure okay so i think there is
like something like 1500 people now here any question
don't be shy come on it's written don't be shy it's a q a session
okay uh do we have a microphone how does it work goons we need a microphone
goons right here ah the microphone is here oh okay you have to come here you have to do the work
so on the replay attack rather than copying it to another device couldn't you just copy it make a
gold image and then after you've used it replay that back onto the original device yeah you you
can do that but the problem is uh when you have the blacklist uh sometimes your ticket can uh can be
put on the blacklist because it actually behave in a not correct way so what we did is to inject
new uid so the system doesn't recognize if the every time you stamp the ticket you put a new id
so that this new id has not pre previous behavior so they don't ban it
other question just stand up and go to the microphone
no no questions come on uh we have like yes more or less minutes yes so we won't go anyway please
ask you have to stay inside close the doors okay thank you i have a question um it's for you not for
us i can talk afterwards it's fine thank you
um singapore is having a real big surge with their smart nation one of the things that they're doing
is they're having a big push for in the name of elder care monitoring in the home are you seeing
that in europe uh nope at least not in italy well we are from italy now maybe you understand
understood that but not in italy we think it's an interesting thing because we actually never
thought about that but um we are going to present the same research in singapore
uh next month at gsec yeah this month two at the end of the month in gsec so maybe there's some
like interesting point to speak about can you tweet where you're doing this information because
i live in singapore i like to attend uh okay you can come later and give you the link and what up
so on the on the parking meter charge hack did you think to try making the charge negative
yeah yeah but something very weird happened
yeah they charged us like 10 times what what we owe yeah so there must be something more in that
formula reversing the firmware there is some like very strange things like some weird vulnerabilities
in which you can like overflow the whole system and crash it it's more to look into but yes we tried
hi so in chicago we have a different bike share system with a different lock at the front of the
bike which i believe uh i'm not sure if this hack will work or not on it so i'm wondering if
you've looked into other hacks for bike share that aren't reliant on the locking mechanism
and then also our bikes have gps so have you figured out how to if you wanted to literally
steal the bike how do you overcome the gps so you have gps on the bike the bike okay
there was a a talk i think last year the blackhead or devcon about both probably about spoofing gps
GPS data with uh SDR. So you can actually bring your SDR in a
backpack with a battery and like spoofing the data and
meanwhile stealing stealing the bike legally. It's uh a
principle we we are trying also to apply to uh car sharing
because they check your mileage and where are you going and they
charge money for that so it's interesting thing. You echo.
Anyone else? Three minutes. Yeah. Maybe four or five. Okay.
Thank you very much for coming. Thank you for your hour. Yeah.
Thanks for. Really appreciate. Also thanks for all our
sponsors and yeah that's it.