[DEADMINCE]

> 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]

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]

> 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]

> 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]

> 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]

>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!"?

[DEADMINCE]

> And you don't actually pentest the software which those users on the windows machine are using on the Linux systems?

You really love your assumptions, huh?

> it's just a "well, I got access, nothing more to see!"?

I said nothing like that, and besides that, if you were not just focused on arguing for the sake of it, you would see MY point was about the infrequency of the situation you were talking about (and even then your original point seemed to be contrarian in nature more than anything).

[mmsc]

>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/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]

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.