Hi Haxers!,

  following you will find a draft of the first artical submitted for Hax6,
please comment on it. Aside from some spelling and gramatical errors we
need general feedback and more info on the following topics:
1) section A: Commer ref. - title?
              how to check if someones sniffing net for various OS's
              more on accessing ENET card/net interface for various OS's
2) sources for sniffers (FTP sites)
3) info on altering the hardware ID/address of the ENET card/network interface
4) info on sniffing upstream from the local subnet (router, backbone, etc)
5) info on counter-sniffer tactics (disable /dev/nit, challenge/responce,
     kerberose, encrypted sessions, TDR, protocol analysers with alarms, etc).

  To the rest of you that are working on articals, please send in a draft
as soon as you can - projected publication date is late january.
  We still need people to write man pages, and test the sniffers we have.
  Any related info is also welcome.

  We need articals, programs, etc on network attacks for Hax7 and beyond,
if you can send in something, or want to work on an artical please let me
know. Specific areas we'd like to see info on are: writing to the network
interface, forging packets, sequence number prediction, DNS spoofing, etc.

ttyl,
  Tangent

---------------8<-------------------8<------------------8<-----------------

List of Contents:

1.01 : A brief introduction to ethernet and tcp/ip
1.02 : Ethernet interfaces and packet sniffers on various machines.
1.03 : STREAMS drivers, and sun's SunOS /dev/nit
1.1  : What can a Packet sniffer do ?
1.2  : Sample code, a discussion on designing an optimal logger
1.3  : Other loggers and other OS's
A    : Appendix, list of sources.

1.01: A brief introduction to ethernet and tcp/ip
-------------------------------------------------
TCP/IP stands for transmission control protocoll/internet protocoll and is
the major OSI Level 3/4 protocoll used on unix machines and the internet today.
Applications that use TCP/IP include telnet,ftp,rlogin,rsh and finger and smpt
mail to mention a few. Usually TCP/IP runs over ethernet on a local network
(other options include FDDI which is faster and also more expensive, and token
ring which is nearly allways used for ibm protcolls, some sites choose to run
TCP/IP over X.25 data networks or serial lines). Ethernet is a network standard
developed at Xerox PARC in 1979 and standardized as IEEE 802.3 The Ethernet
standard governs the phyisical (OSI protocoll stack TP0) link. Ethernet works
on a CSMA/CD principle (Carrier Sense Multiple Access/Collision Detect), this
meens on a ethernet network a host wishing to send a data packet first listens
to see if the network is free and if not sends it's packet. At the same time
every card listens to see if a packet is addressed to itself and if so reads
it and puts in in the operating sytems input que, otherwise discards it.
Most Ethernet Interfaces also support Promiscous mode, whereby a cartain host
receives ALL packets on the local ethernet, this is the system network sniffers
use. Contrary to popular belief the data sent over the ethernet network ISN'T
encrypted. This meens it can be intercepted as plain text, including such
sensitive Information as passwords.

1.02: Ethernet Interfaces on various machines.
----------------------------------------------
The ethernet Card Controller is usually in charge of which Ethernet packets
get sent to the Operating System. In the case of UNIX the kernel handles the
input que for each protocoll (usually called the mbuf structure). Network
sniffers are usually implemented in hardware and are valuable tools for solving
Network Problems, as a rule such a piece of Hardware is a dedicated Computer
with a carefully desinged ethernet interface and support for several diffrent
Protocolls (Appletalk,Decnet,TCP/IP,X25....). These facilities can however also
be duplicated in software, to some extent. Time was when you whished to use
your Workstation or Mainframe as a packet sniffer, you had to modify your
kernel, usually changeing the part that did packet handeling to split the
output two ways. Device Driver programming has two big disadvantages however,
one beeing the fact that it's hard, because debugging is virtually impossible,
two beeing the fact that it's harware dependent. This is the way packet
sniffers used to be implemented under say 4.3 BSD.

1.03 STREAMS drivers and sun's SunOS /dev/nit
---------------------------------------------
Because of the afore mentioned problems sun (microsystems Inc) took another
aproach. System V Unix offers the STREAMS programming interface (not to be
confused with streams). This allows a programmer to desing a fairly simple
device driver that can be pushed onto the input or output (or both) stack of
another driver. So we have:

/dev/something <----> /dev/STREAMS  <---> application.
     |                    |
     |                    |
(a hardware driver)   (a streams driver offering various facilities)

