Spaghetti Detective Users Boiled By Security Gaffe

August 20, 2021 by Tom Nardi 23 Comments

For readers that might not spend their free time watching spools of PLA slowly unwind, The Spaghetti Detective (TSD) is an open source project that aims to use computer vision and machine learning to identify when a 3D print has failed and resulted in a pile of plastic “spaghetti” on the build plate. Once users have installed the OctoPrint plugin, they need to point it to either a self-hosted server that’s running on a relatively powerful machine, or TSD’s paid cloud service that handles all the AI heavy lifting for a monthly fee.

Unfortunately, 73 of those cloud customers ended up getting a bit more than they bargained for when a configuration flub allowed strangers to take control of their printers. In a frank blog post, TSD founder Kenneth Jiang owns up to the August 19th mistake and explains exactly what happened, who was impacted, and how changes to the server-side code should prevent similar issues going forward.

Screenshot from TSD web interface — TSD allows users to remotely manage and monitor their printers.

For the record, it appears no permanent damage was done, and everyone who was potentially impacted by this issue has been notified. There was a fairly narrow window of opportunity for anyone to stumble upon the issue in the first place, meaning any bad actors would have had to be particularly quick on their keyboards to come up with some nefarious plot to sabotage any printers connected to TSD. That said, one user took to Reddit to show off the physical warning their printer spit out; the apparent handiwork of a fellow customer that discovered the glitch on their own.

According to Jiang, the issue stemmed from how TSD associates printers and users. When the server sees multiple connections coming from the same public IP, it’s assumed they’re physically connected to the same local network. This allows the server to link the OctoPrint plugin running on a Raspberry Pi to the user’s phone or computer. But on the night in question, an incorrectly configured load-balancing system stopped passing the source IP addresses to the server. This made TSD believe all of the printers and users who connected during this time period were on the same LAN, allowing anyone to connect with whatever machine they wished.

Changed TSD code from GitHub — New code pushed to the TSD repository limits how many devices can be associated with a single IP.

The mix-up only lasted about six hours, and so far, only the one user has actually reported their printer being remotely controlled by an outside party. After fixing the load-balancing configuration, the team also pushed an update to the TSD code which puts a cap on how many printers the server will associate with a given IP address. This seems like a reasonable enough precaution, though it’s not immediately obvious how this change would impact users who wish to add multiple printers to their account at the same time, such as in the case of a print farm.

While no doubt an embarrassing misstep for the team at The Spaghetti Detective, we can at least appreciate how swiftly they dealt with the issue and their transparency in bringing the flaw to light. This is also an excellent example of how open source allows the community to independently evaluate the fixes applied by the developer in response to a discovered flaw. Jiang says the team will be launching a full security audit of their own as well, so expect more changes getting pushed to the repository in the near future.

We were impressed with TSD when we first covered it back in 2019, and glad to see the project has flourished since we last checked in. Trust is difficult to gain and easy to lose, but we hope the team’s handling of this issue shows they’re on top of things and willing to do right by their community even if it means getting some egg on their face from time to time.

RealSense No Longer Makes Sense For Intel

August 20, 2021 by Roger Cheng 15 Comments

We love depth-sensing cameras and every neat hack they enabled, but this technological novelty has yet to break through to high volume commercial success. So it was sad but not surprising when CRN reported that Intel has decided to wind down their RealSense product line.

As of this writing, one of the better confirmations for this report can be found on the RealSense SDK GitHub repository README. The good news is that core depth-sensing RealSense products will continue business as usual for the foreseeable future, balanced by the bad news that some interesting offshoots (facial authentication, motion tracking) will be declared “End of Life” immediately and phased out over the next six months.

This information tells us while those living out on the bleeding edge will have to scramble, there is no immediate crisis for everyone else, whether they be researchers, hobbyists, or product planners. But this also means there will be no future RealSense cameras, kicking off many “What’s Next?” discussions in various communities. Like this thread on ROS (Robot Operating System) Discourse.

Three popular alternatives offer distinctly different tradeoffs. The “Been Around The Block” name is Occipital, with their more expensive Structure Pro sensor. The “Old Name, New Face” option is Microsoft Azure Kinect, the latest non-gaming-focused successor to the gaming peripheral that started it all. And let’s not forget OAK-D as the “New Kid On The Block” that started with a crowdfunding campaign and building an user community by doing things like holding contests. Each of these will appeal to a different niche, and we’ll keep our eye open in the future. Let’s see if any of them find the success that eluded the original Kinect, Google’s Tango, and now Intel’s RealSense.

[via Engadget]

Get Your Flex On With The FlowIO Platform

August 20, 2021 by Dave Rowntree 7 Comments

