One of the major reasons behind choosing Linux as an operating system is that it’s much more secure than Windows. There are plenty of reasons for this including appropriate user permissions, installing software from trusted sources and, of course, the fact that most software for Linux including the Linux kernel itself is open source which allows anyone to review the code for vulnerabilities. This doesn’t mean that Linux is perfectly secure though, as researchers recently found a major bug found in most major Linux distributions that allows anyone to run code as the root user.
The exploit is a memory corruption vulnerability in Polkit, a framework that handles the privilege level of various system processes. It specifically impacts the program
pkexec. With the proof-of-concept exploit (file download warning) in hand, all an attacker needs to do to escalate themselves to root is to compile the program on the computer and run it as the default user. An example is shown by [Jim MacDonald] on Twitter for those not willing to try this on their own machines.
As bad as this sounds, it seems as though all of the major distributions that this impacts have already released updates that patch the issue, including Debian, Ubuntu, Red Hat, Fedora, open SUSE, and Arch. There is also a temporary workaround that removes read/write permission from the
pkexec program so it can’t run at all. That being said, it might be best to check that your Linux systems are all up-to-date and that no strangers have been typing random commands into the terminal recently.
As the common saying goes, “all networked computers are vulnerable to exploits, but some networked computers are more vulnerable than others”. While not the exact wording from Animal Farm, the saying does have plenty of merit nonetheless. Sure, there are some viruses and issues with Linux distributions but by far most of the exploits target Windows, if only because more people use it daily than any other operating system. The latest Windows 10 exploit, discovered by [jonhat], is almost comically easy too, and involves little more than plugging in a mouse.
While slightly comforting in that an attacker would need physical access to the device rather than simple network access, it is very concerning how simple this attack is otherwise. Apparently plugging in a Razer mouse automatically launches Windows Update, which installs a driver for the mouse. The installation is run with admin privileges, and a Power Shell can be opened by the user simply by pressing Shift and right-clicking the mouse. While [jonhat] originally tried to let the company know, they weren’t responsive until he made the exploit public on Twitter, and are now apparently working on solving the issue.
Others have confirmed the exploit does in fact work, so hopefully there is a patch released soon that solves the issue. In the meantime, we recommend not allowing strangers to plug any devices into your personal computers as a general rule, or plugging in anything where its origins are unknown. Also remember that some attacks don’t required physical or network access at all, like this one which remotely sniffs keystrokes from a wireless keyboard with less than stellar security, also coincidentally built by Microsoft.
After a tough summer of botnet attacks by Internet-of-Things things came to a head last week and took down many popular websites for folks in the eastern US, more attention has finally been paid to what to do about this mess. We’ve wracked our brains, and the best we can come up with is that it’s the manufacturers’ responsibility to secure their devices.
Chinese DVR manufacturer Xiongmai, predictably, thinks that the end-user is to blame, but is also consenting to a recall of up to
300 million 4.3 million of their pre-2015 vintage cameras — the ones with hard-coded factory default passwords. (You can cut/paste the text into a translator and have a few laughs, or just take our word for it. The company’s name gets mis-translated frequently throughout as “male” or “masculine”, if that helps.)
Xiongmai’s claim is that their devices were never meant to be exposed to the real Internet, but rather were designed to be used exclusively behind firewalls. That’s apparently the reason for the firmware-coded administrator passwords. (Sigh!) Anyone actually making their Internet of Things thing reachable from the broader network is, according to Xiongmai, being irresponsible. They then go on to accuse a tech website of slander, and produce a friendly ruling from a local court supporting this claim.
Whatever. We understand that Xiongmai has to protect its business, and doesn’t want to admit liability. And in the end, they’re doing the right thing by recalling their devices with hard-coded passwords, so we’ll cut them some slack. Is the threat of massive economic damage from a recall of insecure hardware going to be the driver for manufacturers to be more security conscious? (We kinda hope so.)
Meanwhile, if you can’t get enough botnets, here is a trio of recent articles (one, two, and three) that are all relevant to this device recall.
[Nathan] is a mobile application developer. He was recently debugging one of his new applications when he stumbled into an interesting security vulnerability while running a program called Charles. Charles is a web proxy that allows you to monitor and analyze the web traffic between your computer and the Internet. The program essentially acts as a man in the middle, allowing you to view all of the request and response data and usually giving you the ability to manipulate it.
While debugging his app, [Nathan] realized he was going to need a ride soon. After opening up the Uber app, he it occurred to him that he was still inspecting this traffic. He decided to poke around and see if he could find anything interesting. Communication from the Uber app to the Uber data center is done via HTTPS. This means that it’s encrypted to protect your information. However, if you are trying to inspect your own traffic you can use Charles to sign your own SSL certificate and decrypt all the information. That’s exactly what [Nathan] did. He doesn’t mention it in his blog post, but we have to wonder if the Uber app warned him of the invalid SSL certificate. If not, this could pose a privacy issue for other users if someone were to perform a man in the middle attack on an unsuspecting victim.
[Nathan] poked around the various requests until he saw something intriguing. There was one repeated request that is used by Uber to “receive and communicate rider location, driver availability, application configurations settings and more”. He noticed that within this request, there is a variable called “isAdmin” and it was set to false. [Nathan] used Charles to intercept this request and change the value to true. He wasn’t sure that it would do anything, but sure enough this unlocked some new features normally only accessible to Uber employees. We’re not exactly sure what these features are good for, but obviously they aren’t meant to be used by just anybody.
[HeadlessZeke] was excited to try out his new AT&T wireless cable box, but was quickly dismayed by the required wireless access point that came bundled with it. Apparently in order to use the cable box, you also need to have this access point enabled. Not one to blindly put unknown devices on his network, [HeadlessZeke] did some investigating.
The wireless access point was an Arris VAP2500. At first glance, things seemed pretty good. It used WPA2 encryption with a long and seemingly random key. Some more digging revealed a host of security problems, however.
It didn’t take long for [HeadlessZeke] to find the web administration portal. Of course, it required authentication and he didn’t know the credentials. [HeadlessZeke] tried connecting to as many pages as he could, but they all required user authentication. All but one. There existed a plain text file in the root of the web server called “admin.conf”. It contained a list of usernames and hashed passwords. That was strike one for this device.
[HeadlessZeke] could have attempted to crack the passwords but he decided to go further down this rabbit hole instead. He pulled the source code out of the firmware and looked at the authentication mechanism. The system checks the username and password and then sets a cookie to let the system know the user is authenticated. It sounds fine, but upon further inspection it turned out that the data in the cookie was simply an MD5 hash of the username. This may not sound bad, but it means that all you have to do to authenticate is manually create your own cookie with the MD5 hash of any user you want to use. The system will see that cookie and assume you’ve authenticated. You don’t even have to have the password! Strike two.
Now that [HeadlessZeke] was logged into the administration site, he was able to gain access to more functions. One page actually allows the user to select a command from a drop down box and then apply a text argument to go with that command. The command is then run in the device’s shell. It turned out the text arguments were not sanitized at all. This meant that [HeadlessZeke] could append extra commands to the initial command and run any shell command he wanted. That’s strike three. Three strikes and you’re out!
[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.