In this case when the app application tries to read or write to /dev/something,
the call gets redirected to /dev/STREAMS which passed the data through in
both directions, but offers further facilities (say a two_way splice). You
can push multiple instances of /dev/STREAMS onto the stack of /dev/something.
How does all this affect ethernet tapping ? well under SunOS "/dev/something"
is the hardware based ethernet driver and "/dev/STREAMS" is /dev/nit. Since
both drivers are allready supplied by the operating system, you can read and
write to the Ethernet driver directly, from user level code, without having
to modify the kernel. Since we won't be mentioning writing much I'll explain
that first: It's main use is what sun calls
'user level protocoll implementations' so for instance you could write an
application that used say appletalk without the OS's support. For hackers it's
main use in writing terms lies in the fact that you can produce data packets
with fake addresses,etc. I have never written any code for writing to /dev/nit
so I don't feal in a position to comment on that. When you READ /dev/nit you
can switch the interface into promiscous mode and therby capture as many of
the data packets as you whish. (You need root priviledges on a sun to do this)

1.1 What can a Packet sniffer do ?
--------------------------
Basically a Packet sniffer reads raw data from /dev/nit, most off the code is
dedicated to processing the ethernet packets into human readble form. The
simlest logger would theirfor be:
main() {
/*
 * init the interface
 */
        while( (cc= read(input,buf,CHUNKSIZE) >= 0) {
                write(output,buf,cc);
        }
}
Why is this a bad idea ? Well this way you'll get a lot of data you don't want
nfs requests,ARP/RARP request, ICMP messages... Also most of the data
will be in network byte order integers. Some packet sniffers like  say tcpdump
only do minimal post processing, and dump the data as hex. it's then up to you
to decode the packets by hand. Other's like D. Reed's tcplog don't print the
data field at all. (only Connect/Disconnect requests). nfswatch uses similar
techniquest to watch UDP packets send to nfsd and mountd. So basically an
ethernet sniffer has two parts, one of which configuring the device with the
options you want, the other of which turns raw data into tcp/ip packets and then
if you wish into sessions. Let us look at the first part, the configuring
of the packet sniffer.

1.2
------------
The SunOS NIT system (which stands for Network Interface Tap) supports several
option. (look at nit,nit_pf,nit_buf, nit_if man pages). Among the options
supported are:
* setting of timeout, sizeof read and number of bytes kept per packet.
* setting the interface into promiscuous mode, for tapping packets to other
  hosts
* prepending lenght of packet's and or number of packets dropped by interface
* efficient filtering of unwanted data based on fields in the data packets
This is a valid routine for initializing the device, it returns a file
descriptor:

int initdevice(device)
char *device;
{                       /* Open device, return filehandle */
   struct strioctl  si;
   struct ifreq     ifr;
   struct timeval   timeout;
   int              if_fd;
   u_long           chunksize,snapsize,if_flags;
   struct packetfilt   pf;
   register u_short    *fwp;

   /* init packet-filter */
   fwp=pf.Pf_Filter;
   /*
    * only look at IP packets
    */
   *fwp++ = ENF_PUSHWORD+6;
   *fwp++ = ENF_PUSHLIT | ENF_CAND;
   *fwp++ = htons(ETHERTYPE_IP);
   /*
    * check for tcp protocoll
    */
   *fwp++ = ENF_PUSHWORD+sizeof(struct ether_header)/sizeof(short)+4;
   *fwp++ = ENF_PUSHLIT | ENF_AND;
   *fwp++ = htons(0x00FF);
   *fwp++ = ENF_PUSHLIT | ENF_CAND;
   *fwp++ = htons( IPPROTO_TCP);
   /*
    * only let packets with src_prt 21 OR dest_prt 21
    * OR src_prt 23 OR dest_prt 23 pass
    */
   *fwp++ = ENF_PUSHWORD + 17;
   *fwp++ = ENF_PUSHLIT | ENF_AND;
   *fwp++ = htons(0xFFFD);
   *fwp++ = ENF_PUSHLIT | ENF_EQ;
   *fwp++ = 21;
   *fwp++ = ENF_PUSHWORD + 18;
   *fwp++ = ENF_PUSHLIT | ENF_AND;
   *fwp++ = htons(0xFFFD);
   *fwp++ = ENF_PUSHLIT | ENF_EQ;
   *fwp++ = 21;
   *fwp++ = ENF_OR;
   pf.Pf_FilterLen = fwp - &pf.Pf_Filter[0];

   snapsize = SNAPSIZE;         /* Only treat first 300 characters of packet */
   chunksize = CHUNK;           /* Send packet after 1000 octets */
   if_flags = NI_PROMISC |      /* receive ALL packets (superuser!) */
     NI_DROPS;                  /* inform about dropped packets */
   /*
    * this opens the /dev/nit device so we can operate with ioctl's on it
    */
   if ((if_fd = open("/dev/nit",O_RDONLY)) < 0) {
      perror("couldn't open /dev/nit");
      exit(-1);
   }

   /*
    * discrete messages from stream
    */
   if (ioctl(if_fd,I_SRDOPT,(char *) RMSGD) == -1) {
      perror("ioctl:I_SRD_OPT");
      exit(1);
   }

   /*
    * Push+configure packet-filter
    */
   si.ic_timout=INFTIM;
   if (ioctl(if_fd,I_PUSH,"pf") == -1) {
      perror("ioctl: I_PUSH pf");
      exit(1);
   }

   /*
    * Declare packet-filter. Note that you don't HAVE to use a filter command
    * list. You can also do the filtering in your readloop this is a lot
    * less efficient however.
    */
   si.ic_cmd=NIOCSETF;
   si.ic_len=sizeof pf;
   si.ic_dp=(char *)&pf;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: NIOCSETF");
      exit(-1);
   }

   /*
    * Push+configure buffer module
    */
   if (ioctl(if_fd,I_PUSH,"nbuf") == -1) {
      perror("ioctl: nbuf");
      exit(1);
   }

   /*
    * set buffer-timeout to 1 sec. This is the time before we return
    * from an unsucessfull read atempt. 0 is infinite.
    */
   timeout.tv_sec=1;
   timeout.tv_usec=0;
   si.ic_cmd=NIOCSTIME;
   si.ic_len=sizeof timeout;
   si.ic_dp=(char *)&timeout;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: I_STR");
      exit(1);
   }

   /*
    * set bufer chunksize (the size of data we read every time, before
    * returning to read_loop)
    */
   si.ic_cmd=NIOCSCHUNK;
   si.ic_len=sizeof chunksize;
   si.ic_dp=(char *)&chunksize;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: CHUNKSIZE");
      exit(1);
   }

   /*
    * set interface-binding. This specifies WHICH ethernet interface
    * we wish to tap (usually le0, find out with /etc/ifconfig -a)
    */
   (void)strncpy(ifr.ifr_name,device,sizeof ifr.ifr_name);
   ifr.ifr_name[sizeof ifr.ifr_name - 1]='\0';
   si.ic_cmd=NIOCBIND;
   si.ic_len=sizeof ifr;
   si.ic_dp=(char *)&ifr;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: NIOCBIND");
      exit(1);
   }

   /*
    * cut incoming packets, (this specifies the maximum number of
    * bytes kept per packet, since some applications might only want the
    * headers.)
    */
   si.ic_cmd=NIOCSSNAP;
   si.ic_len=sizeof snapsize;
   si.ic_dp=(char *)&snapsize;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: NIOCSNAP");
      exit(1);
   }

   /*
    * set flags, including the one for promiscuous mode, and the one
    * which adds a header telling us how many packets the interface dropped
    */
   si.ic_cmd=NIOCSFLAGS;
   si.ic_len=sizeof if_flags;
   si.ic_dp=(char *)&if_flags;
   if (ioctl(if_fd,I_STR,(char *)&si) == -1) {
      perror("ioctl: FLAGS");
      exit(1);
   }
   if( ioctl(if_fd,I_FLUSH,(char *)FLUSHR) == -1) {
      perror("ioctl: I_FLUSHR");
      exit(1);
   }
   nitfd=if_fd;
   return if_fd;

}

