The Browser Wasn’t Enough, Google Wants To Control All Your Software

A few days ago we brought you word that Google was looking to crack down on “sideloaded” Android applications. That is, software packages installed from outside of the mobile operating system’s official repository. Unsurprisingly, a number of readers were outraged at the proposed changes. Android’s open nature, at least in comparison to other mobile operating systems, is what attracted many users to it in the first place. Seeing the platform slowly move towards its own walled garden approach is concerning, especially as it leaves the fate of popular services such as the F-Droid free and open source software (FOSS) repository in question.

But for those who’ve been keeping and eye out for such things, this latest move by Google to throw their weight around isn’t exactly unexpected. They had the goodwill of the community when they decided to develop an open source browser engine to keep the likes of Microsoft from taking over the Internet and dictating the rules, but now Google has arguably become exactly what they once set out to destroy.

Today they essentially control the Internet, at least as the average person sees it, they control 72% of the mobile phone OS market, and now they want to firm up their already outsized control which apps get installed on your phone. The only question is whether or not we let them get away with it.

Continue reading “The Browser Wasn’t Enough, Google Wants To Control All Your Software”

This Week In Security: Encrypted Messaging, NSO’s Judgement, And AI CVE DDoS

Cryptographic messaging has been in the news a lot recently. Like the formal audit of WhatsApp (the actual PDF). And the results are good. There are some minor potential problems that the audit highlights, but they are of questionable real-world impact. The most consequential is how easy it is to add additional members to a group chat. Or to put it another way, there are no cryptographic guarantees associated with adding a new user to a group.

The good news is that WhatsApp groups don’t allow new members to read previous messages. So a user getting added to a group doesn’t reveal historic messages. But a user added without being noticed can snoop on future messages. There’s an obvious question, as to how this is a weakness. Isn’t it redundant, since anyone with the permission to add someone to a group, can already read the messages from that group?

That’s where the lack of cryptography comes in. To put it simply, the WhatsApp servers could add users to groups, even if none of the existing users actually requested the addition. It’s not a vulnerability per se, but definitely a design choice to keep in mind. Keep an eye on the members in your groups, just in case. Continue reading “This Week In Security: Encrypted Messaging, NSO’s Judgement, And AI CVE DDoS”

This Week In Security: AirBorne, EvilNotify, And Revoked RDP

This week, Oligo has announced the AirBorne series of vulnerabilities in the Apple Airdrop protocol and SDK. This is a particularly serious set of issues, and notably affects MacOS desktops and laptops, the iOS and iPadOS mobile devices, and many IoT devices that use the Apple SDK to provide AirPlay support. It’s a group of 16 CVEs based on 23 total reported issues, with the ramifications ranging from an authentication bypass, to local file reads, all the way to Remote Code Execution (RCE).

AirPlay is a WiFi based peer-to-peer protocol, used to share or stream media between devices. It uses port 7000, and a custom protocol that has elements of both HTTP and RTSP. This scheme makes heavy use of property lists (“plists”) for transferring serialized information. And as we well know, serialization and data parsing interfaces are great places to look for vulnerabilities. Oligo provides an example, where a plist is expected to contain a dictionary object, but was actually constructed with a simple string. De-serializing that plist results in a malformed dictionary, and attempting to access it will crash the process.

Another demo is using AirPlay to achieve an arbitrary memory write against a MacOS device. Because it’s such a powerful primative, this can be used for zero-click exploitation, though the actual demo uses the music app, and launches with a user click. Prior to the patch, this affected any MacOS device with AirPlay enabled, and set to either “Anyone on the same network” or “Everyone”. Because of the zero-click nature, this could be made into a wormable exploit. Continue reading “This Week In Security: AirBorne, EvilNotify, And Revoked RDP”

This Week In Security: XRP Poisoned, MCP Bypassed, And More

Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?

The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.

The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.

The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys. Continue reading “This Week In Security: XRP Poisoned, MCP Bypassed, And More”

This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon

Last Friday Github saw a supply chain attack hidden in a popular Github Action. To understand this, we have to quickly cover Continuous Integration (CI) and Github Actions. CI essentially means automatic builds of a project. Time to make a release? CI run. A commit was pushed? CI run. For some projects, even pull requests trigger a CI run. It’s particularly handy when the project has a test suite that can be run inside the CI process.

Doing automated builds may sound straightforward, but the process includes checking out code, installing build dependencies, doing a build, determining if the build succeeded, and then uploading the results somewhere useful. Sometimes this even includes making commits to the repo itself, to increment a version number for instance. For each step there are different approaches and interesting quirks for every project. Github handles this by maintaining a marketplace of “actions”, many of which are community maintained. Those are reusable code snippets that handle many CI processes with just a few options.

