This Week in Security: CIA Star Wars, Git* Prompt Injection and More

The CIA ran a series of web sites in the 2000s. Most of them were about news, finance, and other relatively boring topics, and they spanned 29 languages. And they …read more

May 30, 2025 - 19:20

This Week in Security: CIA Star Wars, Git* Prompt Injection and More

The CIA ran a series of web sites in the 2000s. Most of them were about news, finance, and other relatively boring topics, and they spanned 29 languages. And they all had a bit of a hidden feature: Those normal-looking websites had a secret login and hosted CIA cover communications with assets in foreign countries. A password typed in to a search field on each site would trigger a Java Applet or Flash application, allowing the spy to report back. This isn’t exactly breaking news, but what’s captured the Internet’s imagination this week is the report by [Ciro Santilli] about how to find those sites, and the fact that a Star Wars fansite was part of the network.

This particular CIA tool was intended for short-term use, and was apparently so effective, it was dragged way beyond it’s intended lifespan, right up to the point it was discovered and started getting people killed. And in retrospect, the tradecraft is abysmal. The sites were hosted on a small handful of IP blocks, with the individual domains hosted on sequential IP addresses. Once one foreign intelligence agency discovered one of these sites, the rest were fairly easily identified.

This report is about going back in time using the Wayback Machine and other tools, and determining how many of these covert sites can be discovered today. And then documenting how it was done and what the results were. Surprisingly, some of the best sources for this effort were domain name data sets. Two simple checks to narrow down the possible targets were checking for IPs hosting only one domain, and for the word “news” as part of the domain name. From there, it’s the tedious task of looking at the Wayback Machine’s archives, trying to find concrete hits. Once a site was found on a new IP block, the whole block could be examined using historic DNS data, and hopefully more of the sites discovered.

So far, that list is 472 domains. Citizen Lab ran a report on this covert operation back in 2022, and found 885 domains, but opted not to publish the list or details of how they were found. The effort is still ongoing, and if you have any ideas how to find these sites, there’s a chance to help.

Profiling Internet Background Radiation

You may have noticed, that as soon as you put a host on a new IP address on the Internet, it immediately starts receiving traffic. The creative term that refers to all of this is Internet Background Radiation. It’s comprised of TCP probes, reflections from spoofed UDP attacks, and lots of other weird traffic. Researchers at Netscout decided to look at just one element of that radiation, TCP SYN packets. That’s the unsolicited first packet of a TCP handshake. What secrets would this data contain?

The first intriguing statistic is the number of spoofed TCP SYN packets coming from known bogus source IPs: zero. This isn’t actually terribly surprising for a couple reasons. One, packets originating from impossible addresses are rather easy to catch and drop, and many ISPs do this sort of scrubbing at their network borders. But the second reason is that TCP requires a three-way handshake to make a useful connection. And while it’s possible to spoof an IP address on a local network via ARP poisoning, doing so on the open Internet is much more difficult.

Packet TTL is interesting, but the values naturally vary, based on the number of hops between the sender and receiver. A few source IPs were observed to vary in reported TTLs, which could indicate devices behind NAT, or even just the variation between different OS network stacks. But looking for suspicious traffic, two metrics really stand out. The TCP Header is a minimum 20 bytes, with additional length being used with each additional option specified. Very few systems will naturally send TCP SYN packets with the header set to 20, suggesting that the observed traffic at that length was mostly TCP probes. The other interesting observation is the TCP window size, with 29,200 being a suspicious number that was observed in a significant percentage of packets, without a good legitimate explanation.

Hacking the MCP

GitHub has developed the GitHub MCP Server, a ~~Master Control Program~~ Model Context Protocol server, designed to allow AI agents to interact with the GitHub API. Invariant Labs has put together an interesting demo in how letting an agentic AI work with arbitrary issues from the public could be a bad idea.

The short explanation is that a GitHub issue can include a prompt injection attack. In the example, it looks rather benign, asking for more information about the project author to be added to the project README. Just a few careful details in that issue, like specifying that the author isn’t concerned about privacy, and that the readme update should link to all the user’s other repos. If the repo owner lets an agentic AI loose on the repo via MCP, it’s very likely to leak details and private repo information that it really shouldn’t.

