This Week In Security: The Log4j That Won’t Go Away, WebOS, And More

December 31, 2021 by Jonathan Bennett 5 Comments

In the past two weeks, Log4j has continued to drive security news, with more vulnerable platforms being found, and additional CVEs coming out. First up is work done by TrendMicro, looking at electric vehicles and chargers. They found a log4j attack in one of the published charger frameworks, and also managed to observe evidence of vulnerability in the Tesla In-Vehicle Infotainment system. It isn’t a stretch to imagine a piece of malware that could run on both a charger, and an EV. And since those systems talk to each other, they could spread the virus through cars moving from charger to charger.

Log4j is now up to 2.17.1, as there is yet another RCE to fix, CVE-2021-44832. This one is only scored a 6.6 on the CVSS scale, as opposed to the original, which weighed in at a 10. 44832 requires the attacker to first exert control over the Log4j configuration, making exploitation much more difficult. This string of follow-on vulnerabilities demonstrates a well-known pattern, where a high profile vulnerability attracts the attention of researchers, who find other problems in the same code.

There are now reports of Log4j being used in Conti ransomware campaigns. Additionally, a Marai-based worm has been observed. This self-propagating attack seems to be targeting Tomcat servers, among others.

Continue reading “This Week In Security: The Log4j That Won’t Go Away, WebOS, And More” →

Hackaday Links: March 21, 2021

March 21, 2021 by Dan Maloney 31 Comments

If you think you’re having a bad day at work, pity the poor sysadmin at Victoria University of Wellington in ~~Australia~~ New Zealand, who accidentally nuked the desktops of pretty much everyone at the university. This apparently happened last week and impacted everyone connected to the university network with a Windows machine, which had any files stored on their desktops deleted and also appears to have reset user profiles to the default state. This caused no end of consternation, especially among those who use their desktop folder to organize work in progress; we’d imagine more than one student at VUW is hating life right now for not storing work on a backed-up network drive. The problem seems to have started with an attempt to clean up files and profiles left behind by former students; how that escalated to nuking files on the desktop will require some ‘splaining.

Speaking of mea culpas, there was quite a dustup this week in the Cricut community. It started when the maker of CNC cutting machines announced its intention to limit uploads to their online design software unless the user signs up for a $10 a month account. After getting an earful from the users, the CEO of the company announced that these changes would be delayed until the end of 2021. That decision still didn’t sit well with the community, which includes a fair number of users designing PCBs, and two days later, the CEO announced that they were throwing in the towel on the whole plan, and that everything was going back to status quo ante. Story over? We’ll see — it seems like Cricut has tipped its hand here that they’re looking to extract more money from the users, and the need for that likely hasn’t gone away just because they relented. As Elliot Williams pointed out when we discussed the whole debacle, it’s easy to see how Cricut could start adding new features to the paid version of their software, basically abandoning the free user base. We’ll have to see how the obviously vociferous community responds to something like that.

Much interesting news from Mars this week, where the Perseverance rover is getting used to its new home and getting itself ready to roll. Late last week, Perseverance successfully dropped the “belly pan” that was covering the sensitive instruments under the rover, including the Adaptive Sample Caching system that will seal up Martian core samples and drop them out onto the surface for later pickup. This seemingly simple task was a critical one; had the pan not cleanly separated, the mission could have been severely impacted. Perseverance also did a little test drive this week, and recorded what it sounds like to drive on Mars. The audio clip is 16 minutes long, and the noises coming from the billion-dollar rover are just awful at times. We hear clunks and clanks and squeals galore, and while we’re sure they all have a good explanation and will provide valuable engineering data, they sound somewhat alarming to us.

But not so alarming as the sounds that must have come from a Jeep that suffered a bad tow job recently. The cringe-making story starts with a brand-new Jeep being towed on its wheels behind a motorhome, which allows the RV owners to park their rig and still have something to drive around in while they camp. The towed vehicle, or “pusher”, is normally equipped with a manual transmission, as towing with the wheels on the ground for extended distances is easier with them. Unfortunately, the Jeep’s owner set up the shift levers wrong and left the transmission in first gear, with the transfer case in low range. The linked article estimates the gearing ratios meant that the poor Jeep’s engine was being spun at something like 54,000 RPM; chances are good the engine exploded long before that point. The damage shown in the video accompanying the article is just brutal — the oil pan and bell housing are gone, the bottom of the crankcase is blown out, and at least two pistons and their share of the crankshaft are missing in action. We feel sorry for the owner, but really wish the Jeep had had a belly cam like the one on Perseverance.

This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians

September 18, 2020 by Jonathan Bennett 19 Comments

The big news this week is the huge flaw in Microsoft’s Active Directory, CVE-2020-1472 (whitepaper). Netlogon is a part of the Windows domain scheme, and is used to authenticate users without actually sending passwords over the network. Modern versions of Windows use AES-CFB8 as the cryptographic engine that powers Netlogon authentication. This peculiar mode of AES takes an initialization vector (IV) along with the key and plaintext. The weakness here is that the Microsoft implementation sets the IV to all zeros.

It’s worth taking a moment to cover why IVs exist, and why they are important. The basic AES encryption process has two inputs: a 128 bit (16 byte) plaintext, and a 128, 192, or 256 bit key. The same plaintext and key will result in the same ciphertext output every time. Encrypting more that 128 bits of data with this naive approach will quickly reveal a problem — It’s possible to find patterns in the output. Even worse, a clever examination of the patterns could build a decoding book. Those 16 byte patterns that occur most often would be guessed first. It would be like a giant crossword puzzle, trying to fill in the gaps.

This problem predates AES by many years, and thankfully a good solution has been around for a long time, too. Cipher Block Chaining (CBC) takes the ciphertext output of each block and mixes it (XOR) with the plaintext input of the next block before encrypting. This technique ensures the output blocks don’t correlate even when the plaintext is the same. The downside is that if one block is lost, ~~the entire rest of the data cannot be decrypted~~ Update: [dondarioyucatade] pointed out in the comments that it’s just the next block that is lost, not the entire stream. You may ask, what is mixed with the plaintext for the first block? There is no previous block to pull from, so what data is used to initialize the process? Yes, the name gives it away. This is an initialization vector: data used to build the initial state of a crypto scheme. Generally speaking, an IV is not secret, but it should be randomized. In the case of CBC, a non-random IV value like all zeros doesn’t entirely break the encryption scheme, but could lead to weaknesses. Continue reading “This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians” →