The Nissan Leaf is the best-selling electric car of all time so far, thanks largely to it being one of the first mass produced all-electric EVs. While getting into the market early was great for Nissan, they haven’t made a lot of upgrades that other EV manufacturers have made and are starting to lose customers as a result. One of those upgrades is charge limiting, which allows different charging rates to be set from within the car. With some CAN bus tinkering, though, this feature can be added to the Leaf.
Limiting the charging rate is useful when charging at unfamiliar or old power outlets which might not handle the default charge rate. In Europe, which has a 240V electrical distribution system, Leafs will draw around 3 kW from a wall outlet which is quite a bit of power. If the outlet looks like it won’t support that much power flow, it’s handy (and more safe) to be able to reduce that charge rate even if it might take longer to fully charge the vehicle. [Daniel Öster]’s modification requires the user to set the charge rate by manipulating the climate control, since the Leaf doesn’t have a comprehensive user interface.
The core of this project is performed over the CAN bus, which is a common communications scheme that is often used in vehicles and is well-documented and easy to take advantage of. Luckily, [Daniel] has made the code available on his GitHub page, so if you’re thinking about trading in a Leaf for something else because of its lack of features it may be time to reconsider.
Whilst swapping out the stereo in his car for a more modern Android based solution, [Aaron] noticed that it only utilised a single CAN differential pair to communicate with the car as opposed to a whole bundle of wires employing analogue signalling. This is no surprise, as modern cars invariably use the CAN bus to establish communication between various peripherals and sensors.
In a series of videos, [Aaron] details how he used this opportunity to explore some of the nitty-gritty of CAN communication. In Part 1 he designs a cheap, custom CAN bus sniffer using an Arduino, a MCP2515 CAN controller and a CAN bus driver IC, demonstrating how this relatively simple hardware arrangement could be used along with open source software to decode some real CAN bus traffic. Part 2 of his series revolves around duping his Android stereo into various operational modes by sending the correct CAN packets.
These videos are a great way to learn some of the basic considerations associated with the various abstraction layers typically attributed to CAN. Once you’ve covered these, you can do some pretty interesting stuff, such as these dubious devices pulling a man-in-the-middle attack on your odometer! In the meantime, we would love to see a Part 3 on CAN hardware message filtering and masks [Aaron]!
In the days of carburetors and leaf spring suspensions, odometer fraud was pretty simple to do just by disconnecting the cable or even winding the odometer backwards. With the OBD standard and the prevalence of electronics in cars, promises were made by marketing teams that this risk had all but been eliminated. In reality, however, the manipulation of CAN bus makes odometer fraud just as easy, and [Andras] is here to show us exactly how easy with a teardown of a few cheap CAN bus adapters.
We featured another project that was a hardware teardown of one of these devices, but [Andras] takes this a step further by probing into the code running on the microcontroller. One would imagine that basic measures would have been taken by the attackers to obscure code or at least disable debugging modes, but on this one no such effort was made. [Andras] was able to dump the firmware from both of his test devices and start analyzing them.
Analyzing the codes showed identical firmware running on both devices, which made his job half as hard. It looked like the code was executing a type of man-in-the-middle attack on the CAN bus which allowed it to insert the bogus mileage reading. There’s a lot of interesting information in [Andras]’s writeup though, so if you’re interested in CAN bus or attacks like this, it’s definitely worth a read.
Progress and the proliferation of computers in automotive applications have almost made the shade tree mechanic a relic of the past. Few people brave the engine compartment of any car made after 1999 or so, and fewer still dive into the space behind the dashboard. More’s the pity, because someone may be trying to turn back the odometer with one of these nefarious controller area network (CAN bus) dongles.
Sold through the usual outlets and marketed as “CAN bus filters,” [Big Clive] got a hold of one removed from a 2015 Mercedes E-Class sedan, where a mechanic had found it installed between the instrument cluster and the OEM wiring harness. When the dongle was removed, the odometer instantly added 40,000 kilometers to its total, betraying someone’s dishonesty.
[Big Clive]’s subsequent teardown of the unit showed that remarkably little is needed to spoof a CAN bus odometer. The board has little more than an STM32F microcontroller, a pair of CAN bus transceiver chips, and some support circuitry like voltage regulators. Attached to a wiring harness that passes through most of the lines from the instrument cluster unmolested while picking off the CAN bus lines, the device can trick the dashboard display into showing whatever number it wants. The really interesting bit would be the code, into which [Clive] does not delve. That’s a pity, but as he points out, it’s likely the designers set the lock bit on the microcontroller to cover their tracks. There’s no honor among thieves.
We found this plunge into the dark recesses of the automotive world fascinating, and [Big Clive]’s tutelage top-notch as always. If you need to get up to speed on CAN bus basics, check out [Eric Evenchick]’s series on automotive network hacking.
For home use IoT systems, getting sensor data from tons of physical locations centralized to a single Raspberry Pi can be a difficult job, especially when considering the power consumption that’s necessary for doing it all over WiFi. When you’re using an ESP8266, for instance, swapping out batteries and accounting for connectivity issues can be a major hassle for a long-term solution. The NoCAN platform, created by [Alain Pannetrat], solves this problem using a wired approach that improves the use of the CAN bus.
Since SPI and I2C only work for short distances, approaches like RS-485 and CAN bus are a better bet for this type of setup. For systems with one centralized point, RS-485 works best – thus, the CAN bus is the better approach when you’re considering using multiple masters in a single environment.
CAN devices typically need a static address, so messaging involves sending data to the known address of the destination device. With NoCAN, a dynamic address assignment scheme allows nodes to request an address from a node manager on boot-up (similar to DHCP). A command line application also allows users to send and receive message from nodes using a pub/sub implementation – a device sends messages to a channel, and every device subscribed to the channel receives the message.
The hardware for the NoCAN platform consists of a Raspberry Pi with a “PiMaster” HAT and an Arduino-compatible CANZERO board. The PiMaster HAT uses an STM32F042 ARM Cortex M0 MCU, acting as an interface between the Pi and the CAN bus as well as preventing over-current events with a software-controlled smart switch. The CANZERO is based on the the SAMD21G18 ARM Cortex M0+ running at 48MHz, similar to the Arduino MKR Zero, with CAN bus networking using the STM32F042 ARM Cortex M0. The double MCU design allows the secondary MCU to reset the primary if it gets stuck due to a programming error, with the messages sent over the CAN bus.
To join the network together, a four-wire cable daisy-chains the nodes in the bus network, providing connectivity for up to 1000 feet. Either 12V or 24V DC power runs through the network, stepping down to 5V or 3.3V at each node. The approach is similar to PoE (power over Ethernet), although it is slower and lower in cost. Overall, it seems like a good solution for environments where wireless connectivity simply doesn’t cut it.
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.
They come in through the firewall.
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.
Cabarrus County, NC
It seemed simple enough. The general contractor for the county’s new school building needed to update bank account information. The appropriate forms were signed and filed, and the information was updated. Nothing seemed amiss unto two months later, when the contractor notified the county that they had missed a scheduled payment of 2.5 million dollars. But the transaction went through, and the money was transferred to the account on file.
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!
