Author: Pedro Umbelino

77 Articles

Nitro Powered Rotary Tool

May 30, 2017 by 26 Comments

We really don’t know if the world needs it but we’re sure glad [johnnyq90] took the time to build one. We’re talking about a nitro powered rotary tool. Based on a Kyosho GX-12 nitro engine, commonly used in R/C cars, [johnnyq90] machines almost all other parts in his shop to make a really cool ‘Nitro-Dremel’. But success didn’t come at the first try.

The first prototype was made using a COX 049 engine but the lack of proper lubrication cause damage to the crankshaft. Because of this setback, [johnnyq90] swaps it out with a O.S Max 10 Aero engine he had lying around in the shop. That didn’t work out so well as the engine was quite hard to start. On the third try he finally decided to use the 2.1 cc Kyosho GX-12 engine to power up his 20.000 rpm tool. As noisy as one would expect and, from the videos it seems quite powerful too as it easily pierces through an aluminium block, cuts steel like a breeze, and breezes through other less demanding feats.

But [johnnyq90] is no stranger to nitro engines nor to Hackaday. In the past he built, among other things, a nitro powered cordless drill and showed impressive feats of machining in a micro version of a Tesla turbine. We wonder what’s next…. a nitro powered tattoo gun perhaps?

In the 20 minute video after the break, we enjoy watching the construction of the ‘Nitro-Dremel’, as well as other parts from two previously failed prototypes:

Continue reading “Nitro Powered Rotary Tool” →

Hackaday Prize Entry: LiFePO4wered/Pi+

May 26, 2017 by 21 Comments

For some of you the title might seem familiar, as [Patrick Van Oosterwijck] LiFePO4wered/Pi project is a quite successful Hackaday.io project. Now he’s designing from scratch the plus version to fill in some gaps and solve some of the challenges that affected the initial project. So what exactly is LiFePO4wered/Pi+ and what can it do?

In a nutshell, it’s a smart UPS for the Raspberry Pi. The standard version allows a Model A+ and Pi Zero to run on battery for over 2 hours, and the B+, B2 and B3 to run for at least an hour (it maybe less, depending on the system load, of course). It implements two-way communications between the power system and the Raspberry Pi (running the open-source daemon) over the I2C bus. This allows for continuous measurement of the battery voltage and load voltage, with user programmable thresholds for boot, clean shutdown and hard power down. There’s a touch pad that provides clean boot/shutdown capability even in a headless setup, a wake timer allowing the Raspberry Pi to be off for low duty cycle applications and an auto-boot feature to maximize uptime by making the Raspberry Pi run whenever there is sufficient battery power.

That’s the standard version, which we covered last year… what else could the plus version have?

Well, to start, it brings more current to run complete systems with LCD screen and hard drives, the previous version was limited when it came to current. It will provide the option for a wider range of input power sources, such as solar panels, which is pretty nice. The on/off button and the power led will no longer be soldered on the main board so they can ‘relocated’ elsewhere, for example, when making a custom enclosure. Detection of input power to trigger automatic boot and shutdown will be added and last, but not least, a real-time clock with absolute time wake up.

So there it is, the new LiFePO4wered/Pi+ version, with all bells and whistles for the Raspberry Pi enthusiast.

The HackadayPrize2017 is Sponsored by:

Hacked By Subtitles

May 25, 2017 by 15 Comments

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

May 25, 2017 by 25 Comments

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.

Hackaday Prize Entry: Heart Failure Detection Device

May 25, 2017 by 19 Comments

Early and low-cost detection of a Heart Failure is the proposal of [Jean Pierre Le Rouzic] for his entry for the 2017 Hackaday Prize. His device is based on a low-cost Doppler device, like those fetal Doppler devices used to listen an unborn baby heart, feeding a machine learning algorithm that could differentiate between a healthy and an unhealthy heart.

The theory behind it is that a regular, healthy heart tissue has a different acoustic impedance than degenerated tissue. Based on the acoustic impedance, the device would classify the tissue as: normal, degenerated, granulated or fibrous. Each category indicates specific problems mostly in connective tissues.

There are several advantages to have a working device like the one [Rouzic] is working on. To start, it would be possible to use it at home, without the intervention of a doctor or medical staff. It seems to us that would be as easy as using a blood pressure device or a fetal Doppler. It’s also relatively cheap (estimated under 150$) and it needs no gel to work. We covered similar projects that measure different heart signals, like Open Source electrocardiography, but ECG has the downfall that it requires attaching electrodes to the body.

One interesting proposed feature is that what is learn from a single case, is sent to every devices at their next update, so the devices get ‘smarter’ as they are used. Of course, there are a lot of ways for this to go wrong, but it’s a good idea to begin with.

The HackadayPrize2017 is Sponsored by:

Hackaday Prize Entry: WiFi EPaper

May 22, 2017 by 32 Comments

[Frank Buss] designed an electronic version of a sticky note: a WiFi enabled, solar-powered ePaper, with magnets embedded in the casing. It’s based on the new ESP32, and the idea is that you can update it via your smart-phone or over the internet via a cloud app to show any message you want. Being an ePaper display, the power consumption is greatly reduced, at least if you are cautious using the ESP32.

The final version plans to poll a server once per hour to get a new image to display. Depending on the final size and battery constraints, our guess is that it could probably poll often. Of course, that depends on the available charging light, which is usually reduced when you are inside the house. The project also has 3 buttons to provide user input, which can be customized for a wide array of actions, as [Frank Buss] notes:

For example install it on the fridge of your grandma, who might not be very proficient in using modern internet connected devices. Then you can send her birthday wishes, or remind her of schedules. And the buttons could be used as a feedback channel, like confirming a date. Or when installed at a public place, it can act as a bulletin board. Or it can be used for a modern form of internet connected graffiti or other art projects. The possibilities are infinite.

This project immediately reminds us of the recent SHA2017 badge we covered some days ago, with a bigger display and solar panel or the e-ink wifi display project from last year.

The latest version is being tested with a black/white/red ePaper display, as we can see in the video:

Continue reading “Hackaday Prize Entry: WiFi EPaper” →

Git Shell Bypass, Less Is More

May 10, 2017 by 4 Comments

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?