A White Hat Virus for the Internet of Things

The Internet of Things is going gangbusters, despite no one knowing exactly what it will be used for. There’s more marketing money being thrown at IoT paraphernalia than a new soda from Pepsi. It’s a new technology, and with that comes a few problems: these devices are incredibly insecure, and you only need to look at a few CCTV camera streams available online for proof of that.

The obvious solution to vulnerable Internet of Things things would be to get people to change the login credentials on their devices, but that has proven to be too difficult for most of the population. A better solution, if questionable in its intentions, would be a virus that would close all those open ports on routers, killing Telnet, and reminding users to change their passwords. Symantec has found such a virus. It’s called Wifatch, and it bends the concept of malware into a force for good.

Wifatch is a bit of code that slips through the back door of routers and other IoT devices, closes off Telnet to prevent further infection, and leaves a message telling the owner to change the password and update the device firmware. Wifatch isn’t keeping any secrets, either: most of the code is written in unobfuscated Perl, and there are debug messages that enable easy analysis of the code. This is code that’s meant to be taken apart, and code that includes a comment directed at NSA and FBI agents:

To any NSA and FBI agents reading this: please consider whether defending
the US Constitution against all enemies, foreign or domestic, requires you
to follow Snowden's example.

Although the designer of Wifatch left all the code out in the open, and is arguably doing good, there is a possible dark side to this white hat virus. Wifatch connects to a peer-to-peer network that is used to distribute threat updates. With backdoors in the code, the author of Wifatch could conceivably turn the entire network of Wifatch-infected devices into a personal botnet.

While Wifatch is easily removed from a router with a simple restart, and re-infection can be prevented by changing the default passwords, this is an interesting case of virtual vigilantism. It may not be the best way to tell people they need to change the password on their router, but it’s hard to argue with results.

[Image source: header, thumb]

Getting Biometrics in Hand

It is amazing how quickly you get used to a car that starts as long as you have the key somewhere on your person. When you switch vehicles, it becomes a nuisance to fish the key out and insert it into the ignition. Biometrics aims to make it even easier. Why carry around a key (or an access card), if a computer can uniquely identify you?

[Alexis Ospitia] wanted to experiment with vein matching biometrics and had good results with a Raspberry Pi, a web cam, and a custom IR illumination system. Apparently, hemoglobin is a good IR reflector and the pattern of veins in your hand is as unique as other biometrics (like fingerprints, ear prints, and retina vein patterns). [Alexis’] post is in Spanish, but Google Translate does a fine job as soon as you realize that it thinks “fingerprint” is “footprint.” The software uses OpenCV, but we’ve seen the same thing done in MATLAB (see the video below).

Continue reading “Getting Biometrics in Hand”

Reverse Engineering An Obsolete Security System

[Veghead] recently went to a surplus warehouse filled with VHS editing studios, IBM keyboards, electronic paraphernalia from 40 years ago, and a lot of useless crap. His haul included a wooden keypad from an old alarm system that exuded 1980s futurism, and he figured it would be cool to hook this up to an alarm system from 2015. How did he do that? With software defined radio.

After pulling apart the alarm panel, [Veghead] found only a single-sided board with a 9V battery connector. There were no screw terminals for an alarm loop, meaning this entire system was wireless – an impressive achievement for the mid-80s hardware. A quick search of the FCC website showed this alarm panel was registered to two bands, 319MHz and 340MHz, well within the range of an RTL-SDR USB TV tuner dongle.

After capturing some of the raw data and playing it back in Audacity, [Veghead] found a simple OOK protocol that sends two identical binary patterns for each key. A simple program takes the raw bit patterns for each key press and codes them into a map for each of the twelve buttons.

Although the radio still works, [Veghead] found the waveforms captured by his RTL-SDR were an abomination to RF. All the components in this security system are more than 30 years old at this point, and surely some of the components must be out of spec by now. Still, [Veghead] was able to get the thing working again, a testament to the usefulness of a $20 USB TV tuner.

Thanks [Jose] for sending this one in

The Year of the Car Hacks

With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.

Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).

An early paper on this research [PDF] was published back in 2010 by The Center for Automotive Embedded Systems Security,a joint research effort between University of California San Diego and the University of Washington. They showed a number of vulnerabilities that could be exploited with physical access to a vehicle’s networks.

A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.

The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.

Continue reading “The Year of the Car Hacks”

Use Your Mouse Pointer to Send Data

[Ido Gendel] was thinking about new and interesting ways to send data between devices, when he realized that the answer was right in his hand. Literally: he decided to try sending data using the mouse pointer. What he came up with was an interesting hack that uses small movements of the mouse pointer to send data at up to 1200bps, or about 150 bytes per second.

The way he did this was very, very clever. He used an Arduino Leonardo that is set to emulate a mouse, working alongside his existing mouse. This setup means that he can use his existing mouse: the system just sees the Arduino as a second mouse, and the pointer just looks a little jerky when you zoom in. That is because the Arduino is just sending tiny movements, each of which is a code that represents a nybble (4 binary bits) of data. By using both a combination of three left-right or up-down movements, he was able to create 16 movements, each of which can encode 4 bits of data. Each of these encoding movements also returns the mouse to its origin point, so the mouse doesn’t mysteriously scroll off the screen when data is being sent.

Continue reading “Use Your Mouse Pointer to Send Data”

Oracle CSO to Customers: Leave the Vulnerabilities to Us

[Mary Ann Davidson], chief security officer of Oracle, is having a bad Tuesday. The internet has been alight these past few hours over a blog post published and quickly taken down from oracle’s servers. (archive) We’re not 100% sure the whole thing isn’t a hack of some sort. Based on [Mary’s] previous writing though, it seems to be legit.

The TL;DR version of Mary’s post is that she’s sick and tired of customers reverse engineering Oracle’s code in an attempt to find security vulnerabilities. Doing so is a clear violation of Oracle’s license agreement. Beyond the message, the tone of the blog says a lot. This is the same sort of policy we’re seeing on the hardware side from companies like John Deere and Sony. Folks like [Cory Doctorow] and the EFF are doing all they can to fight it. We have to say that we do agree with [Mary] on one point: Operators should make sure their systems are locked down with the latest software versions, updates, and patches before doing anything else.

[Mary] states that “Bug bounties are the new boy band”, that they simply don’t make sense from a business standpoint. Only 3% of Oracles vulnerabilities came from security researchers. The rest come from internal company testing. The fact that Oracle doesn’t have a bug bounty program might have something to do with that. [Mary] need not worry. Bug Bounty or not, she’s placed her company squarely in the cross-hairs of plenty of hackers out there – white hat and black alike.

DEF CON vs IoT: On Hackability and Security

Ahh DEF CON! One group of hackers shows off how they’ve broken into all sorts of cool devices and other hackers (ahem… “security professionals”) lament the fact that the first group were able to do so. For every joyous “we rooted the Nest thermostat, now we can have fun” there’s a doom-mongering “the security of network-connected IoT devices is totally broken!”.

And like Dr. Jekyll and Mr. Hyde, these two sides of the hacker persona can coexist within the same individual. At Hackaday, we’re totally paranoid security conscious, but we also like to tinker with stuff. We believe that openness and security are best friends forever. If you can open it, you can see if it’s well-made inside, at least in principle. How do we reconcile this with the security professional’s demand for devices that only accept signed binary firmware updates so that they can’t be tampered with?

We’ve got no answers, but we’ve got plenty of questions. Read on, and let us know what you think.

Continue reading “DEF CON vs IoT: On Hackability and Security”