exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

S-95-04.asc

S-95-04.asc
Posted Jan 10, 2000

Subject IP spoofing attacks and hijacked Date 23-Jan-95

tags | spoof
SHA-256 | 2d6651420db78e3ce1ef8e7a5956d797889828299aca4edd1db3b4e550eb791c

S-95-04.asc

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>> CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl. Links <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>> <<
>> CERT-NL also has stopped the CERT-CC-Mirror service. Due to this the <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the <<
>> complete CERT-CC advisory texts: http://www.cert.org <<
===============================================================================
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : Don Stikvoort & Gert Meijerink Index : S-95-04
Distribution : World Page : 1
Classification: External Version: Final
Subject : IP spoofing attacks and hijacked Date : 23-Jan-95
terminal connections
===============================================================================

By courtesy of CERT/CC we received the following information about IP
spoofing attacks (a.k.a. sequence number attacks) and hijacked terminal
connections. It is a slightly modified version of CERT Advisory CA-95:01
of January 23, 1995.

We STRONGLY advise you to pay thorough attention since the IP spoofing
possibility is exploited by hackers currently and many, many sites are
expected to be vulnerable to this kind of attack, sites who have installed
safeguards like TCPwrapper and/or firewalls NOT A PRIORI being excluded!

Since there's been press coverage of this already today (New York Times
and Reuter) considerable interest in this topic could be expected.

How to get other CERT-NL advisories and how to contact us, you will find
at the very bottom of this document.

===============================================================================

The CERT Coordination Center has received reports of attacks in which
intruders create packets with spoofed source IP addresses. These attacks
exploit applications that use authentication based on IP addresses. This
exploitation leads to user and possibly root access on the targeted system.
Note that this attack does not involve source routing. Recommended solutions
are described in Section III below.

{Example:
System manager uses rlogin from system A to gain root access to system B,
both on the same LAN. Hacker obtains IP number of system A from the
outside over the site's Internet access, and after that starts a session
with system B simulating the IP source address of system A and thus
gaining root access to system B.
NOTE-1: this is only ONE example, more protocols than the r's are vulnerable.
NOTE-2: firewalls only provide protection against this kind of event if
they are configured against it - see below.
- -cert-nl}

In the current attack pattern, intruders may dynamically modify the kernel of
a Sun 4.1.X system once root access is attained. In this attack, which is
separate from the IP spoofing attack, intruders use a tool to take control of
any open terminal or login session from users on the system. Note that
although the tool is currently being used primarily on SunOS 4.1.x systems,
the system features that make this attack possible are not unique to SunOS.

Future additional information relating to this advisory will be made
available by means of the cert-nl-ssc mailing list.

- -----------------------------------------------------------------------------

I. Description

This description summarizes both the IP spoofing technique that can
lead to root access on a system and the tool that intruders are using to
take over open terminal and login connections after they get root access.
We are currently seeing attacks in which intruders combine IP spoofing
with use of the tool. However, these are two separate actions. Intruders
can use IP spoofing to gain root access for any purpose; similarly, they
can highjack terminal connections regardless of their method of gaining
root access.

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. Note that firewall protected networks
are potentially vulnerable as well: 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 one or more 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

The IP spoofing attacks we are currently seeing are similar to those
described in two papers: 1) "Security Problems in the TCP/IP Protocol
Suite" by Steve Bellovin, published in _Computer Communication Review_
vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD
Unix TCP/IP Software" by Robert T. Morris. Both papers are available
from

ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/papers

Bellovin paper: ipext.ps
Morris paper: 117.ps

Services that are vulnerable to the IP spoofing attack include
SunRPC & NFS
BSD UNIX "r" commands
Services secured by TCP wrappers using source address access control
X windows
other applications that use source IP addresses for authentication

Hijacking tool
Once the intruders have root access on a system, they can use a tool
to dynamically modify the UNIX kernel. This modification allows them
to hijack existing terminal and login connections from any user on the
system.

In taking over the existing connections, intruders can bypass one-time
passwords and other strong authentication schemes by tapping the
connection after the authentication is complete. For example, a
legitimate user connects to a remote site through a login or terminal
session; the intruder hijacks the connection after the user has
completed the authentication to the remote location; the remote site
is now compromised. (See Section I for examples of vulnerable
configurations.)

