Network level attack - Source port 20,53

Some of the ancient firewalls and lousy implemented screening routers have a
problem with dealing with FTP reverse connections. For those that does not
know how it works - a normal (active) FTP session works like this. The FTP
client makes a connection from a random port to port 21 on the FTP daemon.
This is the control connection. As soon as you type "ls" or "get" or "put" a
secondary connection (the data connection) is needed. This connection is
made from the FTP server with a source port of 20 to a port on the client.
The client using the FTP native PORT command specifies the destination port
of the reverse connection. As such the client's firewall needs to allow
connection from source port 20 to (high) destination ports in order for the
reverse data connection to be made. With state ful inspection firewalls the
firewall will monitor (sniff) the initial outgoing (control connection)
packets. When it sees the PORT command, it will automatically open the
packet filters to allow the reverse connection to the client on the port
that it specified (this is the source of much mischief - spoofing such PORT
commands could be used to fool the firewall to open up a port on an IP
number that it is not suppose to). Firewalls that do not make use of
stateful inspection have a problem with these reverse connections. If we can
change our source port to 20 we could bypass the filters and connect to an
IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused
As can be seen from this example - when we connect to a port <= 1024 we hit
the packet filter. Trying ports > 1024 we are bypassing the filter (although
there is nothing running on port 1025. What is the use then - nothing runs
on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco
configurations on 2001,3001, Squid on 3128, and a lot of proxies on
1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting
behind a crappy firewall that allows connection with source port 20. How do
we put it all together? Netcatagain:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh
Hit your own machine with Microsoft SQL Enterprise Manager.
This is just about straight from the net cat documentation - so be sure to
read it as well. go.shis execute when the SQL manager hit port 1433; it
makes a connection to the victim using source port 20.
For applications that use multiple connections (such as HTTP) you will need
to have ncin a loop - so that it fires off a new instance of go.shfor
every new connection. As this is explained in the net cat docs I will not
repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone
transfers). Also keep in mind that we are only taking about TCP here - think
about DNS...source port 53 to high ports using UDP, and NFS running on port
2049...get creative!