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

Рет қаралды 93,724

Күн бұрын

Пікірлер: 57

@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.

@von... Жыл бұрын

good news boss, we refactored the Samsung Smartfridge integration & reduced the amount of backdoors it had into the customer payment servers by over 10%!

@rogerioar Жыл бұрын

Would def win a best slides award

@57thorns Жыл бұрын

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

@Geo_bot Жыл бұрын

*aggressively reduces overhead* *polls everything constantly*

@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.

@emmafountain2059 Жыл бұрын

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

@oliphab7468 Жыл бұрын

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

@ghostrider-be9ek Жыл бұрын

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

@christopherleubner6633 Жыл бұрын

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

@erwin2487 Жыл бұрын

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.)

@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.

@almoh 7 күн бұрын

Sequence numbers are used in protocols to put the packets back in order at the recipient. Timestamping the payload and hashing is a tech used for avoiding replay attacks. If you double encrypt your hmac using PK encryption, then breaking becomes impossible.

@ride1123 6 күн бұрын

The original pen test. "Do you want to join the Pen 15 club?" Yes? You've just failed the pen test.

@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.

@BLKBRDD 2 ай бұрын

We need a racing series with 20 of these

@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)

@jfbeam Жыл бұрын

I would always attribute it to the desire ("customer requirement") for it to be "simple". Loading certificates, syncing keys, etc. is a pain in the ass, but it's also 100% required for _anything_ to ever be secure. If you use anything that was on it "from the factory" (thus potentially knows to others), it's not secure.

@wesley00042 Жыл бұрын

It's the result of anything built by committees instead of professionals and hidden behind patents and paywalls instead of open for public inspection. (See also WEP/WPA, DVD/CSS, etc.)

@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).

@hazels1967 11 ай бұрын

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!

@theelmonk Жыл бұрын

You could artificially 'kill' a reader if you're on a multidrop bus by corrupting the bus every time it transmits

@henke37 Жыл бұрын

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

@christopherleubner6633 Жыл бұрын

That and admin are the two most common ones unfortunately.

@steven44799 Жыл бұрын

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.

@rogerioar Жыл бұрын

One of the best talks

@MaverickBlue42 Жыл бұрын

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

@reybontje2375 Жыл бұрын

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.

@57thorns Жыл бұрын

The fun thing is the 10 Mbit one could use a decent sized package, a 1kHz polling frequency (allowing for a couple of hundred doors to be polled several times per second) and despite allowing for more attack per seconds, you'd still be waiting way more than 35 days (on average).

@JoeTaber Жыл бұрын

When will they make badges that provide a proof with asymmetric encryption? The way they're done now is like writing your password on a sticky note and pasting it on your forehead in line at the coffee shop.

@christopherleubner6633 Жыл бұрын

Yup most are wide open for general access badges.😂

@xcoder1122 Жыл бұрын

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!

@My1xT Жыл бұрын

SSH is not nesecarily insecure, it allows and in fact highly recommends to actually verify the key sent by the server.

@Kisai_Yuki Жыл бұрын

Watching this, and comparing it to when I replaced the controller server at a client's location. The RS422 box at the controller end was just a USB dongle plugged into a Windows XP machine. The software was just a program on the server that track and log the provisioned cards. A third party had to come in and actually "backup" the old server's install, and then install the new version on the new server. The real weakness in this, is when nobody monitors the access, because every time a door is tapped, it CAN send an email to somewhere. So even if you cloned a card, you really only have one or two attempts before whoever gets the notifications should be contacting the card owner and asking if they are having trouble getting in the building, and when they say "what? I'm not at the office" send security out to that door. So that Install mode, is likely always turned on, because the underlying server, when rebooted for software updates or it just BSOD's for whatever reason, has to start up again, because if the server turns off, all the readers also lose power.

@LeifNelandDk Жыл бұрын

Cheap rfid locks where the keypad and controller is outside the door are unsafe and hackable "just connect red and yellow" or even by a strong magnet triggering the relay.

@tyeth Жыл бұрын

I wonder if you could influence the data+/- to remove the current data, like having 4 current clamps, 2 per wire, hooked up in some transformer cancelling fashion, and you could influence those with the esp32. You'd then be able to control that to add data back on the wire. Surely it must be possible to flatten the data on a differential pair through noise or retardation (think transformer/inductor) if you have enough length / separation and influence/power.

@erroneum Жыл бұрын

In regards to establishing a man-in-the-middle attack while on site, would it not be sufficient if you were wanting to not interrupt the service to essentially have the device tap it twice with a gap between them, then to cut the wire between the taps?

@petergamache5368 Жыл бұрын

Correct ... and this isn't hard to DIY. Here's a cheap "RS485 interposer" that's super fast to install (with some practice): 1. Design your attack device with a RJ45 plug interface. Ex: Upstream on pins 1/2, Downstream on pins 7/8. 2. Insert the wire pair you're attacking into a RJ45 punch-down keystone jack: One wire punched to 1 & 7, the other punched to 2 & 8, leaving an extra inch or so of slack between the sides. 3. Plug in and enable your MITM attack device. 4. Snip the wires bridging the punch-down jack, close to one side. 5. Do the sneaky stuff. 6. When done, take the slack and double-punch across the jack to re-unite the downstream and upstream sides, leaving the keystone jack behind. 7. Pocket your attack device and skedaddle! Post-attack, the presence of a punched-down but disconnected RJ45 jack is unlikely to draw attention unless your target is a very tightly run institution. If this is a concern, leave more slack and use a splicing butt connection instead (McMaster Carr 7056K24), then gently remove the RJ45 prior to vacating the site. Low voltage installers use these splices by the hundreds, so they'll blend in almost anywhere.

@57thorns Жыл бұрын

Cryptography is hard, security is shard, cryptographical security is doubly hard.

@simonisenberg4516 Жыл бұрын

I love these "The emperor#s new clothes" type talks that just try to shame people into doing it right.

@sparkybearbomb533 Жыл бұрын

Also, don’t put PII or CII on the rfid cards Imagine finding a card saying bill smith and company X, now you have a card and the user deets

@1337GameDev Жыл бұрын

Why wouldn't they just do Diffy-Helmann key exchange as is what's done with HTTPS? I can understand the need for a root public key, but that should merely need to require basic setup in install mode, which could be provided as a one time key via a flash drive / sd card. Could be susceptible to man-in-the-middle if you can reset the reader, provide your own key, and then pretend to be another "controller" in the middle, but that seems difficult. Then just encrypt everything with the public key.... and only the controller can read the valid data. Plus, you can then request a nonce, and use the public key of the reader to encrypt that, so the reader is the only one who can read the nonce. This seems "solved".....Why are modern companies still cutting these corners?

@TehNoobiness Жыл бұрын

Because management looks at the estimated dev time and balks at paying for it.

@My1xT Жыл бұрын

what what about that default key SCBK-D, if that is set to a fixed value by the protocol, how do you get rid of that weakness additionally couldnt the key exchange by secured by having the key on a card that can be read into that reader, e.g. having an "admin" card to config the reader and then tapping another card which has the key, which sets the key?