# Hunting Copy Fail: 732 Bytes to Root

## Метаданные

- **Канал:** 13Cubed
- **YouTube:** https://www.youtube.com/watch?v=ZVmpK-9rP0Q
- **Дата:** 01.05.2026
- **Длительность:** 7:03
- **Просмотры:** 2,060
- **Источник:** https://ekstraktznaniy.ru/video/49164

## Описание

In this episode, we'll look at how Copy Fail (CVE-2026-31431) works and highlight key forensic detection opportunities.

*** If you enjoy this video, please consider supporting 13Cubed on Patreon at patreon.com/13cubed. ***

📖 Chapters

00:00 - Intro
01:19 - Demo

🛠 Resources

CVE-2026-31431 (Copy Fail) Forensics:
https://nullsec.us/cve-2026-31431-copy-fail-forensics/

#Forensics #DigitalForensics #DFIR #ComputerForensics #CopyFail

## Транскрипт

### Intro []

Welcome to 13 cubed. In this quick and impromptu episode, we're going to talk about copy-fail. If you're not familiar, copy-fail is a 9-year-old logic bug in the Linux kernel that lets any unprivileged local user gain full root access. So, it's a local privilege escalation or LPE vulnerability. It was publicly disclosed on April the 29th, 2016, which is just 2 days ago as I'm recording this. It works by exploiting a flaw in the kernel's cryptographic subsystem to write 4 bytes directly into the kernel's in-memory copy of a privileged system file. The key part here is in-memory copy. And in this case, the privileged system file that we're targeting is bin SU. As you're probably aware, the SU command can allow us to switch users on a Linux box. Because of the way this works, it doesn't actually touch the file on disk. So, it leaves very little on-disk forensic evidence. Fortunately, there are a couple of logs that you can look at that may indicate successful exploitation of this vulnerability. And that's the entire reason I'm making this 13 cubed episode. What's interesting is the attack can fit into a 732-byte Python script, which is what you're looking at here. If we switch over to the terminal

### Demo [1:19]

you'll notice we're already in the desktop and you can see the script right here. The first thing I want to do is run shasum against the existing bin SU tool and just take note of the hash right here. Next, let's go ahead and run the exploit. So, we'll type python3 copy_fail. py. Now, take note of the time. It's currently 13:43 as I'm recording this. When we press enter, you'll notice that we have a hash mark. And if I type who am I, we are indeed root. And I can further prove that by using ID. You can see that just that easy, we have become root, which is pretty crazy. Let's go ahead and type exit. And now let's repeat that shasum command. And as you can see, the hash is indeed different. But here's the thing. This is actually an in-memory artifact only. If you were to reboot the system and check the hash, it will revert back to what you see here on this specific Ubuntu 24. 04 box. So, it's not actually modifying the file on disk. Just to prove that, if I run stat against bin SU and take a look at the modification time, you'll notice that it does indeed say 3:06. And of course, we're here on May the 1st. So, we have not actually modified the file on disk. Okay. So, now that we've run this particular exploit and it was clearly successful, you may think, well, why don't we just take a look at var/log/auth. log and we can look for authentication events. Well, here's the problem. Do you see any? The last thing we see here is from 13:35, and this is actually cron running some things in the background. This is legit noise. But nothing happened as a result of what we just did. Well, what we can do is take a look at a different log, and in this case, that's going to be kern. log on this Ubuntu system. And notice what we have here. We have a message that says kernel process SU launched bin sh with null argv empty string added. That's a telltale sign of successful exploitation of this vulnerability and is one of the main things that we're going to be looking for forensically, at least based on our understanding right now as I'm recording this. Now, there is another message right above that. Notice it also is related to the kernel and it says net registered pf_alg protocol family. That in and of itself is not evil. However, it is also associated with this exploit. Now, depending on the system you're investigating, if this is a relatively rare message, then this, especially combined with this message, could give you further confidence that the vulnerability was exploited. But again, this alone doesn't necessarily mean that something was compromised. All right. So, what else could we look at besides var/log/kern. log? Well, we could look at the systemd journal. And to do that, we can use journalctl and I'm going to use {dash} since and just say 5 minutes ago. So, we can look at the last 5 minutes. And notice that we do indeed have in yellow text a kernel message that says process SU launched bin sh with null argv empty string added. So, very similar to what we saw in kern. log, which should make sense to you because remember, the systemd journal is just pulling or aggregating those logs and this is indeed a kernel log. And right above that, we have the same net registered pf_alg protocol family that we just talked about. So, basically, what does this mean? Well, it means that var/log/auth. log is not going to have anything. In fact, if you do see root-related activity on a system during a time period in which you knew root was active on the system and there are no authentication events in var/log/auth. log, that in and of itself is evidence that something was wrong. But in terms of actually finding a log that you can look at, well, var/log/kern. log did show us a couple of things as did the systemd journal, which we viewed with journalctl. And again, the main thing we're looking for here is what you see in yellow, and especially that combined with the pf_alg protocol family message, is indeed indicative of successful exploitation. So, what I would like you to do is if you have other methods of detecting this, especially in stock configurations on various distros, please share that in the comments below so that we can all learn. This is again fairly new. It only was released 2 days ago as I'm recording this. So, this is something that we all need to keep an eye on. The other thing I want to mention here is the elephant in the room, and that's the fact that I'll bet you a box of donuts that 10 years from now, you're still going to find systems vulnerable to this. Think about embedded systems and appliances and just all sorts of things that are built upon Linux that may not get timely updates or may not get updates at all. So, I think this is something that's going to be with us for a very long time. And I think that red teamers are certainly going to have a field day with this well into the future. And unfortunately, not just red teamers, but bad guys as well. So, we need to keep an eye on this, and really, that's the whole entire reason I wanted to make this video. I know that there are quite a few that have been made on YouTube right now talking about copy-fail, but very few talk about detection opportunities and forensics. The other thing I'll mention here is that nullsec does have a blog post that I'm sure he'll keep updated that talks about copy-fail, and I'll leave a link to that in this video's description as well. But that's really all I wanted to cover in this quick 13 cubed episode. I hope you found this information useful, and I'll look forward to your comments if you do have other ways and other methods of detecting successful exploitation of copy-fail. Thanks for watching. Thanks for subscribing. And I'll see you in the next 13 cubed episode.