The folks at Pen Test Partners decided to take a look at electric vehicle chargers. Many of these chargers are WiFi-connected, and let you check your vehicle’s charge state via the cloud. How well are they secured? Predictably, not as well as they could be.
The worst of the devices tested, Project EV, didn’t actually have any user authentication on the server side API. Knowing the serial number was enough to access the account and control the device. The serial numbers are predictable, so taking over every Project EV charger connected to the internet would have been trivial. On top of that, arbitrary firmware could be loaded remotely onto the hardware was possible, representing a real potential problem.
The EVBox platform had a different problem, where an authenticated user could simply specify a security role. The tenantadmin role was of particular interest here, working as a superadmin that could see and manage multiple accounts. This flaw was patched within an impressive 24 hours. The
EVBox charger, as well as several other devices they checked had fundamental security weaknesses due to their use of Raspberry Pi hardware in the product. Edit: The EVBox was *not* one of the devices using the Pi in the end product.
Wait, What About the Raspberry Pi?
Apparently the opinion that a Raspberry Pi didn’t belong in IoT hardware caught Pen Test Partners some flack, because a few days later they published a follow-up post explaining their rationale. To put it simply, the Pi can’t do secure boot, and it can’t do encrypted storage. Several of the flaws they found in the chargers mentioned above were discovered because the device filesystems were wide open for inspection. A processor that can handle device encryption, ideally better than the TPM and Windows Bitlocker combination we covered last week, gives some real security against such an attack.
Now Linux on the Pi can certainly do an encrypted filesystem, but the real problem is the storage of the encryption key. Without a secure enclave in the SoC, it’s very tricky to have an encryption key that isn’t trivially read by an attacker with physical access. On a laptop it’s not a problem, since the user can provide a password that’s used as part of the encryption key, but who wants to type a password into every IoT device every time they power them on?
[Amy Burnett] found something on an Ubuntu system that didn’t make sense — A Docker command throwing a segfault. What was even weirder, it only happened when running the command in a particular folder, where a
libc.so.6 file was also stored. Her security-sense tingled. For some reason, that library file was probably getting loaded when the docker command was run. A quick
strace confirmed the theory, but why was that happening? The answer is a security vulnerability in Ubuntu’s new Snapcraft package manager. Ubuntu has started providing certain programs as snaps rather than traditional packages.
The culprit is the Snapcraft logic used to build the
LD_LIBRARY_PATH local variable. If one of the variables used to build that variable is blank, you end up with a double colon as part of the string. Linux interprets that as the current directory, and hence running a package installed via Snapcraft will potentially load dynamic libs unintentionally. A suggested attack is to distribute a video file in an archive, and including a malicious library. Any user that just extracts the files and plays the video in a Snapcraft installed player will automatically load the malicious library. The problem was tracked as CVE-2020-27348 and fixed late 2020.
A trio of stories about request forgeries surfaced this week, the first being a cross site request forgery (CSRF) on OkCupid. To start, a CSRF attack is when visiting one website can trigger an action on a different website. Cross-Origin Resource Sharing is supposed to be the solution to this problem, but there are caveats that you should know about. The important one here is that an HTML form can send a POST off to another domain, even if the CORS header isn’t set. The common way to protect against this attack is a CSRF token than confirms that the request really is coming from an approved site. OkCupid didn’t use these tokens, and as such it was possible to build a web page that triggers an action on behalf of the user.
One of the other common request forgery patterns is the Server-Side Request Forgery, (SSRF). This one is a bit different: Here we fool a server into generating an unintended request. This is usually in the context of a front-end server sending traffic to non-public back-end services. Here it’s the ability to include an internal URL as a parameter for calling the Facebook API. It seems that the API endpoint naively accepts any URL as a valid image, even if that location isn’t one that shouldn’t be publicly accessible. In this case, this action leaked the contents of the internal endpoint, allowing the researcher to snag a canary token, and score a pair of $30,000 bounties.
The final story broke late in the week, and it’s all about HTTP/2. This relatively new protocol is a potential replacement for HTTP, and is all about making the web quicker and more flexible. Guess what comes with a new protocol. Yeah, new creative ways to break it. [James Kettle] of PortSwigger covers quite a few potential vulnerabilities related to request smuggling, mostly involving HTTP/2 translation to HTTP 1.1 by a front-end server. These attacks are things like including colons or newlines in HTTPS/2 fields, where those symbols are interpreted differently once translated to HTTP 1.1.
The most important vulnerability announced is probably CVE-2021-33193, a flaw in Apache’s
mod_proxy. It’s a problem where whitespace in an incoming header is understood differently by the front-end HTTP/2 server than it is on the back-end. This allows an attacker to ask for a privileged endpoint, say
/wp-admin, but disguise that request as something uninteresting. This maneuver can bypass the access rules and allow access to these locations. The flaw is fixed in Apache master, and will be part of 2.4.49 release, but here we are talking about the vulnerability, and 2.4.49 isn’t yet out. If you run a vulnerable server, it might be time to go disable HTTP/2.
Hallucinating TLS Decryption
SySS just released Hallucinate as an open source project. This project is all about decrypting SSL traffic, not on the wire, but by hooking into the OS or application that is doing the encryption. The potential use cases are quite wide. Trying to figure out what data a closed-source binary is sending up to the cloud? Troubleshooting a hard-to-pin-down bug in encrypted data? Hallucinate might just help. It can spit out a decrypted PCAP file, or even run Python scripts to manipulate encrypted data in real time. Definitely a useful trick to add to your library.
Google’s Take on Kernel Security
[Kees Cook] of Google’s Open Source Security Team published a post this week, talking about the state of security in and around the Linux kernel. He makes the point that while the kernel runs very well when things are working properly, when it breaks, it can break in insecure ways. Put another way, he would like to see more work done to make the kernel resilient to compromise even in the case of flaws. While the changes needed to do this aren’t spelled out in the post, I can only think of efforts like adding Rust to the kernel and doing additional address randomization.
The majority of the post isn’t aimed at the upstream kernel, but at downstream integrators. The advice here is simple. Track the latest release or stable kernel. Don’t use a 10 year old kernel. Is that a challenge because you have so much out-of-tree kernel code? Upstream your changes. It makes everyone more secure. Rather than spending so much engineering effort backporting fixes to your ancient kernel, spend that effort making the upstream kernel more secure. It’s interesting that he ends the article with the opinion that the Linux kernel and toolchain needs about 100 more skilled engineers to be effectively maintained.