DEF CON 31 - Badge of Shame Breaking into Secure Facilities with OSDP -Dan Petro, David Vargas

Breaking into secure facilities used to be possible by inserting a listening device (such as an ESPKey) behind an RFID card reader and sniffing the unencrypted Wiegand badge numbers over the wire as they go to the backend controller. The physical security industry has taken notice and there's a new sheriff in town: The encrypted protocol OSDP which is starting to be rolled into production. Surely encryption will solve our problems and prevent MitM attacks right? ... right?

In this presentation, we'll demonstrate over a dozen vulnerabilities, concerning problems, and general "WTF"s in the OSDP protocol that let it be subverted, coerced, and totally bypassed. This ranges from deeply in-the-weeds clever cryptographic attacks, to boneheaded mistakes that undermine the whole thing. We will also demonstrate a practical pentesting tool that can be inserted behind an RFID badge reader to exploit these vulnerabilities.

Get your orange vest and carry a ladder, because we're going onsite!

[infectedrainbow]

'Just because it was intentional, doesn't make it not a vulnerability.' I guffawed. Reminds me of all the 'it is working as intended' arguments I have with our devs. Thank you for the great talk.

[thorns]

I love the thing about the two feet wire "reasonably likely not have a listening device on it".

[JulianSildenLanglo]

Considering the fact that these devices are literally designed to read hardware security tokens, you'd think it would be obvious to use one of those to transfer the setup key for the server.

[Geo_bot]

*aggressively reduces overhead*
*polls everything constantly*

[emmafountain]

When he gets into that undisclosed location in Santa Fe NM I need a copy of whatever book he happens to find lying around.

[christopherleubner]

Havent went to DefCon in years, but discources like these were my favorite thing about the convention. ❤

[ghostrider-beek]

I dont consider my self an expert in any of this, in any way, but I was able to make to 3:00 mark without being completely lost! well done presenter

[oliphab]

*Me in my secure hand drawn building in Santa Fe, New Mexico*😮

[norman-de-plume]

This is like DECT phones - everybody thought they were encrypted and then people realised they weren't. Pretty much overnight, DECT PCMCIA cards became worth more than their weight in gold.

[erwin]

great talk, but i guess you have missed the most important countermeasures from the conclusion:
- don't use the same wiring (bus) to connect high-critical and not-so-critical access devices
- get rid of old-fashined insecure RFID stuff and use modern chip technologies (supporting asymmetric cryptography etc.)

[BLKBRDD]

We need a racing series with 20 of these

[InstrucTube]

Yeah, people really don't realize that "encryption" isn't a magic bullet. Throw all the encryption at me that you want, if you do a dumb and leave an obvious vulnerability I'll breeze right past it.

[hazels]

Quick note on the cost of the OSDP standard document: it's cheaper if you buy it from the Estonian standards body, EVS, where it is called EVS-EN IEC 60839-11-5:2020.

If you buy 1 license you have to use a stupid DRM'd web reader thing, but if you buy a 2 seat multi-user license to the spec (which costs about €50 total) you get it as a PDF (with your name and iirc IP address burnt into every page to discourage sharing it) you can download, look at with normal PDF software, print out etc.

Hope that helps!

[steven]

the OSDP security systems we have run their RS485 bus at only 9600 baud as that allows them to get much greater cable run distances which would make the brute force even worse.

[jfwfreo]

I wonder how much of this is down to the spec writers not knowing about crypto or security, how much is down to the priorities being wrong (e.g. wanting smaller packet sizes at the expense of security, wanting something that is simpler to implement or wanting something that requires less hardware to pull off) and how much is intentional (i.e. deliberate back doors for some reason)

[reybontje]

It'd be interesting to see a card reader with a programmable certificate authority, cards that hold certificates, and the ability to push signed CRLs to the readers. Then, you wouldn't need a controller.

[outwithrealitytoo]

The intention of the master key (MK) would be to have it installed at manufacture, of clients and servers. This would ensure that pairing could only occur between devices sharing the MK. However were that MK compromised (by either a production facility leak or a poor physical security on the encryption modules) then it becomes a worthless appendage to a now broken security scheme. Unfortunately throwing away the MK doesn't fix the scheme.
- if you are designing a protocol with symmetric key scheme, DUKPT is always worth a look. With a touch of salt and pepper is covers a lot of practical bases.
As soon as the slide with "polling" came up I felt a bit queasy. "But it works" is not a defence. Neither is "it follows the letter of the specification". I suspect the project was hurried and on an unrealistic budget. It has the feel of a PoC put into production.
Note: RS485 is an electrical rather than protocol standard, and is largely chosen for range as well as multi-drop - which is great if you are running cable around a building! Tried, tested, off-the-shelf; good choice).

[MaverickBlue]

For that last question, MiM wouldn't be much harder, tap each wire twice and cut the piece in the middle...

[xcoder]

Sadly all known problems and many 101.

Optional encryption pretty often means no encryption in practice as you can never be sure it is used and even if you want to use it, an attacker may find a way to convince a component to deny encryption and everything is unencrypted again (Downgrade Attack, as shown in the video). Even if this can be avoided by a policy, users will forget to set it. Just don't make encryption optional. If encryption is too slow, which rarely ever is the case today, settle for a weaker one which provides only moderate security but at least make that one mandatory.

Replay attacks? Come on, that's 101. 32 bits would have been fine, IPsec uses 32 bits by default. Sure, it can use 64 bits but that's an optional extension rarely used in practice and only really required on super high speed links where the 32 bits would overflow too quickly and you'd otherwise constantly have to renegotiate session keys (which can be pretty expensive if PFS is used). BTW, even when IPsec sequence numbers are 64 bits, only the last 32 bits of them are actually transmitted over the line, so there's not more protocol overhead, but the full 64 bit are used when calculating the HMAC.

Reducing HMAC size? Sure, IPsec does that as well but it reduced 128 or 160 bits to 96 bits, which is still decent. Since SHA2, the reduction is 50% and thus at least 128 bits are sent.

Not reusing IVs? Again, 101. Not so critical with CBC encryption, as long as the first few bytes of data are always different, but deadly in many other cases (e.g. CTR/GCM).

One device sending a nonce? That's bad per se. A session key should always be derived by two nonces. Why? If an attacker has full control over the generation of the nonce on one side, e.g. because he controls the random number source that is used to generate it, it won't help him unless he can also control the nonce at the other side (very, very unlikely).

Setup keys exchanged over the same line as encrypted data later on? Also 101. Even in case of SSH you'd first use a password to access the server, then install your public key there and from this moment on, you can use public key auth. How do you get the inital password? Well, certainly not over the same connection that SSH uses.

Not encrypt everything? Encryption should always been treated as if it was an afterthought, yet it should never be an afterthought, of course. Think of TLS. To make HTTP secure, TLS was imposed on it. There are no parts of HTTP exposed as HTTP doesn't even know that it is encrypted and TLS doesn't even know that it is encrypting HTTP.

Use a hardcoded default key? LOL!

[henke]

The password being "default" is a punchline in a point and click adventure game, not a suitable cryptographic key.