This Week in Security

283 Articles

This Week In Security: Good Faith, Easy Forgery, And I18N

May 27, 2022 by 26 Comments

There’s a danger in security research that we’ve discussed a few times before. If you discover a security vulnerability on a production system, and there’s no bug bounty, you’ve likely broken a handful of computer laws. Turn over the flaw you’ve found, and you’re most likely to get a “thank you”, but there’s a tiny chance that you’ll get charged for a computer crime instead. Security research in the US is just a little safer now, as the US Department of Justice has issued a new policy stating that “good-faith security research should not be charged.”

While this is a welcome infection of good sense, it would be even better for such a protection to be codified into law. The other caveat is that this policy only applies to federal cases in the US. Other nations, or even individual states, are free to bring charges. So while this is good news, continue to be careful. There are also some caveats about what counts as good-faith — If a researcher uses a flaw discovery to extort, it’s not good-faith.
Continue reading “This Week In Security: Good Faith, Easy Forgery, And I18N” →

This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked

May 20, 2022 by 14 Comments

As conspiracy theories go, one of the more plausible is that a cell phone could be running malicious firmware on its baseband processor, and be listening and transmitting data even when powered off. Nowadays, this sort of behavior is called a feature, at least if your phone is made by Apple, with their Find My functionality. Even with the phone off, the Bluetooth chip runs happily in a low-power state, making these features work. The problem is that this chip doesn’t do signed firmware. All it takes is root-level access to the phone’s primary OS to load a potentially malicious firmware image to the Bluetooth chip.

Researchers at TU Darmstadt in Germany demonstrated the approach, writing up a great paper on their work (PDF). There are a few really interesting possibilities this research suggests. The simplest is hijacking Apple’s Find My system to track someone with a powered down phone. The greater danger is that this could be used to keep surveillance malware on a device even through power cycles. Devices tend to be secured reasonably well against attacks from the outside network, and hardly at all from attacks originating on the chips themselves. Unfortunately, since unsigned firmware is a hardware limitation, a security update can’t do much to mitigate this, other than the normal efforts to prevent attackers compromising the OS.
Continue reading “This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked” →

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

May 13, 2022 by 7 Comments

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned” →

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

May 6, 2022 by 8 Comments

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat” →

This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug

April 22, 2022 by 2 Comments

Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.

Continue reading “This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug” →

This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day

April 15, 2022 by 20 Comments

OpenSSH has minted their 9.0 release, and it includes a pair of security changes. Unlike most of the releases we cover here, this one has security hardening to prevent issues, not emergency fixes for current ones. First up, the venerable scp/rcp protocol has been removed. Your scp commands will now use SFTP under the hood. The more interesting security change is the new default key exchange, the NTRU algorithm. NTRU is thought to be quantum-hard.
Continue reading “This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day” →

This Week In Security: Vulnerable Boxes, Government Responses, And New Tools

April 8, 2022 by 1 Comment

The Cyclops Blink botnet is thought to be the work of an Advanced Persistent Threat (APT) from Russia, and seems to be limited to Watchguard and Asus devices. The normal three and four letter agencies publicized their findings back in February, and urged everyone with potentially vulnerable devices to go through the steps to verify and disinfect them if needed. About a month later, in March, over half the botnet was still online and functioning, so law enforcement took a drastic step to disrupt the network. After reverse-engineering the malware itself, and getting a judge to sign off on the plan, the FBI remotely broke in to 13 of the Watchguard devices that were working as Command and Control nodes. They disinfected those nodes and closed the vulnerable ports, effectively knocking a very large chunk of the botnet offline.

The vulnerability in WatchGuard devices that facilitated the Botnet was CVE-2022-23176, a problem where an “exposed management access” allowed unprivileged users administrative access to the system. That vague description sounds like either a debugging interface that was accidentally included in production, or a flaw in the permission logic. Regardless, the problem was fixed in a May 2021 update, but not fully disclosed. Attackers apparently reversed engineered the fix, and used it to infect and form the botnet. The FBI informed WatchGuard in November 2021 that about 1% of their devices had been compromised. It took until February to publish remediation steps and get a CVE for the flaw.

This is definitely non-ideal behavior. More details and a CVE should have accompanied the fix back in May. As we’ve observed before, obscurity doesn’t actually prevent sophisticated actors from figuring out vulnerabilities, but it does make it harder for users and security professionals to do their jobs. Continue reading “This Week In Security: Vulnerable Boxes, Government Responses, And New Tools” →