security

463 Articles

The Year Of The Car Hacks

September 1, 2015 by 61 Comments

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

August 30, 2015 by 11 Comments

[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

August 11, 2015 by 60 Comments

[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

August 10, 2015 by 16 Comments

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” →

Saving An Alarm System Remote And $100

August 2, 2015 by 21 Comments

[Simon] has been using his home alarm system for over six years now. The system originally came with a small RF remote control, but after years of use and abuse it was finally falling apart. After searching for replacement parts online, he found that his alarm system is the “old” model and remotes are no longer available for purchase. The new system had similar RF remotes, but supposedly they were not compatible. He decided to dig in and fix his remote himself.

He cracked open the remote’s case and found an 8-pin chip labeled HCS300. This chip handles all of the remote’s functions, including reading the buttons, flashing the LED, and providing encoded output to the 433MHz transmitter. The HCS300 also uses KeeLoq technology to protect the data transmission with a rolling code. [Simon] did some research online and found the thew new alarm system’s remotes also use the same KeeLoq technology. On a hunch, he went ahead and ordered two of the newer model remotes.

He tried pairing them up with his receiver but of course it couldn’t be that simple. After opening up the new remote he found that it also used the HCS300 chip. That was a good sign. The manufacturer states that each remote is programmed with a secret 64-bit manufacturer’s code. This acts as the encryption key, so [Simon] would have to somehow crack the key on his original chip and re-program the new chip with the old key. Or he could take the simpler path and swap chips.

A hot air gun made short work of the de-soldering and soon enough the chips were in place. Unfortunately, the chips have different pinouts, so [Simon] had to cut a few traces and fix them with jumper wire. With the case back together and the buttons in place, he gave it a test. It worked. Who needs to upgrade their entire alarm system when you can just hack the remote?

Secret Keyboard Stash

July 18, 2015 by 32 Comments

Hide in plain sight is an old axiom, and one that [Kipkay] took to heart. His sneaky keyboard hack takes the little-used numeric keyboard and converts it to a handy (and secret) hiding hole for small objects you want to keep away from prying eyes.

You might have to adapt the hack to your specific model, but [Kipkay] cuts out the membrane keyboard, secures the numeric keypad keys with hot glue, and then cuts it out with a Dremel. Some cardboard makes the compartment and once the fake keypad is in place, no one is the wiser.

As you can see in the clip after the break, the compartment isn’t very big. You aren’t going to hide your phone inside, but it is just the right size for some emergency cash, a credit card, or maybe an SD card or two.

Continue reading “Secret Keyboard Stash” →

search-console

Fooling Google Search Console With Tricky PHP

July 17, 2015 by 42 Comments

When [Steve] received a notice from Google that a new owner had been added to his Google Search Console account, he knew something was wrong. He hadn’t added anyone to his account. At first he thought it might be a clever phishing tactic. Maybe the email was trying to get him to click a malicious link. Upon further investigation, he discovered that it was legitimate. Some strange email address had been added to his account. How did this happen?

When you want to add a website to Google’s services, they require that you prove that you own the actual website as a security precaution. One method to provide proof is by uploading or creating an HTML file to your website with some specific text inside. In this case, the file needed to be called “google1a74e5bf969ded17.html” and it needed to contain the string “google-site-verification: googlea174e5bf969ded17.html”.

[Steve] logged into his web server and looked in the website directory but he couldn’t find the verification file. Out of curiosity, he tried visiting the web page anyways and was surprised to find that it worked. After some experimentation, [Steve] learned that if he tried to load any web page that looked like “googleNNNNNNN.html”, he would be presented with the corresponding verification code of “google-site-verification: googleNNNNNNNN.html”. Something was automatically generating these pages.

After further investigation, [Steve] found that some malicious PHP code had been added to his website’s index.php page. Unfortunately the code was obfuscated, so he couldn’t determine exactly what was happening. After removing the new code from the index.php file, [Steve] was able to remove the hacker’s email address from [Steve’s] Google account.

This is a very interesting hack, because not only did it allow this one hacker to add himself to [Steve’s] Google account, but it would also have allowed anyone else to do the same thing. This is because each new hacker would have been able to fool Google’s servers into thinking that they had uploaded the verification file thanks to the malicious PHP code. It makes us think that perhaps Google’s verification system should use a separate randomized string inside of the verification file. Perhaps one that can’t be guessed or calculated based on known variables such as the file name.