4 ms·

People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to. But, sure, in th

People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to. But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.

mmsc 2y ago
>People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it will be used. Being local also greatly increases the exploitability. Then consider the networks where port 22 is blocked from the internet but sshd is running in some internal network (or just locally for some reason).
- DEADMINCE 2y ago
  > It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Right, which is almost none. www-data should be set to noshell 99% of the time. > or just locally for some reason). This is all that would be relevant, and this is also very rare.
  - infotogivenm 2y ago
    Think “illegitimate” access to www-data. It’s very common on linux pentests to need to privesc from some lower-privileged foothold (like a command injection in an httpd cgi script). Most linux servers run openssh. So yes I would expect this turns out to be a useful privesc in practice.
    - DEADMINCE 2y ago
      > Think “illegitimate” access to www-data. I get the point. My point was the example being given is less than 1% of affected cases. > It’s very common on linux pentests to need to privesc from some lower-privileged foothold Sure. Been doing pentests for 20+ years :) > So yes I would expect this turns out to be a useful privesc in practice. Nah.
      - infotogivenm 2y ago
        > Nah I don’t get it then… Do you never end up having to privesc in your pentests on linux systems? No doubt it depends on customer profile but I would guess personally on at least 25% of engagements in Linux environments I have had to find a local path to root.
        DEADMINCE 2y ago
        > Do you never end up having to privesc in your pentests on linux systems? Of course I do. I'm not saying privsec isn't useful, I'm saying the cases where you will ssh to localhost to get root are very rare. Maybe you test different environment or something, but on most corporate networks I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers for webapps or something else where normal users most who have a windows machine won't have a shell account. If there's a server where I only have a local account and I'm trying to get root and it's running an ssh server vulnerable to this attack, of course I'd try it. I just don't expect to be in that situation any time soon, if ever.
        mmsc 2y ago
        >I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers for webapps or something else where normal users most who have a windows machine won't have a shell account. And you don't actually pentest the software which those users on the windows machine are using on the Linux systems? So you find a Jenkins server which can be used to execute Groovy scripts to execute arbitrary commands, the firewall doesn't allow connections through port 22, and it's just a "well, I got access, nothing more to see!"?
  - mmsc 2y ago
    >www-data should be set to noshell 99% of the time. Huh? execve(2), of course, lets to execute arbitrary files. No need to spawn a tty at all. https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/shell-reverse-cheatsheet/ https://swisskyrepo.github.io/InternalAllTheThings/cheatshee... >This is all that would be relevant, and this is also very rare. Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare? That's exactly what lateral movement is about.
    - DEADMINCE 2y ago
      Instead of taking the time to reply 'huh' multiple times, you should make sure you read what you're replying to. For example: > Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare? The 'this' I refer to is very clearly not what you've decided to map it to here. The 'this' I refer to, if you follow the comment chain, refers to a subset of something you said which was relevant to your point - the rest was not.
remram 2y ago
You could have also said "99% of people don't let their login timeout and hit the SIGALRM"... People don't usually use an SSH RCE because there usually isn't an SSH RCE. If there is, why wouldn't they? It doesn't matter if 99% of the situations you can think of are not problematic. If 1% is feasible and the attackers know about it, it's an attack vector.

mmsc 2y ago

>People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Attackers don't care if it's an RCE or not: if a public sshd exploit can be used on a system with a Linux version without a public Linux LPE, it will be used. Being local also greatly increases the exploitability. Then consider the networks where port 22 is blocked from the internet but sshd is running in some internal network (or just locally for some reason).

DEADMINCE 2y ago
> It's going to apply to the amount of servers that an attacker has low-privileged access (think: www-data) and an unpatched sshd. Right, which is almost none. www-data should be set to noshell 99% of the time. > or just locally for some reason). This is all that would be relevant, and this is also very rare.
- infotogivenm 2y ago
  Think “illegitimate” access to www-data. It’s very common on linux pentests to need to privesc from some lower-privileged foothold (like a command injection in an httpd cgi script). Most linux servers run openssh. So yes I would expect this turns out to be a useful privesc in practice.
  - DEADMINCE 2y ago
    > Think “illegitimate” access to www-data. I get the point. My point was the example being given is less than 1% of affected cases. > It’s very common on linux pentests to need to privesc from some lower-privileged foothold Sure. Been doing pentests for 20+ years :) > So yes I would expect this turns out to be a useful privesc in practice. Nah.
    - infotogivenm 2y ago
      > Nah I don’t get it then… Do you never end up having to privesc in your pentests on linux systems? No doubt it depends on customer profile but I would guess personally on at least 25% of engagements in Linux environments I have had to find a local path to root.
      - DEADMINCE 2y ago
        > Do you never end up having to privesc in your pentests on linux systems? Of course I do. I'm not saying privsec isn't useful, I'm saying the cases where you will ssh to localhost to get root are very rare. Maybe you test different environment or something, but on most corporate networks I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers for webapps or something else where normal users most who have a windows machine won't have a shell account. If there's a server where I only have a local account and I'm trying to get root and it's running an ssh server vulnerable to this attack, of course I'd try it. I just don't expect to be in that situation any time soon, if ever.
        mmsc 2y ago
        >I test the linux machines are dev machines just used for compiling/testing and basically have shared passwords, or they're servers for webapps or something else where normal users most who have a windows machine won't have a shell account. And you don't actually pentest the software which those users on the windows machine are using on the Linux systems? So you find a Jenkins server which can be used to execute Groovy scripts to execute arbitrary commands, the firewall doesn't allow connections through port 22, and it's just a "well, I got access, nothing more to see!"?
- mmsc 2y ago
  >www-data should be set to noshell 99% of the time. Huh? execve(2), of course, lets to execute arbitrary files. No need to spawn a tty at all. https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/shell-reverse-cheatsheet/ https://swisskyrepo.github.io/InternalAllTheThings/cheatshee... >This is all that would be relevant, and this is also very rare. Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare? That's exactly what lateral movement is about.
  - DEADMINCE 2y ago
    Instead of taking the time to reply 'huh' multiple times, you should make sure you read what you're replying to. For example: > Huh? Exploiting an unpatched vulnerability on a server to get access to a user account is.. very rare? The 'this' I refer to is very clearly not what you've decided to map it to here. The 'this' I refer to, if you follow the comment chain, refers to a subset of something you said which was relevant to your point - the rest was not.

remram 2y ago

You could have also said "99% of people don't let their login timeout and hit the SIGALRM"... People don't usually use an SSH RCE because there usually isn't an SSH RCE. If there is, why wouldn't they? It doesn't matter if 99% of the situations you can think of are not problematic. If 1% is feasible and the attackers know about it, it's an attack vector.