Many RAS Service packet filtering rules are insecure.

Description:Because it has no notion of an established connection, allowing connections often require two rules to specify the allowed source and destination ports. But allowing data back from, say, port 25 to allow outgoing mail, also allows a malicious attacker to come in from a source port of 25, even though you never initiated a connection with that host.
Author:Russ <Russ.Cooper@RC.ON.CA>
Compromise:Bypass silly NT packet filters (when will people learn not to use NT as a firewall????)
Vulnerable Systems:Windows NT running the Routing and RAS Service (Steelhead)
Date:26 June 1997

Date: Thu, 26 Jun 1997 12:24:11 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
Subject: Alert: Routing and RAS Filtering issue


I've just uncovered what appears to be a major problem with the
filtering abilities of the Routing and RAS Service (R&R - Steelhead).

I should say that this issue is currently being investigated by MS, but
given the newness of the product, the lack of wide deployment, and the
seriousness of the problem, I thought I should send this message out.

R&R has no concept of an established connection. So in order to allow
for two way communication over any protocol to any host, both Output =
Input rules must be configured. So, for example, if I wanted to permit
an Exchange Server to communicate over the Internet for SMTP only, I'd
need the following table of rules;

Filter  Source IP       Dest IP         Protocol        Source Port
Dest Port
Output         any             TCP             0
Input   any            TCP             25
Output         any             UDP             0
Input   any            UDP             25
Output         any             TCP             0
Input   any            TCP             53

The first rule allows outbound connections to Internet SMTP servers
The second rule allows data back from my outbound sessions
The third rule allows inbound connections from the Internet
The fourth rule allows data back to my inbound sessions
The fifth and sixth rules are for DNS

The problem is in the reciprocal rules. The second rule above allows a
connection to any port on my system as long as it originates from port
25 on any system on the Internet. How difficult would it be to write a
program to use a source port of 25 and a destination port of, say, 19,
and send a request to the chargen server to start spitting stuff out? =
have it access TCP139 repeatedly doing login requests. Nothing would
ever come back to me (since there isn't a reciprocal rule to allow
outbound traffic back from the port I'm targeting), but I could easily
do a Denial of Service on the machine on ports they never expected to
see traffic on.

In the case of a machine without the RPC patch, but using R&R filtering
to prevent connections to TCP135, I could drive the machine to 100% CPU

My point is not what can be done, but that it is possible to connect to
ports that have been thought to be filtered.

Here is a table representing the documentation provided in R&R =
setting up PPTP Filtering. This is intended to duplicate what NT does
when you set the PPTP Filtering option without having R&R installed;

Filter  Source IP       Dest IP         Protocol        Source Port
Dest Port
Output  any             any             TCP             1723
Input   any             any             TCP             any
Output  any             any             TCP             any
Input   any             any             TCP             1723
Output  any             any             47              any
Input   any             any             47              any

As you can see, their own documentation is telling you to open up all
destination ports on your machine to an inbound connection from =
with the only limit that the inbound connection must originate from =
1723. Since there is no packet analysis taking place, that connection
can carry any traffic you want to feed it.

Once again, let me stress, I understand that such a connection would =
be able to retrieve data from the NT server, so it couldn't be used to
interact with the box, but it could be used to access ports other than
the intended port and send that port data, thereby possibly killing the
process, setting it into some abnormal termination, or simply flooding
it with traffic.

Without the concept of "established" connections, the filtering
abilities of R&R are useless. They are misleading at best (since =
in the documentation is this fact explained or even mentioned) and will
ultimately lead people to believe they have a stronger form of security
than they really do.

I had hoped that R&R represented a significant addition to my arsenal =
tools/methods used to protect an NT box, but it clearly does not. I
would say that the product falls way short of being what MS intended it
to be also. An NT server with R&R installed would need to be placed
between a pair of *real* routers with *real* packet filtering for it to
be viable as any kind of security solution that involved packet
filtering. It would have been far better to not provide any packet
filtering thereby removing the possibility that someone might think
their packet filtering gives them any form of security or =

R.C. Consulting, Inc. - NT/Internet Security
owner of the NTBugTraq mailing list:

More Exploits!

The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's Linux Solaris/SunOS Micro$oft
*BSD Macintosh AIX IRIX
ULTRIX/Digital UNIX HP/UX SCO Remote exploits

This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: