|
|
Log in / Subscribe / Register

Security quotes of the week

Already, previous versions of the [USB] Rubber Ducky could carry out attacks like creating a fake Windows pop-up box to harvest a user's login credentials or causing Chrome to send all saved passwords to an attacker's webserver. But these attacks had to be carefully crafted for specific operating systems and software versions and lacked the flexibility to work across platforms.

The newest Rubber Ducky aims to overcome these limitations. It ships with a major upgrade to the DuckyScript programming language, which is used to create the commands that the Rubber Ducky will enter into a target machine. While previous versions were mostly limited to writing keystroke sequences, DuckyScript 3.0 is a feature-rich language, letting users write functions, store variables, and use logic flow controls (i.e., if this... then that).

That means, for example, the new Ducky can run a test to see if it's plugged into a Windows or Mac machine and conditionally execute code appropriate to each one or disable itself if it has been connected to the wrong target. It also can generate pseudorandom numbers and use them to add variable delay between keystrokes for a more human effect.

Perhaps most impressively, it can steal data from a target machine by encoding it in binary format and transmitting it through the signals meant to tell a keyboard when the CapsLock or NumLock LEDs should light up. With this method, an attacker could plug it in for a few seconds, tell someone, "Sorry, I guess that USB drive is broken," and take it back with all their passwords saved.

Corin Faife on the USB Rubber Ducky at The Verge

"Greenluigi1" found within the firmware image the RSA public key used by the updater, and searched online for a portion of that key. The search results pointed to a common public key that shows up in online tutorials like "RSA Encryption & Decryption Example with OpenSSL in C."

That tutorial and other projects implementing OpenSSL include within their source code that public key and the corresponding RSA private key.

This means Hyundai used a public-private key pair from a tutorial, and placed the public key in its code, allowing "greenluigi1" to track down the private key. Thus he was able to sign Hyundai's files and have them accepted by the updater.

Thomas Claburn at The Register

to post comments

Security quotes of the week

Posted Sep 6, 2022 10:48 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

That Reg article is a classic of security fail. Zip password in shipped code: check. IV and private key in shipped code: check. Key taken from first entry in NIST standard examples: check. Key taken from random example found on Internet: check.

I'd have assumed it was *impossible* to make all these mistakes in one place. I mean some of them require you to get your keys from different silly places! But no, Hyundai managed it...

Security quotes of the week

Posted Sep 19, 2022 4:01 UTC (Mon) by calumapplepie (guest, #143655) [Link]

I honestly think that this may be intentional... some Hyundai engineer was told to secure the system against outside updates, and did so in a way that ensured people could reprogram it to play Doom anyways.


Copyright © 2022, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds