Error: Twitter did not respond. Please wait a few minutes and refresh this page.
Incoherent ramblings of an InfoSec professional
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.
A few weeks ago I started looking at Windows Software Restriction Policy (SRP) and using it to stop client side attacks. This is going to go over some of the options, setup and the results once enabled.
SRP is easy to setup via Group Policy Object (GPO). Inside GPO editor create New Software Restriction Policy. Once create the default will be setup. You can look around to see basic options. Here is my tested setup.
Enforcement: Select “All Software files” and “All users except local administrators”
Under Designated File types: Remove type LNK – this will make sure that shortcuts placed outside of the designated execution directories will run. When I initially tested what I thought would work none of the shortcuts on the toolbar or desktop would launch an application and I found this to be the issue.
Ignore trusted publishers, this is used if we are limiting applications based on the certificate authority.
Select “Additional Rules”
The default execution directories will be selected.
Since mine is 64bit Windows I added
Security level for these are all going to be “Unrestricted” I want them to be able to execute as normal.
Now back under “Security Levels” the default setting is Unrestricted, since we are changing users over to defined execution directories I want to set anything not specifically allowed in the Additional Rules section to “Disallowed.” So we change the default to Disallowed.
Save this and run gpupdate /force on the target machine.
Now to test a client side attack using SET. I am going to use the java attack method. 1 -> Social-Engineering Attacks, 2 -> Website Attack Vectors, 1 -> Java Applet Attack Method, 1 -> Web Templates, 1 -> Java Required, 2 -> Windows Reverse_TCP Meterpreter, 16 -> Backdoored Executable – Enter port of listener (default 443)
Fire it up and wait till it starts the payload handler.
Once the handler is started you are ready to test the attack. Go ahead and run the unsafe java applet.
You will notice that the the site is responding but the java applet is unable to execute the payload.
After attempting this and being successful, I tried running SET with PowerShell Injection and to my surprise the attack succeeded. I realized with PowerShell the payload was running from the C:\Windows\sysWOW64\WindowsPowerShell directory which by default is explicitly allowed. To defeat this attack I added the path to the list of Additional Rules and set it to “Basic User”, retested the attack with PS Injection and the attack failed as expected. I tested this with multiple payloads and encoding methods and everyone of them did not result in a successful attack. On 32bit systems PowerShell is located in C:\Windows\System32\WindowsPowerShell\v1.0\ so that directory will need to be accounted for as well.
I ran two other tests, the first was using EXE embedded PDF and an older version of Adobe Reader (9.3). SRP was able to successfully stop this attack.
Finally I tested a physical attack using a USB Rubber Ducky Human Interface Device (HID) from the folks over at hak5 (www.hak5.com). I used a great little payload generator found over on google code (https://code.google.com/p/simple-ducky-payload-generator/ ) It is pretty slick and simple, I used a meterpreter powershell injection payload that didn’t attempt to elevate privileges. SRP was able to successfully stop this attack. If the user had admin privileges and entered in creds in the UAC window it would have worked since I allow Local Admins unrestricted access.
In Production the are likely other directories where code needs to execute, those will need to be added to the allow list. As the config is done, administrators will be able to bypass these rules for installation of software etc. Administrators will also need to ensure that ACLs are properly set since a curious user could move executables into the approved directories and run them. While this is like a bit tough to implement in a very large organization this is a very effective method for stopping client side attacks.
To find other executable directories in use in your environment enable SRP with defaults (fully unrestricted) and set the following registry key:
String Value: LogFileName, <path to log file>
This will log the executable and the directory it was run from a little data mining can determine were applications need to execute from. Also Inventory Collector from Application Compatibility toolkit can assist in this task.
This is a bit of a quick rant. I heard about this last week but didn’t get around to commenting. Apparently last week at RSAC CrowdStrike decided to throw ethics aside for showmanship by bringing down the Kelihos botnet on stage in front of a crowd.
Why? How long were they siting on this just so they could do in front of a bunch of people and press?
While I applaud the work they did do, I wonder about the people who got their creds stolen and bank accounts raided between when they knew how to take it down and when they actually did on stage. This seems completely irresponsible and shaming to see what some folks in the InfoSec industry are headed to.
Read more about the take down at Threatpost.
A couple months back I had the pleasure to attend the 2nd ever DerbyCon event down in Louisville, KY. This was the best conference of the year. DEFCON is great but you get all the feel of DEFCON with 1/10th the people and none of the clicks. This was truly one big group to have fun and learn about security. It was also nice to have multiple defensive talks. While I understand that DEFCON and BlackHat are offensive conferences it was nice to have a mix of both especially when there wasn’t a bunch of vendor sponsored talks. In fact I sat in on a couple talks that were specific to FOSS tools.
Check out the talks at http://www.irongeek.com