When [Nishanth]’s Subaru BRZ came to a sudden halt, he was saddened by the wait to get a new engine installed. Fortunately, he was able to cheer himself up by hacking it into a car simulator in the mean time. This would have the added benefit of not being limited to just driving on the Road Atlanta where the unfortunate mishap occurred, but any course available on Forza and similar racing games.
On paper it seemed fairly straight-forward: simply tap into the car’s CAN bus for the steering, throttle, braking and further signals, convert it into something a game console or PC can work with and you’re off to the races. Here the PC setup is definitely the cheapest and easiest, with a single part required: a Macchina M2 Under the Dash kit ($97.50). The XBox required over $200 worth of parts, including the aforementioned Macchina part, an XBox Adaptive Controller and a few other bits and pieces. And a car, naturally.
The Macchina M2 is the part that listens to the CAN traffic via the OBD2 port, converting it into something that resembles a USB HID gamepad. So that’s all a matter of plug’n’play, right? Not so fast. Every car uses their own CAN-based system, with different peripherals and addresses for them. This means that with the Macchina M2 acquired, [Nishanth]’s first task was to reverse-engineer the CAN signals for the car’s controls.
At this point the story is pretty much finished for the PC side of things, but the XBox One console is engineered to only accept official peripherals. The one loop-hole here is the Adaptive Controller, designed for people with disabilities, which allows the use of alternative inputs. This also enables using a car as an XBox One controller, which is an interesting side-effect.
This has been an interesting week. First off, security researchers at Armis discovered a set of serious vulnerabilities in the vxWorks Real Time Operating System (RTOS). Released under a name that sounds like the title of a western or caper movie, Urgent/11. Not familiar with vxWorks? It’s a toss-up as to whether vxWorks or Linux is more popular for embedded devices. Several printer brands, Arris modems, Sonicwall firewalls, and a whole host of other industrial and medical devices run the vxWorks RTOS.
Several of these vulnerabilities are in the network stack, rather than in applications. The worst offender is CVE-2019-12256, a vulnerability in error handling. An ICMP error response is generated from an incoming packet, and assumptions are made about that incoming packet. When data is copied from that packet into the ICMP error, the length is not first checked, allowing unconfined memory write. If this sounds familiar, it should. We covered a similar vulnerability in Apple’s XNU kernel not long ago.
This particular vulnerability can compromise a vxWorks machine even without an opened port. The saving grace of that vulnerability applies here: a maliciously crafted packet is necessarily malformed, and won’t navigate public routing. In other words, it’s LAN only, and can’t be sent over the internet.
A second class of vulnerability, where the name comes from, is related to the TCP urgent pointer. This rarely used TCP feature was intended to allow more up-to-date information to supersede data still being processed. Not only has TCP urgent not been widely used, the specifications were not written particularly well, with the various RFC documents describing conflicting implementations. It’s surprising that vxWorks supports it at all, but isn’t particularly surprising that their implementation is flawed. Manipulation of the data stream can cause a length integer to underflow. The nature of binary arithmetic means that underflowing an unsigned integer causes it to wrap around to maximum value, which can lead to writing packet data in the buffer in unexpected memory locations. These vulnerabilities require an established TCP connection, but the researchers describe several scenarios where that could be accomplished by an attacker.
The last RCE vulnerability they describe is in the DHCP client, ipdhcpc. This is a very simple vulnerability. One section of code allocates a buffer for DHCP options, but allocates 24 bytes fewer than the maximum size. An attacker could use this 24 byte overflow to manipulate the data structure and potentially jump execution into manipulated memory.
Update (2019-08-02 09:15 UTC-7): Hackaday received a statement from SonicWall that they made a patch for this vulnerability back on July 19th:
Ensuring the security of our customers is a responsibility we take seriously at SonicWall and we work vigilantly to always keep our customers secure. SonicWall physical firewall appliances running certain versions of SonicOS contain vulnerabilities in code utilized for remote management. At this time, there is no indication that the discovered vulnerabilities are being exploited in the wild. The patches are available now and we strongly advised our partners and end users July 19 th to apply the SonicOS patch immediately.
Capital One made use of Amazon AWS for storing customer data. This isn’t surprising, many companies have turned to Amazon’s seemingly inexhaustible cloud computing platform for storing large data sets. It seems, however, that Capital One failed to configure the security properly on that bucket. (As many other companies have done.) Information was leaked for over an estimated 100 million customers. A former Amazon employee has been arrested, and seems to have posted at least a portion of that data in a Github gist.
Reading between the lines, it seems that this was a very simple mistake. Perhaps credentials were leaked, or the S3 bucket was publicly available. That particular detail has not been released. There is something to be said for Capital One’s response to the incident. They were anonymously informed of the existence of the gist on July 17, using their responsible disclosure process. By the 29th, they had fixed the misconfiguration, coordinated with law enforcement, and publicly announced the breach. A twelve day turn-around is an impressive response, particularly when so many companies have tried to hide or ignore similar breaches.
Yes, the transfer went through, but the the county had been hit with a social engineering scam. The report refers to it as an Email Account Compromise (EAC) scam, which seems to indicate that the scammer first gained access to a legitimate email account of the contractor in question. Alternatively, an attacker could simply spoof the sender’s email address, and set a different reply-to field. Unless a user was particularly watching for such a scheme, it would be easy to overlook the discrepancy. In any case, even after recovering some of the transferred money, the county seems to be out about $1.7 million. These scams are becoming more and more popular, so remember, don’t believe anything you read in an email.
The Weird and Wacky
And to round out this week’s news, yet another [Satoshi Nakamoto] candidate has been found: Linus Torvalds. While it appears to be a serious suggestion, I’ll just note that the author doesn’t have his name attached to this article. He does make one interesting observation — git is the killer blockchain app. You see, I tend to compare blockchain to the laser. Both were very clever inventions, but didn’t have any immediate uses. They were solutions in search of a problem. This article points out that core concepts of blockchain are present in git, which seems to be an accurate and clever observation. So what is blockchain good for? Git!
In the old days, a physical button or switch on the dashboard of your car would have been wired to whatever device it was controlling. There was potentially a relay in the mix, but still, it wasn’t too hard to follow wires through the harness and figure out where they were going. But today, that concept is increasingly becoming a quaint memory.
But if you’re the kind of person who doesn’t like to have things done for them (a safe bet, since you’re reading Hackaday), don’t worry. [TJ] starts off his write-up with an overview of how you can read and parse CAN messages on the Arduino with the MCP2515 chip. He breaks his sample Sketch down line by line explaining how it all works so that even if you’ve never touched an Arduino before, you should be able to get the gist of what’s going on.
As it turns out, reading messages on the CAN bus and acting on them is fairly straightforward. The tricky part is figuring out what you’re looking for. That’s where the code [TJ] is working on comes in. Rather than having to manually examine all the messages passing through the network and trying to ascertain what they correspond to, his program listens while the user repeatedly presses the button they want to identify. With enough samples, the code can home in on the proper CAN ID automatically.
Video games, while entertaining to be sure, are a great way to experience things that could not easily be recreated in real life. Shooting aliens on a giant ring in space is an obvious example, but there are some more realistic examples that video games make much more accessible, such as driving a race car. You can make that experience as realistic as you want, too, and can even go as far as using a real car as your controller.
All modern cars use a communication system to allow their various modules to talk to one another. Fuel injection, throttle position, pedal positions, steering wheel angle, and climate control systems can all communicate on the CAN bus, and by tapping into that information the car can be used as a controller for a video game. Once you plug in to the OBD-II port on a car, you’ll need a piece of software to decode all of that information. [Andrew] uses uinput, a tool that allows Linux machines to take any input signal and map it in any way that can be programmed.
The build also includes the use of an integrated pico projector, allowing the car to be parked and turned into a simulator at any time. It’s similar to another project which used a Mazda instead of a Chevrolet Volt, but it just goes to show how straightforward it can be to take information from the CAN bus of a modern car.
Part of the fun of watching action movies is imagining yourself as the main character, always going on exciting adventures and, of course, being accompanied by the perfect soundtrack to score the excitement and drama of your life. While having an orchestra follow you around might not always be practical, [P1kachu] at least figured out how to get some musical orchestration to sync up with how he drives his car, Fast-and-Furious style.
The idea is pretty straightforward: when [P1kachu] drives his car calmly and slowly, the music that the infotainment system plays is cool and reserved. But when he drops the hammer, the music changes to something more aggressive and in line with the new driving style. While first iterations of his project used the CAN bus, he moved to Japan and bought an old Subaru that doesn’t have CAN. The new project works on something similar called Subaru Select Monitor v1 (SSM1), but still gets the job done pretty well.
The hardware uses an Asus Tinkerboard and a Raspberry Pi with the 7″ screen, and a shield that can interface with CAN (and later with SSM1). The new music is selected by sensing pedal position, allowing him to more easily trigger the aggressive mode that his previous iterations did. Those were done using vehicle speed as a trigger, which proved to be ineffective at producing the desired results. Of course, there are many other things that you can do with CAN bus besides switching up the music in your car.
The CAN bus is a rich vein to mine for a hacker: allowing the electronic elements of most current vehicles to be re-purposed and controlled with ease. [MikrocontrollerProjekte] has reverse engineered a CAN bus media and navigation controller and connected it to an STM32F746G-Discovery board. The STM32 is in turn connected to an Android phone, and allows the media controller to trigger a large number of functions on the phone, including music playback, maps, and general Android navigation.
When reverse engineering the controller, [MikrocontrollerProjekte] employed a variety of approaches. A small amount of information was found online, some fuzzing was done with random CAN bus IDs and messages, as well as some data logging with the device inside the car to identify message data to the relevant IDs on the bus.
The STM32F746G-Discovery board acts as a Human Interface Device (HID), emulating a mouse and keyboard connected to the Android phone via USB OTG. The LCD screen shows the output of the keystrokes and touchpad area. We’re not sure how useful the mouse-emulation would be, given that the phone has a touchscreen, but the media functions work really well, and would also make a really snazzy music controller for a PC.
The CAN bus has become a staple of automotive engineering since it was introduced in the late ’80s, but in parallel with the spread of electronic devices almost every single piece of equipment inside a car has been put on the CAN bus. While there are opinions on whether or not this is a good thing, the reality is that enough data is gathered on this bus to turn an unmodified modern car into a video game controller with just a little bit of code.
The core of [Scott]’s project is a laptop and a Python program that scrapes information about the car from the car’s CAN bus, including positions of the pedals and the steering wheel. This information can be accessed by plugging an adapter into the OBD-II port (a standard for all cars made after 1995). From there, the laptop parses the CAN data into keyboard and mouse commands for your video game of choice.
This is an interesting investigation into the nitty-gritty of the CAN bus, but also a less dangerous demonstration of all of the data available from the car than some other cases we’ve seen. At least [Scott]’s Mazda (presumably) lacks any wireless attack vectors!