Hackaday 10th Anniversary: [1o57] And The Art Of Encryption

[Ryan] a.k.a. [1o57] comes from an age before anyone could ask a question, pull out their smartphone, and instantly receive an answer from the great Google mind. He thinks there’s something we have lost with our new portable cybernetic brains – the opportunity to ask a question, think about it, review what we already know, and reason out a solution. There’s a lot to be said about solving a problem all by yourself, and there’s nothing to compare to the ‘ah-ha’ moment that comes with it.

[1o57] started his Mystery Challenges at DEFCON purely by accident; he had won the TCP/IP embedded device competition one year, and the next year was looking to claim his title again. The head of the TCP/IP embedded competition had resigned from his role, and through a few emails, [1o57] took on the role himself. There was a miscommunication, though, and [1o57] was scheduled to run the TCP/IP drinking competition. This eventually morphed into a not-totally-official ‘Mystery Challenge’ that caught fire in email threads and IRC channels. Everyone wanted to beat the mystery challenge, and it was up to [1o57] to pull something out of his bag of tricks.

The first Mystery Challenge was a mechanical device with three locks ready to be picked (one was already unlocked), magnets to grab ferrous picks, and only slightly bomb-like in appearance. The next few years featured similar devices with more locks, better puzzles, and were heavy enough to make a few security officials believe [1o57] was going to blow up the Hoover dam.

With a few years of practice, [1o57] is turning crypto puzzles into an art. His DEFCON 22 badge had different lanyards that needed to be arranged to spell out a code. To solve the puzzle, you’ll need to talk to other people, a great way to meet one of [1o57]’s goals of getting all the natural introverts working together.

Oh. This talk has its own crypto challenge, something [1o57] just can’t get out of his blood:

We talked for a little bit, and 0x06 0x0a1 MFY YWXDWE MEOYOIB ASAE WBXLU BC S BLOQ ZTAO KUBDR HG SK YTTZSLBIMHB

BadUSB Means We’re All Screwed

Does anyone else get the feeling that the frequency of rather horrible vulnerabilities coming to light is accelerating? Off the top of our head, there’s Heartbleed, Shellshock, and now this one. The BadUSB exploit attack stems from the “invisible” microcontroller in most USB devices.

We first heard about it when we were attending DEFCON in August. The exploit had been announced the same week at Blackhat but there wasn’t much information out yet. Now the talk has been posted and there’s a well-explained overview article at Big Mess o’ Wires.

Here’s how this one goes: all USB devices rely on a microcontroller to handle the peripheral-side of USB communications. The computer doesn’t care which microcontroller, nor does it have a way of knowing even if it wanted to. The uC is “invisible” in this situation, it’s the interface and data flowing through it that the computer cares about. BadUSB is an attack that adds malicious functionality to this microcontroller. To the computer it’s a perfectly normal and functional USB device, while all the bad stuff is happening on the peripheral’s controller where the computer can’t see it.

badusb

How deeply do you think about plugging each and every USB device? Check out what happens at 19:20 into the video below. The USB device enumerates and very quickly sets up a spoofed Ethernet connection. You can still load a webpage via WiFi but the fake connection is forwarding packets to a second server.

Once discovered, you can wipe the computer and this will stop happening; until you plug the same device again and reinfect. Worse yet, because the controller is invisible to the computer there’s almost no way to scan for infected devices. If you are smart enough to suspect BadUSB, how long will it take you to figure out if its your mouse, your keyboard, a thumb drive, a webcam, your scanner… you get the point.

Continue reading “BadUSB Means We’re All Screwed”

Very Dumb Security For A WiFi Thermostat

We have finally figured out what the Internet of Things actually is. It turns out, it’s just connecting a relay to the Internet. Not a bad idea if you’re building a smart, Internet-connected thermostat, but you have no idea how bad the security can be for some of these devices. The Heatmiser WiFi thermostat is probably the worst of the current round of smart home devices, allowing anyone with even a tiny amount of skill to control one of these thermostats over the Internet.

The Heatmiser is a fairly standard thermostat, able to connect to an 802.11b network and controllable through iOS, Android, and browser apps. Setting this up on your home network requires you to forward port 80 (for browser access) and port 8068 (for iOS/Android access). A username, password, and PIN is required to change the settings on the device, but the default credentials of user: admin, password: admin, and PIN: 1234 are allowed. If you’re on the same network as one of these devices, these credentials can be seen by looking at the source of the webpage hosted on the thermostat.

if you connect to this thermostat with a browser, you’re vulnerable to cross-site request forgery. If you use the Android or iOS apps to access the device with the custom protocol on port 8068, things are even worse: there is no rate limiting for the PIN, and with only four digits and no username required, it’s possible to unlock this thermostat by trying all 10,000 possible PINs in about an hour.

