Mianna and Mixon, let's give a good DEF CON welcome.
Yes, so my name's Mixon, and I'm gonna,
or we're gonna present digital skeleton keys.
Yep, my name's Mianna.
Essentially, the talk is about a vulnerability
that we found in a RFID access control system
called SmartAir.
It's specifically what's known as an update on card system,
so the readers are different from normal ones,
but I'll let Mixon explain more about that.
Yeah, so in short terms,
a traditional access control system is a online system
where the credential just stores an identifier,
and then once you go up to any reader
within the installation,
it's gonna do a lookup on your credential number
towards the databases that are often distributed
on the controllers, but essentially then on a database.
Whereas in a offline access control system,
or also referred to as an update on card,
you would then provision a credential,
the head of time, with the access,
with a, often a list of what doors
you're supposed to have access to.
In, this should be done in a secure way,
so you can't manipulate it,
but as we will see, that's not always the case.
Yeah, and there is also some nuances to this,
because you can get a mixture of offline access,
and online readers, within the same installation,
where an online reader will then revalidate your credentials
as you're going through, so you can have,
have like a online reader on the main entrance door,
and then the rest of the building is offline.
The reason that you would use a update on card system
is mainly associated with cost
of getting the infrastructure there,
so you get places that are,
so you get places that are,
are remote, or hotel rooms, or stuff like that,
where you would have those kind of systems.
We've used something called the Proxmark 3
to do most of our research on this.
In general, the credentials that are being deployed
on these systems normally,
are the Mifred Classic credentials,
which has so many vulnerabilities these days,
that the Proxmark client has a command called autopawn,
to just read off the credential,
and then be able to get the keys necessary
to do changes to it.
So, how, it all started with me dumping one credential,
but then, I saw a pattern in it,
and wanted to investigate it further.
Turns out that if you Google few is good,
you can find the software online,
and if you go on eBay,
you'll find readers that are decommissioned,
and before I knew it,
I had a working installation at home.
So, the first thing I did was,
I dumped a credential with access to one door,
and saw what I got,
and a Mifred Classic credential has multiple sectors.
To make it simpler, I've taken out one, two, three, four,
and one sector's data here, just to illustrate this.
So, we can see that, well, we're using four bytes.
And then I made another credential
with access to another two doors,
and we're adding eight bytes.
Well, four bytes per door looks kind of repeating,
and kind of matches the situation I had with my four doors.
What would happen,
if I just continue the pattern
of adding another four bytes at the end of it?
Well, turns out, that's all you need
to do a privilege escalation attack in this system.
So, at this point, I was like, okay, this is cool,
and I was talking with Miana and a few others in a group,
and in a group of people that does a lot of RFID,
and it's gonna get much worse,
as Miana is gonna talk about now.
So, basically, the part that really interested me was,
now we've worked out some of the data structure
involved in the card,
and can take a credential and escalator,
is there a way to get that information from the reader,
without ever needing a card?
Well, we'll see.
Going back to things that are vulnerable
about the My Fair Classic credentials that they were using,
and with the Proxmark 3 tooling,
we could use an existing attack
to extract the encryption keys for the card from the reader,
based on simulating a set of specifically crafted cards,
and the Proxmark does that all by itself,
thanks to many other people's research.
The interesting thing about that encryption key
is it happened to have the installation ID,
which is one of the fields inside the card's data,
as the last four bytes of that key.
So, there's one piece of information that we need,
and you'll see that highlighted on here in green,
and the key's at the bottom.
But that's not all we needed.
It turns out, from looking through the software,
that the cards can be configured with different sectors,
assigned for different purposes,
and you then have to go and flash all of your readers
to have them read the credentials like that.
So, the next step was to try and work out
the card structure that a reader was expecting
without ever having seen that card.
So, made a little script that worked on for a while,
and the first attempt was running that My Fair Key extraction
and working out where the user data sector was,
as well as the key, which gives us the installation ID.
And then, I would create a,
a card that the Proxmark would simulate
that had the, a fake generated user data sector
in the location that the reader was expecting,
and then it would fill the rest of it
with a generated update on card sector.
The reason why I filled the rest of the card with that,
even though it only needs one, is so that it could read that,
and using the Proxmark,
we could see exactly what sector it was trying to read,
and then the next sector it tried to read
would be where the reader was expecting the doors to be.
So, from that card simulation,
we get the next two important pieces of information,
and the third step is just brute forcing the doors.
It turns out that the doors are sequentially ID'd,
so the very first door in the installation,
ID one, number two, ID two.
So, depending on the size of the card,
and exactly how far back they had configured the door sector,
we would just have to fill it
with as many access control sectors as we could,
and keep on generating new credentials
until one of them opened.
What happens when the reader finds the records,
the record for its door,
is it actually updates the data structure in there,
saying it's been updated,
and it stores the user ID in its internal storage,
so it doesn't need to search through so many pages of data,
and that's how we can detect what door ID it is,
because that's the one that it writes to.
Now, an interesting thing we discovered from this
is I sent this proof of concept script to Mixon
to try with the readers that he had,
and those were configured with a different card structure
from the one that I had wrote the exploit on,
and yet my script was still working,
but the proxmark was saying it was reading the sectors
in a different order.
Turns out that despite the instructions saying you need to reflash all the readers,
that's not the case.
The full config is on the card
as long as you get the first block right,
which is almost always in sector two anyway,
but now that we could identify
where this update on card block was specified in memory,
which is that purple spot,
we could completely get rid of that middle step.
This also had the advantage of allowing us
to define a much more compact data structure
on the card that doesn't use any of the sectors
that we didn't care about,
increasing the number of doors that we could fit
on each one of the brute force attempts.
In fact, because everything about the card
is configured via this system,
we went from being able to fit on the demo system
I was developing this on
around 120 doors per card to like 850,
which doesn't take long to get through
most facilities, entire access control system with that.
So after this script runs, the door will open,
but also you can then write the generated data
to credentials of your own
that will open any door in the system,
and this is what one of them looks like.
So this is the sector for the user data.
We put the extracted installation ID in,
come up with a random UID,
or less random in this case, fool.
Disable any pin code,
because don't want to have to type that in,
and specify where we want the update on card block.
Next sector.
This is what that looks like.
We've got some further research to do
to work out what all of the other values
in this sector mean.
But all we really needed was this door block in orange,
and the number of doors.
So we put that in the next sector, and 840 doors.
And then every sector following that looks like this,
where we have the door number,
the schedule of when it can be accessed,
which 0F means all the time,
and then the 01 means that the door hasn't read it yet,
and it hasn't updated.
So that user ID fool is always allowed in through this door.
And yeah, that's what the cards look like.
The problem that we have with this now
is that anyone who can run this script,
which requires a $30 tool,
can open any installations within this system.
And I'll let Mixon talk about some of the
blast radius of that.
Okay.
Yeah, so I started doing disclosure on this
around one and a half years ago
with the manufacturer of this.
It's, the manufacturer is Tesa,
which has been bought by Assa Abloy.
And these days, it's then being rebranded
and resold under different brands in different areas.
So in the US, it's sold under the Multilock brand.
And we've seen some fairly secure buildings,
or buildings that should have been secure
that are using this system in an offline capacity.
And there is, for instance, an airport in Norway
that uses this to, in areas between white and red zone,
which is two, which is unclean and clean zones
at an airport, which is a big issue.
They have, from what I've disclosed this to them as well,
they have done things to be able to mitigate for this.
There's also, so while we don't know exactly
how many of these systems there are,
and they do advertise that they are using this
in at least these places with their case studies.
So, and, yeah.
And it's a wide variety of everything from corporate
to healthcare to industrial applications
where this is being used.
So one of the places it was being used
is at a power distribution,
or a company that has a lot of remote sites
with power distribution.
And that's a problem,
because you're not gonna get any updates from these stores
if they are opened.
Another thing that Mianna didn't mention
is that they do not keep a log.
If you're opening the door with the user ID,
that doesn't exist.
The log is being kept in the lock,
but as soon as it's being written into the database of the,
if you pull the log off the door
and then go back to your server
to then be able to read off what has happened,
nothing shows up.
So as long as there is no user ID
which is valid associated with it,
they just ignore that entry.
And that seems to be a big oversight from what we've seen.
Another thing that they're doing is,
so to be able to patch this,
you now have to contact Tessa
and ask for a licensing upgrade.
Because apparently,
essentially, security needs a license.
So I haven't spoken to them
after I did my initial disclosure.
So I don't know the details of how that works,
but I know that it's quite a chore
to be able to get your installation back to a secure state.
One of the other bigger issues with these systems
is literally by design,
they're for remote locations or locations
where it's not feasible to network all of the readers.
Which means to update them,
you have to go and flash the firmware manually
by plugging a device in to every single one of these readers.
Not once, but twice, because you need to do it.
Then you need to reissue every single credential
in the system and you need to go back out
to all these remote stations and reflash the firmware.
So,
yeah this could be in the wild for
an unknown period of time
and we're hoping that it gets patched quickly.
But,
yeah,
I'm not sure if that's the case
if you have to reach out for license upgrades
and do all that work.
So,
yeah.
Do you have anything else to add on that?
No, I think I'm good on that.
Well, just in general,
we wanted to thank the whole RFID hacking community.
We got a lot of encouragement.
and like advice and bouncing ideas off of people as well as all of the
contributions made towards tools like the proxmark and the previous work done
on the my fair classic hacking without any of that this exploit would have
never been discovered let alone get this far also want to thank all the goons and
the whole DEF CON community because I've wanted to talk here since I was like 12
and yeah this community inspires people to look into this sort of stuff so thanks
so these are our contact details if anyone wants to get in touch and it
looks like we've got two and a half minutes if anyone has any questions
yes
that we're gonna release the code shortly after DEF CON so follow us on
Twitter and we'll make that available I wanted to have it available but I'm a
bit of a perfectionist and I ran out of time I will get it up I promise any
others
oh yeah
it's so and the card itself we don't need to attack the card itself we can go
directly to the reader and get the keys of that and that's not affected by the
hardened RNG that you would have on the card yeah yeah this attack needs
absolutely no knowledge of the system walking up to it as long as it's a smart
air system that uses these credentials you walk up with a proxmark running this
code and the door opens there are also some further things we've been
researching with that it turns out you can configure a fair bit more about the
locks but we didn't have enough time to fully dig into that but pretty certain
you can lock out all existing users and stuff like that as well so yeah some fun
things
time for one more question
sure okay maybe it wasn't cool well thank you then