From: Jon Hart (warchild@spoofed.org)
Date: Thu Mar 25 2004 - 16:46:14 EST
On Wed, Mar 24, 2004 at 10:57:49PM -0400, BillyBobKnob wrote:
> My friend asked me to see if I could scan or penetrate his firewall. He =
> only told me that it was a Linux box setup as a firewall running NAT to =
> hide internal IPs.
>
> - I did a nmap -O and a nmap -O --fuzzy but it said "too many =
> fingerprints match for accurate OS guess"
> but it did tell me that TCP port 113 was in the closed state
> - so I tried a TCP reverse inet scan (nmap -sT -I) and it still gave me =
> same info as this port was closed
> - so I tried nmap -sU and no results
> - then I tried nmap -sU -p 113 and it said that UDP port 113 was open !!
>
> I was then able to netcat to it (nc -u ipaddress 113) and I verified =
> that I was connected with a netstat.
>
> While connected via netcat I tried sending it commands like (ls, cd .., =
> help, echo) but got nothing.
>
> Is there anything that can be done with this connection ??
> Or is there anyway to find out what internal IPs are behind it ?
If I had to guess, all traffic to port 113 TCP is disallowed, but the
firewall sends back a TCP RST to indicate that it is closed. This makes
applications that try to use ident time out quicker. If traffic to 113
TCP was just dropped, the connections to ident would take much longer to
timeout, thereby resulting in an unnecessary delay. This is why I
"drop" all unwanted traffic by default, but for unwanted connections
that I want to go away even quicker, I "return" them. For TCP
connections, a TCP RST is sent, and for UDP, an icmp port unreachable is
sent. On this list I include ident and most windows networking ports.
Keep in mind how UDP works, and how scanners determine whether or not a
UDP port is "open". If a scanner receives no response, it assumes the
port is open. If an ICMP message (generally $port unreachable) is
received, it is assumed closed. In most situations this is a valid
assumption.
So, when you nc to that UDP port, if the firewall is dropping your
packets on the floor, it'll look like the port is "open" when it really
isnt.
If ident really was listening on port 113 UDP, you could issue standard
ident commands as specified in RFC 1413. However, I've never heard of
ident listening on UDP, so thats probably not the case here. If you are
feeling adventurous, brute force all the possible combinations, which
may give you some useful information:
#!/usr/bin/perl
#
foreach $server_port (1..65535) {
foreach $client_port (1..65535) {
system("echo '$server_port,$client_port' | nc $ARGV[0] 113");
}
}
Hope that helps,
-jon
---------------------------------------------------------------------------
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
www.coresecurity.com/promos/sf_ept1
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:51 EDT