The most interesting part is the actuall filter command list fwp. This
according to sun is the best way of filtering out unwanted Packets. It works
like a classic Stack machine. With the commands ENF_PUSHWORD + N you push
the n'th 16 bit shortword of the data packet onto the stack. ENF_PUSHLIT
pushes a literal (a constant number) onto the stack. All the other commands
operate on the two top words on the stack, popping the two top words off
the stack and pushing ONE result word. Note that a command and an action
can be combined by OR'ing so:

*fwp++ = ENF_PUSHWORD + 17;
*fwp++ = ENF_PUSHLIT | ENF_AND;
*fwp++ = htons(0xFFFD);

is equivalent to:

*fwp++ = ENF_PUSHWORD + 17; /* push the 17'th shortword onto the stack */
*fwp++ = ENFPUSHLIT;        /* push the literal following this onto the stack*/
*fwp++ = htons(0xFFFD);     /* this is the literal that gets pushed */
*fwp++ = ENF_AND;           /* We now pop (17'th word) and 0xFFFD and
                             * AND them togeither and put that result onto
                             * the stack */
A packet will be accepted if the last value left on the stack after all the
commans have been executed is positive.
The only operators that behave differently are (apart from ENF_NOP that does
nothing) are the ones starting with ENF_C* (like ENF_CAND, ENF_COR, ENF_CNOR
and ENF_CNAND). These compare the two top words and can be used to imediatly
exit the filter if the condition they are checking is true or false (depending
on the command of course). They do not leave a value on the stack. This
mechanism can be used to quickly discard unwanted packets:

