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.
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.
> 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.
>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!"?
> 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).
Fidelity, who remains a stakeholder in the private company and gets insight to internal financials, has cut the valuation of their holding by 75% so far [1]. While twitter might not have been profitable when purchased, it was structured as a growth stock (that is, expected to invest most profit back into the product, in order to continue to multiply revenue) and had yearly revenues of $5B.
Em, that seems an extremely generous comparison, where did you come up with that? Last I checked for example systemd relies on polkit for policies, which drags in a javascript interpreter engine. If the author thinks BNF is complex…
Came here to mention this. I used this exact setup (used a laptop battery bank off of amazon as a UPS for my home modem), and came home months later to find the bank had caught fire at some point, melted, and was no longer functional. Would not recommend
> First, some vendors make it difficult to associate an SSH key with a user. Then, many vendors do not support certificate-based authentication, making it difficult to scale. Finally, interactions between public-key authentication and finer-grained authorization methods like TACACS+ and Radius are still uncharted territory
Keys (with/without certs) are the best route, but not always possible for every situation.
Honest question, unless it's mandated by your employer, or you don't personally care, why would you ever choose to use a service that doesn't offer that?
There are not many network vendors. Check the link in the first footnote for an example how Cisco, the leader in the field, makes it difficult to deploy SSH keys. This is getting better. For example, Juniper (another network vendor) now supports SSH certificates.
I have no idea what's going on in the footnote, but deploying SSH keys on Cisco equipment is like 3 commands (conf t, user x, ssh something something) to deploy public keys, not hard at all.
It's been a few years, but this requires manually deploying keys and adding/removing users on all your devices. Most use TACACS+ and/or Radius to centrally manage users, which don't support keys in that way (or at least didn't the last time I worked with them.)
Another possibility would be to use CA certificates for authentication and only TACACS+ for authorization and accounting. Juniper now supports CA certificates. Cisco may in 10 years.
Public key authentication is actually a Must Implement for SSHv2. Since SSHv1 is long obsolete, any gear that doesn't have pubkey doesn't actually have a de jure SSH implementation.
That doesn't mean it's always easy to install and manage keys. For example, the author of the passh tool recommended by this post somehow managed to come away with the impression that OpenWRT's ssh server only supports password authentication.
Another example: Ubiquiti gateway consoles like the UDM-Pro. You can install an SSH key but these are erased on reboot. So after every reboot I have a script that uses the SSH user password to re-install an SSH key but this can’t be relied upon and I haven’t found a way to make an SSH key persist.
One good example is bringing up equipment that comes out-the-box with a default password. This is common on BMCs for example, and you have to initially provision things somehow.
I’ve noticed the code reader is worthless on even slightly out of date browsers now, and even on newer browsers it tends to choke and stutter on large files. Sad :( it used to be the best
