This Week in Security

285 Articles

This Week In Security: Unicode Strikes Again, Trust No One (Redditor), And More

June 14, 2024 by 7 Comments

There’s a popular Sysadmin meme that system problems are “always DNS”. In the realm of security, it seems like “it’s always Unicode“. And it’s not hard to see why. Unicode is the attempt to represent all of Earth’s languages with a single character set, and that means there’s a lot of very similar characters. The two broad issues are that human users can’t always see the difference between similar characters, and that libraries and applications sometimes automatically convert exotic Unicode characters into more traditional text.

This week we see the resurrection of an ancient vulnerability in PHP-CGI, that allows injecting command line switches when a web server launches an instance of PHP-CGI. The solution was to block some characters in specific places in query strings, like a query string starting with a dash.

The bypass is due to a Windows feature, “Best-Fit”, an automatic down-convert from certain Unicode characters. This feature works on a per-locale basis, which means that not every system language behaves the same. The exact bypass that has been found is the conversion of a soft hyphen, which doesn’t get blocked by PHP, into a regular hyphen, which can trigger the command injection. This quirk only happens when the Windows locale is set to Chinese or Japanese. Combined with the relative rarity of running PHP-CGI, and PHP on Windows, this is a pretty narrow problem. The XAMPP install does use this arrangement, so those installs are vulnerable, again if the locale is set to one of these specific languages. The other thing to keep in mind is that the Unicode character set is huge, and it’s very likely that there are other special characters in other locales that behave similarly.

Downloader Beware

The ComfyUI project is a flowchart interface for doing AI image generation workflows. It’s an easy way to build complicated generation pipelines, and the community has stepped up to build custom plugins and nodes for generation. The thing is, it’s not always the best idea to download and run code from strangers on the Internet, as a group of ComfyUI users found out the hard way this week. The ComfyUI_LLMVISION node from u/AppleBotzz was malicious.

The node references a malicious Python package that grabs browser data and sends it all to a Discord or Pastebin. It appears that some additional malware gets installed, for continuing access to infected systems. It’s a rough way to learn. Continue reading “This Week In Security: Unicode Strikes Again, Trust No One (Redditor), And More” →

This Week In Security: Recall, Modem Mysteries, And Flipping Pages

June 7, 2024 by 6 Comments

Microsoft is racing to get into the AI game as part of Windows 11 on ARM, calling it Copilot+. It’s an odd decision, but clearly aimed at competing with the Apple M series of MacBooks. Our focus of interest today is Recall, a Copilot+ feature that not only has some security problems, but also triggers a sort of visceral response from regular people: My computer is spying on me? Eww.

Yes, it really sort of is. Recall is a scheme to take screen shots of the computer display every few seconds, run them through character recognition, and store the screenshots and results in a database on the local machine hard drive. There are ways this could be useful. Can’t remember what website had that recipe you saw? Want to revisit a now-deleted tweet? Is your Google-fu failing you to find a news story you read last week? Recall saw it, and Recall remembers. But what else did Recall see? Every video you watched, ever website you visited, and probably some passwords and usernames you typed in.

Continue reading “This Week In Security: Recall, Modem Mysteries, And Flipping Pages” →

This Week In Security: Operation Endgame, Appliance Carnage, And Router Genocide

May 31, 2024 by 3 Comments

This week saw an impressive pair of takedowns pulled off by law enforcement agencies around the world. The first was the 911 S5 botnet, Which the FBI is calling “likely the world’s largest botnet ever”. Spreading via fake free VPN services, 911 was actually a massive proxy service for crooks. Most lately, this service was operating under the name “Cloud Router”. As of this week, the service is down, the web domain has been seized, and the alleged mastermind, YunHe Wang, is in custody.

The other takedown is interesting in its own right. Operation Endgame seems to be psychological warfare as well as actual arrests and seizures. The website features animated shorts, a big red countdown clock, and a promise that more is coming. The actual target was the ring that manage malware droppers — sort of middlemen between initial shellcode, and doing something useful with a compromised machine. This initial volley includes four arrests, 100+ servers disrupted, and 2,000+ domains seized.

