Problem
It is common during a penetration test that a tester may run into the problem of figuring out which ports and maybe even which protocols are allowed out of an environment. This is due to the need for a payload to successfully establish command and control. With the adoption of layer 7 inspection for firewalls and the slow adoption of proper egress filtering, this problem will only get more prevalent.
Possible Solution (<– click if you don’t want to read)
Seeing as most browsers now support websockets, I set out to create a simple client/server setup that would be able to test the most common ports. The tool would consist of a python based server and simple javascript to include with any webpage that would cycle thru connection attempts via websockets on an array of ports.
Upon further investigation I found why no tool already existed to do what I was trying to accomplish. As I started to piece together some python based on the RFCs I could find, I found that someone else had already done it better than I (https://gist.github.com/rich20bb/4190781). Taking this code as a starting point I soon had a multi-threaded websocket server that listened on ports 21, 22, 23, 53, 3389 and 8080. I worked up some javascript to test it and found this:
data-animation-override>
“If port is a port to which the user agent is configured to block access, then throw a SECURITY_ERR exception. (User agents typically block access to well-known ports like SMTP.)”
— http://dev.w3.org/html5/websockets/
This basically meant that browsers blocked most interesting ports and the ones that I wanted to know about. Somewhat frustrated at this point I continued to search for a solution. I then began digging into what possibilities I might have by utilizing Flash. While finding the use of flash sockets as a possibility, I reluctantly accepted this as a dependency and continued on.
What I came up with is much less elegant than I had hoped, but what you do is setup a server to listen to ports of interest. Then you setup some javascript which will invoke websocket requests to the server on those various ports. For this you can use egress_serve.py like this:
In its current form the the egress server requires connectivity from the client on port 843 to function because of the way that Flash handles its socket security policy (see this). Once your server is setup you need to host a couple files on a web server (WebSocketMain.swf, egress_test.js, swfobject.js, web_socket.js, egress.html). Then in a separate directory you will need to have egress_serve.py and flashpolicy.xml.
Finally you will have to place the public ip that you are using for your egress server into the egress_test.js file like so:
It is also important to note that you should ensure that your firewall for the egress server allows the ports through that you wish to test, because of this I highly suggest using an AWS, Azure, or some other virtual private server for this purpose. Do not host any sensitive data on the server that is running this. Once things are all in place have your target browse to the egress.html page. On your egress server it should look like this:
This utility is valuable if you need to quickly gather possible egress ports available from a network that you are currently on, such as in an audit context. But it is also useful for a pretext to a social engineering attack where you need to ensure your payload will successfully communicate out and establish command and control. For example, many companies have online chat where you can talk to a representative. Simply engage the customer service rep in a way that will get them to load the page, and you should have good intel into what ports are allowed out.
Let SynerComm know if you have any questions. Enjoy!
