3 ms·

I too can break into my own house when I leave a door wide open for myself. There is nothing wrong with logrotate, ubuntu, ssh, or sudo here. Once you are pass

I too can break into my own house when I leave a door wide open for myself. There is nothing wrong with logrotate, ubuntu, ssh, or sudo here. Once you are passing arbitrary strings to bash as root -- yeah it's gonna be game over. This reminds me of the time a pentester found an XSS vuln and spent the entire rest of the engagement stuffing a keylogger into it. Like, OK, thanks, we already understand the implications of XSS. The solution provided is suboptimal because all the focus is spent in making a good exploit demo instead of considering the root cause(s): the configuration of ssh, sudo, and the godawful shell script the author dredged up from parts unknown. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush

burnte 3y ago
This is what Raymond Chen describes as "being on the other side of this airtight hatchway". https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- charcircuit 3y ago
  That is different. The user is intended to have privilege to rotate logs as root, but after the exploit the user is elevated to have full root.
mmsc 3y ago
OP here: I never said it's something wrong with logrotate, ubuntu, ssh, or sudo. It's a thought challenge with a guide, and could be a stage in a CTF challenge to get root. It's "something wrong" with the configuration chosen by a system administrator to allow "/usr/sbin/logrotate *" to be run as root without consideration of what the logrotate binary may do with certain arguments. It's just an explanation of how to exploit this situation if you find a server using this type of configuration. That's the whole basis of projects like https://gtfobins.github.io/ https://gtfobins.github.io/ and https://gtfoargs.github.io/ https://gtfoargs.github.io/. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush Did you actually read the article at all? If you use rbash or rshell and logrotate can be run as root, this issue still persists. The logrotate binary is the one performing these actions, not bash. Once you are passing arbitrary strings to bash as root Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate.
- singlow 3y ago
  Your opening line can easily be interpreted as stating that the stock 22.04 server install has an account with this privilege: > The scenario is this: a brand new Ubuntu 22.04 server has an account which is restricted to running sudo logrotate . It might have been better to say: > The scenario is this: take a brand new Ubuntu 22.04 server and create an account which is restricted to running sudo logrotate .
- gorkish 3y ago
  > Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate. No it's not; you are just exploiting bash's argument expansion in a badly written script you wrote to feed some additional shell stuff to bash /after/ the logrotate command. You could have done this as easily with 'sudo /bin/false' in there. Yes, you made logrotate do some things, but that's just a red herring in this case. The entire security issue is with the dumb bash script; it has nothing to do with anything else. Nothing in ubuntu's documentation anywhere tells you to "use this insecure bash script" to restrict a user to running a single command. It doesn't tell you to give global passwordless sudo privileges to the user that you want to do this either. Your configuration is cobbled from suggestions you found online and proceeded to implement incompletely/poorly.
  - mmsc 3y ago
    you are just exploiting bash's argument expansion /etc/sudoers does not use "bash's argument expansion". to feed some additional shell stuff to bash /after/ the logrotate command Wrong. It's clearly about a sudoers rule which uses wildcards (see sudoers(5) "Wildcards" section. The entire security issue is with the dumb bash script; it has nothing to do with anything else. The security issue is that a sudoers(5) rule allows a nonprivliged user to run logrotate with any arguments, and as it turns out, those arguments can be used to achieve root. It doesn't tell you to give global passwordless sudo privileges A /etc/sudoers rule of user ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate \* does not provide the user with "global passwordless sudo privileges". rtfm of sudoers(5).
    - 3y ago
Retr0id 3y ago
last time I checked (several years ago), rbash is full of security holes, and while those may have been patched now I really would not trust it to lock down a privileged shell session.

burnte 3y ago

This is what Raymond Chen describes as "being on the other side of this airtight hatchway". https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

charcircuit 3y ago
That is different. The user is intended to have privilege to rotate logs as root, but after the exploit the user is elevated to have full root.

mmsc 3y ago

OP here: I never said it's something wrong with logrotate, ubuntu, ssh, or sudo. It's a thought challenge with a guide, and could be a stage in a CTF challenge to get root. It's "something wrong" with the configuration chosen by a system administrator to allow "/usr/sbin/logrotate *" to be run as root without consideration of what the logrotate binary may do with certain arguments. It's just an explanation of how to exploit this situation if you find a server using this type of configuration. That's the whole basis of projects like https://gtfobins.github.io/ https://gtfobins.github.io/ and https://gtfoargs.github.io/ https://gtfoargs.github.io/. As I have seen this style of script being used with forced commands in authorized_keys, my conclusion is that the author loosely followed some online guide for restricting SSH access to certain commands and either inherited the flawed original script or made the error adapting it to the local requirements. Proper options for restricting the shell abound. From the top of my head: rssh, sshdo, PolicyKit, rbash, rush Did you actually read the article at all? If you use rbash or rshell and logrotate can be run as root, this issue still persists. The logrotate binary is the one performing these actions, not bash. Once you are passing arbitrary strings to bash as root Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate.

singlow 3y ago
Your opening line can easily be interpreted as stating that the stock 22.04 server install has an account with this privilege: > The scenario is this: a brand new Ubuntu 22.04 server has an account which is restricted to running sudo logrotate . It might have been better to say: > The scenario is this: take a brand new Ubuntu 22.04 server and create an account which is restricted to running sudo logrotate .
gorkish 3y ago
> Passing arbitrary strings to bash as root? It's about passing arbitrary arguments to logrotate. No it's not; you are just exploiting bash's argument expansion in a badly written script you wrote to feed some additional shell stuff to bash /after/ the logrotate command. You could have done this as easily with 'sudo /bin/false' in there. Yes, you made logrotate do some things, but that's just a red herring in this case. The entire security issue is with the dumb bash script; it has nothing to do with anything else. Nothing in ubuntu's documentation anywhere tells you to "use this insecure bash script" to restrict a user to running a single command. It doesn't tell you to give global passwordless sudo privileges to the user that you want to do this either. Your configuration is cobbled from suggestions you found online and proceeded to implement incompletely/poorly.
- mmsc 3y ago
  you are just exploiting bash's argument expansion /etc/sudoers does not use "bash's argument expansion". to feed some additional shell stuff to bash /after/ the logrotate command Wrong. It's clearly about a sudoers rule which uses wildcards (see sudoers(5) "Wildcards" section. The entire security issue is with the dumb bash script; it has nothing to do with anything else. The security issue is that a sudoers(5) rule allows a nonprivliged user to run logrotate with any arguments, and as it turns out, those arguments can be used to achieve root. It doesn't tell you to give global passwordless sudo privileges A /etc/sudoers rule of user ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate \* does not provide the user with "global passwordless sudo privileges". rtfm of sudoers(5).
  - 3y ago

Retr0id 3y ago

last time I checked (several years ago), rbash is full of security holes, and while those may have been patched now I really would not trust it to lock down a privileged shell session.