 |
| with a logo like this, who can resist to learn more |
An interesting report by Qualys
"The Qualys Research Labs discovered multiple vulnerabilities in procps, a set of command line and full screen utilities for browsing procfs..."
I'd like to use this as an example today of how many strange, unknown attack surfaces must exist on the Unix ecosystem today, and how we must think creatively and diligently to defend against them.
When I saw this report, my initial reaction was "...a set of command line utilities for browsing procfs, awesome, how could I have never seen that before!" ...but then I realized that this is just the official project's way of describing top, ps, w, free, and some other programs which every Unix professional should know in and out (this includes you, Mac folks). Then it hit me how ultimately critical these vulnerabilities could be, which was not evident just by reading the Debian security bullitin.
The /proc directory on every Linux machine is full of files used to explore and learn more about your system in real time; actually it is literally the kernel manifesting itself into the "runtime," so this is the computer coming to life to interface with the human if that's how you want to visualize it. You can read information out of it to create other applications and even modify it directly. In some ways it's like the Windows registry. Most actions you take on Linux actually can be achieved in an alternative form by writing over a file somewhere within /proc. An common example is that to create a linux router, you must enable packet forwarding using the sysctl command, but you can also do that temporarily by typing at the command prompt " echo 1 > proc/sys/net/ipv4/ip_forward ." If you look at that file, it is simply a "1" or a "0." It is storing the state of the ip_forward value of your system, so that you can read it and other tools can access it. One of the first Linux systems I built was on a Powerbook G4 (powerpc arch), where you had to do a similar echo command in order to make the system hibernate or standby.
This is the explanation of how top works, from the man page:
Today I wanted to just use this as a challenge to creativity, research, and continual learning, but if you are interested in POC here are the links to the attacks:
https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txthttps://gitlab.com/procps-ng/procps/commit/b45c4803dd176f4e3f9d3d47421ddec9bbbe66cd
I asked around online, in which cases would the $HOME constant not be set, and it seems to be a rare occasion, but due to the flaws in comparative scoring like CVE, this rarity may be the only reason the vulnerability was listed as "low impact." There might also be a away to remove the constant, like I mentioned above. Qualys mentions that is also the case when there is simply an empty $HOME environment variable (which might be a mistake by an admin or even a slightly more common scenario). I pointed out that even in the dash shell (default in Debian if you don't set Bash), it is set. So as @espen mentioned to me, this is defined in the POSIX standard, so it would almost always be set, but in the world of ever-growing IOT devices and systems that are designed primarily to offer a service and never be "logged into," this may be silently becoming more of an issue. Think too of systems like busybox, which I see getting attacked by bots on my honeypots on a daily basis. Think of all those accounts on Linux, even your Kali box for pentesting, that you have no idea what they are form even more so on systemd: learn what they are for.
In my mind this creates a number or probable attack surfaces to defend against. Assume breach. A saavy attacker--and with Unix I always assume there is a veteran who knows more than me--might know of a way to compromise a system account without the shell set, and "own" your system. This is the main takeaway today. Humility and creativity. The Blue Team doesn't want to simply ask "what if," we want to ask "what if," but then be able to confidently say "that is not possible," or at least say "that is extremely unlikely," with much greater granularity than assigning a high, medium, or low value on a traffic light to each vulnerability summary.
Take a further look around the top man page if you are interested. The global configuration file also is quite interesting in the same way. It is a perfect example of how hundreds of such bugs must exist in so many programs core to the Linux ecosystem, which literally runs the Internet.
From https://attack.mitre.org/wiki/Linux_Techniques there are only a few examples given of similar attacks, actually Mitre ATT&CK provides excellent coverage of Exploitation for Privilege Escalation overall, but just basically mentions software flaws as ways an adversary could gain unauthorized credentials, or evade defenses, without giving many examples. In a future post, I plan to go through all the linux priv-esc cases from ATT&CK which I was not aware of. I also have some new packet analysis cases to go through, as always.
A really cool example is given though of "a rare attack" which comes from classic research by Skape at Hick.org. They explained (in 2003!) the general concept of injection into a running process or the proc system. "/proc/[pid]/mem provides access to the memory of the process and can be used to read/write arbitrary data to it. This technique is very rare due to its complexity" according to Mitre.
In closing remember, that however hard to pull off, these attacks exist, and this is where vulnerabilities like the procps set last week come from. The other attacks were even much more serious than top; I just chose top to focus on since almost everyone has used it at one time or another. It only takes one person to engineer an exploit for these to become simple for anyone to use.
A special thanks goes to Espen Rønnevik (@espen) who gave me a great tip about POSIX via the infosec.exchange. It always pays to have great *nix folks around.
When I saw this report, my initial reaction was "...a set of command line utilities for browsing procfs, awesome, how could I have never seen that before!" ...but then I realized that this is just the official project's way of describing top, ps, w, free, and some other programs which every Unix professional should know in and out (this includes you, Mac folks). Then it hit me how ultimately critical these vulnerabilities could be, which was not evident just by reading the Debian security bullitin.
The /proc directory on every Linux machine is full of files used to explore and learn more about your system in real time; actually it is literally the kernel manifesting itself into the "runtime," so this is the computer coming to life to interface with the human if that's how you want to visualize it. You can read information out of it to create other applications and even modify it directly. In some ways it's like the Windows registry. Most actions you take on Linux actually can be achieved in an alternative form by writing over a file somewhere within /proc. An common example is that to create a linux router, you must enable packet forwarding using the sysctl command, but you can also do that temporarily by typing at the command prompt " echo 1 > proc/sys/net/ipv4/ip_forward ." If you look at that file, it is simply a "1" or a "0." It is storing the state of the ip_forward value of your system, so that you can read it and other tools can access it. One of the first Linux systems I built was on a Powerbook G4 (powerpc arch), where you had to do a similar echo command in order to make the system hibernate or standby.
The power of Proc - why are you reading this..?
- Procps includes "ps, top, vmstat, sysctl, w, kill, skill, nice, snice, pgrep, free, tload, uptime, watch" according to the sourceforge page. These tools are a must-know for security engineers. You can literally login and within seconds find everything you need to know (or completely destroy a system) with these commands. A red team can attack with them or quickly gain knowledge about a system, and a blue team needs to defend against them or use them to analyze a headless system.
- This is an amazing example of the huge amount of work by thousands of individuals that goes into open source software in general, but specifically the Unix ecosystem. Don't take this for granted.
- These bugs were of the extra quirky sort, just imagine how many hundreds more must exist in Linux or even OSX. The top vuln was labeled by the CVS database as "low impact." Bayesian probability fans may point out to you at this moment that "high medium low" is not the best way to assess risks with hundreds of random factors in your very valuable corporate environment. The point is: think creatively about security. The article linked just above is from Adam Shostack, and is a really fun read.
- The entire project has a heavy does of humor hidden around every turn, just read the man page for top for example. The contributors include "just a sampler" of "hidden tricks" including the Big Bird trick and the Bouncing Window trick. I have to say that I didn't know about these. Here's another example from the project website's FAQ: "Why does ps get signal 17? No ps release has ever had this problem. Most likely your system has been broken into. You might want to install a more recent version of the OS. If you'd rather take your chances, simply upgrade procps."
An example of these attacks, would you have thought of this?
"... If the $HOME and $XDG_CONFIG_HOME variables are not present, top will try to write the personal configuration file in the current directory, subject to permissions."There was a bug found in the way that the program looks for the config file if it is not there. An unprivileged attacker might even have a way of removing the constant, first! These situations would mean that you can kill processes, renice (adjust the relative priority) processes, reorder jobs, and more; you could do anything top can do. Some of the other attacks let the attacker block admins from stopping processes, hide malicious processes altogether, and even escape containers!
Today I wanted to just use this as a challenge to creativity, research, and continual learning, but if you are interested in POC here are the links to the attacks:
https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txthttps://gitlab.com/procps-ng/procps/commit/b45c4803dd176f4e3f9d3d47421ddec9bbbe66cd
Humility and Creativity
In my mind this creates a number or probable attack surfaces to defend against. Assume breach. A saavy attacker--and with Unix I always assume there is a veteran who knows more than me--might know of a way to compromise a system account without the shell set, and "own" your system. This is the main takeaway today. Humility and creativity. The Blue Team doesn't want to simply ask "what if," we want to ask "what if," but then be able to confidently say "that is not possible," or at least say "that is extremely unlikely," with much greater granularity than assigning a high, medium, or low value on a traffic light to each vulnerability summary.
Take a further look around the top man page if you are interested. The global configuration file also is quite interesting in the same way. It is a perfect example of how hundreds of such bugs must exist in so many programs core to the Linux ecosystem, which literally runs the Internet.
Mitre agrees
A really cool example is given though of "a rare attack" which comes from classic research by Skape at Hick.org. They explained (in 2003!) the general concept of injection into a running process or the proc system. "/proc/[pid]/mem provides access to the memory of the process and can be used to read/write arbitrary data to it. This technique is very rare due to its complexity" according to Mitre.
In closing remember, that however hard to pull off, these attacks exist, and this is where vulnerabilities like the procps set last week come from. The other attacks were even much more serious than top; I just chose top to focus on since almost everyone has used it at one time or another. It only takes one person to engineer an exploit for these to become simple for anyone to use.
A special thanks goes to Espen Rønnevik (@espen) who gave me a great tip about POSIX via the infosec.exchange. It always pays to have great *nix folks around.