The arrests happened in Armenia and Ukraine. The messaging around this really seems to be aimed at the rest of the gang that’s out of reach of law enforcement for now. Those criminals may still be anonymous, or operating in places like Russia and China. The unmistakable message is that this operation is coming for the rest of them sooner or later. Continue reading “This Week In Security: Operation Endgame, Appliance Carnage, And Router Genocide” →

This Week In Security: Drama At The C-Level, Escape Injection, And Audits

May 24, 2024 by 6 Comments

There was something of a mystery this week, with the c.root-servers.net root DNS server falling out of sync with it’s 12 siblings. That’s odd in itself, as these are the 13 servers that keep DNS working for the whole Internet. And yes, that’s a bit of a simplification, it’s not a single server for any of the 13 entities — the C “server” is actually 12 different machines. The intent is for all those hundreds of servers around the world to serve the same DNS information, but over several days this week, the “C” servers just stopped pulling updates.

The most amusing/worrying part of this story is how long it took for the problem to be discovered and addressed. One researcher cracked a ha-ha-only-serious sort of joke, that he had reported the problem to Cogent, the owners of the “C” servers, but they didn’t “seem to understand that they manage a root server”. The problem first started on Saturday, and wasn’t noticed til Tuesday, when the servers were behind by three days. Updates started trickling late Tuesday or early Wednesday, and by the end of Wednesday, the servers were back in sync.

Cogent gave a statement that an “unrelated routing policy change” both affected the zone updates, and the system that should have alerted them to the problem. It seems there might room for an independent organization, monitoring some of this critical Internet Infrastructure.

Continue reading “This Week In Security: Drama At The C-Level, Escape Injection, And Audits” →

This Week In Security: The Time Kernel.org Was Backdoored And Other Stories

May 17, 2024 by 1 Comment

Researchers at Eset have published a huge report on the Ebury malware/botnet (pdf), and one of the high profile targets of this campaign was part of the kernel.org infrastructure. So on one hand, this isn’t new news, as the initial infection happened back in 2011, and was reported then. On the other hand, according to the new Eset report, four kernel.org servers were infected, with two of them possibly compromised for as long as two years. That compromise apparently included credential stealing or password cracking.

The Ebury attackers seem to gain initial access through credential stuffing — a huge list of previously captured credentials are tried one at a time. However, once the malware has a foothold in the network, a combination of automated and manual steps are taken to move laterally. The most obvious is to grab any private SSH keys from that system, and try using them to access other machines on the local network. Ebury also replaces a system library that gets called as a part of sshd, libkeyutils.so. This puts it in a position to quietly capture credentials.

For a targeted attack against a more important target, the people behind Ebury seem to go hands-on-keyboard, using techniques like Man-in-the-Middle attacks against SSH logins on the local network using ARP spoofing. In this case, someone was doing something nasty.

And that doesn’t even start to cover the actual payload. That’s nasty too, hooking into Apache to sniff for usernames and passwords in HTTP/S traffic, redirecting links to malicious sites, and more. And of course, the boring things you might expect, like sending spam, mining for Bitcoin, etc. Ebury isn’t exactly easy to notice, either, since it includes a rootkit module that hooks into system functions to hide itself. Thankfully there are a couple of ways to get a clean shell to look for the malware, like using systemd-run or launching a local shell on the system console.

And the multi-million dollar question: Who was behind this? Sadly we don’t know. A single arrest was made in 2014, and recovered files implicated another Russian citizen, but the latest work indicates this was yet another stolen identity. The rest of the actors behind Ebury have gone to great lengths to remain behind the curtain.

Continue reading “This Week In Security: The Time Kernel.org Was Backdoored And Other Stories” →

This Week In Security: TunnelVision, Scarecrows, And Poutine

May 10, 2024 by 9 Comments

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine” →

This Week In Security: Default Passwords, Lock Slapping, And Mastodown

May 3, 2024 by 8 Comments

The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.

I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.

What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.

So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.

Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown” →