Failed SSH Lockout!
--
So today I have an interesting story for you! Infact this incident happened with me today, and it was like those FUN CTF exercises, and in the end I pwned the machine as well, so I thought why not share it :)
Evil Team mate locked me out
So yesterday I was playing around with some JWT tokens of an online platform and wanted to perform some injection attacks to find out if its vulnerable in any way.
I was going for fuzzing the JWT token and thought to modify the iss (Issuer) URL in the token and set it to my own server IP and see if I get the token validation request (leading to an SSRF attack and potential token bypass as well).
So I head over to the shared server, which I share with my team. I was quite excited to try it out but the excitement ended when I saw I couldn’t login to my server!
I was quite confused first since the connection succeeded and I see the banner but suddenly it closed the connection! That’s quite weird… All worked well till yesterday, I told myself.
Then I googled for this issue and found this question: https://serverfault.com/questions/384676/linux-closing-connection-after-successful-login
The answers didn’t seemed okay to me since my user was there, it worked till yesterday and login shell was /bin/bash, atleast till the day before…
So I approached one of my team mates to see if he can login. Yes, he said. And that was quite shocking to me.
Sherlock Mode: Detecting the issue
Well I asked him to get me the /etc/passwd file first. And he happily shared it.
In no time I saw that indeed my login shell has been set to /bin/false to lock me out! I was quite shocked at this point. How the hell can someone lock you out of the server without even informing you atleast once! What about all my files there, need to take the backup bruh ._.
But anyways, I thought to myself why not bypass this and see if I can break in anyhow!
So I set out to talk to my friend who knows a lot btw, and his/her (whatever you like) name is Google xP
So I look for:
- How to execute commands via SSH?
- How to bypass /bin/false shell?
- How to recover disabled user account without root?
- …
And then I find one interesting article: SSH Security and You — /bin/false is *not* security
It tells about a similar story of locking out accounts using /bin/false or something equivalent (like /sbin/nologin) as the login shell for the users.
But it highlights a very interesting thing! SSH Channels
The problem is that we can SSH but we cannot access our login session due to the login shell being set to /bin/false!
So what if we try to perform port forwarding? Can that happen! Since it doesn’t uses the shell session so that should work right! And off I went to try that, and guess what, it worked!
I was like yaaay! The team mate considers himself a security geek but turns out that he forgot to secure SSH server in the first place against such attacks!
The fix would have been to use the AllowGroups option and restrict the ssh-authenticatable users by adding them to a single group that is allowed to use SSH. This would prevent any unauthorized user from SSHing. So to lock me or anyone else for that matter, a smart person could have tried to get me out of that group (simple enough right!)
So the conclusion is: If you don’t want me to have access to your machines, then don’t allow me access to your machines. /bin/false is not security!!!
What is /bin/false?
The article explains what /bin/false is actually used for. You must have installed some softwares on your machine including say a database server or a webserver. These services run as an unprivileged service user. That user doesn’t has any reason to login to the machine and therefore these user’s have their shell set to /bin/false. This has the effect of rejecting shell login attempts over ssh, telnet, or other shell-requesting protocols.
BUT…
Simply using /bin/false as someone's shell does not keep them from using said account to authenticate over ssh and using non-shell tools such as port forwarding. A default configuration in sshd will often allow tunneling and other non-shell activity.
The article goes ahead and explains how we can actually leverage these issues to perform stunts like: Firewall Bypass, Anonymous Traffic, Resource Starvation
The article also mentions that: Modern systems will generally have a pam module that will help you here — possibly allowing you to reject authentication requests over ssh simply because the user’s shell is set to /bin/false, or /usr/sbin/nologin (or wherever that is on your system).
So here that blog ended and the real pwn story began…
If you know me, I am not those silent types who will accept what someone did! I need to show them who’s the BOSS right :)
Preparing the Ground before PWNing the server
So I reached out to my team mate who helped me do this figuring out of my account being locked and asked him if he could run chsh command using my credentials.
Simple enough right! I thought I would just share my credentials* with him and take his help in resetting my account once he has logged into the server and things can work well! Well not that fast…
So that mate tried a few commands without any success:
$ su securitygoat -c “chsh -s /bin/bash securitygoat”
$ su securitygoat -s /bin/bash
$ su securitygoat -c /bin/bash
sudo wasn’t an option for him as he didn’t had access to login as root.
And the su command didn’t helped either!
Why so?
Because if you check the man page for su:
So the shell option will get ignored since my user had the restrictive shell (/bin/false)!
And by default su would have logged my user in using its default shell and then ran the chsh command (the very first command). So in that case, the command that actually got executed was /bin/false which exited immediately and chsh didn’t had any interpreter (no shell like /bin/bash) to run it! Sad….
Now this got more irritating but I knew I had to get in, anyhow!!
Vengeance time! Let’s PWN the server
So I approached my team mate who had been helping me and asked him to share his credentials (low-privileged user duh!).
And then I start to see if I can do anything to recover my account… Tried to run those same commands with no luck and was starting to get disappointed now! Since the user didn’t had root access, can’t do sudo, can’t run chsh unless I am root. So that means I can’t do much now.
Unless, there’s something out there to help me out… And a bright light shines and I find a file in /tmp (just random luck I guess).
The file was shown in red color… SETUID root my brain shouted! And indeed there was a setuid binary in /tmp. Guess which binary? BASH…
I guess that’s GAME OVER NOW! Let’s teach them how to SECURE a server and how to lock someone out properly xP
So I ran bash with -p flag:
And that gave me a root prompt! Looks like the BOSS is on his way xP
My effective user id was 0 but the real user id was still set to the low privileged user. So I just ran a few Python commands to become root:
import os; os.setuid(0); os.system(“/bin/bash”)
And that’s it… So now I am root! Then I just modified shell for my user and brought things back to normal. That felt quite relaxing!
Time for revenge?!
Don’t worry, I didn’t locked anyone out haha. Learnt some tricks on how to “effectively” lock someone out, if need be and some ways not to mess up xP
It’s quite easy to follow an answer from StackOverflow or google without going into the full depth.
Like what my team mate did — he locked me out by changing my shell to /bin/false. Must have read on SO or google — surface level knowledge ;)
What he forgot was — to do your homework well when you need to plan against someone :)
Well anyways, enough of that drama and I guess the post is getting too long now!
Will leave it here.
Btw if you are enjoying my work and would like to support me, then please check out my Patreon page: https://www.patreon.com/SecurityGOAT
See ya!
Until next time, keep learning and happy hacking!
