- Miana and Micsen.
Let's give them a good DEFCON welcome.
(audience applauds)
Okay (mumbles and laughs).
- Yes so my name's Micsen
and I'm gonna
or we are gonna present digital skeleton keys.
- Yep, my name's Miana.
Essentially the talk is about a vulnerability
that we found in a RFID access
control system called smarter.
It's specifically what's known as an update on card system.
So the readers are different from normal ones
but I'll let Micsen explain more about that.
- Yeah.
So in short terms, a traditional access
control systems system is a online system
where the credential just stores an identifier.
And then once you go to
go up to any reader within the installation
it's gonna do a look at 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 a update on card
you would then provision a credential ahead of time
with the access with a often a list
of what doors you're supposed to have access to.
And 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.
(microphone creaks)
Yeah.
And there is also some nuances to this
cuz you can get a mixture of offline
and online readers within the same installation
where a online reader will then revalidate
your credentials as you're going through.
So you can have a online reader on the main entrance store
and then the rest of the building is offline.
The reason that you would use a
off a update on card system
is mainly associated
with the cost of getting the infrastructure there.
So you get places that are remote
or hotel rooms or stuff like that
where you would have those kind of systems.
We've used something called the Proxmark tree
to do most of the research on this.
In general the credentials that are being deployed
on these systems normally are the micro classic credentials
which has so many vulnerabilities
these days that the Proxmark client has a command
called Autopwn 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 view is good
you can find the software online.
And if you go on eBay
you'll find readers that are geek missioned.
And before I knew it, I had a working installation at home.
Oh.
So the first thing I did was
I dumped a credential with access to one door
and saw what I got.
And a MIFARE Classic credential has multiple sectors.
To make it simpler I've taken out one sector
(indistinct) just to illustrate this.
So we can see that, well we're using four bites.
And then I made another credential with access
to another two doors
and we're adding eight bites.
Well, four bites per door looks kind of repeating
and kind of matches the situation I had with my four doors.
What would happen if I just complete the
or continue the pattern
of adding another four bites at the end of it?
Well, turns out that's all you need to
do a privileged escalation attack in the system.
(laughs)
So at this point I was like
okay, this is cool.
And I was talking with Miana
and a few others in a group
in a group of people that does a lot of RFID
and it's gonna get much worse
as Miana is going to (laughs) 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 MIFARE 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 cards data
as the last four bites 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 keys 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 MIFARE 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
card that the Proxmark
would simulate that had 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 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 Micsen
to try with the readers that he had.
And those were configured with a different
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
reflash all the readers,
that's not the case.
the full configures 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'
(laughs) entire access control system with that.
So after the 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 U ID
or less random in this case, full (laughs).
Disable any pin code
cuz don't wanna have to type that in
and specify where we want the update on card block.
Next sector.
(mumbles) next page.
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 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 zero F means all the time.
And then the zero one means
that the door hasn't read it yet
and it hasn't updated it
so that user ID full 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 Micsen talk about some of the
blast radius of that.
- Yeah.
So I started doing disclosure on this
around one and a half years ago
with the manufacturer of this.
The manufacturer is Teza
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 Mul-T-Lock 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
a 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're using this
in at least these places with their case studies.
So 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
cuz you're not gonna get any updates
from these stores if they are opened.
Another thing that Miana 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 Teza
and ask for a licensing upgrade
because apparently 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 assured
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 are 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
into 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 a
unknown period of time,
and we are 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 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 MIFARE Classic hacking.
Without any of that this exploit
would've never been discovered, let alone get this far.
Also want to thank all the goons
and the whole DEFCON 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.
(audience applauds)
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.
But.
- Yes.
- [Crowd Member One] Is the code available (mumbles)?
- That we are gonna release the code shortly
after they've gone.
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.
(Micsen and Miana laugh)
I will get it up I promise.
Any others?
Oh.
- Oh.
- Yeah.
- [Crowd Member Two] (indistinct).
- So the card itself,
we don't need to attack the card itself,
we can go directly to the reader
and get the keys off 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. (laughs)
Time for one more question.
(mumbles).
Sure.
Okay maybe it wasn't then.
Oh well thank you then.
(audience applauds)
- Okay (mumbles).
- Huh?