[HD Moore] recently posted an article on Rapid 7’s blog about an interesting security problem. They’ve been doing some research into the security of automated tank gauges (ATGs). These devices are used at gas stations and perform various functions including monitoring fuel levels, tracking deliveries, or raising alarms. [Moore] says that ATGs are used at nearly every fueling station in the United States, but they are also used internationally. It turns out these things are often not secured properly.
Many ATG’s have a built-in serial port for programming and monitoring. Some systems also have a TCP/IP card, or even a serial to TCP/IP adapter. These cards allow technicians to monitor the system remotely. The most common TCP port used in these systems is port 10001. Some of these systems have the ability to be password protected, but Rapid 7’s findings indicate that many of them are left wide open.
The vulnerability was initial reported to Rapid 7 by [Jack Chadowitz]. He discovered the problem due to his work within the industry and developed his own web portal to help people test their own systems. [Jack] approached Rapid 7 for assistance in investigating the issue on a much larger scale.
Rapid 7 then scanned every IPv4 address looking for systems with an open port 10001. Each live system discovered was then sent a “Get In-Tank Inventory Report” request. Any system vulnerable to attack would respond with the station name, address, number of tanks, and fuel types. The scan found approximately 5,800 systems online with no password set. Over 5,300 of these stations are in the United States.
Rapid 7 believes that attackers may be able to perform such functions as to reconfigure alarm thresholds, reset the system, or otherwise disrupt operation of the fuel tank. An attacker might be able to simulate false conditions that would shut down the fuel tank, making it unavailable for use. Rapid 7 does not believe this vulnerability is actively being exploited in the wild, but they caution that it would be difficult to tell the difference between an attack and a system failure. They recommend companies hide their systems behind a VPN for an additional layer of security.
Thermostats can be a pain. They often only look at one sensor in a multi-room home and then set the temperature based on that. The result is one room that’s comfortable and other rooms that are not. Plus, you generally have to get up off the couch to change the temperature. In this day and age, who wants to do that? You could buy an off-the-shelf solution, but sometimes hacking up your own custom hardware is just so much more fun.
[redditseph] did exactly that by modifying his home thermostat to be controlled by a Raspberry Pi. The temperature is controlled by a simple web interface that runs on the Pi. This way, [redditseph] can change the temperature from any room in his home using a computer or smart phone. He also built multi-sensor functionality into his design. This means that the Pi can take readings from multiple rooms in the home and use this data to make more intelligent decisions about how to change the temperature.
The Pi needed a way to actually talk to the thermostat. [redditseph] made this work with a relay module. The Pi flips one side of the relays, which then in turn switches the buttons that came built into the thermostat. The Pi is basically just emulating a human pressing buttons. His thermostat had terminal blocks inside, so [redditseph] didn’t have to risk damaging it by soldering anything to it. The end result is a functional design that has a sort of cyberpunk look to it.
Them kids with those Arduinos don’t know what they’re missing. A serial connection is just too easy, and there’s so much fun to be had with low bandwidth modems. [Mark] made the MicroModem with this in mind. It’s a 1200 baud AFSK modem, capable of APRS, TCP/IP over SLIP, mesh network experimentations, and even long-range radio communication.
As the MicroModem is designed to be an introduction to digital wireless communication, it’s an extremely simple build using only 17 components on a board compatible with the Microduino. The software is built around something called MinimalProtocol1, a protocol that will be received by all other listening stations, features error correction, and automatic data compression. There’s also the ability to send TCP/IP over the link, which allowed [Mark] to load up our retro site at a blistering 1200 bps.
The code is extremely well documented, as seen on the Github for this project, with board files and even breadboard layouts included. [Mark] has three PCBs of his prototype left over, and he’s willing to give those out to other Hackaday readers who would like to give his modem a shot.
A couple of weeks ago we put up a post titled Addressing Microchip’s open source problem where we talked about some of their shortcomings as far as open source code goes, specifically the TCP/IP stack and the USB stack. The comments were predictably fairly negative. The interesting part here is that Microchip actually listened. If you read through all of the comments, you will get a bit of an inside look at what is going on internally at Microchip. At the very end, [Marc] from Microchip left a couple of comments outlining a pair of prizes for independently ported stacks for TCP/IP and USB. Microchip can’t fully open the ones that they have because of legal reasons so they need the help of the development community and they are putting up $1000 for each one to prove that they are serious. If you follow this link you will arrive at a page outlining the rules for the contest.
The gauntlet has been dropped! Do you have chops to pull this off and earn yourself a cool $1000?
If you are a frequent reader, you are undoubtedly familiar with hacker [Sprite_tm]. He has been working with fellow members of the TkkrLab hackerspace to get things ready for their official grand opening on May 28th, and wrote in to share a project he recently completed to kick things off.
As part of their preparations, they have been stocking the joint with all sorts of hacker-friendly goodies including plenty of tools and Club Mate, as well as a vintage ‘1943’ arcade cabinet. The game is a group favorite, though every time the power is turned off, it loses all of the hard-earned high scores. [Sprite_tm] knew he could improve on the current paper-based score register, so he pulled the machine open to see what could be done.
He used an AVR to tap into the machine’s Z80 logic board, allowing him to read and write to the entirety of the game’s RAM whenever he pleased. This enabled him to keep tabs on the high scores, restoring them to memory whenever the machine is powered back on. The addition of the AVR also allowed him to add a TCP/IP interface, which is used to send high scores to Twitter whenever someone beats the previous record.
His modular bus tap can be used in all sorts of Z80-based hardware, so if you have some vintage equipment laying around, be sure to swing by his site for a more detailed look at the build process.
OpenSound Control protocol is an emerging standard for communication between musical programs. It’s meant to replace MIDI. The DSMI, DS Music Interface, team has just added support for OSC. You can now use your DS as generic OSC music controller over WiFi. OSC has TCP/IP support built in, so there is no need to run a host sever to talk to DSMI like you did when they only supported MIDI. We’ve seen OSC used in other projects like the monome. It’s also the basis for the multitouch communication protocol TUIO.
[sgk] built this tiny ethernet board to be used with the Arduino. It’s based on a WIZnet W5100 chip. The chip handles all of the TCP/IP communication and you talk to it via SPI. It’s compatible with the standard Arduino ethernet library. [sgk] hand soldered these boards including the 80pin LQFP main chip. His next project is to put the AVR and W5100 all on the same board. It sounds like he’ll use components larger than 1005 though.