/*
 * This pushes the sixth shortword onto the stack. This field (should)
 * contain the Packet type
 */
 *fwp++ = ENF_PUSHWORD+6;
/*
 * Exit immediatly if the result tested for isn't true, and discard packet
 * Otherwise continue.
 */
 *fwp++ = ENF_PUSHLIT | ENF_CAND;
 *fwp++ = htons(ETHERTYPE_IP);

Please read the man pages for an exact discription of all commands. Note that
ENF_GT meens Greater than, ENF_LT meens less than, etc. The various ioctl's
are also fairly well documented and part of pushing the filter onto the
stream, setting the mode flags and so on. The NI_DROPS flag prepends a header
to the read data telling us how many packets the device has (had to drop).
Software based sniffers aren't very efficient on a busy network, and packets
are only kept as long as theirs room in the Operating Systems input que. Here's
the readloop routine:

void readloop(fd)
int fd;
{
   static u_char buf[4*CHUNK];
   register u_char *bp, *cp, *bufend;
   register struct nit_bufhdr *hp;
   register struct nit_ifdrops *np;
   register struct nitstat *nsp = &nst;
   int cc;

   while( (cc = read(fd,buf,CHUNK)) >=0) {
     bp = buf;
     bufend = buf +cc;
     /*
      * loop through each snapshot in the chunk
      */
     while (bp < bufend) {
        cp = (u_char *) ((char *)bp + NIT_HDRSIZE);
        /*
         * get past nit buffer
         */
        hp = (struct nit_bufhdr *)bp;
        np = (struct nit_ifdrops *) ((char *)bp + BUFHDR_SIZE);
        if (nsp->dcount < np->nh_drops) {
           fprintf(fptr,"Warning: %d Packets droppend\n",
                    np->nh_drops - nsp->dcount);
           nsp->dcount = np->nh_drops;
        }
        /*
         * next snapshot
         */
        bp += hp->nhb_totlen;

        con_monitor(cp,bp);
     }

   }    /* while ((cc=read(fd... */
}

The only other code a packet sniffers needs is a lot of application level
code to convert raw packets into something readable to humans. tcplog and
tcpdump and even nfswatch have a lot of good examples of this.

1.3 Other loggers and other OS's
--------------------------------
Well I've allready mentioned tcpdump. This is very large but supports many
diffrent os's including those that don't support user level packet sniffing
(and theirfor need kernel changes). tcplog is smaller and only runs on suns
but won't print out any part of the data field(s). etherfind which comes
with SunOS is also an ethernet analyzer, though like tcpdump it's not really
suited for looking at packet contents (again hex only). Of the other
OS's I'd like to mention Ultrix on DEC Systems which has a packet filtering
system very similar (but not source compatible) with SunOS. The main
differences are that the sysadmin can set a flag allowing all users to sniff
a system (on a sun you have to be root) and a few minor changes with the
ENF_* Commands. This system is called pfilt. HP-UX machines come with a command
for network monitoring but don't allow promiscuous mode monitoring (it's
hinted that's bacause Hewlett Packard doesn't want competition for their
Hardware analyzers). IBM R6000 Machines also have some sort of sniffer though
I've heard (and not been able to confirm) that their Ethernet Card doesn't
allow promiscious mode sniffing at all (some pc cards don't either). Mentioning
PC's theirs an ethernet sniffer called gobbler for those (which is public
domain). Macs have sniffers avaliable too as far as I can tell only commercial
ones though. DEC VAX users running VMS might like to look at ETHERMON which is
written mainly in fortran,but does allow promiscious mode monitoring. Slightly
of the topic Sun's Sunlink Software for X.25 (Sunlink X.25) supports sniffing
of the X.25 link via a very similar interface (called /dev/snpkt0 i think)
They even have a command for dooing this called x25trace.