Invariant Labs suggests that MCP servers will need granular controls, limiting what an AI agent can access. I suspect we’ll eventually see a system for new issues like GitHub already has for Pull Requests, where a project maintainer has to approve the PR before any of the automated Github Actions are performed on it. Once AI is a normal part of dealing with issues, there will need to be tools to keep the AI from interacting with new issues until a maintainer has cleared them.

GitLab Too

GitLab has their own AI integration, GitLab Duo. Like many AI things, it has the potential to be helpful, and the potential to be a problem. Researchers at Legit Security included some nasty tricks in this work, like hiding prompt injection as Hex code, and coloring it white to be invisible on the white GitLab background. Prompt injections could then ask the AI to recommend malicious code, include raw HTML in the output, or even leak details from private repos.

Gitlab took the report seriously, and has added additional filtering that prevents Duo from injecting raw HTML in its output. The prompt injection has also been addressed, but the details of how are not fully available.

Finally, Actually Hacking the Registry

We’ve been following Google’s Project Zero and [Mateusz Jurczyk] for quite a while, on a deep dive into the Windows Registry. We’re finally at the point where we’re talking about vulnerabilities. The Windows registry is self-healing, which could be an attack surface on its own, but it definitely provides a challenge to anyone looking for vulnerabilities with a fuzzer, as triggering a crash is very difficult.

But as the registry has evolved over time and Windows releases, the original security assumptions may not be valid any longer. For instance, in its original form, the registry was only writable by a system administrator. But on modern Windows machines, application hives allow unprivileged users and process to load their own registry data into the system registry. Registry virtualization and layered keys further complicate the registry structure and code, and with complexity often comes vulnerabilities.

An exploit primitive that turned out to be useful was the out-of-bound cell index, where one cell can refer to another. This includes a byte offset value, and when the cell being referred to is a “small dir”, this offset can point past the end of the allocated memory.

There were a whopping 17 memory corruption exploits discovered, but to produce a working exploit, the write-up uses CVE-2023-23420, a use after free that can be triggered by performing an in-place rename of a key, followed by deleting a subkey. This can result in a live reference to that non-existent subkey, and thus access to freed memory.

In that free memory, a fake key is constructed. As the entire data structure is now under the arbitrary control of the attacker, the memory can point to anywhere in the hive. This can be combined with the out-of-bounds cell index, to manipulate kernel memory. The story turns into a security researcher flex here, as [Mateusz] opted to use a couple registry keys rigged in this way to make a working kernel memory debugger, accessible from regedit. One key sets the memory address to inspect, and the other key contains said memory as a writable key. Becoming SYSTEM at this point is trivial.

Bits and Bytes

[Thomas Stacey] of Assured has done work on HTTP smuggling/tunneling attacks, where multiple HTTP requests exist in a single packet. This style of attack works against web infrastructure that has a front-end proxy and a back-end worker. When the front-end and back-end parse requests differently, very unintended behavior can result.

ONEKEY researchers have discovered a pair of issues in the Evertz core web administration interface, that together allow unauthenticated arbitrary command injection. Evertz manufactures very large video handling equipment, used widely in the broadcast industry, which is why it’s so odd that the ONEKEY private disclosure attempts were completely ignored. As the standard 90 day deadline has passed, ONEKEY has released the vulnerability details in full.

On the other hand, Mozilla is setting records of its own, releasing a Firefox update on the same day as exploits were revealed at pwn2own 2025. Last year Mozilla received the “Fastest to Patch” award, and may be on track to repeat that honor.

What does video game cheat development have to do with security research? It’s full of reverse engineering, understand memory structures, hooking functions, and more. It’s all the things malware does to take over a system, and all the things a researcher does to find vulnerabilities and understand what binaries are doing. If you’re interested, there’s a great two-part series on the topic just waiting for you to dive into. Enjoy!