Facebook and Yandex have been caught performing user-hostile tracking. This sort of makes today just another Friday, but this is a bit special. This time, it’s Local Mess. OK, it’s an attack with a dorky name, but very clever. The short explanation is that web sites can open connections to localhost. And on Android, apps can be listening to those ports, allowing web pages to talk to apps.

That may not sound too terrible, but there’s a couple things to be aware of. First, Android (and iOS) apps are sandboxed — intentionally making it difficult for one app to talk to another, except in ways approved by the OS maker. The browser is similarly sandboxed away from the apps. This is a security boundary, but it is especially an important security boundary when the user is in incognito mode.

The tracking Pixel is important to explain here. This is a snippet of code, that puts an invisible image on a website, and as a result allows the tracker to run JavaScript in your browser in the context of that site. Facebook is famous for this, but is not the only advertising service that tracks users in this way. If you’ve searched for an item on one site, and then suddenly been bombarded with ads for that item on other sites, you’ve been tracked by the pixel.

This is most useful when a user is logged in, but on a mobile device, the user is much more likely to be logged in on an app and not the browser. The constant pressure for more and better data led to a novel and completely unethical solution. On Android, applications with permission to access the Internet can listen on localhost (127.0.0.1) on unprivileged ports, those above 1024.

Facebook abused this quirk by opening a WebRTC connection to localhost, to one of the ports the Facebook app was listening on. This triggers an SDP connection to localhost, which starts by sending a STUN packet, a UDP tool for NAT traversal. Packed into that STUN packet is the contents of a Facebook Cookie, which the Facebook app happily forwards up to Facebook. The browser also sends that cookie to Facebook when loading the pixel, and boom Facebook knows what website you’re on. Even if you’re not logged in, or incognito mode is turned on.

Yandex has been doing something similar since 2017, though with a different, simpler mechanism. Rather than call localhost directly, Yandex just sets aside yandexmetrica.com for this purpose, with the domain pointing to 127.0.0.1. This was just used to open an HTTP connection to the native Yandex apps, which passed the data up to Yandex over HTTPS. Meta apps were first seen using this trick in September 2024, though it’s very possible it was in use earlier.

Both companies have ceased since this report was released. What’s interesting is that this is a flagrant violation of GDPR and CCPA, and will likely lead to record-setting fines, at least for Facebook.

What’s your Number?

An experiment in which Google sites still worked with JavaScript disabled led to a fun discovery about how to sidestep rate limiting and find any Google user’s phone number. Google has deployed defensive solutions to prevent attackers from abusing endpoints like accounts.google.com/signing/usernamerecovery. That particular endpoint still works without JS, but also still detects more than a few attempts, and throws the captcha at anyone trying to brute-force it.

This is intended to work by JS in your browser performing a minor proof-of-work calculation, and then sends in a bgRequest token. On the no-JavaScript version of the site, that field instead was set to js_disabled. What happens if you simply take the valid token, and stuff it into your request? Profit! This unintended combination bypassed rate-limiting, and means a phone number was trivially discoverable from just a user’s first and last names. It was mitigated in just over a month, and [brutecat] earned a nice $5000 for the effort.

Catching Reflections

There’s a classic Active Directory attack, the reflection attack, where you can trick a server into sending you an authentication, and then deliver that authentication data directly back to the origin server. Back before 2008, this actually worked on AD servers. The crew at RedTeam Pentesting brought this attack back in the form of doing it with Kerberos.

It’s not a trivial attack, and just forcing a remote server to open an SMB connection to a location the attack controls is an impressive vulnerability. The trick is a hostname that includes the target name and a base64 encoded CREDENTIAL_TARGET_INFORMATIONW all inside the attacker’s valid hostname. This confuses the remote, triggering it to act as if it’s authenticating to itself. Forcing a Kerberos authentication instead of NTLM completes the attacker magic, though there’s one more mystery at play.

When the attack starts, the attacker has a low-privileged computer account. When it finishes, the access is at SYSTEM level on the target. It’s unclear exactly why, though the researchers theorize that a mitigation intended to prevent almost exactly this privilege escalation is the cause.

X And the Juicebox

X has rolled out a new end to end encrypted chat solution, XChat. It’s intended to be a significant upgrade from the previous iteration, but not everyone is impressed. Truly end to end encryption is extremely hard to roll out at scale, among other reasons, because users are terrible at managing cryptography keys. The solution generally is for the service provider to store the keys instead. But what is the point of end-to-end encryption when the company holds the keys? While there isn’t a complete solution for this problem, There is a very clever mitigation: Juicebox.

Juicebox lets users set a short PIN, uses that in the generation of the actual encryption key, breaks the key into parts to be held at different servers, and then promise to erase the key if the PIN is guessed incorrectly too many times. This is the solution X is using. Sounds great, right? There are two gotchas in that description. The first is the different servers: That’s only useful if those servers aren’t all run by the same company. And second, the promise to delete the key. That’s not cryptographically guaranteed.

There is some indication that X is running a pair of Hardware Security Modules (HSMs) as part of their Juicebox system, which significantly helps with both of those issues, but there just isn’t enough transparency into the system yet. For the time being, the consensus is that Signal is still the safest platform to use.

Bits and Bytes

We’re a bit light on Bits this week, so you’ll have to get by with the report that Secure Boot attacks are publicly available. It’s a firmware update tool from DT Research, and is signed by Microsoft’s UEFI keys. This tool contains a vulnerability that allows breaking out of it’s intended use, and running arbitrary code. This one has been patched, but there’s a second, similar problem in a Microsoft-signed IGEL kernel image, that allows running an arbitrary rootfs. This isn’t particularly a problem for us regular users, but the constant stream of compromised, signed UEFI boot images doesn’t bode well for the long term success of Secure Boot as a security measure.