'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
@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.
The original pen test. "Do you want to join the Pen 15 club?" Yes? You've just failed the pen test.
@RasAlHaq2 күн бұрын
You win two tickets to Pen Island! 😆
@57thorns Жыл бұрын
I love the thing about the two feet wire "reasonably likely not have a listening device on it".
@hazels1967 Жыл бұрын
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!
@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.
@christopherleubner6633 Жыл бұрын
Havent went to DefCon in years, but discources like these were my favorite thing about the convention. ❤
@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
@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.)
@almohАй бұрын
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.
@oliphab7468 Жыл бұрын
*Me in my secure hand drawn building in Santa Fe, New Mexico*😮
@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.)
@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.
@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).
@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.
@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.
@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.
@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).
@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...
@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.
@My1xT Жыл бұрын
SSH is not nesecarily insecure, it allows and in fact highly recommends to actually verify the key sent by the server.
@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.
@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?
@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.😂
@theelmonk Жыл бұрын
You could artificially 'kill' a reader if you're on a multidrop bus by corrupting the bus every time it transmits
@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.
@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!
@BLKBRDD3 ай бұрын
We need a racing series with 20 of these
@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.
@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
@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.
@57thorns Жыл бұрын
Cryptography is hard, security is shard, cryptographical security is doubly hard.
@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.
@berndeckenfels Жыл бұрын
Can a rough reader clone or record the badges? (I.e. are the challenges safe enough?)
@kellyzinser424Ай бұрын
🙏🙏
@LeonDerczynski Жыл бұрын
11:44 💀
@terranzoid Жыл бұрын
Defcon presenter using windows!
@TouYubeTom Жыл бұрын
echo chamber audio horror
@OBGuy Жыл бұрын
Nothing but "dizayn".
@Gunbudder Жыл бұрын
dude's logo is VERY similar to the Faze Clan logo and its extremely distracting. i would change that asap lol
@Talie5in Жыл бұрын
Or FaZe Clan should change as they were founded 5 years after Bishop Fox? 😅