+- Sinisterly (https://sinister.li)
+-- Forum: Hacking (https://sinister.li/Forum-Hacking)
+--- Forum: Hacking Tools (https://sinister.li/Forum-Hacking-Tools)
+--- Thread: Dirty Pipes and CVEs (/Thread-Dirty-Pipes-and-CVEs)
Dirty Pipes and CVEs - ConcernedCitizen - 03-13-2022
SL, let's talk pipe bombs:
...no, not those kinds. I mean in reference to how they work on Linux and how to secure your sessions.
The topic: Dirty Pipe (CVE-2022-0847):
It's time.
A local privilege escalation vulnerability in the Linux kernel that could potentially allow an unprivileged user to do the following:
1. Modify/overwrite arbitrary read-only files like /etc/shadow or /etc/passwd.
2. Obtain an elevated shell.
Affected versions:
So far, Linux kernel versions newer than 5.8 are affected.**
So far, the vulnerability has been patched in the following Linux kernel versions, but doesn't mean everyone is already up-to-date:
* 5.16.11, 5.15.25, 5.10.102 are the known patched versions.
You can learn more about the vulnerability here:
CVE-2022-0847
DirtyPipe Vulnerability Scanner:
If you are not sure if a target system is vulnerable, use this really cool bash script developed by @basharkey.
DirtyPipe Checker: https://github.com/basharkey/CVE-2022-0847-dirty-pipe-checker
Compiling the exploit:
An automated compiler bash script has been provided to you to automate the compilation of both exploits.
In order to compile the exploit succesfully, you will need to have GCC installed.
1. Install the only dependency for the Dirty Pipe exploit:
Code:
sudo apt-get install gcc2. After installing GCC, you can run the 'compile.sh" script as follows:
Code:
chmod +x compile.sh
./compile.sh./exploit-1: Modifying/overwriting read only files
This repo contains 2 exploits, the 'exploit-1.c' exploit can be used to modify or overwrite arbitrary read only files.
This exploit is a proof of concept that was developed by Max Kellermann and has been modified to change the root password in the /etc/passwd file, consequently providing you with access to an elevated shell.
Running the exploit binary:
The exploit code has already been configured to replace the root password with the password "piped" and will take a backup of the /etc/passwd file under /tmp/passwd.bak. Furthermore, the exploit will also provide you with an elevated root shell and will restore the original passwd file when done.
Code:
./exploit-1./exploit-2 - Hijacking SUID binaries:
This exploit can be used to inject and overwrite data in read-only SUID process memory that run as root.
Finding SUID binaries:
Code:
find / -perm -4000 2>/dev/nullRunning the exploit binary:
Code:
./exploit-2 /usr/bin/sudoImportant Note:
I do not claim credit/ownership/disclosure of the vulnerability and all corresponding exploits hosted in this GitHub repo.
All the credit goes to the awesome Max Kellerman, you can check out the official disclosure here: https://dirtypipe.cm4all.com/
Credits:
1. https://github.com/febinrev/dirtypipez-exploit
2. https://github.com/basharkey/CVE-2022-0847-dirty-pipe-checker
** 5.10.60.1-microsoft-standard-WSL2 (the current version for default install) is also affected, interestingly. :>
Now with more exploit discovery using YARA:
Code:
/*
This Yara ruleset is under the GNU-GPLv2 license (http://www.gnu.org/licenses/gpl-2.0.html)
and open to any user or organization, as long as you use it under this license.
Author: Max Kellerman
Date: 2022-02-19
Identifier: Dirty Pipe PoC
*/
/* Super Rule ------------------------------------------------------------- */
rule DirtyPipez_CVE_2022_0847
meta:
description = "Exploit Sample DirtyPipe CVE-2022-0847"
author = "Max Kellerman"
eference = "https://dirtypipe[.]cm4all[.]com/"
date = "2022-02-19"
vuln_type = "Local Privilege Escalation (DirtyCow reloaded?)"
vuln_impact = "SUID binary hijack"
affected_versions = "Linux kernel >5.15 <5.15.25 >=5.16 <5.16.11"
report = "https://dirtypipe[.]cm4all[.]com/"
hash1 = "8ced0e276f4cbe52ddac086b0a902e63970edc1a3ef22ba9dfc7150d8052bcf7"
hash2 = "49561b607ebee157831f4eb55be9893165cf522c71a92c1b80aacc8262489f14"
/* Automatically generated by yarGen -------------------------------------- */
strings:
$s1 = "prepare_pipe" fullword ascii
$s2 = "pipe@GLIBC_2.2.5" fullword ascii
$s3 = "splice failed" fullword ascii
$s4 = "_IO_stdin_used" fullword ascii
$s5 = ".note.ABI-tag" fullword ascii
$s6 = "__stack_chk_fail@GLIBC_2.4" fullword ascii
$s7 = ".eh_frame_hdr" fullword ascii
$s8 = "__FRAME_END__" fullword ascii
$s9 = "__frame_dummy_init_array_entry" fullword ascii
$s10 = "read@GLIBC_2.2.5" fullword ascii
$s11 = "__GNU_EH_FRAME_HDR" fullword ascii
$s12 = "short splice" fullword ascii
$s13 = "__libc_start_main" fullword ascii
$s14 = "__do_global_dtors_aux_fini_array_entry" fullword ascii
$s15 = "buffer.0" fullword ascii
condition:
uint16(0) == 0x457f and ( 8 of them ) or ( all of them )RE: Dirty Pipes and CVEs - ConcernedCitizen - 04-03-2022
Bumping because I created a YARA rule to detect operation of the two binaries and similar fuzzed binaries with their respective hashes. You can read more about the functionality over at SysDig.
https://raw.githubusercontent.com/Yara-Rules/rules/d44a5197d9855ab9d01ad7665ea840cf545883d7/cve_rules/CVE-2022-0847.yar
RE: Dirty Pipes and CVEs - Drako - 04-03-2022
Most Linux exploits happen at the kernel level. This is why I always keep my kernel as up-to-date as possible. Whenever a new kernel package is released to the Gentoo repository, I compile it. And my config is heavily modified. Of course, doing both of those things can lead to problems, and it has many times. But, it's a learning experience and leads to a better system.
I'll have to check and see if 5.17.1 is still vulnerable to this.
RE: Dirty Pipes and CVEs - ConcernedCitizen - 04-04-2022
(04-03-2022, 06:00 PM)Drako Wrote: Most Linux exploits happen at the kernel level. This is why I always keep my kernel as up-to-date as possible. Whenever a new kernel package is released to the Gentoo repository, I compile it. And my config is heavily modified. Of course, doing both of those things can lead to problems, and it has many times. But, it's a learning experience and leads to a better system.Tested on Bullseye amd64 linux-image-amd64 5.16.18-1, it's fixed in versions 5.16.11, 5.15.25 and 5.10.102 (WSL)
I'll have to check and see if 5.17.1 is still vulnerable to this.