Using a legitimate USB charger.
The GSM radio for 2G internet broadcast.
The built in battery for short term unplugged continued sniffing.
Trigger word SMS messages.
Live streaming web portal.
That is very, very cool. This is the kind of stealth monitoring device people just would never think to check and could easily be replaced without the user being any the wiser.
This is a beautiful example of a real hack superbly executed. Bravo.
Edit: Just realised this is the guy (or team?) behind EverCookie.
This case still gets me. Showing some text on MySpace is a "felony" charge?
> Felonies: Felonies are the most serious types of crimes... ...Felonies are usually crimes that are viewed severely by society, and include crimes such as murder, rape, burglary, kidnapping, or arson. However, felonies can also be punished in a range of ways so that the punishment matches the severity of the crime. - http://criminal.findlaw.com/criminal-law-basics/what-disting...
In the plus side, it demonstrates how serious the state perceives the threat of "weaponized" javascript and can be a legitimate defense if someone is ever pursued for using noscript-alikes.
Some states view these types of crimes as crimes of 'moral turpitude' and it doesn't matter if it is a felony or misdemeanor. It will definitely effect your ability to get a security clearance or job in the security space.
I can' imagine whoever wrote this ever having difficulties landing a job in the security space, unless the prospective employer is really dumb.
Then again, it has happened to me that I didn't have the security clearance necessary to check out the code I was working on from a repository (this caused me to make a second repository on the laptop I carried back and forth, which more than defeats the point - dumbly enough, they were fine with this).
Even if they received no jail time, that sentence still seems disproportionately harsh. Heck most drunk drivers receive a lighter sentence and they're endangering human life.
Sounds like some public-key crypto could make it safe:
embed some unique keys at manufacturing time and use some small crypto library (like tweetnacl) to communicate and have mutual authentication. For the paranoid there could be a way to update the keys so that not even the vendor can sniff the keystrokes.
Isn't there a RFC for something similar?
That's the entire point. The crypto is not very good. Also it doesn't apply to all bluetooth keyboards because Microsoft uses a proprietary protocol to communicate apparently (at least this series of keyboards).
This is very specifically for Microsoft keyboards. There's multiple bugs that are exploited (both in the $1 receiver chip he's using and the fact that all MS keyboards start with the same bit for their mac address) that make it very easy in that specific case.
Hold my beer while I perform a table flip and throw away all my Microsoft Wireless Keyboards
Interestingly Microsoft aren't the only manufacturer to use the Nordic chipset for their "proprietary" 2.4GHz keyboards. I believe that Logitech's system is based on the same protocol.
I'm unsure if Logitech keyboard are affected in a similar way, I know that this attack only affects Microsoft keyboards but they may have similar issues.
As far as I can tell, bluetoooth keyboards should be a bit better off. Not sure how the "secure" modes work (presumably some kind of DH-exchange?) - but apparently they're not immune to brute forcing.
I recently switched back to usb Microsoft Natural keyboard for comfort from multiple versions of Microsoft wireless ergonomic keyboards but this hack makes me value the wire even more.
You know this'd be a fair bit less complex to implement as a USB hub, right? (for maximum lulz, a powered USB hub with one of these as it's power brick!)
The only wireless keyboard I use is for my HTPC... Interesting, and somewhat scary thing. Thinking it would be easy enough to plant other electronics (surveillance devices) in such a thing.
No, I meant the preventive measures. Would encryption be such a big battery-hog that they preferred security through "obscurity" or did they just overlook the fact that those devices were broadcasting users' keystrokes to the open air? It's unjustifiable in either case but just wondering. (BTW I also don't get the down-vote. Did I say something unrelated?)
The datasheet for the nRF24LE1 talks about it's AES encryption/decryption accelerator (section 15) and thermal noise random number generator (section 16), but the power consumption specs (section 26.1) talk about the rng using 0.5mA and don't even mention the AES hardware (even though they list other modules all the way down to 0.5uA). The RX/TX modules use over 10mA, so an order of magnitude more than the hardware RNG, and possibly 4 orders of magnitude more than the AES hardware.
I doubt the encryption would even register in battery life - completely obscured by the power consumed by the TX/RX modules.
The added electronics just rest against the adapter's boards: http://samy.pl/keysweeper/testingsize.jpg. This looks quite unsafe because of reduced clearances. It has a chance of either exposing HV on the LV (USB power) side or shorting the various boards, potentially starting a fire.
It's a pretty cool proof-of-concept, but I wouldn't connect anything to the USB port. These issues could be solved for deployment by potting or by using a custom smaller PCB integrating the various boards.
I'm assuming it was intentional, but I love how the page is structured somewhat like a page from the NSA ANT catalog[0][1]. The device itself seems like it would fit right in to that list.
Are there any good resources for learning more about wireless communication? Its something I have been wanting to learn for a while but compared to resources for programming, resources for learning about wireless communication are scarce. I am especially referring to embedded wireless, I would love to know how the nRF24 works.
So since the protocol contains basically no authentication other than the MAC address of the keyboard which the attacker can easily figure out, why isn't there already a key injection portion of this exploit ala wireless USBdriveby? I can totally see this being extended to wireless keyboard and mouse combos which would give you a great way to know if the user was at the computer and when it would be safe to compromise it without someone noticing.
The most frustrating thing when reading about keyboard vendors implementing such insecure protocols is knowing that the nRF24LE1 chip Microsoft uses has all it needs for security: hardware accelerated support for AES, as well as a hardware random number generator [1]. Some comments here suggest using public/private crypto as a fix, but it would not even be necessary. During manufacturing they could simply generate a unique secret AES key for each keyboard/dongle pair, store it in the 1536-byte non-volatile area of the chips, have the hardware RNG on the keyboard generate the IV when a wireless session begins, and use AES in CTR mode. Heck you could even afford to reserve a few bytes in each packet to store the counter in plaintext for automatic resynchronization when packets are lost, since the nRF24 radios support big enough packets (32 bytes). There are absolutely zero technical reasons not to implement security. It does not significantly increase power consumption. It does not bloat the code that much.
(I know all this because I have done a lot of work with the nRF24LE1. It is cheap: $4 for a fully assembled module on eBay [2]. It "supports" Bluetooth by bit-banging it [3]. And code for the builtin 8051 core can be compiled by the open source compiler sdcc. These are reasons why I selected this chip for my DIY home automation system.)
In fact the nRF24 radios are so popular that the vast majority of non-Bluetooth wireless keyboards use them. And I guarantee you that even though they use different protocols, they are almost certainly just as insecure as these Microsoft keyboards. The only reason vendors do not implement secure protocols is because customers do not know or care about security. The very few vendors who do such as [4] sell keyboards for hundreds of dollars... there is again zero reasons why it would cost that much given that it could be done with a standard nRF24LE1 :-(
Edit #1: a colleague of mine opened up the Matias Secure Pro keyboard and confirmed it uses an nRF24LE1.
Edit #2: @cortesoft: The way I would support this "one dongle many devices" feature is by doing the key generation during pairing (sometimes done by pressing a small switch under the keyboard) instead of during manufacturing. The only window of attack would be if an active attacker was present during pairing and pretended to be the dongle. It would still be significantly more secure than current keyboard protocols.
It's a free market, and the vendor has all the incentives to maximize the money-in minus the money-out. If reducing the money-out means selling cheap junk that anyone could crack with a $7 microcontroller, so be it.
If you have a unique key embedded in each keyboard/dongle pair, you would lose the ability to do this. In addition, if you lost the dongle, you would be SOL.
I think more people will care about the convenience instead of the security.
Ideally, you could have both; what if the keyboard had a USB slot that you plug in a dongle to pair it? You could have it generate a random key whenever a dongle is plugged in, to prevent someone plugging in their dongle to your keyboard (it would only pair with one dongle at a time).
> If you have a unique key embedded in each keyboard/dongle pair, you would lose the ability to do this. In addition, if you lost the dongle, you would be SOL.
I'm not sure I understand why? If public/private key cryptography were used then each dongle & keyboard would contain a private key. The dongle then contains a store for up to X public keys.
The pairing procedure starts due to a physical button press on the two devices, they find each other and exchange public keys. All future communication is then encrypted & signed using the private keys these devices hold. The attack described in venaoy's edit still applies though, an active attacker present during pairing may pretend to be an access point & keyboard, overpowering the original access point and acting as a sort of relay. The link would however break if this relay were to leave the vicinity.
The comment I was replying to stated that each pair would have an AES key generated for them at manufacture, and that is the key they would use to communicate together.
After I posted my reply, the comment was edited to mention this sort of public key exchange you describe happening with a button push. My comment does not apply to this sort of functionality. It would work great, with only the concern you mentioned about a relay attacker. I was only saying having a symmetric key generated at manufacture wouldn't allow for dongle changing and/or dongle consolidation.
Logitech 2.4 GHz keyboards use 128-bit AES symmetric encryption.
As I understand it, the encryptiion key is generated at the time of pairing in both the the keyboard and the receiver independently, and thus never transmitted wirelessly.
This is accomplished by having a secret algorithm that is encoded in both devices and produces the key based on some random input data that is shared between the devices at the time of pairing.
> If you have a unique key embedded in each keyboard/dongle pair, you would lose the ability to do this. In addition, if you lost the dongle, you would be SOL.
What about initializing the key during pairing? See parent's edit
Yes, initializing the key during pairing would work great.
I posted my reply before the parent's edit. I don't think this is an intractable problem; my suggestion of a physical connection for pairing or even a remote pairing with a button press would work fine. My ONLY point was that hard coding a symmetric key into the keyboard/dongle pair and then using that key for all communication wouldn't be practical.
Sammy mentioned, he would tell us how to prevent this but he never did. I am guessing since Microsft keyboard emits the CD at all time and is prone to this attack, for now I should stop using it.
If you show how to break a system, don't you implicitly show the parts that are broken that need to be fixed? The entire protocol is so poor you should probably just not use the tech anymore.
The cryptography method uses a key of 4 bytes and is reused constantly, that's pretty much reason alone to dump keyboards using that encryption scheme.
Using a legitimate USB charger. The GSM radio for 2G internet broadcast. The built in battery for short term unplugged continued sniffing. Trigger word SMS messages. Live streaming web portal.
That is very, very cool. This is the kind of stealth monitoring device people just would never think to check and could easily be replaced without the user being any the wiser.
This is a beautiful example of a real hack superbly executed. Bravo.
Edit: Just realised this is the guy (or team?) behind EverCookie.