OpenSSL Vulns, RepoJacking, Authentication Bypass, & Supercharging Your Hacking – PSW #762

“This traffic is perhaps strong enough to DoS some less well provisioned servers all by itself,” Davis wrote in his report. “In theory, a hundred of these, working in unison, could generate a Terabit per second of attack traffic.”

This is simpler than described here: "A GitHub repository is vulnerable to RepoJacking when its creator decided to rename his username while the old username is available for registration. We have shown the coupling in the repository URLs between the repository name and the creator username, and this means attackers can create a new GitHub account having the same combination to match the old repository URL used by existing users." - Basically Github was not protecting the namespaces, which means if you rename your repo, Github created a redirect. An attacker just has to create a new username that matches the old repo name and they gain control.

I said this earlier in the week on Twitter: "I feel like there will always be authentication bypass and remote code execution, at the same time even, to keep hope from every being truly alive" - Turns out this is exactly that...

A breakdown of various hardware vendors that are implementing hardware-based tactics to protect data. Always keep in mind that "hardware security" is really just software security as the hardware runs firmware, which is just software that is inconvenient to program.

How to be more organized to do "hacking". While important, make sure you still maintain creative freedom and aren't just following a script.

I liked the "New Tools & Techniques" section, good stuff in there.

So interesting: "Side note: initially, we thought that the symlink attack 1/ would fail, because /dev/shm is a sticky world-writable directory, and the kernel's fs.protected_symlinks is 1 by default; to our great surprise, however, it succeeded. Eventually, we understood that only the final component of a path is protected, not its intermediate components; for example, if /tmp/foo is a symlink, then an access to /tmp/foo itself is protected, but an access to /tmp/foo/bar is not. Interestingly, this weakness was already pointed out in 2017 by Solar Designer, and the original Openwall, grsecurity, and Yama protections are not affected"

Nice collection of talks, I have yet to watch them, though the printer one seems interesting.

Backward compatibility and security do not go together. This is a really in-depth technical post, however, if we fast forward to the fix this is something to consider: "The only fix I can find is in the KDC service for the domain controller. Microsoft has added a new flag which by default disables the RC4-MD4 algorithm and an old variant of RC4-HMAC with the encryption type of -133. This behavior can be re-enabled by setting the KDC configuration registry value AllowOldNt4Crypto. The reference to NT4 is a good indication on how long this vulnerability has existed as it presumably pre-dates the introduction of Kerberos in Windows 2000."

This cat and mouse game will continue, right now are the attackers winning?

This is the problem with vulnerability scanning: " In this first-of-its-kind benchmark and root cause analysis, Rezilion researchers examined 20 popular containers on DockerHub, ran them locally, and scanned them using six different, popular vulnerability scanners in the commercial and open source market. Each vulnerability scanner reported a different number of vulnerabilities, equating to less than 50 percent of common findings, exposing an exceptional amount of false positives and negatives"

Sort of funny...

This is really interesting, and it seems no one really cared about my observation, which is if a package maintainer turns off signature validation shouldn't the user/admin receive a warning and get the option to either accept or deny the update? This does not happen on Arch Linux today, which has me very worried.

This is the problem: "initrd typically unlocks root file system encryption, but is not protected whatsoever, and trivial to attack and modify offline". A little background: "initrd is mainly designed to allow system startup to occur in two phases, where the kernel comes up with a minimum set of compiled-in drivers, and where additional modules are loaded from initrd." - See the problem when we apply Secure Boot? This article outlines a fix, that is creating one UKI that is signed and ultimately trusted: "Central to the proposed design is the concept of a Unified Kernel Image (UKI). These UKIs are the combination of a Linux kernel image, and initrd, a UEFI boot stub program (and further resources, see below) into one single UEFI PE file that can either be directly invoked by the UEFI firmware (which is useful in particular in some cloud/Confidential Computing environments) or through a boot loader (which is generally useful to implement support for multiple kernel versions, with interactive or automatic selection of image to boot into, potentially with automatic fallback management to increase robustness)."

A step in the right direction: " A patch sent out today continues the upstream discussion over flipping on this feature by default that is part of Intel's Control-flow Enforcement Technology (CET) for helping to defend against jump/call oriented programming attacks." Reference: https://www.intel.com/content/www/us/en/developer/articles/technical/technical-look-control-flow-enforcement-technology.html

Actual research that proves the phrase: "given enough eyeballs, all bugs are shallow.". This summarized the research: "On average, it takes over 800 days to discover a security flaw in open source projects. For instance, the infamous Log4shell (CVE-2021-44228) vulnerability was undiscovered for a whopping 2649 days."

Everyone should read this (probably more than once), very well-done and one of the best explanations and depictions of memory safety issues and mitigations. I am so curious about who the author(s) are...

Detect files with Canaries!

Ironic, an in-depth explanation of a XNU kernel exploitation bug!

If you read only one article about the OpenSSL 3.0.0-3.0.6 vulnerabilities it must be this one. Other OpenSSL references include: https://securityaffairs.co/wordpress/137689/security/openssl-second-critical-flaw-ever.html and https://www.malwaretech.com/2022/11/everything-you-need-to-know-about-the-openssl-3-0-7-patch.html and https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows

The "world's fastest shoes," Moonwalk, allow you to "walk at the speed of a run." They should replace scooters, and be safer.

Visa is targeting crypto payments and NFTs, with plans to manage cryptocurrency transactions and create a virtual environment “in which users can interact for recreational, leisure or entertainment purposes.”

SIAM is a computer system that works behind the scenes of Iranian cellular networks, providing its operators a broad menu of remote commands to alter, disrupt, and monitor how customers use their phones. The tools can slow their data connections to a crawl, break the encryption of phone calls, track the movements of individuals or large groups, and produce detailed metadata summaries of who spoke to whom, when, and where.

Bluesky announced the roadmap of its decentralised social network protocol, which will be the underlying code behind the app. The app's code will allow user account data to be moved from platform to platform. Bluesky users will be able to use their account to log in to any social media account that adopts the new code.

On November 1, the European Union’s Digital Markets Act comes into force. Companies will be forced to break open their walled gardens. “If you have an iPhone, you should be able to download apps not just from the App Store but from other app stores or from the Internet.” A second sweeping EU law, the Digital Services Act, requires risk assessments of some algorithms and disclosures about automated decision-making and could force social apps like TikTok to open their data to outside scrutiny.