3 ms·

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 w

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

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.