Continued IP Spoofing Attacks (INFO#95.16723)
- Date: Fri, 21 Jul 1995 15:34:58 EDT
-----BEGIN PGP SIGNED MESSAGE-----
==============================================================================
CONTINUED IP SPOOFING ATTACKS
CERT Coordination Center
July 21, 1995
==============================================================================
**** This note is the same ``heads-up'' that was originally sent on June 29,
**** 1995. It is being resent because some recipients were unable to read
**** it. Because of the importance of the subject matter, we are resending
**** with a PGP signature but without a MIME header.
Over the past few weeks, we have received reports of 170 IP spoofing attacks
against Internet sites internationally. We are sending you this "heads-up"
because you, a network service provider, are a likely target. At least 80 of
the targets we know of are name servers, routers, and other network operation
systems. The attacks have been largely successful, we continue to receive
reports, and we are concerned that more attacks are going undetected.
We urge you to check your systems and routers for any signs of compromise and
to use the information in CERT advisory CA-95:01, "IP Spoofing Attacks and
Hijacked Terminal Connections," to help protect yourself, detect IP spoofing
attacks, and recover from root compromises. The advisory is available by
anonymous FTP from
ftp://info.cert.org/pub/cert_advisories
This "heads-up" contains additional information about what you can do, as well
as issues to consider before taking action. Please feel free to forward this
to other providers of Internet services.
What is IP Spoofing?
- --------------------
To gain access, intruders create packets with spoofed source IP addresses.
This exploits applications that use authentication based on IP addresses
and leads to unauthorized user and possibly root access on the targeted
system. Examples are the rsh and rlogin services.
It is possible to route packets through filtering-router firewalls if they
are not configured to filter incoming packets whose source address is in the
local domain. It is important to note that the described attack is possible
even if no reply packets can reach the attacker.
Examples of configurations that are potentially vulnerable include:
- - routers to external networks that support multiple internal interfaces
- - routers with two interfaces that support subnetting on the internal network
- - proxy firewalls where the proxy applications use the source IP address for
authentication
Communicating with us
- ----------------------
Warning: For sensitive information, use encrypted email. You will find the
CERT public PGP key at the end of this document.
We would appreciate it if you would let us know whether you are watching for
IP spoofed packets on your networks (or plan to do so).
If you see spoofed packets, we'd like to learn how many you see and from how
many different sites; this will help us determine the scope and pattern of the
attacks. We will keep all detailed information and the identity of
organizations confidential.
Because of our workload, we must ask you not to send log files of activity,
but we would be happy to work with you as needed on how to interpret data that
you may collect.
If you see activity that indicates an attack is in progress, we encourage you
to contact your customer, or other involved sites or their service provider.
We have some general information on IP spoofing and on recovering from a
compromise that we can make available to you for your customers' use. We
would also be happy to provide guidance and advice, if needed, on how to
handle incidents and work with law enforcement.
.............................................................................
Some things you can do
- ----------------------
It is possible to check network traffic for indications of the type of
attack we are currently seeing. Before doing so, please look at the next
section, "Issues to consider before taking action."
There are several classes of packets that you could watch for. The
most basic is any TCP packet where the network portion (Class A, B, or C
or a prefix and length as specified by CIDR, the Classless Inter-Domain
Routing specification) of the source and destination addresses are the
same but neither are from your local network.
These packets would not normally go outside the source network unless there is
a routing problem, worthy of additional investigation, or the packets actually
originated outside your network. The latter may occur with Mobile IP testing,
but an attacker spoofing the source address is a more likely cause.
For a NAP or NSP, the interface into which a packet arrived indicates the
direction of the source of the attack. The packet's destination address
indicates the "trusted" host involved in an attack. That information suggests
which hosts may be under attack.
There are public domain and vendor provided tools available for checking your
networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop.
Argus 1.5
- ---------
Argus is an IP network transaction-auditing tool developed at the Software
Engineering Institute of Carnegie Mellon University. The Argus 1.5
distribution includes scripts that perform simple network administrative
tasks, one of which is IP spoofing detection.
The data that Argus generates makes it possible to analyze network activity
and performance in ways that have not been possible before. For example, you
can answer questions such as, "Were there any IP spoofing attempts into our
firewall network over the past 8 hours?"
The developers of Argus have made the tools available from
ftp://ftp.sei.cmu.edu/pub/argus-1.5
If you have any questions, comments, or suggestions, please send mail
to argus@localhost.
Scripts
- -------
At the end of this document ("Attachment A") are scripts you may want to use
to check your network. We are aware that the Internet is now "classless,"
meaning that the old notion of class A, B, and C addresses is being replaced
with a prefix and length notation, also known as CIDR. Even so, the scripts,
which are based on classes, may be useful to some service providers. In all
the IP spoofing incidents reported to us to date, we believe that the scripts
would have shown the spoofed packets. (The problem here is that these scripts
may either show other packets labeled as spoofed or not show true spoofed
packets due to CIDR.)
A standalone machine running tcpdump or equivalent should be able to run
these scripts without affecting the performance of the local net. It may be
possible to configure routers to do this check directly but we are not
currently aware of any systems on which this is possible.
..............................................................................
Issues to consider before taking action
- ---------------------------------------
Before writing this "heads-up," we consulted colleagues on other response
teams, several network service providers, and other technical experts. They
raised the following issues, and there surely are others you should consider
before taking action.
Technical and performance issues:
- There may be too many "false positives." Two causes are mobile IP and
misconfigurations; there may be other causes as well.
- The feasibility of installing network monitors may depend on
network topology.
- It is not clear how many monitoring machines you would need to
pinpoint the problem.
- When the tcpdump and snoop scripts were tested on a dedicated Sun IPX
connected to a T1, the impact on performance was only marginal. Long-haul
tests with similar scripts do not have performance problems either.
- Anything above a T1 is going to cause some performance problems
(applications like tcpdump and snoop do not work very well at all on
DS3 or FDDI interfaces).
Legal issues:
- - Some service providers believe that checking your network as we suggest is
all right; others believe that there may be a problem. We urge you to check
with your legal advisors about analyzing packet header information,
analyzing traffic content to detect unauthorized activity, and analyzing
internal traffic and customer-bound traffic.
- - For US service providers, the Digital Telephony Bill of 1994 is relevant;
in particular, check the amended provision found at 18 U.S.C. 2511(2) (a)
(i), which permits an electronic communications service and its employees
to
...intercept, disclose, or use that communication in the normal
course of...employment while engaged in any activity which is
a necessary incident to the rendition of...service or to the
protection of the rights or property of the provider of that
service....
..............................................................................
Attachment - Scripts for Checking Networks
- --------------------------------------------
We have tested the following scripts on a recent version of tcpdump and
snoop (192.9.200.0 would be replaced by the site's local net, of
course):
--- script for tcpdump ---
#!/bin/sh
tcpdump 'tcp and not dst net 192.9.200.0 and
(
(ip[12]&0x80=0 and ip[12]=ip[16]) or
(ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or
(ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18])
)'
(Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.)
--- script for snoop ---
#!/bin/sh
snoop 'tcp and not net 192.9.200.0 and
((ip[12]&0x80=0 and ip[12]=ip[16]) or
(ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or
(ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))'
(Note that this does not appear to work with Solaris 2.3 machines.)
To more accurately analyze network traffic, it is useful to first describe
the network topology; for example:
----------------
| INTERNET |
----------------
|
---------- |
| NETWORK | ----------------
| MONITOR | | ROUTER |
---------- ----------------
| |
| |
-----------------------------------------------------------------
|MAC-A |MAC-B |MAC-C
--------- --------- ---------
|ROUTER | |ROUTER | |ROUTER |
--------- --------- ---------
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
Ca Cb Cc Cd Ce Cf Cg Ch Ci
(MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router
interfaces attached to the same network as the network monitor machine.)
In this case, the machine used to check network traffic could be any machine
capable of running tcpdump, snoop, or any other packet capture and analysis
software. This machine could be programmed so that any packets that match
the following expression are displayed.
tcp and (
not ether src MAC-A and (
src net Ca or
src net Cb or
src net Cc
)
not ether src MAC-B and (
src net Cd or
src net Ce or
src net Cf
)
not ether src MAC-C and (
src net Cg or
src net Ch or
src net Ci
)
)
This expression looks at the source address of each packet and identifies
those that did not originate from the correct interface.
This example should be extensible to take CIDR into account. For example,
if the CIDR specification of network Ca is 192.9.200/21, then the
sub-expression:
src net Ca
should be replaced with:
ip[12:4]&0xfffff800=192.9.200.0
..............................................................................
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMA/8F3VP+x0t4w7BAQGKfgQArR6jBz+HjRbPBRAjO88aNIaH/ZbBzt1K
cPDE54nLWa0+CP4F4ZWhn+UH1SMdRrLFdYZdD1sn5j56zx+nXmzo2sL3eRvylpdp
LigpavVWJoOoC8XY8AJqUCT+A4txd4QacawGZMMbedIi9IyzU/33ia7BIb4wW/k6
bidvD0ExGNQ=
=nyX9
-----END PGP SIGNATURE-----