Note: From this episode onward, we have added the generated summaries of the articles using Wordtune in block quote format. The first person terms (I, we) used in the quoted text represented the author of the article, not this website.
#1. Extracting Clear-Text Credentials Directly From Chromium’s Memory 1
After accidentally finding a password stored in clear-text format in two separate locations in the memory of two separate processes, I decided to take a deeper look to see what else was stored in clear-text format.
One could think that data stored in Private memory pages is not accessible to any other process. Surprisingly, other processes have no problem reading the data in Private memory pages.
A browser process is made up of many disjointed small, committed memory sections separated by “reserved” sections. These sections are virtually “empty” (not “really” used) and contain strings that look like passwords or cookie values.
A standard non-privileged process can effectively extract clear text credential data from the browser’s memory.
When the browser is started, the most recently used passwords are loaded into memory. The passwords are DPAPI-encrypted, but when they are “scattered” into the memory, they are saved in clear-text format.
The program waits for the user to sign into a specific application, and then steals all the cookies that belong to that session.
When stolen cookies are used to hijack a session, typical applications do not recognize that a new device or location has been used.
Some applications encourage their users not to sign out of the application, and therefore an attacker may “share” the account with the real owner for an awfully long time.
Chromium.org stated they will not fix issues related to physical local attacks, but my next blog post will suggest several mitigation techniques to make it harder to execute the attack.
#2. Supply Chain Attack: CTX Account Takeover and PHPass Hijack Explained 2
When discussing supply chain attacks, it is important to remember that they rely on trusted third-party vendors.
A recent exploit in the Python Package Index (aka PyPi or ‘Cheese Shop’) extracted users' environment variables and AWS credentials, resulting in impacting millions of users worldwide.
After almost 8 years of inactivity, the Python CTX Module received an unexpected upgrade. The upgrade contained malicious code.
The post about the supposed “Update” to PyPi trended on Reddit, with users asking why there had been no updates for the last 8 years. The post was deleted later.
The exploit relies on the OS python module, which allows an attacker to obtain user environment variables, such as AWS, which are then encoded and sent to an endpoint remotely controlled by the attacker.
The attacker can create dependency confusion using Python PyPi packages by creating a web crawler that goes through every package maintainer’s Github profile page.
A researcher took over the figlief.com domain on May 14, 2022, and used the PyPi password-reset to claim the account.
The PyPi team removed 27,000 malicious versions of CTX from the index, prohibited the name from being re-registered, and frozen the compromised user account.
PHP packages are managed by Composer, and the researcher was able to identify the popular PHPass package as vulnerable, since its maintainer Github profile does not exist.
#3. Hertzbleed: Turning Power Side-Channel AttacksInto Remote Timing Attacks on x86 3
Power side-channel attacks exploit data-dependent variations in a CPU’s power consumption to leak secrets. We show that on modern Intel (and AMD) x86 CPUs, power side-channel attacks can be turned into timing attacks that can be mounted without access to any power measurement interface.
Hertzbleed is a new family of side-channel attacks that takes advantage of the dynamic frequency scaling of modern x86 processors. Hertzbleed can be used to extract cryptographic keys from remote servers that were previously believed to be secure.
The paper is a collaboration between Yingchen Wang, Riccardo Paccagnella, Elizabeth Tang He, Hovav Shacham, Christopher Fletcher, and David Kohlbrenner.
#4. SBOM in Action: finding vulnerabilities with a Software Bill of Materials 4
The past year has seen an industry-wide effort to embrace Software Bills of Materials (SBOMs), which are ingredient labels for software. Once an SBOM is available for a given piece of software, it needs to be mapped onto a list of known vulnerabilities to know which components could pose a threat.
In this blog post, we demonstrate how to use an open source tool to connect an SBOM from a large and critical project - Kubernetes - to a database of vulnerabilities.
The SBOM created by the bom tool does not specify an ecosystem, and could therefore return false positives. It would be more helpful if the SBOM differentiated between different library and package versions.
Tooling creators should add a reference to Purl for all packages included in the software. This makes package identification easier.
We are getting very close to achieving the goal of SBOMs: using them to help manage the risk of vulnerabilities in software. When we connect SBOMs with vulnerability databases, we will be able to worry less about the risks in the software we use.
#5. Project Zero: An Autopsy on a Zombie In-the-Wild 0-day 5
A zombie Safari 0-day was disclosed in 2022, 5 years after it was initially fixed.
In 2013 a commit changed the stateObject argument in SerializedScriptValue::deserialize from a raw pointer to a reference-counted pointer. The commit description included a comment to check out a Chromium bug. Sergei Glazunov reported the bug back in 2013, and the developers fixed the bug by changing every caller of SerializedScriptValue::deserialize to increase the reference count on the stateObject.
The bug was re-introduced in December 2016 due to refactoring, but the change in return value for HistoryItem:stateObject in October 2016 makes it appear that loadInSameDocument does not need to hold a reference to stateObject.
Sergei’s 2013 bug report included additional hardening measures that prevented user-code callbacks being processed during deserialization. Therefore, we needed to find another event in the loadInSameDocument function that would trigger the callback to user JavaScript. Sergei and I teamed up to identify a way to get user code execution sometime during the loadInSameDocument function, but prior to the call to statePopped.
In 2013, the developers patched all the different paths to trigger the vulnerability, but in December 2016 the vulnerability was revived and re-patched.
CVE-2022-22620 was correctly fixed in 2013, but was regressed in 2016 during refactoring. We don’t know how long an attacker exploited this vulnerability in-the-wild, but we do know that it existed (again) for 5 years: December 2016 until January 2022.
As an offensive security research team, we believe that developers and security teams need time to review patches, especially for security issues, and that rewarding these efforts will make a difference.
Footnotes
1. Extracting Clear-Text Credentials Directly From Chromium’s Memory (www.cyberark.com)
See also: