OSDP supports, but doesn't strictly require, encryption. So your connection might not even be encrypted at all. Attack #1 is just to passively listen and see if you can read the card numbers on the wire.
encryption keys. Clearly these are meant to be samples, where the user is supposed to generate keys in a secure way on their own. But this is not explained or made simple for the user, however. And anyone who’s been in security long enough knows that whatever’s the default is likely to be there in production.So as an attack vector, when the link between reader and controller is encrypted, it’s worth a shot to enumerate some common weak keys. Now these are 128-bit AES keys, so we’re not going to be able to enumerate them all. Or even a meaningful portion of them. But what we can do is hit some common patterns that you see when someone . So you'll probably want to pick some of those up. Doesn't have to be that model, though.
If you have a controller you want to test, then great. Use that. If you don't, then we have an intentionally-vulnerable OSDP controller that you can use here: vulnserver.py.
Some of the attacks in attack_osdp.py will expect to be as a full MitM between a functioning reader and controller. To test these, you might need three USB<-->RS485 adapters, hooked together with a breadboard.
Additional Medium / Low Risk Issues
These issues are not, in isolation, exploitable but nonetheless represent a weakening of the protocol, implementation, or overall system.
- MACs are truncated to 32 bits "to reduce overhead". This is very nearly (but not quite in our calculation) within practical exploitable range.
- IVs (which are derived from MACs) are similarly reduced to 32 bits of entropy. This will cause IV reuse, which is a big red flag for a protocol.
- Session keys are only generated using 48 bits of
SOCIAL SHARE CARD GENERATOR