After reading an April Fools joke we fell for, [Mortimer] decided to replicate this project that turns the common USB mouse into a powerful tool that can bring down corporations and governments. Actually, he just gave himself one-click access to Hackaday, but that’s just as good.
The guts of this modified mouse are pretty simple; the left click, right click, and wheel click of the mouse are wired up to three pins on an Arduino Pro Micro. The USB port of the ‘duino is configured as a USB HID device and has the ability to send keyboard commands in response to any input on the mouse.
Right now, [Mortimer] has this mouse configured that when the left click button is pressed, it highlights the address bar of his browser and types in http://www.hackaday.com. Not quite as subversive as reading extremely small codes printed on a mousepad with the optical sensor, but enough to build upon this project and do some serious damage to a computer.
Video of [Mort]’s mouse below.
Continue reading “A Real Malware In A Mouse”
Keyloggers, in both hardware and software forms, have been around for a long, long time. More devious keyloggers are smart enough to ‘type’ commands into a computer and install Trojans, back doors, and other really nasty stuff. What about mice, though? Surely there’s no way the humble USB mouse could become an avenue of attack for some crazy security shenanigans, right?
As it turns out, yes, breaking into a computer with nothing but a USB mouse is possible. The folks over at CT Magazine, the preeminent German computer rag, have made the Trojan mouse (German, terrible Google translation)
The only input a mouse receives are button presses, scroll wheel ticks, and the view from a tiny, crappy camera embedded in the base. The build reads this camera with an Arduino, and when a certain pattern of gray and grayer pixels appear, it triggers a command to download a file from the Internet. From there, and from a security standpoint, Bob’s your uncle.
Looking through the camera inside a mouse is nothing new; it’s been done over the Internet and turned into the worst scanner ever made. Still, being able to process that image data and do something with it is very cool. Just don’t accept mouse pads from strangers.
Danke [Ianmcmill] for the tip.
Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.
Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.
Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.
What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.
[Daniel, Adi, and Eran],
students researchers at Tel Aviv University and the Weizmann Institute of Science have successfully extracted 4096-bit RSA encryption keys using only the sound produced by the target computer. It may sound a bit like magic, but this is a real attack – although it’s practicality may be questionable. The group first described this attack vector at Eurocrypt 2004. The sound used to decode the encryption keys is produced not by the processor itself, but by the processor’s power supply, mainly the capacitors and coils. The target machine in this case runs a copy of GNU Privacy Guard (GnuPG).
During most of their testing, the team used some very high-end audio equipment, including Brüel & Kjær laboratory grade microphones and a parabolic reflector. By directing the microphone at the processor air vents, they were able to extract enough sound to proceed with their attack. [Daniel, Adi, and Eran] started from the source of GnuPG. They worked from there all the way down to the individual opcodes running on the x86 processor in the target PC. As each opcode is run, a sound signature is produced. The signature changes slightly depending on the data the processor is operating on. By using this information, and some very detailed spectral analysis, the team was able to extract encryption keys. The complete technical details of the attack vector are available in their final paper (pdf link).
Once they had the basic methods down, [Daniel, Adi, and Eran] explored other attack vectors. They were able to extract data using ground fluctuations on the computers chassis. They even were able to use a cell phone to perform the audio attack. Due to the cell phone’s lower quality microphone, a much longer (on the order of several hours) time is needed to extract the necessary data.
Thankfully [Daniel, Adi, and Eran] are white hat hackers, and sent their data to the GnuPG team. Several countermeasures to this attack are already included in the current version of GnuPG.
Recently, Google discovered that a certificate authority (CA) issued forged certificates for Google domains. This compromises the trust provided by Transport Layer Security (TLS) and Secure HTTP (HTTPS), allowing the holder of the forged certificates to perform a man-in-the-middle attack.
To validate that the website you’re visiting is actually who they claim to be, your browser ensures that the certificate presented by the server you’re accessing was signed by a trusted CA. When someone requests a certificate from a CA, they should verify the identity of the person making the request. Your browser, and operating system, have a set of ultimately trusted CAs (called root CAs). If the certificate was issued by one of them, or a intermediate CA that they trust, you will trust the connection. This whole structure of trust is called a Chain of Trust.
With a forged certificate, you can convince a client that your server is actually http://www.google.com. You can use this to sit between a client’s connection and the actual Google server, eavesdropping their session.
In this case, an intermediate CA did just that. This is scary, because it undermines the security that we all rely on daily for all secure transactions on the internet. Certificate pinning is one tool that can be used to resist this type of attack. It works by associating a host with a specific certificate. If it changes, the connection will not be trusted.
The centralized nature of TLS doesn’t work if you can’t trust the authorities. Unfortunately, we can’t.
[Karl Lunt] has updated his Secure Digital Card locker to support password based locking. [Karl’s] original design only supported write locking via the TMP_WRITE_PROTECT bit. The new design gives the user an option: TMP_WRITE_PROTECT, or password protection. [Karl] goes into further detail this time around about the bit fields used with CMD42, and how they are set. The passwords in this case are up to 16 bytes. The bytes don’t necessarily have to be printable characters – any binary value can be used. Unfortunately, [Karl’s] locker doesn’t utilize a user interface beyond the buttons, so any password must be “baked in” to the SD Card locker firmware. We would love to see the option of even a basic serial interface for entering a password (most likely in hex).
[Karl] tried his device out with several different cards, and several computers. While not an exhaustive test, he did find that the computers always behaved the same: A locked SD card would not show up. In the case of windows, no beep, no drive, nothing. He goes into the security possibilities of using password locking: Financial data could be stored and physically transferred via SD or microSD, with the password sent separately (say in an email or SMS). Any unenlightened data thief attempting to use the card would think they have a broken device on their hands.
We don’t know how secure the password lock feature is – brute forcing a variable length 16 byte binary password would take some time. It all comes down to how quickly each password attempt takes. Some cursory web searching didn’t bring up any information about successful SD card password cracking. Sounds like a challenge for our readers!
If you’re an Evil Customs Agent or other nefarious Three Letter Agency Person, you’re probably very interesting in getting data off people’s phones. Even if the screen is locked, there’s a way around this problem: just use the Android Debug Bridge (ADB), a handy way to get a shell on any Android device with just a USB cable. The ADB can be turned off, though, so what is the Stasi to do if they can’t access your phone over ADB? [Michael Ossmann] and [Kyle Osborn] have the answer that involves a little-known property of USB devices.
USB mini and micro plugs have five pins – power, ground, D+, D-, and an oft-overlooked ID pin. With a particular resistance between this ID pin and ground, the USB multiplexor inside your phone can allow anyone with the proper hardware to access the state of the charger, get an audio signal, mess around with the MP3s on your device, or even get a shell.
To test their theory, [Michael] and [Kyle] rigged up a simple USB plug to UART adapter (seen above) that included a specific value of resistor to enable a shell on their test phone. Amazingly, it worked and the thought of having a secure phone was never had again.
The guys went farther with some proprietary Samsung hardware that could, if they had the service manual, unlock any samsung phone made in the last 15 years. They’re working on building a device that will automagically get a shell on any phone and have built some rather interesting hardware. If you’re interested in helping them out with their project, they have a project site up with all the information to get up to speed on this very ingenious hack.
Continue reading “Getting a Shell on any Android Device”