Friday Hack Chat: Security for IoT

securityforiot-01Over the last few weeks, our weekly Hack Chats on have gathered a crowd. This week, we’re talking about the greatest threat humanity has ever faced: toasters with web browsers.

The topic of this week’s Hack Chat is Security for IoT, because someone shut down the Internet with improperly configured webcams.

This chat is hosted by the Big Crypto Team at the University of Pittsburgh. [Wenchen Wang], [Ziyue Sun], [Brandon Contino], and [Nick Albanese] will be taking questions about lightweight devices connected to the Internet. Discussion will include building things that connect to larger networks securely.

The Big Crypto team at UP are thinking about the roadblocks people have to implement security in their projects, and if apathy or ignorance is the main reason security isn’t even considered in the worst IoT offenders.

The Hack Chat is scheduled for Friday, February 24th at noon PST (20:00 GMT).

Here’s How To Take Part:

join-hack-chatOur Hack Chats are live community events on the Hack Chat group messaging.

Log into, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Upcoming Hack Chats

These Hack Chats are becoming very popular, and that’s due in no small part to the excellent lineup of speakers we’ve hosted. Already, we’ve had [Lady Ada], [Sprite_tm], and [bunnie] — engineers, hackers, and developers who are at the apex of their field. We’re not resting on our laurels, though: in a few weeks we’ll be hosting Hack Chats with [Roger Thornton], an engineer with Raspberry Pi, and Fictiv, masters of mechanical manufacturing.

Using SDR to Take Control of Your Home Security System

[Dan Englender] was working on implementing a home automation and security system, and while his house was teeming with sensors, they used a proprietary protocol which was not supported by the open source system he was trying to implement. The problem with home automation and security systems is the lack of standardization – or rather, the large number of (often incompatible) standards used to ensure consumers get tied in to one specific system. He has shared the result of his efforts at getting the two to talk to each other via his project decode345.

The result enabled him to receive signals from Honeywell’s 5800 series of wireless products and interface them with OpenHAB — a vendor and technology agnostic open source automation software. OpenHAB offers “bindings” that allow a wide variety of systems and hardware to be integrated. Unfortunately for [Dan], this exhaustive list does not yet include support for the (not very popular) 345MHz protocol used by the Honeywell 5800 system, hence his project. Continue reading “Using SDR to Take Control of Your Home Security System”

Popular Printers Pwned In Prodigious Page Prank

A new day dawns, and we have another story involving insecure networked devices. This time it is printers of all makes and descriptions that are causing the panic, as people are finding mystery printouts bearing messages such as this:

Stackoverflowin has returned to his glory, your printer is part of a botnet, the god has returned

Well that’s it then, you can’t argue with a deity, especially one who has apparently created a botnet from the world’s printing devices. Printer owners the world over are naturally worried about their unexpected arrival, and have appeared on support forums and the like to express their concern.

We are of course used to taking everything our printers tell us at face value. Low on ink? I hear you, my inanimate reprographic friend! But when our printer tells us it’s part of a botnet perhaps it’s time to have a little think. It is entirely possible that someone could assemble a botnet of compromised printers, but in this case we smell a rat. Only in farcical crime dramas do crooks announce their crimes in such a theatrical fashion, you might say it’s the point of a botnet not to be detected by its host. Reading some of the reports it seems that many of the affected systems have port 9100 open to the world, that’s the standard TCP printer port, so it seems much more likely that someone has written a little script that looks for IP addresses with port 9100 open, and trolls them with this message.

The real message here is one with which we expect Hackaday readers will be very familiar, and which we’ve covered before. Many network connected appliances have scant regard for security, and are a relative push-over for an attacker. The solution is relatively straightforward to those of a technical inclination, be aware of which services the devices is exposing, lock down services such as uPNP and close any open ports on your router. Unfortunately these steps are probably beyond many home users, whose routers remain with their default manufacturer’s settings for their entire lives. It’s a shame our printer troll didn’t add a link to basic router security tips.

If you want to have a little fun, some of the printed pages include an email address for ‘the god’. It would be fun to figure out who this is, right?

33C3: How Can You Trust Your Random Numbers?

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

mpv-shot0012-zoomCryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?”

Autonomous Delivery: Your Impulse Buys Will Still Be Safe

I heard a “Year in Review” program the other day on NPR with a BBC World Service panel discussion of what’s ahead for 2017. One prediction was that UAV delivery of packages would be commonplace this year, and as proof the commentator reported that Amazon had already had a successful test in the UK. But he expressed skepticism that it would ever be possible in the USA, where he said that “the first drone that goes over somebody’s property will be shot down and the goods will be taken.”

He seemed quite sincere about his comment, but we’ll give him the benefit of the doubt that he was only joking to make a point, not actually grotesquely ignorant about the limitations of firearms or being snarky about gun owners in the US. Either way, he brings up a good point: when autonomous parcel delivery is commonplace, who will make sure goods get to the intended recipient?

Continue reading “Autonomous Delivery: Your Impulse Buys Will Still Be Safe”

TruffleHog Sniffs Github for Secret Keys

Secret keys are quite literally the key to security in software development. If a malicious actor gains access to the keys securing your data, you’re toast. The problem is, to use keys, you’ve got to write them down somewhere – oftentimes in the source code itself. TruffleHog has come along to sniff out those secret keys in your Github repository.

It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.

Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.

For a real world example of stolen secret keys, read up on this HDMI breakout that sniffs HDCP keys.

OWL Insecure Internet of Energy Monitors

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to hack read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.