Some switches in Cisco’s 9000 series are susceptible to a remote vulnerability, numbered CVE-2019-1804 . It’s a bit odd to call it a vulnerability, actually, because the software is operating as intended. Cisco shipped out these switches with the same private key hardcoded in software for all root SSH logins. Anyone with the key can log in as root on any of these switches.
Cisco makes a strange claim in their advisory, that this is only exploitable over IPv6. This seems very odd, as there is nothing about SSH or the key authentication process that is IPv6 specific. This suggests that there is possibly another blunder, that they accidentally left the SSH port open to the world on IPv6. Another possibility is that they are assuming that all these switches are safely behind NAT routers, and therefore inaccessible through IPv4. One of the advantages/disadvantages of IPv6 is that there is no NAT, and all the network devices are accessible from the outside network. (Accessible in the sense that a route exists. Firewalling is still possible, of course.)
It’s staggering how many devices, even high end commercial devices, are shipped with unintentional yet effective backdoors, just like this one. Continue reading “This Week in Security: Backdoors in Cisco Switches, PGP Spoofing in Emails, Git Ransomware”
Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.
A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.
Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:
- It must be possible to set up the device without direct physical access
- You must be able to remotely turn it on and off as needed.
- It needs to be accessible from the Internet.
The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?
As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.
Continue reading “The Linux Throwie: A Non-Spacefaring Satellite”
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”
At this point, everyone has already heard that Microsoft is buying GitHub. Acquisitions of this scale take time, but most expect everything to be official by 2019. The general opinion online seems to be one of unease, and rightfully so. Even if we ignore Microsoft’s history of shady practices, there’s always an element of unease when somebody new takes over something you love. Sometimes it ends up being beneficial, the beginning of a new and better era. But sometimes…
Let’s not dwell on what might become of GitHub. While GitHub is the most popular web-based interface for Git, it’s not the only one. For example GitLab, a fully open source competitor to GitHub, is reporting record numbers of new repositories being created after word of the Microsoft buyout was confirmed. But even GitLab, while certainly worth checking out in these uncertain times, might be more than you strictly need.
Let’s be realistic. Most of the software projects hackers work on don’t need even half the features that GitHub/GitLab offer. Whether you’ve simply got a private project you want to maintain revisions of, or you’re working with a small group collaboratively in a hackerspace setting, you don’t need anything that isn’t already provided by the core Git software.
Let’s take a look at how quickly and easily you can setup a private Git server for you and your colleagues without having to worry about Microsoft (or anyone else) having their fingers around your code.
Continue reading “Keep it Close: A Private Git Server Crash Course”
When we say “hack” here we most often mean either modifying something to do something different or building something out of parts. But as we build more Internet-connected things, it is worthwhile to think about the other kind of hack where people gain unauthorized access to a system. For example, you wouldn’t think a remote control would be a big deal for hackers. But the Logitech Harmony Hub connects to the Internet and runs Linux. What’s more is it can control smart devices like door locks and thermostats, so hacking it could cause problems. FireEye’s Mandian Red Team set out to hack the Harmony and found it had a lot of huge security problems.
The remote didn’t check Logitech’s SSL certificate for validity. It didn’t have a secure update process. There were developer tools (an SSH server) left inactive in the production firmware and — surprisingly — the root password was blank! The team shared their findings with Logitech before publishing the report and the latest patch from the company fixes these problems. But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
In fact, that’s the most interesting part of the story is the blow-by-blow description of the attack. We won’t spoil the details, but the approach was to feed the device a fake update package that turned on a dormant ssh server. Although they started by trying to solder wires to a serial port, that wasn’t productive and the final attack didn’t require any of that.
We’ve looked at some ways to harden Linux systems like the Raspberry Pi before, but honestly, it is an ongoing battle. We’ve seen plenty of devices with cybersecurity holes in them — some not found by good guy hackers first.
[Rafael Scheel] a security consultant has found that hacking smart TVs takes nothing much more than an inexpensive DVB-T transmitter, The transmitter has to be in range of the target TV and some malicious signals. The hack works by exploiting hybrid broadcast broadband TV signals and widely known about bugs in web browsers commonly run on smart TVs, which seem run in the background almost all the time.
Scheel was commissioned by Cyber security company Oneconsult, to create the exploit which once deployed, gave full root privileges enabling the attacker to setup and SSH into the TV taking complete control of the device from anywhere in the world. Once exploited the rogue code is even unaffected by device reboots and factory resets.
Once a hacker has control over the TV of an end user, he can harm the user in a variety of ways, Among many others, the TV could be used to attack further devices in the home network or to spy on the user with the TV’s camera and microphone. – Rafael Scheel
Smart TV’s seem to be suffering from IoT security problems. Turning your TV into an all-seeing, all-hearing surveillance device reporting back to it’s master is straight out of 1984.
A video of a talk about the exploit along with all the details is embedded below.
Continue reading “Remotely Get Root On Most Smart TVs With Radio Signals”
Did you know you can run remote Linux GUI programs in a browser with HTML5 support? It’s even secure because you can use SSH tunneling and that little trick means you don’t even need to open additional ports. If this sounds like gibberish, read on, it’s actually pretty easy to get up and running.
I recently was a guest on a Houston-based podcast, and the hosts asked me if the best thing about writing for Hackaday was getting to work with the other Hackaday staff. I told them that was really good, but what I like best was interacting with people (well, most people) in the comments. That sometimes you’d post an article and someone would bring a topic up in comments that would really knock your socks off. This is how I wound up with this nearly ideal remote access solution, that requires nothing on the remote side but a web browser.
A while back I posted about keeping programs running after log off on a Linux box. The post was mostly about non-GUI programs but you could use NX or VNC to handle it. In the comments, someone mentioned how unhappy they’d been with recent copies of NX and another commenter called [Screen for X11] posted about a tool called xpra.
Continue reading “Linux-Fu: Applications on the Web”