Hackaday Prize 2021 entry FlowIO Platform promises to be to pneumatics what Arduino is to Electronics. The modular platform comprises a common controller/valve block, a selection of differently sized pumps, and a few optional connectivity and sensing blocks. With Arduino software support as well as as Javascript and web-GUI, there’s a way to program this no matter what the level of experience the user has.

flowIO exploded view from http://www.softrobotics.io/flowio

This last point is a critical one for the mission [Ali Shtarbanov] from the MIT Media Lab is setting out for this project. He reminds us that in decades gone by, there was a significant barrier to entry for anyone building electronics prototypes. Information about how to get started was also much harder to by before the internet really got into gear.

It’s a similar story for software, with tools like Scratch and Python lowering the barrier to entry and allowing more people to get their toes wet and build some confidence.

But despite some earlier work by projects like the Soft Robotics Toolkit and Programmable-Air, making a start on lowering the bar for pneumatics support for soft robotics, and related applications, the project author still finds areas for further improvement. FlowIO was designed from the ground-up to be wearable. It appears to be much smaller, more portable and supports more air ports and a greater array of sensing and connectivity than previous Open Source work to date.

Creative Commons Hardware

Whilst you can take all the plans (free account signup required) and build yourself a FlowIO rig of your very own, the project author offers another solution. Following on from the Wikipedia model of free sharing and distribution of information, FlowIO offers its hardware for free, for the common good. Supported by donations to the project, more hardware is produced and distributed to those who need it. The only ask is that redundant kits are passed on or returned to base for upgrade, rather than landfill.

Continue reading “Get Your Flex On With The FlowIO Platform” →

This Week In Security: Breaking Apple ID, Political Hacktivism, And Airtag Tracking

August 20, 2021 by Jonathan Bennett 10 Comments

Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.

Continue reading “This Week In Security: Breaking Apple ID, Political Hacktivism, And Airtag Tracking” →

Thor does battle with a man shooting lasers from his hands

Of Lasers And Lightning: Thwarting Thor With Technology

August 17, 2021 by Adam Zeloof 45 Comments

Most of us don’t spend that much time thinking about lightning. Every now and then we hear some miraculous news story about the man who just survived his fourth lightning strike, but aside from that lightning probably doesn’t play that large a role in your day-to-day life. Unless, that is, you work in aerospace, radio, or a surprisingly long list of other industries that have to deal with its devastating effects.

Humans have been trying to protect things from lightning since the mid-1700s, when Ben Franklin conducted his fabled kite experiment. He created the first lightning rod, an iron pole with a brass tip. He had speculated that the conductor would draw the charge out of thunderclouds, and he was correct. Since then, there haven’t exactly been leaps and bounds in the field of lightning rod design. They are still, essentially, a metal rods that attract lightning strikes and shunt the energy safely into the earth. Just as Ben Franklin first did in the 1700s, they are still installed on buildings today to protect from lightning and do a fine job of it. While this works great for most structures, like your house for example, there are certain situations where a tall metal pole just won’t cut it.

Continue reading “Of Lasers And Lightning: Thwarting Thor With Technology” →

Tesla Automatic Driving Under Scrutiny By US Regulators

August 16, 2021 by Al Williams 66 Comments

The US National Highway Traffic Safety Administration (NHTSA) has opened a formal investigation about Tesla’s automatic driving features (PDF), claiming to have identified 11 accidents that are of concern. In particular, they are looking at the feature Tesla calls “Autopilot” or traffic-aware cruise control” while approaching stopped responder vehicles like fire trucks or ambulances. According to the statement from NHTSA, most of the cases were at night and also involved warning devices such as cones, flashing lights, or a sign with an arrow that, you would presume, would have made a human driver cautious.

There are no details about the severity of those accidents. In the events being studied, the NHTSA reports that vehicles using the traffic-aware cruise control “encountered first responder scenes and subsequently struck one or more vehicles involved with those scenes.”

Despite how they have marketed the features, Tesla will tell you that none of their vehicles are truly self-driving and that the driver must maintain control. That’s assuming a lot, even if you ignore the fact that some Tesla owners have gone to great lengths to bypass the need to have a driver in control. Tesla has promised full automation for driving and is testing that feature, but as of the time of writing the company still indicates active driver supervision is necessary when using existing “Full Self-Driving” features.

We’ve talked a lot about self-driving car safety in the past. We’ve also covered some of the more public accidents we’ve heard about. What do you think? Are self-driving cars as close to reality as they’d like you to believe? Let us know what you think in the comments.

This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes

August 13, 2021 by Jonathan Bennett 14 Comments

We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.

Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.

During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.

They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed. Continue reading “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes” →