66% or better

Rackmount RasPi Leaves No Excuse to Lose Data

RasPi backup server

[Frank] knows how important backups are for data security, but his old method of plugging a hard drive in to take manual backups every so often is not the most reliable or secure way of backing up data. He realized he was going to need a secure, automated solution. He didn’t need a full-sized computer with a ton of power; why waste electricity for something so simple? His solution was to use a Raspberry Pi as the backup computer.

The main problem he faced with the Pi was finding a way to make it rack mountable. [Frank] started with an empty 1U server case. He then had to bend a few metal plates in order to securely mount the backup drive into the case. A couple of small rubber pads help dampen any vibrations caused by the hard drive.

The computer power supply was able to put out the 12V needed for the hard disk, but not the 5V required to run the Pi. [Frank's] solution was to use an LM2596 based switching supply to turn the 12V into 5V. He soldered the power supply wires directly to the Pi, thinking that a USB plug might vibrate loose over time. Mounting the Pi to the computer case should have been the trickiest part but [Frank] made it easy by simply gluing the Pi’s plastic case to the inside of the computer case. When all was said in done, the backup server pulls 29W under full load, 9W with the disk spinning, and only about 2W in an idle state.

On the software side of things, [Frank's] backup box uses bash shell scripts to get the job done. The Pi connects to his main server via VPN and then the bash scripts use rsync to actually collect the files. The system not only saves backups every night, but also keeps week old backups just in case. If you are really paranoid about your backups, try hooking up a custom battery backup solution to your Pi. If a Pi just isn’t doing it for you, you can always try one of many other methods.

Developed on Hackaday: 2 Days Left to Submit your Design!

We’re sure that many of Hackaday readers already know that one of the two main components of the Mooltipass project is a smart card, containing (among others) the AES-256 encryption key. Two weeks ago we asked if you’d be interested coming up with a design that will be printed on the final card. As usual, many people were eager to contribute and recently sent us a few suggestions. If you missed the call and would like to join in, it’s not too late! You may still send your CMYK vector image at mathieu[at]hackaday[dot]com by sunday. More detailed specifications may be found here.

In a few days we’ll also publish on Hackaday a project update, as we recently received the top and bottom PCBs for Olivier’s design. The low level libraries will soon be finished and hopefully a few days later we’ll be able to ship a few devices to developers and beta testers. We’re also still looking for contributors that may be interested in helping us to develop browser plugins.

The Mooltipass team would also like to thank our dear readers that gave us a skull on Hackaday projects!

A Real Malware In A Mouse

mouseagain

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.

[Read more...]

Malware In A Mouse

mouser

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.

Developed on Hackaday: Security and Arduino Compatibility

2013-12_Developed_on_Hackaday

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.

Ambient Computer Noise Leaks Your Encryption Keys

RSA Key extraction

[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.

Google Security Certificates Forged

Chain of Trust

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.