Currently, the tool is used primarily on SunOS 4.1.x systems. However,
the system features that make this attack possible are not unique to
SunOS.


II. Impact

Current intruder activity in spoofing source IP addresses can lead to
unauthorized remote root access to systems, including those behind a
filtering-router firewall.

After gaining root access and taking over existing terminal and login
connections, intruders can gain access to remote hosts.


III. Solutions

A. Detection

IP spoofing
If you monitor packets using network-monitoring software such as
netlog, look for a packet on your external interface that has
both its source and destination IP addresses in your local domain.
If you find one, you are currently under attack. Netlog is
available by anonymous FTP from
net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz
MD5 checksum: 1dd62e7e96192456e8c75047c38e994b

Another way to detect IP spoofing is to compare the process
accounting logs between systems on your internal network. If
the IP spoofing attack has succeeded on one of your systems,
you may get a log entry on the victim machine showing a remote
access; on the apparent source machine, there will be no
corresponding entry for initiating that remote access.

Hijacking tool
When the intruder attaches to an existing terminal or login
connection, users may detect unusual activity, such as commands
appearing on their terminal that they did not type or a blank window
that will no longer respond to their commands. Encourage your users
to inform you of any such activity. In addition, pay particular
attention to connections that have been idle for a long time.

Once the attack is completed, it is difficult to detect. However,
the intruders may leave remnants of their tools. For example, you
may find a kernel streams module designed to tap into existing TCP
connections.

B. Prevention

IP spoofing
The best method of preventing the IP spoofing problem is to install
a filtering router that restricts the input to your external
interface (known as an input filter) by not allowing a packet
through if it has a source address from your internal network. In
addition, you should filter outgoing packets that have a source
address different from your internal network in order to prevent
a source IP spoofing attack originating from your site.

The following vendors have reported support for this feature:
Bay Networks/Wellfleet routers, version 5 and later
Cabletron - LAN Secure
Cisco - RIS software all releases of version 9.21 and later
Livingston - all versions

If you need more information about your router or about firewalls,
please contact your vendor directly.

If your vendor's router does not support filtering on the inbound
side of the interface or if there will be a delay in incorporating
the feature into your system, you may filter the spoofed IP packets
by using a second router between your external interface and your
outside connection. Configure this router to block, on the outgoing
interface connected to your original router, all packets that have a
source address in your internal network. For this purpose, you can
use a filtering router or a UNIX system with two interfaces that
supports packet filtering.

NOTE: Disabling source routing at the router does not protect you
from this attack, but it is still good security practice to
do so.

Hijacking tool
There is no specific way to prevent use of the tool other than
preventing intruders from gaining root access in the first place.
If you have experienced a root compromise, see Section C for general
instructions on how to recover.

C. Recovery from a UNIX root compromise

1. Disconnect from the network or operate the system in
single-user mode during the recovery. This will keep users
and intruders from accessing the system.

2. Verify system binaries and configuration files against the
vendor's media (do not rely on timestamp information to
provide an indication of modification). Do not trust any
verification tool such as cmp(1) located on the compromised
system as it, too, may have been modified by the intruder.
In addition, do not trust the results of the standard UNIX
sum(1) program as we have seen intruders modify system
files in such a way that the checksums remain the same.
Replace any modified files from the vendor's media, not
from backups.
-- or --

Reload your system from the vendor's media.

3. Search the system for new or modified setuid root files.

find / -user root -perm -4000 -print

If you are using NFS or AFS file systems, use ncheck to
search the local file systems.

ncheck -s /dev/sd0a

4. Change the password on all accounts.

5. Don't trust your backups for reloading any file used by
root. You do not want to re-introduce files altered by an
intruder.

- ---------------------------------------------------------------------------
The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic,
Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our
understanding of these problems and their solutions.
- ---------------------------------------------------------------------------

If you believe that your system has been compromised, please take the
appropriate steps to secure your network and inform CERT-NL.
==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands

NOODGEVALLEN: 06 22 92 35 64 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IDTSYjBqwfc9jEQKQVACg6DjbP5C2NCzRJEMtYrP8XeCjN6oAoP7U
pAkXoQScKBozYTmID7yz2iJQ
=eufc
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close