Malduino Elite – First Impressions

A while back, I wrote an article about Malduino, an Arduino-based, open-source BadUSB device. I found the project interesting so I signed up for an Elite version and sure enough, the friendly postman dropped it off in my mail box last Friday, which means I got to play around with it over the weekend. For those who missed the article, Malduino is USB device which is able to emulate a keyboard and inject keystrokes, among other things. When in a proper casing, it will just look like a USB flash drive. It’s like those things you see in the movies where a guy plugs in a device and it auto hacks the computer. It ships in two versions, Lite and Elite, both based on the ATmega32U4.

The Lite version is really small, besides the USB connector it only contains a switch, which allows the user to choose between running and programming mode, and a LED, which indicates when the script has finished running.

Original Malduino Elite sketch and Lite prototype

The Elite version is bigger, comes with a Micro-SD card reader and four DIP switches, which allow the user to choose which script to run from the card. It also has the LED, which indicates when a script has finished to run. This allows the user to burn the firmware only once and then program the keystroke injection scripts that stored in the Micro-SD card, in contrast to the Lite version which needs to be flashed each time a user wants to run a different script.

These are the two Malduinos and because they are programmed straight from the Arduino IDE, every feature I just mentioned can be re-programmed, re-purposed or dropped all together. You can buy one and just choose to use it like a ‘normal’ Arduino, although there are not a lot of pins to play around with. This freedom was one the first things I liked about it and actually drove me to participate in the crowd-funding campaign. Read on for the full review.
Continue reading “Malduino Elite – First Impressions”

Radio Controlled Pacemakers Are Easily Hacked

Doctors use RF signals to adjust pacemakers so that instead of slicing a patient open, they can change the pacemakers parameters which in turn avoids unnecessary surgery. A study on security weaknesses of pacemakers (highlights) or full Report (PDF) has found that pacemakers from the main manufacturers contain security vulnerabilities that make it possible for the devices to be adjusted by anyone with a programmer and proximity. Of course, it shouldn’t be possible for anyone other than medical professionals to acquire a pacemaker programmer. The authors bought their examples on eBay.

They discovered over 8,000 known vulnerabilities in third-party libraries across four different pacemaker programmers from four manufacturers.  This highlights an industry-wide problem when it comes to security. None of the pacemaker programmers required passwords, and none of the pacemakers authenticated with the programmers. Some home pacemaker monitoring systems even included USB connections in which opens up the possibilities of introducing malware through an infected pendrive.

The programmers’ firmware update procedures were also flawed, with hard-coded credentials being very common. This allows an attacker to setup their own authentication server and upload their own firmware to the home monitoring kit. Due to the nature of the hack, the researchers are not disclosing to the public which manufacturers or devices are at fault and have redacted some information until these medical device companies can get their house in order and fix these problems.

This article only scratches the surface for an in-depth look read the full report. Let’s just hope that these medical companies take action as soon as possible and resolve these issue’s as soon as possible. This is not the first time pacemakers have been shown to be flawed.

Hacked by Subtitles

CheckPoint researchers published in the company blog a warning about a vulnerability affecting several video players. They found that VLC, Kodi (XBMC), Popcorn-Time and strem.io are all vulnerable to attack via malicious subtitle files. By carefully crafting a subtitles file they claim to have managed to take complete control over any type of device using the affected players when they try to load a video and the respective subtitles.

According to the researchers, things look pretty grim:

We estimate there are approximately 200 million video players and streamers that currently run the vulnerable software, making this one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years. (…) Each of the media players found to be vulnerable to date has millions of users, and we believe other media players could be vulnerable to similar attacks as well.

One of the reasons you might want to make sure your software is up to date is that some media players download subtitles automatically from several shared online repositories. An attacker, as the researchers proved, could manipulate the website’s ranking algorithm and not only would entice more unsuspecting users to manually download his subtitles,  but would also guarantee that his crafted malicious subtitles would be those automatically downloaded by the media players.

No additional details were disclosed yet about how each video player is affected, although the researchers did share the details to each of the software developers so they can tackle the issue. They reported that some of the problems are already fixed in their current versions, while others are still being investigated. It might be a good idea to watch carefully and update your system before the details come out.

Meanwhile, we can look at the trailer:

Continue reading “Hacked by Subtitles”

Linux SambaCry

Great news everyone, Windows is not the only operating system with remote code execution via SMB. Linux has also its own, seven-year-old version of the bug. /s

This Linux remote execution vulnerability (CVE-2017-7494) affects Samba, the Linux re-implementation of the SMB networking protocol, from versions 3.5.0 onwards (since 2010). The SambaCry moniker was almost unavoidable.

The bug, however, has nothing to do on how Eternalblue works, one of the exploits that the current version of WannaCry ransomware packs with. While Eternalblue is essentially a buffer overflow exploit, CVE-2017-7494 takes advantage of an arbitrary shared library load.  To exploit it, a malicious client needs to be able to upload a shared library file to a writeable share, afterwards it’s possible for the attacker to cause the server to load and execute it. A Metasploit exploit module is already public, able to target Linux ARM, X86 and X86_64 architectures.

A patch addressing this defect has been posted to the official website and Samba 4.6.4, 4.5.10 and 4.4.14 have been issued as security releases to correct the defect. Patches against older Samba versions are also available. If you can’t apply the patch at the moment, the workaround is to add the parameter “nt pipe support = no” to the [global] section of your smb.conf and restart smbd. Note that this can disable some expected functionality for Windows clients.

