emptymonkey / revsh

A reverse shell with terminal support, data tunneling, and advanced pivoting capabilities.
MIT License
458 stars 90 forks source link

Statically compile for dropping onto remote servers? #11

Open dwendt opened 7 years ago

dwendt commented 7 years ago

Hey, so the intended use is to drop /usr/local/bin/revsh onto a host after install, right?

Maybe there should be an extra build step to generate a full static build into a folder. I went into the makefile and set the static build cflags and everything worked fine, but it'd probably be beneficial to usability.

Thanks for the tool though, it's much more convenient than socat.

emptymonkey commented 7 years ago

There are many difficult questions about static vs non-static due to the underlying crypto libraries that may or may not exist on the target host and conflicting versions. Also with the new OpenSSL 1.1 tree, revsh doesn't build at all. I'll keep this approach in mind as I go rewrite the crypto interface to handle other SSL/TLS libs (as a static OpenSSL 1.1 helloworld will segfault during initialization so, time to look into other libs.)

I haven't forgotten about this ticket though, I'm just short of time. I'll keep this ticket open until this all get rolled in, or decided against in the (hopefully near) future.

Cheers!

sempervictus commented 7 years ago

@emptymonkey: Far as static and cross compile setups, you may want to take a look at how Metasploit builds mettle via musl and deps built on it, and embedded w the payload. Would be rather nice to have the VPN pivots in mettle, in case you want to push some code :-).

ghost commented 6 years ago

Musl is the way to go for building a fully static revsh binary linked statically with a "statically" built OpenSSL 1.1.x library

Here are some examples:

https://github.com/ernw/static-toolbox/blob/07fb90a57717e7008afc8f5582f49ee2abda56ee/recipes/nmap/linux_x86_64/build_x86_64.sh

https://github.com/ernw/static-toolbox/blob/07fb90a57717e7008afc8f5582f49ee2abda56ee/recipes/socat/build.sh

Also something like: https://github.com/richfelker/musl-cross-make or https://github.com/GregorR/musl-cross

Would really make life easier for cross compiling

mzpqnxow commented 5 years ago

musl works fine to build this, you just need to remove one include, I believe it is :

#include <linux/if.h>

And of course you will need to cross-compile libssl.a and libcrypto.a as well using your toolchain

And yes, musl-cross-make is the easiest way to do this by far. See https://github.com/mzpqnxow/cross-compile-openssl for how to build openssl using a musl toolchain if you get stuck

ghost commented 5 years ago

No problem with <linux/if.h> include for me maybe that's for arm or mips ? I'm only compiling for x86_64-linux

The only hiccup I found is posix_openpt() defined in revsh.c It's needed to be defined for really ancient systems with glibc < 2.2.1 (CentOS "2.0" has glibc 2.2.4 !) and in Musl libc it's already defined and you even get multiple definition error while linking So I just ignore it with a simple flag -DMUSL when linking with musl libc

revsh.c

#if !defined(MUSL)
    int posix_openpt(int flags){
        return open("/dev/ptmx", flags);
    }
#endif

common.h

#if !defined(MUSL) && !defined(FREEBSD)
    int posix_openpt(int flags);
#endif
superuser5 commented 4 years ago

Hello, is it possible to share how to compile revsh properly with/without musl for x86_64-linux and arm (to run on raspberry pi)? I tried compiling many times and everything seems to fail. Many thanks in advance.

mzpqnxow commented 4 years ago

@ghost could just be due to changes in musl as it’s VERY actively developed. I believe my targets were both MIPS/MIPSEL and ARM. Great to hear it’s working without an ifdef/ifndef.

@superuser5 I can try to post something if I get time (actually, please look through my gists and you may find something- I seem to remember posting a guide to building openssl with a musl toolchain at some point

Or, if you just want to get started, clone https://github.com/richfelker/musl-cross-make

Use the example config.mak.dist, copy it to config.mak, modify it to your desired architecture, to save build time only enable C as a supported language, and use make -j && make install

That will get you a good cross-compile toolchain and sysroot. From there, you’ll need to build openssl using that toolchain.

The openssl build system is slightly unusual compared to most but you should be able to find documentation on cross-compiling. If not in my gists, google for “build openssl with musl” or something along those lines.

From there you just need to tell the revsh build where the installed cross-compiled openssl headers/libs are using -Iand by specifying the path to libssl.a and libcrypto.a on the command-line as opposed to using the library path flag

It’s not as complicated as it sounds but if you’re not experienced with cross-compiling (or the details of basic, native compilation) you’ll need at least an afternoon or two to get it right.

mzpqnxow commented 4 years ago

There are many difficult questions about static vs non-static due to the underlying crypto libraries that may or may not exist on the target host and conflicting versions. Also with the new OpenSSL 1.1 tree, revsh doesn't build at all. I'll keep this approach in mind as I go rewrite the crypto interface to handle other SSL/TLS libs (as a static OpenSSL 1.1 helloworld will segfault during initialization so, time to look into other libs.)

I haven't forgotten about this ticket though, I'm just short of time. I'll keep this ticket open until this all get rolled in, or decided against in the (hopefully near) future.

Cheers!

@emptymonkey I proposed switching to mbedtls a while back and I think we both agreed but neither had/has had the time to do it.

I’m not sure who is officially helping out with development on revsh now, but maybe someone would be interested in starting an mbedtls branch in earnest, which would probably end up easier since the API is stable across versions and it’s just simpler and more lightweight in general- and meant more to be used as something buikt in-tree, I think. It would also be great to drop all the unnecessary support for TLS < 1.2 as well as all of the unneeded cipher-suites. And all the other cruft openssl brings with it.

mzpqnxow commented 4 years ago

@superuser5 I found an old gist I put up @ https://gist.github.com/mzpqnxow/0974f4be1146256637aed20cfcb30da3

Not sure if this is helpful for you, but maybe you can use this to send in a PR?

superuser5 commented 4 years ago

@mzpqnxow thank you so much, i will test everything and will post update what works.