One other element to understand is “secrets”. If a project release process ends with uploading to an AWS store, the process needs an access key. Github stores those secrets securely, and makes them available in Github Actions. Between the ability to make changes to the project itself, and the potential for leaking secrets, it suddenly becomes clear why it’s very important not to let untrusted code run inside the context of a Github Action.

And this brings us to what happened last Friday. One of those community maintained actions, tj-actions/changed-files, was modified to pull an obfuscated Python script and run it. That code dumps the memory of the Github runner process, looks for anything there tagged with isSecret, and writes those values out to the log. The log, that coincidentally, is world readable for public repositories, so printing secrets to the log exposes them for anyone that knows where to look.

Researchers at StepSecurity have been covering this, and have a simple search string to use: org:changeme tj-actions/changed-files Action. That just looks for any mention of the compromised action. It’s unclear whether the compromised action was embedded in any other popular actions. The recommendation is to search recent Github Action logs for any mention of changed-files, and start rotating secrets if present. Continue reading “This Week In Security: The Github Supply Chain Attack, Ransomware Decryption, And Paragon”

This Week In Security: Cookie Monster, CyberGhost, NEXX, And Dead Angles

“Operation Cookie Monster” ranks as one of the best code names in recent memory. And it’s apropo, given what exactly went down. Genesis Market was one of those marketplaces where criminals could buy and sell stolen credentials. This one was a bit extra special.

Websites and services are getting better about detecting logins from unexpected computers. Your Google account suddenly logs in from a new computer, and a two-factor authentication challenge launches. Why? Your browser is missing a cookie indicating you’ve logged in before. But there’s more. Providers have started rolling out smart analytics that check for IP address changes and browser fingerprints. Your mix of time zone, user string, installed fonts, and selected language make a pretty unique identifier. So sites like Genesis offer Impersonation-as-a-Service (IMPaaS), which is session hijacking for the modern age.

A victim computer gets owned, and credentials are collected. But so are cookies and a browser fingerprint. Then a criminal buyer logs in, and runs a virtual browser with all that collected data. Run through a proxy to get a IP that is geolocated close enough to the victim, and Mr. Bad Guy has a cloned machine with all accounts intact.

And now back to Operation Cookie Monster, a multi-organization takedown of Genesis. It’s apparently a partial takedown, as the latest word is that the site is still online on the Tor network. But the conventional domains are down, and something like eight million credentials have been captured and added to the Have I Been Pwned database.

Another researcher team, Sector 7, has been working the case with Dutch authorities, and has some interesting details. The vector they cover was a fake activation crack for an antivirus product. Ironic. There are several extensions that get installed on the victim computer, and one of the most pernicious is disguised as Google Drive. This extension looks for a Command and Control server, using Bitcoin as DNS. A hardcoded Bitcoin address is polled for its latest transaction, and the receiving address is actually an encoded domain name, you-rabbit[.]com as of the latest check.

This extension will look for and rewrite emails that might be warning the victim about compromise. Get an email warning about a cryptocurrency withdrawal? It modifies it in the browser to be a sign-in warning. It also allows Genesis customers to proxy connections through the victim’s browser, bypassing IP address security measures. Continue reading “This Week In Security: Cookie Monster, CyberGhost, NEXX, And Dead Angles”

This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key

There’s a naming overload here, as two bits of security news this week are using the “MacStealer” moniker. We’re first going to talk about the WiFi vulnerability, also known as Framing Frames (pdf). The WPA encryption schemes introduced pairwise encryption, ensuring that not even other authenticated users can sniff each others’ traffic. At least that’s the idea, but this attack finds a couple techniques to bypass that protection.

A bit more background, there are a couple ways that packets can be delayed at the sender side. One of those is the power-save message, that signals the access point that the given client is going into a low power state. “Hold my calls, I’m going to sleep.” That message is a single bit in a frame header. And notably, that bit isn’t covered by WPA encryption or verification. An attacker can send a message, spoof a victim’s MAC address, and the access point marks that client as being in power-save mode.

This observation leads to a question: What happens when the encryption details change between the packet joining the queue, and actually transmitting? Turns out, the specifications on WiFi encryption don’t spell it out, and some implementations do the last thing you’d want, like sending the packets in the clear. Whoops. This behavior was the case in the Linux kernel through version 5.5.0, but starting with 5.6.0, the buffered packets were simply dropped when the encryption key was unavailable. Continue reading “This Week In Security: Macstealer, 3CX Carnage, And Github’s Lost Key”