Chris Truncer is a Penetration Tester at Veris Group where he performs a variety of assessments for Federal and commercial customers. Currently Chris is supporting DHS and their development of a operational Penetration Testing team to support civilian government agencies. He currently helps to develop the overall program while also leading pen testing teams for other customers. His specialties include wireless network assessments and network level penetration testing. Recently, Chris became interested AV evasion methods, which led to the development of Veil.
May 2013 Archives
Gunnar Peterson does security consulting, training and research on Identity and Access Management, Cloud, Mobile and software security. He is a Microsoft MVP for Application security, an IANS Research Faculty member, and a Securosis Contributing Analyst. He maintains a popular information security blog at http://1raindrop.typepad.com.
A few weeks ago (Episode 329 http://pauldotcom.com/wiki/index.php/Episode329#Tech_Segment:_Free_Amazon_Socks_Proxy_by_Allison) Allison gave a great segment on avoiding firewalls using port forwarding and SOCKS proxy via ssh with a server on port 443 using free Amazon AWS instance. Something struck me:
1) you could have a proxy block SSH traffic going over 443.
2) you could haven IDS detect and, if inline, block since any IDS will detect SSH over non-standard ports.
So how do we fix this problem? Encapsulate SSH traffic inside SSL of course. In comes stunnel! Stunnel creates a SSL tunnel to pass almost any traffic through it. All you need is the same AWS instance that Allison talked about with stunnel installed and a client on the other end also with stunnel.
yum or apt-get install stunnel - Both server and client (there is a macport of stunnel as well as Android and Windows installers at stunnel.org)
Server side configuration, create file stunnel.config with the contents below:
accept = <serverip>:443
connect = 127.0.0.1:22
Create Self Signed certificate.
Create a key
$ openssl genrsa 1024 > stunnel.key
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)
Generate the self signed certificate.
$ openssl req -new -key stunnel.key -x509 -days 1000 -out stunnel.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 (e.g. server FQDN or YOUR name) :
Email Address :
Next up create the PEM file which just contains the key and the crt contents
$ cat stunne.crt stunnel.key > stunnel.pem
Now you can start the tunnel -- in Debian there is a perl wrapper for stunnel4 that is /usr/local/bin/stunnel -- when I envoked stunnel this way the tunnel would not start. When I bypassed the wrapper and called stunnel4 directly it worked fine.
$ stunnel4 stunnel.config
verify with netstat that the port is running (netstat -tanp) or you can test it with an openssl command: $ openssl s_client -connect <ip>:443
Now over on the client side copy over the .pem certificate from the server and place it somewhere. Then create your client configuration file stunnelclient.config
*If you need to go through a proxy you can uncomment the "protocol" lines and fill out the information accordingly. Where protocolHost is the server you want to connect to, and connect becomes the ip and port of the proxy device. If there is no proxy present the connect line is the ip and port of the remote host to connect to.
Now fire up stunnel on the client machine
$ stunnel4 stunnelclient.config
netstat -tapn to verify it is running on the assigned local port, in this example it is 2200
Now you can simply use ssh to the localhost
$ ssh -p 2200 localhost
and you are on the remote server, all hidden in nice SSL packets. I was able to run through a web proxy on port 443 with this config and did not trip signatures on the IDS that was otherwise tripping without stunnel in the middle.
You should be able to follow Allison's documentation for getting port forwarding working properly for full enjoyment.
Go forth and evade.
Join us for PaulDotCom Security Weekly Episode 333, With guest Gunnar Peterson. Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and insurance systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, a contributor to the SEI and DHS Build Security In portal on software security, a Visiting Scientist at Carnegie Mellon Software Engineering Institute, and an in-demand speaker at security conferences. He maintains a popular information security blog at 1raindrop . Also, for our tech segment we are joined by Chris Truncer . Chris is going to be explaining a new python script that he created called Veil. Veil is used to crank out metasploit payloads to bypass all anti-virus companies. Sit back and enjoy the show live or participate in the live chat on our Ustream channel:
NOTE: The video will play the most recent show up until we are live!