User Profile

While there are some more crazy theoretical works out there, this talk showed how they did the work and it paid off on something not theoretically new. Basically they built a bit-squatting system that would handle DNS, SSL reg, and HTTP/IMAP/SMTP for a domain 1-bit off of the target (e.g., coogle.com instead of google.com). This technique has been around for years, but it's been very crufty, and mostly just done to do a talk. These folks spent a lot of time investing into the tooling, and they showed how quickly it paid off, 1000s of OAuth creds for F500 companies, 15k emails with scanned documents, etc.

They assumed that they'd see more hits during the solar storm, but didn't see anything, which they found correlated with a paper that seems to saw that cosmic rays are not the cause of in-memory bit-flips. They also spend a bit of time discussing defenses (from AWS' approach of buying every flipped domain), to cert pinning and other app-based defenses.

Going into this read, I figured that IP spoofing was of niche availability and applicability, especially in our TLS-dominated world. However, federated services such as SMTP, or database replication commonly use IP addresses for validation.

There are two core new discoveries here, a TCP stack weakness that results in dramatically smaller search spaces to brute-force the correct ISN to continue a TCP session (as few as four guesses!), and a few techniques for determining the ISN outright. Of these, the application-specific ones are cute and reliable. SMTP is the easiest to explain, but if you host your own DNS server for an attacker-controlled domain name, you can spoof a handshake that includes a "HELO .attacker.com". Once you get a hit on that DNS server, you have the correct ISN and can continue the session. Coupled with SPF records which specify which IPs/domains can send email on behalf of a domain, it's a powerful phishing/spam primitive.

The brute-forcing and generic TCP stack techniques were clever, but were a bit more difficult to understand from the paper, and likely less robust in real-world network scenarios. One required maintaining a server's connect queue at close to a buffer limit, which may be difficult with other legitimate traffic. Still a good read!

With the race to collect and train on ever more data (and re-train on the latest data more quickly), the ability for LLM creators to perform even cursory checks against training set corruption is almost nil. This paper shows two ways an attacker can corrupt 0.01-1% of a LLM training dataset for a reasonable sum. Existing works have shown that for a specific desired error state, a 0.01% training data poisoning attack can yield a 60-90% chance of tampering with model performance.

There are two core primitives presented in this paper: 1. The corpi release a metadata archive of URLs, and then the fetched content. There are enough expired domains in the metadata that allows for an attacker to corrupt a percentage of the URLs being scraped. 2. Wikipedia is converted into a timestamped dump (e.g., a ZIM file) in a predictable order, and on a predictable schedule. By changing Wikipedia articles just before archival, even if they are reverted by attentive editors, they will persist in the dump. The authors estimate that they could alter ~6.5% of Wiki articles during this process.