A: Appendix, question and answer
--------------------------------
Q: I'd like to find out more about TCP/IP Ethernets Networking. Where do I
   look ?
A: For TCP/IP have a look at Commer (very large). For writing Network Code have
   a look at Stevens Unix Network Programming. For ethernet standards and or
   OSI have a look at Tannenbaums Computer Networks. For more info on nit
   programming you'll have to look at the code of the network programms
   mentioned. There is also rummor of a fabled Sun white paper on the subject
   (which i haven't managed to get hold of).

Q: What's promiscuous mode ?
A: The mode you can set an ethernet card in, so it accepts ALL packets on the
   network rather than just those with it's Ethernet address.

Q: Can I have your complete sniffer with all the src ?
A: No.

Q: I didn't understand any of the code up their. Can you explain _insert_your
   _favourite_simple_c_concept ?
A: Well this article was intended for people with some experience in C.
   (Where did you get your copy from ?) If you don't have that experience I
   can't really help you (except by telling you to look at K&R)

Q: Does all this really meen that someone could be snooping *my* password ?
A: If your on an ethernet yes.

Q: Thats terrible!
A: Isn't it!

Q: Why wasn't the system desinged so this couldn't happen
A: In the days ethernet was desinged people weren't that worried about security
   besides with slow hardware encryption was expensive.

Q: What can I do about people snooping my network ?
A: You can buy an expensive ethernet hub that only sends packets to the host
   they are destined to. Though your not using a broadcast network any more.
   Or you can encrypt. Have a look at kerberos and SecureNFS/RPC for that.
   A solution that's sometimes mentioned is rlogin with a trusted entry in
   .rhosts. While this doesn't send a password accross the network it intro-
   duces other (security) problems. If your worried about someone running a
   sniffer on your sun (who has to be root anyway to do that) the you can
   take out /dev/nit from the kernel. Then again someone who's root can put
   it right back so....

Q: Can i check weither someons snooping my network ?
A: Lets split this into two parts: 1: SunOS. With the command /etc/ifconfig -a
   you can see if the interface of your local host is in promiscious mode
   (if so the flag PROMISC should appear next to UP,RUNNING). With Sunlink
   snmp Software you can check the status of ALL interfaces from a remote
   workstation. 2: PC's as a rule you can't check what mode their in. Theirs
   no apparent sign from the point of view of the network. The moral of that
   story is don't share an ethernet with a publicly accessible PC Cluster.
   Any other OS's i'm not sure.

---(snip)----(snip)----(snip)----
well this is a rought draft. pass it around and tell me what people think
and what I should add. I might be willing to add some more code if that's
going to help. The rest is fairly standard though (mainly sorting packets
into sessions with a hash table, printing output etc...)



X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
 Another file downloaded from:                                NIRVANAnet(tm)

 &TOTSE                510/935-5845   Walnut Creek, CA         Taipan Enigma
 Burn This Flag        408/363-9766       San Jose, CA                Zardoz
 realitycheck          415/666-0339  San Francisco, CA    Poindexter Fortran
 Governed Anarchy      510/226-6656        Fremont, CA             Eightball
 New Dork Sublime      805/823-1346      Tehachapi, CA               Biffnix
 Lies Unlimited        801/278-2699 Salt Lake City, UT            Mick Freen
 Atomic Books          410/669-4179      Baltimore, MD               Baywolf
 Sea of Noise          203/886-1441        Norwich, CT             Mr. Noise
 The Dojo              713/997-6351       Pearland, TX               Yojimbo
 Frayed Ends of Sanity 503/965-6747     Cloverdale, OR              Flatline
 The Ether Room        510/228-1146       Martinez, CA Tiny Little Super Guy
 Hacker Heaven         860/456-9266        Lebanon, CT         The Visionary
 The Shaven Yak        510/672-6570        Clayton, CA             Magic Man
 El Observador         408/372-9054        Salinas, CA         El Observador
 Cool Beans!           415/648-7865  San Francisco, CA        G.A. Ellsworth
 DUSK Til Dawn         604/746-5383   Cowichan Bay, BC         Cyber Trollis
 The Great Abyss       510/482-5813        Oakland, CA             Keymaster

                          "Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X