Section 5.8 Spoofing Techniques

   


5.8 Spoofing Techniques

Spoofing is when one pretends to be another. This can apply to a person, system, or packet. This discussion will be restricted to a system generating network packets or messages that appear to come from somewhere else. A message would be a set of packets that comprise a complete chunk of information, such as an e-mail message that might comprise a long sequence of TCP packets. Masquerading and impersonating mean the same as spoofing.

5.8.1 Mail Spoofing

graphics/twodangerlevel.gif

This is where an e-mail message appears to come from someone other than who it actually does. This is trivial for any unprivileged user to do because the sending program puts in the mail headers that say who the mail is from, who it was sent to, the reply address, and the date. All one needs to do is to connect to sendmail on their system directly to bypass Mail, Netscape, or whatever Mail program they would otherwise use. With a few hours experimentation, they could bypass sendmail and connect to your port 25 directly via TCP.

Newer versions of sendmail will signal may be forged if different pieces of data do not match. Many recent sendmail configurations indicate the senders actual IP address and real host name (through reverse address lookup) so you can determine if the mail was forged and submit them to the Realtime Blackhole List. More details are presented in "Forging Mail and News Senders Address" on page 182.


Even telnet could be used to connect to port 25 and send e-mail, as demonstrated in this example. Here you will spoof a message to the president of Pentacorp, purporting to be from the Securities and Exchange Commission, claiming that he is under investigation for insider trading.

 
 telnet mail.pentacorp.com 25 EHLO mail.sec.gov MAIL From:<jwebb@mail.sec.gov> RCPT To:<pres@pentacorp.com> DATA From jwebb@mail.sec.gov Mon Oct 11 23:53:38 2000 Return-Path: jwebb@mail.sec.gov Received: (from jwebb) by mail.sec.gov (8.8.9/8.8.9) id XAA19239 \    for pres@pentacorp.com; Mon, 11 Oct 2000 23:43:47 -0500 (EST) Received: by mail.pentacorp (8.8.9/8.8.9) id XAA19239 \    from rootkit.com; Mon, 11 Oct 2000 23:43:58 -0500 (EST) From: jwebb@mail.sec.gov (Jack Webb) Message-Id: <200010120443.XAA19239@mail.sec.gov> Subject: Insider trading investigation To: pres@pentacorp.com Date: Mon, 11 Oct 2000 23:43:47 -0500 (EST) Mr. Sellhi: This is to inform you that you are under investigation for possible violation of the federal insider trading laws.  Our investigators will be contacting you, your staff, and your broker as our investigation continues. Very sincerely, J. Webb, Sr. Investigator 800-SEC-0330 . 

In the initial message, the sending system will tell its name but, unlike the numeric IP, it can claim to be any system. There is one useful feature that allows a knowledgeable recipient to trace the e-mail; most intermediate systems that handle the mail will add a Received line to it among the headers. Although a spoofer could add her own fake Received lines, the subsequent legitimate systems will add correct ones.

 
 Received: by mail.pentacorp (8.8.9/8.8.9) id XAA19239 \    from rootkit.com; Mon, 11 Oct 2000 23:43:58 -0500 (EST) 

Note that the Pentacorp mail system added a real header that allows tracing the e-mail to rootkit.com, despite our spoofer taking the trouble to add the fake Received entry:

 
 Received: (from jwebb) by mail.sec.gov (8.8.9/8.8.9) id XAA19239 \    for pres@pentacorp.com; Mon, 11 Oct 2000 23:43:47 -0500 (EST) 

Mail servers that handle the message will include the validated host name of the system that each mail message was received from and some will show the numeric IP (that is much, much harder to fake). Some intermediate systems will refuse to accept e-mail from systems that do not supply a valid name on the EHLO line. A few even will verify that it corresponds to the numeric IP of the system that is connecting to them. The only way to guard against this attack besides doing some testing of EHLO data is education and PGP. Educate your users to understand that this spoof is possible, and to not trust e-mail unless sent via PGP.

5.8.2 MAC Attack

graphics/threedangerlevel.gif

The MAC address, short for Media Access Control address, is the actual address of the network card. It also is known as the Ethernet address and is represented by 12 hex digits similar to 28:44:29:31:0A:69. This is the card's true address. Unless changed under program control, it is the address burned into the card's PROM. The card, and, therefore, its computer, receives data intended for the computer's IP address only because there is a protocol to associate the IP address with the MAC address. This protocol enables the sending system to ask, "What MAC address should I send data addressed to a certain IP address to?" The sending system then addresses the packet to the MAC address.

This attack is where a cracker has control of a system on the LAN and he alters the MAC address (Ethernet address) presented by the Ethernet card to be that of another system. Then, when he sends packets out, they will appear to have come from the system being spoofed. It does help to have taken the real system off the network by disconnecting its Ethernet card, by powering it down, or by crashing it. Note that most Ethernet cards allow their MAC addresses to be changed, and the ifconfig command's hw ether option may be used to do this.

Use Arpwatch, discussed in "Using Arpwatch to Catch ARP and MAC Attacks" on page 626, to detect attacks. Also see MAC in the index.

5.8.3 Poisoned ARP Cache

graphics/threedangerlevel.gif

At the lowest level, two computers using Ethernet communicate by using their MAC addresses, sometimes called the Ethernet address. This MAC address must be translated to the Internet Protocol (IP) address that is familiar as the dotted-quad of numbers.

The way that this works is that when system X wants to send a message to the system with IP address 205.180.58.231, it sends out an ARP (address resolution protocol) broadcast asking, "Who is IP 205.180.58.231?"

The system that has the address is supposed to then respond, "I have it and my MAC address is 00:87:72:13:16:F7. The sending system now knows that data packets should be sent to MAC address 00:87:72:13:16:F7.

All systems on the network should be listening to this traffic and cache this mapping so that they do not need to send out their own requests. Defeating this and spoofing another system is almost as easy as ifconfig eth0 167.192.183.135.

Now, assuming the real system owning IP address 167.192.183.135 is not online, you now have "become" that other system with all its privileges.

Also, see MAC in the index.

5.8.4 Poisoned DNS Cache

graphics/threedangerlevel.gif

There are a variety of ways that a cracker might poison your DNS cache. If some of your name servers are outside your domain, there is a fairly simple poisoning technique discussed by D. J. Bernstein (djb@cr.yp.to). If an intruder can inject DNS replies into your network, there are other exploits. Certainly, one solution is to require all your internal sites to go through your name servers and then have your firewall block all responses from UDP and TCP port 53 from outside the firewall to any systems inside except for your firewalls. Most sites should have their firewalls block TCP port 53 to or from any of their systems to the Internet.

This path is not needed and blocking it will prevent poisoning the DNS cache via bogus zone transfers. (If some or all of your DNS servers are provided by your ISP, Domain Registrar, or someone else, you will need to work with them to solve this problem.) Bernstein also offers his replacement of named which he calls dnscache. It may be downloaded from

http://cr.yp.to/dnscache.html

Some information on blocking undesired zone transfers and the like is given at

http://webmail.cotse.com/CIE/RFC/2065/37.htm


       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net