There are about a half-dozen more ways to bypass the security on the Heatmiser thermostat, but the most damning is the fact there is no way to update the firmware without renting a programmer from Heatmiser and taking the device apart. Combine this fact with the huge amount security holes, and you have tens of thousands of installed devices that will remain unpatched. Absolutely astonishing, but a great example of how not to build an Internet connected device.

The “Unstealable” Transformer Bike

A team of Chilean engineering students have designed a bike that comes complete with detachable parts that can be re-positioned to lock the vehicle in place. They are calling it the Yerka Project and have marketed it as the world’s first unstealable bike.

The genius of it is the frame itself literally acts as the locking mechanism. This means that if a thief wanted to break the lock, they would have to break the actual bike, leaving little to be desired. This also eliminates the need to go out and purchase a standalone bicycle lock, which can be opened up relatively easily anyway.

The Yerka works by splitting the bike’s down tube in half and extending it outwards around a nearby object like a tree, a light post, or a designated bicycle rack. The saddle and seatpost is then removed and inserted into a hole that was drilled into the down tube. After that, a lock at the end is secured and the rider can walk away knowing that their bike is safe.

However, clever hackers will probably still find a way to unlock this bike. No matter how unstealable it might be, someone will figure it out. In the meantime though, it gives a nice sense of security for those hoping to deter your average bike thief from attempting to jack the bicycle.

For a good look at the design, watch the videos posted below:

Continue reading “The “Unstealable” Transformer Bike”

Unbricking A BluRay Drive

All BluRay player, devices, and drives contain a key that unlocks the encryption and DRM present on BluRay discs. Since 2007, the consortium responsible for this DRM scheme has been pushing updates and revocation lists on individual BluRay releases. Putting one of these discs in your drive will brick the device, and this is the situation [stephen] found himself in when he tried to watch Machete Kills. Not wanting to update his software, he searched for a better solution to unbrick his drive.

Every time [stephen] played or ripped a disc, the software he was using passed a key to the drive. This key was compared to the revocation list present on the drive. When a match was found, the drive bricked itself. Figuring the revocation list must be stored on a chip in the device, [stephen] broke out the screwdriver and started looking around inside the drive.

There aren’t many chips inside a modern BluRay drive, but [stephen] did manage to find a few Flash chips. These Flash chips can be dumped to a computer using a BusPirate, and comparing the dump to a publicly available ‘Host Revocation List Record’, [stephen] was able to find the location on the Flash chip that contained the revocation list.

The next task was to replace the revocation list currently on the drive with an earlier one that wouldn’t brick his drive. [stephen]’s MakeMKV install made this very easy, as it keeps a record of all the revocation lists it runs across. Updating the Flash in the drive with this old list unbricked the drive.

This is only a temporary fix, as [stephen] still can’t put a new disc in the drive. A permanent fix would involve write protecting the Flash and preventing the drive from ever updating the revocation list again. This would be a very complex firmware hack, and [stephen] doesn’t even know what architecture the controller uses. Still, the drive works, saved from terrible DRM.

Arduino-Powered Alarm System Has All The Bells And Whistles

Put aside all of the projects that use an Arduino to blink a few LEDs or drive one servo motor. [IngGaro]’s latest project uses the full range of features available in this versatile microcontroller and has turned an Arduino Mega into a fully-functional home alarm system.

The alarm can read RFID cards for activation and control of the device. It communicates with the front panel via an I2C bus, and it can control the opening and closing of windows or blinds. There is also an integrated GSM antenna for communicating any emergencies over the cell network. The device also keeps track of temperature and humidity.

The entire system can be controlled via a web interface. The Arduino serves a web page that allows the user full control over the alarm. With all of that, it’s hard to think of any more functionality to get out of this tiny microcontroller, unless you wanted to add a frickin’ laser to REALLY trip up the burglars!

Gaining Access To The Oculus Developer Database

One of the hackers over at Bitquark popped a shell on on the Oculus Developer Portal giving him full reign over the special admin panel inside. If he felt so inclined, this allowed him edit users, modify projects, add news articles, edit the dashboard, upload SDK files, and variety of other goodies.

The process started by using a SQL injector called BSQLi to test out parameters, cookies, and headers. Injecting into the header revealed that the Oculus team members were inserting X-Forwarded-For headers directly into the database without proper escape formatting. This got him in the door, and with a little assistance from sqlmap, the database was enumerated, and a pattern was recognized. Oculus passwords that were stored in the DB were heavily hashed. However, the user session variables remained unprotected. A SQL query was quickly built, the latest admin session was promptly extracted, and then the information was plugged in granting access to the portal. A bit more snooping around uncovered that the AJAX eval() preview script wasn’t secured by a CSRF token which could easily be exploited by a malicious hacker.

The findings were then turned into Facebook who paid the guy $15,000 for the first vulnerability plus the privilege escalation attack. $5,000 was then awarded for each subsequent SQL injection as the admin account takeover vulnerability that was found, giving the guy a nice payout for a week’s worth of work.