Bill’s 100 Year-Old Smart Home

[Bill]  purchased a house in Central Florida, and like any good hacker, he started renovating, pulling Ethernet cables, and automating things. Lucky for us, he decided to write up his experiences and lessons learned. He found a few problems along the way, like old renovations that compromised the structure of the pool house. After getting the structural problems sorted, he started installing Insteon smart switches. If automated lighting is of interest, and you don’t want to wire up relays yourself, Insteon might be the way to go.

He linked the buildings together with a wireless bridge, and then worked out how to automatically reset the PoE switch when the wireless bridge hangs, automating that recovery process. For your viewing pleasure, he even has one of the security cameras streaming 24/7 online.

His blog looks like a good resource to keep an eye on, and we wouldn’t be surprised to have more of his work show up here on Hackaday. For more home automation goodness, check out some of our previous articles on the subject.

Apple Kernel Code Vulnerability Affected All Devices

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices”

When Good Software Goes Bad: Malware In Open Source

Open Source software is always trustworthy, right? [Bertus] broke a story about a malicious Python package called “Colourama”. When used, it secretly installs a VBscript that watches the system clipboard for a Bitcoin address, and replaces that address with a hardcoded one. Essentially this plugin attempts to redirects Bitcoin payments to whoever wrote the “colourama” library.

Why would anyone install this thing? There is a legitimate package named “Colorama” that takes ANSI color commands, and translates them to the Windows terminal. It’s a fairly popular library, but more importantly, the name contains a word with multiple spellings. If you ask a friend to recommend a color library and she says “coulourama” with a British accent, you might just spell it that way. So the attack is simple: copy the original project’s code into a new misspelled project, and add a nasty surprise.

Sneaking malicious software into existing codebases isn’t new, and this particular cheap and easy attack vector has a name: “typo-squatting”.  But how did this package get hosted on PyPi, the main source of community contributed goodness for Python? How many of you have downloaded packages from PyPi without looking through all of the source? pip install colorama? We’d guess that it’s nearly all of us who use Python.

It’s not just Python, either. A similar issue was found on the NPM javascript repository in 2017. A user submitted a handful of new packages, all typo-squatting on existing, popular packages. Each package contained malicious code that grabbed environment variables and uploaded them to the author. How many web devs installed these packages in a hurry?

Of course, this problem isn’t unique to open source. “Abstractism” was a game hosted on Steam, until it was discovered to be mining Monero while gamers were playing. There are plenty of other examples of malicious software masquerading as something else– a sizable chunk of my day job is cleaning up computers after someone tried to download Flash Player from a shady website.

Buyer Beware

In the open source world, we’ve become accustomed to simply downloading libraries that purport to do exactly the cool thing we’re looking for, and none of us have the time to pore through the code line by line. How can you trust them?

Repositories like PyPi do a good job of faithfully packaging the libraries and programs that are submitted to them. As the size of these repositories grow, it becomes less and less practical for every package to be manually reviewed. PyPi lists 156,750 projeccts. Automated scanning like [Bertus] was doing is a great step towards keeping malicious code out of our repositories. Indeed, [Bertus] has found eleven other malicious packages while testing the PyPi repository. But cleverer hackers will probably find their way around automated testing.

That the libraries are open source does add an extra layer of reliability, because the code can in principal be audited by anyone, anytime. As libraries are used, bugs are found, and features are added, more and more people are intentionally and unintentionally reviewing the code. In the “colourama” example, a long Base64 string was decoded and executed. It doesn’t take a professional researcher to realize something fishy is going on. At some point, enough people have reviewed a codebase that it can be reasonably trusted. “Colorama” has well over a thousand stars on Github, and 28 contributors. But did you check that before downloading it?

Typo-squatting abuses trust, taking advantage of a similar name and whoever isn’t paying quite close enough attention. It’s not practical for every user to check every package in their operating system. How, then, do we have any trust in any install? Cryptography solves some of these problems, but it cannot overcome the human element. A typo in a url, trusting a brand new project, or even obfuscated C code can fool the best of us from time to time.

What’s the solution? How do we have any confidence in any of our software? When downloading from the web, there are some good habits that go a long way to protect against attacks. Cross check that the project’s website and source code actually point to each other. Check for typos in URLs. Don’t trust a download just because it’s located on a popular repository.

But most importantly, check the project’s reputation, the number of contributors to the project, and maybe even their reputation. You wouldn’t order something on eBay without checking the seller’s feedback, would you? Do the same for software libraries.

