I never really tracked down what exactly causes the vulnerability, but it's a rather common bug in various SSH implementations (millions of affected devices). Dropbear is the most commonly affected.
I guess easiest way to demonstrate it is like this:
debug1: Next authentication method: password
root@117.243.179.217's password:
debug1: Authentication succeeded (password).
Authenticated to 117.243.179.217 ([117.243.179.217]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_CTYPE = en_US.UTF-8
login failed: please enter correct username and password
Login:
Notice how for the initial login attempt the SSH server itself will accept any password, but subsequently the login is handled by the binary set as the login shell? After the initial "failed" login attempt you can freely open as many SSH tunnels as you please. You can most likely get RCE from here
I guess easiest way to demonstrate it is like this:
Notice how for the initial login attempt the SSH server itself will accept any password, but subsequently the login is handled by the binary set as the login shell? After the initial "failed" login attempt you can freely open as many SSH tunnels as you please. You can most likely get RCE from here