 Hello everyone, I'm Marc-André Abondé. I'm here to talk about the Black Bear Project which is basically a fork of open SSH. I made that fork to transform open SSH in a reverse SSH shell. So I was a system administrator for more than 10 years and since two years ago I moved that way into penetration testing and that is what I've been doing ever since. So yeah, why I did it and I'm gonna talk about why I did it and how I did it especially. So it's a fork of open SSH. It's designed to provide a fully interactive shell. Don't know if you've tried like the DEV TCP bash trick or web shells or Python reverse shells when you're using those shells and some command may not work properly like TAP or VI or even Sudo. I wanted a regular SSH shell as a reverse shell when I need to do a connect back. And also I wanted to leverage open SSH dynamic and port forwarding like the SUX proxy and the VPN functionality and the regular remote reverse port forwarding and the regular port forwarding as well which you won't have if you do like the DEV TCP bash. So a bit of history about the project. It started when the AgFest event used to have war games. The last two war games were playing countries by fighting each other and the first such war games I was kicked out of my home machine by some adversary team. I thought never again so I started to form open SSH to provide me with some sort of backdoor that I could use also defensively. So if some adversary in a war game will infiltrate my machine and change all the password and replace all the authorized key with my SSH fork SSH shell I will still be able to log in and fight back. And then the first version was based on open SSH but it lacked the reverse shell functionality. Then for DropBear the DropBear project that's why it's called BlackBear. So the code base is simple so I could understand the code and add the reverse shell functionality but DropBear do lack the SUX proxy for dynamic port forwarding so I went back to open SSH. I became a better programmer so I was able to finally understand open SSH and finish the job. So that's functionality. Talk about it. You have to know that you could use these options to let's say you want to use an additional service on the target side. You will use the capital L option to open a port on your machine that if you connect to it it will be it will go through the SSH tunnel then you will be able to reach the service on the remote machine because otherwise firewall might prevent that connection. You may also provide services to the remote machine through your connection. Let's say you have a connect back but from a network that doesn't have access to the internet and you need machines from the network to have internet access. You can use the capital R option to open a port on the target side. If the target side connected it will be forwarded to your machine and then you can tunnel to a proxy and give internet access to the otherwise enclosed restricted network. So that these functionality I wanted to have them inside my reverse shell. So of course it's a post exploitation tool so you have to have the ability to run code on the target machine so you have to have an exploit or a login or some way to run code remotely and like I said provides the tunneling ability and I use it for manual enumeration like since I have a regular SSH shell, I can run PI, I can run TUB, I can run any tools that could be on the machine. I use it to manually explore machines. Talk about that already. So the issues that I encountered in the development of the software is like I encountered what they call the privilege separation. Privilege separation is when the SSH server receives a connection it's going to fork into two processes and it's meant to provide security to prevent someone that is reaching the server from the network to reduce the attack surface. So what will happen is when you connect to the SSH server, the server will fork and then the network code will drop privilege and will change routes so it will have restricted access to the file system and then it will be further restricted with technology like SecComp on Linux or a pledge on OpenBSD that will restrict the system calls that can be made from that process, that restricted process and another process will be created that is the privilege one and that privilege process will be responsible for authenticating the user so it will receive the password or receive credential and the authentication tokens or it will challenge if the user is using a key bear will challenge the user to prove it has the required private key and both processes do communicate with each other more on that later that could be abused as well and also I did try not to use the disk on the target side so I did want to bypass any account restriction let's say you are attacking a web server the account of web server is running on often as it shall set to bin files or bin login and there are also other configuration to restrict access to those system accounts so I wanted to bypass that and I wanted to leave as little lug as possible and I wanted not to depend on the target authentication mechanisms so I don't use the target password databases I don't use authorized key on the target actually the authentication is done with a key pair but the public key is embedded inside the binary it's not on the it's on the binary that you will upload but not on the target server and finally add this issue as when I do upload the sshd binary to the target I have to upload it and then to toggle the execute execute bit on the binary like do change model on it and then to run it with proper arguments so I wanted to streamline that process so I discovered that I could also make the sshd a bash script so it it's a bash script and a ELF file at once so the bash script that is embedded in the binary will take care of the uh change mode will turn on the execute bit then uh run it with the supplied arguments so first um the privilege version that I talked about it's like uh will fork with would fork both uh two processes one that is uh talking with the network that is heavily restricted uh change route with second force and the other privilege process which is called the monitor most of the privilege process code is in the monitor dot c file and these two communicate over a defined protocol uh over a unique socket and um my surprise people but the information that is uh sent and received over that socket is in the clear so if you try to eavesdrop the network uh on the the right side uh the information is encrypted but if you attempt to eavesdrop on the unique socket that connect both the privilege and the unprivileged process then you will have access to uh clear text credentials and so how it works is um in the privilege uh the unprivileged process uh the code will call mm request send to send data over the socket and then the privilege process will receive that request with the credential will validate and will uh insert um with mm insert old password to say the account is authenticated or not after uh the password has been validated but uh we can eavesdrop on that um you can test with uh the ps and the ss tools so this screen capture has been made right after a client do connect but before the user actually entered a password so let's say you you have route access on a machine and from another machine you uh you connect to it with ssh you'll get the password prompt you don't enter anything you go back on your on your machine and uh you use ps you'll see um the two sshd child processes uh the privilege one uh you'll see priv within square brackets and the the network part of it you'll see net into the uh square brackets so you can get the pid uh 13 60 for the privilege one 30 13 61 for the uh network code and using the ss tool uh you can enumerate enumerate uh unique sockets uh yeah that are used by these processes so from the privilege size the find the descriptor of the socket is the file descriptor six and uh from the network side is it is file descriptor four so then you see the pipe that does link the two and i made quite a few experiments and uh if i monitored the privilege process to try to gather credential i noticed that the file descriptor which i can get them from is pretty much always six uh might be different but in my experience i got a lot of success with six so you can gather credential um like let's say overnight over a few days for as long as you want and uh you can do it with s trace if it's it's install on the machine uh you can also do it with other tools there is a tool uh it's called tree snake uh it's like built in rodent and uh that tool will do it will extract password and show you the password automatically but um i prefer to use s trace if it's already installed and i will uh avoid to upload the binary on the machine and the point is your root already it's like if you can do that that means that you you already compromise that machine but uh what you want to do is to collect and perhaps reuse credentials so you wait for a system administrator to log in and so yeah demo time the root already on the virtual machine it's like the the high p is 192 168 122 17 and then i look for the p id of the main s hd demon so that's the one that is actually listening on port 22 uh often you'll see uh if you grip for s hd you'll see a lot of s hd processes uh you want to target that one uh that is listening to the main service port i'm running s trace and then i'm logging in as ascending uh i use a long password password are getting longer and longer these days so i'm typing the password in and then what as i hit enter uh it's generate a log a lot of logs files um so i i grip for ssh connection to locate the file in which the credential will be logged and uh when you find that string inside the s trace the log file that will be generated by s trace uh you look for that string and the password will be a few line uh below so here it is so that's how uh one can abuse privilege uh separation of openness s h so back to the slides so then um i wanted to avoid the disk on the target side and also uh avoid uh logging and uh login restriction so i disable the no login check so it's like there's a configuration file you can deny access to some user in sshd so i disable that so if my sshd demon runs on the server even though that file is there and defined out in the yard and uh also a lot of ways make sure the the shell that you'll get uh is bnsh and i wanted to use bash i prefer bash but i'm not sure bash is present on all systems so uh i thought i was safer to use bnsh and it's uh and if the shell of the user that is compromises let's say triple the value data and whose shell is no login um like i said the the authorization is done with public keys and the key is embedded in the binary so i modified the make file so when you you build a project it will generate a key bear uh which are called id black bear and it will create a c file pubkeys.c uh we see it here and it will embed the public key in our character array uh do notice that no pointer at the end that is well tell my my my code to stop looking for keys so you can have your own keys and rebuild but uh make sure that no pointer is there and i did replace the usual uh code that is designed to read keys from authorized key file disk with that function read key file man which read keys from the array uh so that's how authorization work with black bear and also the configuration of the ssh demon uh is also embedded uh you can modify it by editing surfconf.c and then recompile so that's uh that way i don't have to rely on configuration file on the target side and i also turn on uh you know the gateway port option when you use uh capital r to expose a port on the target side and to forward it on your side and usually by default you're you are restricted to the look back interface so you cannot uh let's say your target uh as uh network interface and it will expose other network you cannot serve a port to these networks you can only serve to look back so i turn gateway port on so with black bear you can expose port on our network interfaces on the remote system and finally um like yeah the the old skis uh are generated on the fly that's a remnant of the whole design and so i didn't want to use host keys on disk so i copied code from the ssh key gen uh you know that that part is responsible for generated in key bears that the uh host keys are user keys so i copied the generate the code responsible for key generation into the sshd binary but there is one big issue is that like you'll never know uh if the the host key is good or not so that makes the software vulnerable to man the middle attack and so i recently developed the the code for compile time generation of user keys so i should use the same course the same code for host keys as well that that is a fix that is coming and i wanted to deliver more effectively the binary so as time of downloading it's like let's say you have a web shell you have to send a request download the binary send the second request to turn on the executable bit and then send the third request to run the binary with the arguments you want so i wanted to streamline that process so i found a way to include a bash script inside the elf binary uh sort of like the uh proof of concept or get the forgot publication or doing with their magazines it's like it's a polyglot file or a file can be multiple type at once so i did look at the elf header to find places where i could include my shell script and if you try to first i've tried to pipe my sshd binary into bash and then i noticed that it will fail but later it's like it will go through like the first 300 bytes and it will fail the first parenthesis it will encounter so bash can actually uh is actually permissive so it will absorb a lot of different bytes before it will bail out for a syntax error so i did i did profit from that and i also did profit from the fact that inside the elf file header several bytes that are on use so i use that small amount of space as a code cave to include a here document so i used here document to make bash when i pipe sshd i make it ignore whatever is between my here document inside the file header and the closing tag of the here document right before my script that i include as another character array so we see here i wrote a python script that will patch sshd to add the here document inside the elf file header and the lower part of the screen capture is in the river shell dot c file had the character array which include the closing part then the actual bash script that will receive arguments from the environment and it will turn on the execute bit then run the sshd binary so that's that is when the elf takes over so demo time so let's say the program is compile i run the python script to patch it and then i'll move it to uh location which uh from which i will serve it uh to the network so the target can reach it so i use a python http server to serve it then i'll invoke the client you'll notice i had the dash r flag to specify a listen address so that's that tells the client that that i will need to listen for a connection instead of trying to make a connection and also i included an example uh in the remi.md file that i will use uh against the web server so i invoke the client you have to specify the key just as you will do usually and i just made a mistake uh i need to use dash p the regular dash p will allow you to specify the port so then the client is listening for our connection i just copy and paste the command inside the dem vulnerable web application and when i submit i get a connect back then from there uh the uh the usual ssh protocol take place so it's only a reverse tcp then it's regular ssh so i'm troubled about you data uh i can't see my shares user bin all again but i i got bin ssh i can run top i can run bin and it's like just like i had a regular ssh connection that's pretty much it any questions