Meanwhile, NAS vendors start to realise they have work on their hands. Different brands and models that use Samba for file sharing (a lot, if not all, of them provide this functionality) will have to issue firmware updates if they want to patch this flaw. If the firmware updates for these appliances take the same time they usually do, we will have this bug around for quite some time.

Git Shell Bypass, Less is More

We’ve always been a fans of wargames. Not the movie (well, also the movie) but I’m referring to hacking wargames. There are several formats but usually you have access to an initial shell account somewhere, which is level0, and you have to exploit some flaw in the system to manage to get level1 permissions and so forth. Almost always there’s a level where you have to exploit a legitimate binary (with some shady permissions) that does more than what the regular user thinks.

In the case of CVE-2017-8386, less is more.

[Timo Schmid] details how the git-shell, a restricted shell meant to be used as the upstream peer in a git remote session over a ssh tunnel, can be abused in order to achieve arbitrary file read, directory listing and somewhat restricted file write. The git-shell basic idea is to restrict the allowed commands in an ssh session to the ones required by git (git-receive-pack, git-upload-pack, git-upload-archive). The researcher realized he could pass parameters to these commands, like the flag –help:

$ ssh git@remoteserver "git-receive-pack '--help'"

GIT-RECEIVE-PACK(1)            Git Manual             GIT-RECEIVE-PACK(1)

NAME
 git-receive-pack - Receive what is pushed into the repository
[...]

What the flag does is make the git command open the man page of git, which is passed on to a pager program, usually less. And this is where it get interesting. The less command, if running interactively, can do several things you would expect like searching for text, go to a line number, scroll down and so on. What it can also do is open a new file (:e), save the input to a file (s) and execute commands (!). To make it run interactively, you have to force the allocation of a PTY in ssh like so:

$ ssh -t git@remoteserver "git-receive-pack '--help'"

GIT-RECEIVE-PACK(1) Git Manual GIT-RECEIVE-PACK(1)

NAME
 git-receive-pack - Receive what is pushed into the repository

 Manual page git-receive-pack(1) line 1 (press h for help or q to quit)
 

Press h for help and have fun. One caveat is that usual installations the code execution will not really execute arbitrary commands, since the current running login shell is the git-shell, restricted to only some white listed commands. There are, however, certain configurations where this might happen, such as maintaining bash or sh as a login shell and limit the user in ways that they can only use git (such as in shared environments without root access). You can see such example here.

The quickest solution seems to be to enable the no-pty flag server-side, in the sshd configuration. This prevents clients from requesting a PTY so less won’t run in an interactive mode.

$ man less

LESS(1) General Commands Manual LESS(1)

NAME
less - opposite of more

Ironic, isn’t it?

Keep the Burglars Away With Some Pi

Ten years ago, we never imagined we would be able to ward off burglars with Pi. However, that is exactly what [Nick] is doing with his Raspberry Pi home security system.

We like how, instead of using a standard siren, [Nick] utilized his existing stereo system to play a custom audio file that he created. (Oh the possibilities!) How many off the shelf alarm systems can you do that with?

The Pi is the brains of the operation, running an open source software program called Home Assistant. If any of the Z-Wave sensors in his house are triggered while the alarm system is armed, the system begins taking several actions. The stereo system is turned on via IR so that the digital alarm audio file can be played. Lights flash on and off. An IP camera takes several snapshots and emails them to [Nick].

Home Assistant didn’t actually have the ability to send images in an email inline at the time that [Nick] was putting together his system. What did [Nick] do about that? He wrote some code to give it that ability, and submitted it through GitHub. That new code was put into a later version of the program. Ah, the beauty of open source software.

Perhaps the most important part of this project is that there were steps taken to help keep the wife-approval factor of the system on the positive side. For example, he configured one of the scripts so that even if the alarm is tripped multiple times in succession, the alarm won’t play over itself repeatedly.

This isn’t [Nick’s] first time being featured here. Check out another project of his which involves a couple of Pi’s communicating with each other via lasers.

 

Hackaday Prize Entry: Secure Storage on SD Cards

Here’s a puzzler for you: how do you securely send data from one airgapped computer to another? Sending it over a network is right out, because that’s the entire point of an airgap. A sneakernet is inherently insecure, and you shouldn’t overestimate the security of a station wagon filled with tapes. For his Hackaday Prize entry, [Nick Sayer] has a possible solution. It’s the Sankara Stones from Indiana Jones and the Temple of Doom, or a USB card reader that requires two cards. Either way, it’s an interesting experiment in physical security for data.

The idea behind the Orthrus, a secure RAID USB storage device for two SD cards, is to pair two SD cards. With both cards, you can read and write to this RAID drive without restriction. With only one, the data is irretrievable so they are safe during transit if shipped separately.

The design for this device is based around the ATXMega32A4U. It’s pretty much what you would expect from an ATMega, but this has a built-in full speed USB interface and hardware AES support. The USB is great for presenting two SD cards as a single drive, and the AES port is used to encrypt the data with a key that is stored in a key storage block on each card.

For the intended use case, it’s a good design. You can only get the data off of these SD cards if you have both of them. However, [Nick] is well aware of Schneier’s Law — anyone can design a cryptosystem that they themselves can’t break. That’s why he’s looking for volunteers to crack the Orthrus. It’s an interesting challenge, and one we’d love to see broken.