Penetration Testing mailing list archives

RE: Netcat through Squid HTTP Proxy


From: "Todd Towles" <toddtowles () brookshires com>
Date: Tue, 19 Apr 2005 10:18:17 -0500

Well you have to understand how they do it to prevent it. Proxy will
never be totally secure, it has to be a multiple level protection idea.
If you allow tunneling on 80 and 443, then Stunnel and other things will
still work. But it is better than it was before, and to pass the proxy
would recommend know-how and some pre-work. 

Packet Inspection could be used to filter known bad traffic, but that
type of protection isn't cheap.  443 tunnel hide all the traffic from
the proxy and most IDS/IPS system so client security becomes important.
AV on the client or possible Host IPS, if money isn't a big deal.

-----Original Message-----
From: Henderson, Dennis K. [mailto:Dennis.Henderson () umb com] 
Sent: Monday, April 18, 2005 11:28 AM
To: Todd Towles; Joachim Schipper; pen-test () securityfocus com
Subject: RE: Netcat through Squid HTTP Proxy

It seems like he was looking for information on how to prevent this.

You can configure squid to only allow tunneling on certain ports like
443 and 80. You'll have to figure out what your safe ports 
are to prevent legitimate traffic from being impacted. 

I usually make sure the usual ports like ssh, telnet, irc are 
not allowed.

Cheers

Dennis 

-----Original Message-----
From: Todd Towles [mailto:toddtowles () brookshires com]
Sent: Monday, April 18, 2005 8:20 AM
To: Joachim Schipper; pen-test () securityfocus com
Subject: RE: Netcat through Squid HTTP Proxy

There is a POC shell program that uses XML-RPC called Monkey shell 
(http://www.securiteam.com/tools/6L00F0KBFE.html). It looks like it 
might require a re-code to be fully used as a pen-test tool. But it 
something to look at. -

You can try HTTPTunnel as well.

httptunnel creates a bidirectional virtual data connection 
tunnelled 
in HTTP requests. The HTTP requests can be sent via an HTTP 
proxy if 
so desired.

This can be useful for users behind restrictive firewalls. If WWW 
access is allowed through a HTTP proxy, it's possible to use 
httptunnel and, say, telnet or PPP to connect to a computer outside 
the firewall.

http://www.nocrew.org/software/httptunnel.html

-Todd

-----Original Message-----
From: Joachim Schipper [mailto:j.schipper () math uu nl]
Sent: Sunday, April 17, 2005 10:13 AM
To: pen-test () securityfocus com
Subject: Re: Netcat through Squid HTTP Proxy

On Fri, Apr 15, 2005 at 10:40:31AM -0400, Rod S wrote:
Hello,

I have a squid proxy server running, caching and filtering
web access.
User workstations on my network are only allowed http
access through
this proxy server. The firewall (Cisco PIX) will not let
them connect
outbound to any ports.

I've done some testing and was successful in running netcat
to connect
to a remote server listening with netcat on port 80 and get
a command
prompt for an internal machine (which is allowed to
connect to any
outgoing ports) on that remote server. I'm wondering if
it's possible
for netcat to connect through our proxy server to a remote
machine and
send a cmd.exe shell in the same way? Any tips on
preventing this or
any other information you care to share is appreciated.

Thanks!
Rod

Dear Rod,

if I understand correctly, you can get a shell on a remote
machine and
want to allow a remote machine to get a shell on a local 
host. This 
can be achieved quite easily - search for 'reverse shell'.
One example
which looks nice is rrs (*nix
only) - see freshmeat.net. This one cannot do HTTP
proxying, though,
so it should be augmented or wrapped in something that can.

The Hacker's Choice (www.thc.org) has just run an article 
on this, 
including an example in Perl. If you desire something more 
Windows-specific, you may want to ask Google, or any 
shades-of-grey-hat site you can find. ;-)

However, simply, yes, this is possible. Quite a few of
these kinds of
reverse shells rely on HTTP CONNECT, so limiting that may
help - but
there are some seriously scary things out there, 
including reverse 
shells that communicate over DNS or ICMP (pings etc).

A good I(P|D)S may help a little. Locking down the network
further may
help. However, it is almost impossible to keep a smart
attacker in -
make sure to keep him out.

          Joachim





Current thread: