0

On a recent penetration test it was identified that the rbash restricted shell we use could be escaped by simply forcing allocation of a pseudo terminal.

ssh -i id_rsa_key user@hostname -t "bash --noprofile"

I have done a fair amount of research and haven't been able to find anything regarding how to prevent this via an ssh config or other process. Any suggestions on how to lock this down would be greatly appreciated.

mindgame3713
  • 35
  • 3
  • 1
    Possibly of interest: https://stackoverflow.com/q/33713680/1126841 – chepner May 16 '18 at 18:52
  • 1
    Are you sure it's related to `-t`? If your only step was to set the user's login shell to `rbash` then it's expected that a simple `bash` will give you a complete, unrestricted shell. – that other guy May 16 '18 at 21:10
  • 1
    Your security hole is the user's ability to execute `bash`, not the user's ability to get a TTY. Even without a TTY, the user would be able to invoke bash and send commands to it. – Kenster May 17 '18 at 11:34
  • Thanks for the replys. When the user connects without the `-t "bash --noprofile"` flag, they receive a rbash shell which only allows execution of commands within the `/home/bin/` directory. If you try and execute anything outside of that you are denied, including bash. – mindgame3713 May 17 '18 at 20:42

1 Answers1

1

Finally found a fix using a method found here:

How to restrict SSH users to a predefined set of commands after login?

You can restrict allocation of the PTY using a directive in the authorized_key file.

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1.......

mindgame3713
  • 35
  • 3