4 ms·

Yeah but you can harden against that. You can: 1. Audit writes to paths like bashrc (I've written this alert and many others like it) 2. Audit writes from pro

Yeah but you can harden against that. You can: 1. Audit writes to paths like bashrc (I've written this alert and many others like it) 2. Audit writes from processes under uid X to files in uid Y's home 3. Limit the need to sudo in the first place 4. Add a TOTP auth to sudo 5. Limit the ability for arbitrary processes to write to arbitrary files (containerize your shells, services, etc). The thing is that all of the above assume the attacker isn't already root. If the attacker is root, this all becomes a lot harder.

zaarn 5y ago
Alright, instead, knowing this, I shall simply change the configuration of your terminal emulator to use a wrapper script I wrote. It'll inject a script into the shell to alias sudo to my evil variant. The evil variant will instead of calling whatever you wanted with sudo instead call itself and first worm into the system with root, then continue execution with what you wanted. A simple scan should reveal running services and the executable will disguise itself as those, ideally by writing to files that the original sudo command would have written to. Like, if you sudo crontab -e, then I shall simply worm into your crontab and wrap access to it to hide the actual contents. Once that is done I can go into manipulating your audit to hide myself before continuing with more nefarious things.
- staticassertion 5y ago
  I'm not sure I understand this attack. You're some process under a uid, say 1000. I SSH into the box and get a shell at uid 1000. You're describing an attack where you configure my terminal to use a wrapper script? What exactly does that entail?
  - zaarn 5y ago
    Well for SSH you can simply edit the authenticated_keys file to get what you want.
    - staticassertion 5y ago
      Sorry, I'm still not understanding your attack. As a user on the system, which files are you writing to exactly in order to execute this attack you've described?
      - zaarn 5y ago
        Any configuration files of programs the user might call, such as editors, ssh, terminal emulators, shells or anything the user regularly executes. Every binary that loads data from the user directory for user configuration is a vector for further inserting oneself into the system. The spellcheck function of Nano can be exploited to spawn a subprocess that takes over the session. When you exit Nano, you're exiting this new subprocess and end up in a shell that has been manipulated. Same for Vim. SSH can be manipulated into replacing your shell easily by editing authorized_keys. If a program has write access to your home directory, you cannot trust the shell you open. Even something as innocous as git status being included in your prompt can be abused to gain control of your shell session. Once you have that you just wait for sudo to be entered or you manipulate the shell to execute an attacker's code instead of sudo when called.
        staticassertion 5y ago
        I'd be interested in hearing more about the specific for some of these, but others seem unlikely to work. For example, there's no reason for a user to have read, let alone write, access to authorized_keys. Read and write access for users is way overly permissive by default, but it's really easy to fix that. I do agree that you can't trust the shell if a user is compromised though. But this is about preventing an attacker from gaining root access, which means you now can't trust the entire system (since they can just shut off security controls). Also keep in mind that all of these described attacks require performing auditable actions. If an attacker can trivially, quickly escalate, you can't trust your auditing.

zaarn 5y ago

Alright, instead, knowing this, I shall simply change the configuration of your terminal emulator to use a wrapper script I wrote. It'll inject a script into the shell to alias sudo to my evil variant. The evil variant will instead of calling whatever you wanted with sudo instead call itself and first worm into the system with root, then continue execution with what you wanted. A simple scan should reveal running services and the executable will disguise itself as those, ideally by writing to files that the original sudo command would have written to. Like, if you sudo crontab -e, then I shall simply worm into your crontab and wrap access to it to hide the actual contents. Once that is done I can go into manipulating your audit to hide myself before continuing with more nefarious things.

staticassertion 5y ago
I'm not sure I understand this attack. You're some process under a uid, say 1000. I SSH into the box and get a shell at uid 1000. You're describing an attack where you configure my terminal to use a wrapper script? What exactly does that entail?
- zaarn 5y ago
  Well for SSH you can simply edit the authenticated_keys file to get what you want.
  - staticassertion 5y ago
    Sorry, I'm still not understanding your attack. As a user on the system, which files are you writing to exactly in order to execute this attack you've described?
    - zaarn 5y ago
      Any configuration files of programs the user might call, such as editors, ssh, terminal emulators, shells or anything the user regularly executes. Every binary that loads data from the user directory for user configuration is a vector for further inserting oneself into the system. The spellcheck function of Nano can be exploited to spawn a subprocess that takes over the session. When you exit Nano, you're exiting this new subprocess and end up in a shell that has been manipulated. Same for Vim. SSH can be manipulated into replacing your shell easily by editing authorized_keys. If a program has write access to your home directory, you cannot trust the shell you open. Even something as innocous as git status being included in your prompt can be abused to gain control of your shell session. Once you have that you just wait for sudo to be entered or you manipulate the shell to execute an attacker's code instead of sudo when called.
      - staticassertion 5y ago
        I'd be interested in hearing more about the specific for some of these, but others seem unlikely to work. For example, there's no reason for a user to have read, let alone write, access to authorized_keys. Read and write access for users is way overly permissive by default, but it's really easy to fix that. I do agree that you can't trust the shell if a user is compromised though. But this is about preventing an attacker from gaining root access, which means you now can't trust the entire system (since they can just shut off security controls). Also keep in mind that all of these described attacks require performing auditable actions. If an attacker can trivially, quickly escalate, you can't trust your auditing.