A further layer of security can be found in using libraries supported by popular distributions. In quality distributions, each package has a maintainer that is familiar with the project being maintained. While they aren’t checking each line of code of every project, they are ensuring that “colorama” gets packaged instead of “colourama”. In contrast to PyPi’s 156,750 Python modules, Fedora packages only around 4,000. This selection is a good thing.

Repositories like PyPi and NPM are simply not the carefully curated sources of trustworthy software that we sometimes think them to be– and we should act accordingly. Look carefully into the project’s reputation. If the library is packaged by your distribution of choice, you can probably pass this job off to the distribution’s maintainers.

At the end of the day, short of going through the code line by line, some trust anchor is necessary. If you’re blindly installing random libraries, even from a “trustworthy” repository, you’re letting your guard down.

Hack My House: ZoneMinder’s Keeping an Eye on the Place

Hacks are often born out of unfortunate circumstances. My unfortunate circumstance was a robbery– the back door of the remodel was kicked in, and a generator was carted off. Once the police report was filed and the door screwed shut, it was time to order cameras. Oh, and record the models and serial numbers of all my tools.

We’re going to use Power over Ethernet (POE) network cameras and a ZoneMinder install. ZoneMinder has a network trigger capability, and we’ll wire some magnetic switches to our network of PXE booting Pis, using those to inform the Zoneminder server of door opening events. Beyond that, many newer cameras support the Open Network Video Interface Forum (ONVIF) protocol and can do onboard motion detection. We’ll use the same script, running on the Pi, to forward those events as well.

Many of you have pointed out that Zoneminder isn’t the only option for open source camera management. MotionEyeOS, Pikrellcam, and Shinobi are all valid options.  I’m most familiar with Zoneminder, even interviewing them on FLOSS Weekly, so that’s what I’m using.  Perhaps at some point we can revisit this decision, and compare the existing video surveillance systems.

Continue reading “Hack My House: ZoneMinder’s Keeping an Eye on the Place”

LibSSH Vuln: You Don’t Need to See my Authentication

Another day, another CVE (Common Vulnerabilities and Exposures). Getting a CVE number assigned to a vulnerability is a stamp of authenticity that you have a real problem on your hands. CVE-2018-10933 is a worst case scenario for libssh.  With a single response, an attacker can completely bypass authentication, giving full access to a system.

Before you panic and yank the power cord on your server, know that libssh is not part of OpenSSH. Your Linux box almost certainly uses OpenSSH as the SSH daemon, and that daemon is not vulnerable to this particular problem. Libssh does show up in a few important places, the most notable is probably Github and their security team already announced their implementation was not vulnerable.

Libssh has released a new version that fixes the problem. Stick around for the details after the break.

Continue reading “LibSSH Vuln: You Don’t Need to See my Authentication”

FIDO2 Authentication In All The Colors

Here at Hackaday, we have a soft spot for security dongles. When a new two-factor-authentication dongle is open source, uses USB and NFC, and supports FIDO2, the newest 2FA standard, we take notice. That just happens to be exactly what [Conor Patrick] is funding on Kickstarter.

We’ve looked at [Conor]’s first generation hardware key, and the process of going from design to physical product.  With that track record, the Solo security key promises to be more than the vaporware that plagues crowdfunding services.

Another player, Yubikey, has also recently announced a new product that supports FIDO2 and NFC. While Yubikey has stepped away from their early open source policy, Solo is embracing the open source ethos. The Kickstarter promises the release of both the software and hardware design as fully open, using MIT and CC BY-SA licenses.

For more information, see the blog post detailing the project goals and initial design process.  As always, caveat emptor, but this seems to be a crowdfunding project worth taking a look at.

Hack My House: Running Raspberry Pi Without an SD Card

Many of us have experienced the pain that is a Raspberry Pi with a corrupted SD card. I suspect the erase-on-write nature of flash memory is responsible for much of the problem. Regardless of the cause, one solution is to use PXE booting with the Raspberry Pi 3. That’s a fancy way to say we’ll be booting the Raspberry Pi over the network, instead of from an SD card.

What does this have to do with Hacking My House? As I discussed last time, I’m using Raspberry Pi as Infrastructure by building them into the walls of every room in my house. You don’t want to drag out a ladder and screwdriver to swap out a misbehaving SD card, so booting over the network is a really good solution. I know I promised we’d discuss cabling and cameras. Think of this as a parenthetical article — we’ll talk about Ethernet and ZoneMinder next time.

So let’s dive in and see what the Preboot Execution Environment (PXE) is all about and how to use PXE with Raspberry Pi.

Continue reading “Hack My House: Running Raspberry Pi Without an SD Card”