The people at Pen Test Partners decided Look at the electric car chargerMany of these chargers are WiFi connected, allowing you to check the charging status of the vehicle through the cloud. How safe are they? Predictably, it is not as good as they thought.
The worst device tested, Project EV, does not actually have any user authentication on the server-side API. Knowing the serial number is sufficient to access the account and control the device. The serial number is predictable, so it would be trivial to take over every Project EV charger connected to the Internet. Most importantly, it is possible to remotely load arbitrary firmware onto the hardware, which represents a real potential problem.
The EVBox platform has a different problem. The authenticated user can simply assign a security role. The role of tenant administrator is particularly interesting here, as a super administrator who can view and manage multiple accounts. This vulnerability was patched in an impressive 24 hours. Due to the use of Raspberry Pi hardware in the product, the EVBox charger and several other devices they checked have fundamental security vulnerabilities.
Wait, what about the Raspberry Pi?
Obviously, the notion that Raspberry Pi is not part of IoT hardware caused some criticism from Pen Test Partners, because a few days later They published a follow-up article explaining their reasonsTo put it simply, the Raspberry Pi cannot be used for secure boot, nor can it be used for encrypted storage. The few defects they found in the above chargers are because the device file system is open for inspection. A processor that can handle device encryption, ideally better than the TPM and Windows Bitlocker combination we introduced last week, can provide some real security for this type of attack.
Now Linux on Pi can of course be an encrypted file system, but the real problem is the storage of encryption keys. If there is no secure enclave in the SoC, having an encryption key that cannot be easily read by an attacker with physical access is very tricky. This is not a problem on a laptop, because the user can provide a password as part of the encryption key, but who wants to enter the password every time every IoT device is turned on?
Snapcraft side load
[Amy Burnett] I found something meaningless on the Ubuntu system-a Docker command that throws a segfault.What’s even stranger is that this happens only when you run the command in a specific folder, where libc.so.6 The file is also stored. Her sense of security began to sting. For some reason, the library file may be loaded when running the docker command.A quick strace This theory is confirmed, but why is it so? The answer is a security hole in Ubuntu’s new Snapcraft package manager. Ubuntu has begun to provide certain programs as snaps instead of traditional packages.
The culprit is used to build LD_LIBRARY_PATH Local variables. If one of the variables used to construct the variable is empty, you will end up with a double colon as part of the string. Linux interprets it as the current directory, so running a package installed via Snapcraft may unintentionally load a dynamic library. The suggested attack is to distribute video files in archives and contain malicious libraries. Any user who only extracts the file and plays the video in the player installed by Snapcraft will automatically load the malicious library.The issue was tracked as CVE-2020-27348 and Restoration at the end of 2020.
Request forgery
Three stories about request forgery appeared this week, the first one is Cross-site request forgery (CSRF) on OkCupid. First, a CSRF attack refers to a visit to a website that can trigger an operation on another website. Cross-domain resource sharing should be the solution to this problem, but you should be aware of some considerations. The important point here is that the HTML form can send a POST to another domain even if the CORS header is not set. A common way to prevent this attack is to use a CSRF token to confirm that the request is indeed from an approved site. OkCupid does not use these tokens, so it can build a web page that triggers actions on behalf of the user.
One of the other common request forgery patterns is server-side request forgery (SSRF). This one is a bit different: here we trick the server to generate an unexpected request. This is usually in the context of front-end servers sending traffic to non-public back-end services.it’s here Ability to include internal URL as a parameter to call Facebook APIThe API endpoint seems to naively accept any URL as a valid image, even if the location is not a location that should not be publicly accessible. In this case, this operation leaked the contents of the internal endpoint, enabling the researcher to obtain canary tokens and receive a pair of $30,000 bounties.
The last story happened later this week, and everything has to do with HTTP/2. This relatively new protocol is a potential replacement for HTTP, designed to make the web faster and more flexible. Guess what the new agreement brings. Yes, a new creative way to break it. [James Kettle] Port Sweig Covers quite a lot of potential vulnerabilities Related to request smuggling, it mainly involves the front-end server converting HTTP/2 to HTTP 1.1. These attacks include including colons or newline characters in HTTPS/2 fields, which have different interpretations once they are converted to HTTP 1.1.
The most important vulnerability announced may be CVE-2021-33193, which is a vulnerability in Apache mod_proxyThis is a problem. The front-end HTTP/2 server understands the spaces in the incoming header differently from the back-end.This allows an attacker to request privileged endpoints, such as /wp-admin, But disguised the request as something boring. This action can bypass the access rules and allow access to these locations. The vulnerability has been fixed in Apache master and will become part of version 2.4.49, but here we are talking about the vulnerability, 2.4.49 has not yet been released. If you are running a vulnerable server, it may be time to disable HTTP/2.
Illusion TLS decryption
SySS just released Hallucinations As an open source project. This project is about decrypting SSL traffic, not on the network, but by connecting to an operating system or application that encrypts it. The potential use cases are very wide. Trying to figure out what data the closed source binary file sends to the cloud? Solve the hard-to-determine errors in encrypted data? Hallucinations may help. It can spit out decrypted PCAP files, and even run Python scripts to manipulate encrypted data in real time. Adding to your library is definitely a useful trick.
Google’s view on kernel security
[Kees Cook] Member of Google Open Source Security Team Published an article this week about the security situation In and around the Linux kernel. He pointed out that although the kernel works well when everything is normal, when it crashes, it may crash in an unsafe way. In other words, he would like to see more work done to make the kernel adapt to compromise even in the presence of flaws. Although the article did not detail the changes required to perform this operation, I can only think of efforts such as adding Rust to the kernel and doing additional address randomization.
Most of this article is not aimed at upstream kernels, but at downstream integrators. The advice here is simple. Keep track of the latest version or stable kernel. Don’t use a 10-year kernel. This is a challenge, because do you have so much out-of-tree kernel code? Upstream your changes. It makes everyone safer. Instead of spending a lot of engineering effort to backport the fixes to your old kernel, it is better to spend this effort to make the upstream kernel more secure. Interestingly, he concluded at the end of the article that the Linux kernel and tool chain need about 100 skilled engineers to be effectively maintained.