This Week In Security: Another Linux Exploit, Ubuntu Knocked Offline, Finals Interrupted, And Backdoored Tools

After the CopyFail vulnerability gave root access from any user on almost all distributions last week, this week we’ve got DirtyFrag. This chains the vulnerability in CopyFail (xfrm-ESP) and a new vulnerability in a RPC function which allows similar overwriting of the page cache.

Both vulnerabilities manipulate the Linux page cache where data from disk is stored for rapid access. The kernel will always prefer the cached version of a file, which means that anything that is able to manipulate the contents of the cache can effectively replace the contents of the file. Both of the vulnerabilities leverage a similar mechanism – picking a binary which is flagged to run as root, such as su, and replacing the contents that would prompt for the users password with a launcher to immediately run a shell.

Like CopyFail, DirtyFrag requires the ability to execute code on the target in the first place, but turning almost any code or command execution vulnerability in any network service into root raises the impact significantly, allowing an attacker to break out of containers and privilege environments, or establish a persistent presence in the system when the original vulnerabilities are discovered and closed.

The previous mitigations to block specific kernel modules related to CopyFail are not sufficient to block the new vulnerabilities. At the time of writing this, there are no available patches from the distributions, however the vulnerable kernel modules can be temporarily disabled.

CopyFail added to KEV

CISA (the United States cyber security agency) has added CopyFail to the KEV, or Known Exploited Vulnerabilities list. Attacks on the KEV have been observed under active exploitation, which in the case of CopyFail is hardly a surprise.

The KEV is designed as a tool to allow security teams in government and commercial industry to prioritize the highest risk vulnerabilities – or at least give another source of data to point at when you say “we really need to patch this now”.

Prolonged Ubuntu DDOS

On the heels of the CopyFail vulnerability impacting almost all distributions, Ubuntu has had to face a prolonged distributed denial-of-service (DDoS) attack against the main infrastructure. Ars Technica reported at the beginning of the attack, and after several days, services appear to be restored. In the meantime, core services such as package updates, core repositories, and even the Ubuntu and Canonical websites were largely unreachable.

An Iraqi group claims responsibility for the attack, but it is unclear if they were the actual perpetrators – or why. The timing with the CopyFail vulnerability seems like an opportune moment to cause chaos by taking the update mechanisms of a major distribution offline, but in the era of modern Internet behavior, it could also just have been a Tuesday.

Continue reading “This Week In Security: Another Linux Exploit, Ubuntu Knocked Offline, Finals Interrupted, And Backdoored Tools”

This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

Continue reading “This Week In Security: The X DDoS, The ESP32 Basementdoor, And The CamelCase RCE”

Hackaday Links Column Banner

Hackaday Links: July 28, 2024

What is this dystopia coming to when one of the world’s largest tech companies can’t find a way to sufficiently monetize a nearly endless stream of personal data coming from its army of high-tech privacy-invading robots? To the surprise of almost nobody, Amazon is rolling out a paid tier to their Alexa service in an attempt to backfill the $25 billion hole the smart devices helped dig over the last few years. The business model was supposed to be simple: insinuate an always-on listening device into customers’ lives to make it as easy as possible for them to instantly gratify their need for the widgets and whatsits that Amazon is uniquely poised to deliver, collecting as much metadata along the way as possible; multiple revenue streams — what could go wrong? Apparently a lot, because the only thing people didn’t do with Alexa was order stuff. Now Amazon is reportedly seeking an additional $10 a month for the improved AI version of Alexa, which will be on top of the ever-expanding Amazon Prime membership fee, currently at an eye-watering $139 per year. Whether customers bite or not remains to be seen, but we think there might be a glut of Echo devices on the second-hand market in the near future. We hate to say we told you so, but — ah, who are we kidding? We love to say we told you so.

Continue reading “Hackaday Links: July 28, 2024”

This Week In Security: Somebody’s Watching, Microsoft + Linux, DDoS

In case you needed yet another example of why your IoT devices shouldn’t be exposed to the internet, a large swath of Hikvision IP Cameras have a serious RCE vulnerability. CVE-2021-36260 was discovered by the firm Watchful_IP in the UK. In Hikvision’s disclosure, they refer to the problem as a command injection vulnerability in the device’s web interface. The vuln is pre-authentication, and requires no user interaction. This could be something as simple as a language chooser not sanitizing the inputs on the back-end, and being able to use backticks or a semicolon to trigger an arbitrary command.

Now you’re probably thinking, “I don’t use Hikvision cameras.” The sneaky truth is that a bunch of cameras with different brand names are actually Hikvision hardware, with their firmware based on the Hikvision SDK. The outstanding question about this particular vulnerability is whether it’s present in any of the re-labelled cameras. Since the exact vulnerability has yet to be disclosed, it’s hard to know for sure whether the relabeled units are vulnerable.  But if we were betting… Continue reading “This Week In Security: Somebody’s Watching, Microsoft + Linux, DDoS”

This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More

Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.

We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.

NXNSAttack has a theoretical per-byte amplification factor of 163. That’s not a missed decimal point, this has the potential to be quite the nasty problem. Continue reading “This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More”

This Week In Security: Zeroconf Strikes Again, Lastpass Leaks Your Last Password, And All Your Data Is Belong To Us

VoIP cameras, DVRs, and other devices running the Web Services Dynamic Discovery (WSDD) protocol are being used in a new type of DDoS attack. This isn’t the first time a zeroconf service has been hijacked as part of a DDoS, as UPnP has also been abused in similar ways.

Feel like alphabet soup yet? A Denial of Service attack is one where the target is simply made unavailable, rather than actually compromised. The classic example of this is the SYN flood, where an attacker would open hundreds of connections to a web server at once, exhausting the server’s resources and interrupting legitimate use of that server. As mitigations for these attacks were developed (SYN Cookies, for example), DoS attacks were replaced by Distributed Denial of Service (DDOS) attacks. Rather than attack a weakness on the target machine, like available RAM or CPU cycles, a DDoS generally targets available network bandwidth by hitting the target website from many, many locations at once. No clever software tricks can help when your Internet connection is fully saturated with junk traffic. Continue reading “This Week In Security: Zeroconf Strikes Again, Lastpass Leaks Your Last Password, And All Your Data Is Belong To Us”

Memcached Servers Abused For DDoS Attacks

Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.

We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.

This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.

So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.

Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway.  And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.