[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]

..[ Phrack Magazine ]..
.:: Network Miscellany ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ]
Current issue : #40 | Release date : 1992-08-01 | Editor : Dispater
Phrack LoopbackMind Mage & Dispater
Phrack Pro-Phile on Lex LuthorTaran King & Lex Luthor
Network MiscellanyThe Racketeer
Pirates CoveRambone
Cellular Telephony, Part IIBrian Oblivion
The Fine Art of TelephonyCrimson Flash
BT Tymnet, Part 1 of 3Toucan Jones
BT Tymnet, Part 2 of 3Toucan Jones
BT Tymnet, Part 3 of 3Toucan Jones
SummerCon 1992Knight Lightning & Dispater
PWN/Part 1Datastream Cowboy
PWN/Part 2Datastream Cowboy
PWN/Part 3Datastream Cowboy
Title : Network Miscellany
Author : The Racketeer
                                ==Phrack Inc.==

                     Volume Four, Issue Forty, File 4 of 14

                               Network Miscellany
           <    How to Acquire Information on Internet Computers   >
                         Compiled from Internet Sources

                                by The Racketeer
                              of The Hellfire Club

                    Network Miscellany created by Taran King

Generally speaking, information is everything.  A lot of hacking any computer
on a network is being able to gather information about the machine and its
vulnerabilities.  This file is about using the available resources on the
Internet network in order to gain important information about any perspective

A large amount of information has been printed in Phrack recently about the
Internet, most of it copied straight from manuals and in my opinion lacking
hacking flair.  Therefore, I'm going to take you straight into the heart of the
heart of the matter with this file on acquiring information!

Now, the Internet is notorious for not having an instruction manual.  Most
people who find out what the Internet is learn from their friends.  It used to
be that there was only one real landmark on the Internet, and that was the
SIMTEL-20 FTP archive.  Now, the Internet is probably the largest free network
in existence.  In fact, it's a hacker's paradise!

Unfortunately, you have to know about "public" sites on the network before you
can use them.  Likewise, how are you going to hack an organization if you don't
know any machines on it?  Sort of like trying to complain to Packard-Bell about
your computer equipment not working when the bastards don't supply their name,
address, or phone number. You are going to have to find another way to get that
information if you want to get anything done.

There is not any one particular way to learn about a site.  In fact, you'll
have to combine several unusual methods of gathering information in order to
obtain anything resembling a "complete picture."  However, using the
combinations of techniques described in this file, you can maneuver through any
network on the Internet and learn about the machines within.

The first stop on this journey is the ARPANet Network Information Center
(frequently called "NIC" by experienced network users).  NIC's purpose is
simply to keep track of all the network connections, fields, domains, and hosts
that people wish to be told about.

To connect to NIC, you would issue a command from your Internet connected
machine similar to this:

               .----------------------- command
[lycaeum][1]> telnet nic.ddn.mil

This will (within a short period of time) route you to the Network Information
Center and grant you access.  There isn't a straight forward login/logout
system on NIC like other Unix computers; it will just connect you to the
Information System upon connection.  The message you will get will be similar
to this:

*  -- DDN Network Information Center --
*  For TAC news, type:                    TACNEWS <return>
*  For user and host information, type:   WHOIS <return>
*  For NIC information, type:             NIC <return>
*  For user assistance call (800) 235-3155 or (415) 859-3695
*  Report system problems to ACTION@NIC.DDN.MIL or call (415) 859-5921

 SRI-NIC, TOPS-20 Monitor 7(21245)-4
@ <prompt>

Great, now we are in.  Essentially, since NIC is just a great big telephone
book, we need to let our fingers to the walking.  Let's demonstrate a few
simple commands as I go after one of the government contract giants, the
corporation known as UNISYS.  Let's start by entering WHOIS.

SRI-NIC WHOIS 3.5(1090)-1 on Tue, 22 Aug 91 15:49:35 PDT, load 9.64
  Enter a handle, name, mailbox, or other field, optionally preceded
  by a keyword, like "host sri-nic".  Type "?" for short, 2-page
  details, "HELP" for full documentation, or hit RETURN to exit.
---> Do ^E to show search progress, ^G to abort a search or output <---

Okay, now we are in the database.  Since Unisys is our target, let's go ahead
and ask it about "Unisys."

Whois: unisys

Cartee, Melissa (MC142)         unisys@email.ncsc.navy.mil     (904) 234-0451
Ebersberger, Eugen (EE35)       UNISYS@HICKAM-EMH.AF.MIL       (808) 836-2810
Lichtscheidl, Mark J. (MJL28)   UNISYS@BUCKNER-EMH1.ARMY.MIL   (DSN) 634-4390
Naval Warfare Assessment Center (UNISYS) UNISYS.NWAC.SEA06.NAVY.MIL
Navratil, Rich (RN74)           UNISYS@COMISO-PIV.AF.MIL       (ETS) 628-2250

There are 28 more matches.  Show them?  y      -->  of course

Peterson, Randy A. (RP168)      UNISYS@AVIANO-SBLC.AF.MIL      (ETS) 632-7721
Przybylski, Joseph F. (JP280)   UNISYS@AVIANO-SBLC.AF.MIL      (ETS) 632-7721
UNISYS Corporation (GVLV2)      GVL.UNISYS.COM      
Unisys Corporation (NET-MRC-NET)MRC-NET                 
Unisys Corporation (NET-SDC-PRC-CR) UNISYS-ISF-11       
Unisys Corporation (NET-SDC-PRC-LBS) UNISYS-ISF-9       
Unisys Corporation (NET-SDC-PRC-SA) UNISYS-ISF-10       
Unisys Corporation (NET-SDC-PRC-SW) UNISYS-ISF-8        
Unisys Corporation (NET-UNISYS-CULV) UNISYS-CULV        
Unisys Corporation (NET-UNISYS-PRC) UNISYS-PRC          
Unisys Corporation (NET-UNISYS-RES1) UNISYS-RES1        
Unisys Corporation (NET-UNISYS-RES2) UNISYS-RES2        
Unisys Corporation (NET-UNISYS2)UNISYS-B2               
Unisys Corporation (STARS)      STARS.RESTON.UNISYS.COM
Unisys Corporation (UNISYS-DOM)                                    UNISYS.COM
Unisys Linc Development Centre (NET-LINC) LINC           
UNISYS (ATC-SP)                 ATC.SP.UNISYS.COM   
Unisys (FORMAL)                 FORMAL.CULV.UNISYS.COM 
UNISYS (NET-UNISYS-RES3)        UNISYS-RES3            
Unisys (NET-UNISYS-SP)          UNISYS-SP               
UNISYS (SYS-3)                  SYS3.SLC.UNISYS.COM   
Wood, Roy (RW356)               UNISYS@LAKENHEATH-SBLC.AF.MIL
                                              0044-0638-522609 (DSN) 226-2609

As you can see, the details on these computers get fairly elaborate.  The first
"column" is the matching information, second column is the network name or
title, then it is followed by a phone number or IP port address.  If the phone
number has an area code, then it is of a standard phone nature; however, if it
is (DSN) then it's on the "Data Security Network," aka Autovon (the military
phone system).

Now, as you can tell from the above list, there are several UNISYS accounts at
military machines -- including a military machine NAMED after Unisys (mclean-
unisys.army.mil).  This stands to reason since Unisys deals mostly in military
computer equipment.  Since it is a secretive military group, you'd figure an
outsider shouldn't be able to gain much information about them.

Here is what happens if you center on a specific person:

Whois: cartee
Cartee, Melissa (MC142)            unisys@email.ncsc.navy.mil
   7500 McElvey Road
   Panama City, FL 32408
   (904) 234-0451
   MILNET TAC user

   Record last updated on 18-Apr-91.

Hmm..  Very interesting.  This user obviously has access to military computers
since she has a TAC card, and goes under the assumed identity as "Unisys" in
general.  Could this person be a vital link to the Unisys/U.S.  Defense
connection?  Quite possibly.  More likely she is a maintenance contact, since
she can use her TAC card to contact multiple (confined) military networks.

I've gone ahead and requested specific information about kauai.mcl.unisys.com,
which as far as I know is a focal point for the Unisys Networks.  Of course,
the information on this machine is non-classified (or if it IS classified,
Unisys will probably be chewed out by Uncle Sam).  Notice all the great
information it gives:

Whois: kauai.mcl.unisys.com
   Building 8201, 10th Floor Computer Room
   8201 Greensboro Drive
   McLean, VA 22102

   Nicknames: MCL.UNISYS.COM
   System: SUN-3/180 running SUNOS

      Meidinger, James W.  (JWM3)  jim@BURDVAX.PRC.UNISYS.COM
      (215) 648-2573

   domain server

   Record last updated on 05-Aug-91.

   No registered users.

Aha!  The Coordinator on this machine doesn't use it!  There are no registered
users!  Namely, if you wanted to hack it, you aren't screwing with the higher
ups (this is good).  Since when does Unisys buy computers from other companies?
Can't they just grab a few off the assembly line or something?  The computer is
stationed in McLean, Virginia!  That's where the CIA is!  Could Unisys be
developing computers for the international espionage scene?  Obviously, there
is a great deal of information to be sucked out of this machine.

How?  The answer was listed there.  The machine is a DOMAIN SERVER.  That means
this computer holds the network information used to identify all the computer
systems on its network and all we need to do right now is figure out a way to
squeeze that information out!  But first, let's see if our hunch was correct in
assuming the bigwigs are far away by checking out the head honcho, "Mr.

Whois: jim@burdvax.prc.unisys.com
Meidinger, James W. (JWM3)             jim@BURDVAX.PRC.UNISYS.COM
   Unisys Corporation
   Computer Resources
   Room g311
   P.O. Box 517
   Paoli, PA 19301-0517
   (215) 648-2573

   Record Last Updated on 04-Jul-90.

Yup, Mr. Meidinger is far away -- Pennsylvania, to be exact.  Not exactly
keyboard's length away, is he?  Besides, being in the "Computer Resources"
department, I'd suspect he is just an accountant.  Accountants are to computing
as beavers are to trees (unless, of course, they actually like computers, which
isn't a foregone conclusion in the business world).

I'm going to skip the rest of the information on NIC, since it has been
overkilled in this particular magazine anyway.  The only hint I have is to read
CERT's and DDN's news blurbs, since they give out some interesting information
which would be useful and educational.  Besides, messing around with the CIA's
hired goons sounds much more fun.

Now is the time for a little bit of a lesson in critical reasoning: the
Internet isn't exactly a "free to the public" network, meaning you just can't
attach your computer to a machine on the Internet and expect it to work all of
a sudden.  You need to configure your machine around the computers in the
network domain you are linking into, and if you have their permission, then
everything is cool.  But once you're configured, and your router and/or server
has been notified of your existence, does that mean anyone else has that
information?  The answer is yes, although that info won't be forwarded to a
place like NIC -- it will have to be obtained another way.

All packets of data on the Internet need to be routed to and from valid
computer hosts.  Therefore, all of this information is stored on the network's
gateway.  But the routing information stored is simply in numeric format, such
as  At least, that is as understandable as it gets, since
Ethernet addresses are even more elaborate and in binary.

However, as Internet users know, there is more than a single way of describing
a computer.  "telnet" would be one way of connecting to a
computer, or "telnet aviary.stars.reston.unisys.com" would be another way of
connecting to the same computer.  These names are chosen by the owner of the
network, and are described through the use of "domain servers."

As you recall, kauai.mcl.unisys.com was listed by NIC as a domain server.  This
means that the names of the computer systems on that network are stored on that
particular host.  Of course, that's not the only thing.  The domain server
presents the computer name and IP number to the connecting machine allowing you
to connect to the computer by using a "domain style name."  Ultimately,
everything is converted to IP numbers.

Most network software allows compatibility with domain servers, meaning if you
want to connect to nic.ddn.mil, and you specify a command "telnet nic.ddn.mil"
then you will connect to nic.ddn.mil.  Sadly, this isn't true of all computers
(which require IP numbers only), but at least it is true enough that the
general user is likely to have such computer resources.

Reaching back to the Dark Ages, there is a computer program that allows
machines that don't directly interpret domain style addresses to IP addresses
to still find out what the name of a machine is.  This program is called
"nslookup" and is usually found in the Unix operating system (at least, I
haven't used it anywhere else -- it might only work on Unix).

"nslookup" stands for Name Server Lookup (there has been some debate, it seems,
if a domain server is really a name server, or visa versa; in fact, both
describe what they do well enough to have conflict).  Regardless, let's go
ahead and work on learning how to use nslookup.

[lycaeum][2]> nslookup
Default Name Server:  lycaeum.hfc.com

Now, going back to that NIC information we got earlier, let's continue to hack
on poor old Unisys, which is giving up its info every step we make.  We
determined that the kauai.mcl.unisys.com was a domain server, so let's jump
ahead to that by changing our server to their server (after all, the computers
we are after aren't on our machine).

> server kauai.mcl.unisys.com
Default Server:  kauai.mcl.unisys.com

Okay, now we have connected to the server.  This isn't a constant connection,
by the way.  It will only establish a connection for the brief instant that it
takes for it to execute commands.  It doesn't require a password or an account
to get this information off of a nameserver.

Let's start off by having it give us a list of everything about Unisys that
this server knows.  "Everything" is pretty much a good place to start, since we
can't go wrong.  If we come up with nothing, then that's what's available.  The
basic command to list machines is "ls" like the Unix directory command.

> ls unisys.com
Host of domain name            Internet address
 unisys.com                     server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 unisys.com                     server = kronos.nisd.cam.unisys.com     3600
 kronos.nisd.cam.unisys.com                     3600
 unisys.com                     server = kauai.mcl.unisys.com           3600
 kauai.mcl.unisys.com                    43200
 unisys.com                     server = io.isf.unisys.com              3600
 io.isf.unisys.com                      3600
 reston.unisys.com              server = aviary.stars.reston.unisys.com 3600
 aviary.star.reston.unisys.com                   3600
 aviary.star.reston.unisys.com                   3600
 reston.unisys.com              server = kauai.mcl.unisys.com           3600
 kauai.mcl.unisys.com                    43200
 rosslyn.unisys.com             server = aviary.stars.reston.unisys.com 3600
 aviary.stars.reston.unisys.com                   3600
 aviary.stars.reston.unisys.com                   3600
 rosslyn.unisys.com             server = kauai.mcl.unisys.com           3600
 kauai.mcl.unisys.com                    43200
 rmtc.unisys.com                server = rmtcf1.rmtc.unisys.com         3600
 rmtcf1.rmtc.unisys.com                      3600
 rmtc.unisys.com                server = gvlv2.gvl.unisys.com           3600
 gvlv2.gvl.unisys.com                  3600
 sp.unisys.com                  server = dsslan.sp.unisys.com           3600
 dsslan.sp.unisys.com                    3600
 sp.unisys.com                  server = sys3.slc.unisys.com            3600
 sys3.slc.unisys.com                     3600
 cam.unisys.com                 server = kronos.nisd.cam.unisys.com     3600
 kronos.nisd.cam.unisys.com                     3600
 cam.unisys.com                 server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 prc.unisys.com                 server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 prc.unisys.com                 server = kronos.prc.unisys.com          3600
 kronos.prc.unisys.com                     3600
 prc.unisys.com                 server = walt.prc.unisys.com            3600
 walt.prc.unisys.com                      3600
 walt.prc.unisys.com                     3600
 culv.unisys.com                server = formal.culv.unisys.com         3600
 formal.culv.unisys.com                    3600
 culv.unisys.com                server = kronos.nisd.cam.unisys.com     3600
 kronos.nisd.cam.unisys.com                     3600
 slc.unisys.com                 server = sys3.slc.unisys.com            3600
 sys3.slc.unisys.com                     3600
 slc.unisys.com                 server = dsslan.sp.unisys.com           3600
 dsslan.sp.unisys.com                    3600
 slc.unisys.com                 server = nemesis.slc.unisys.com         3600
 nemesis.slc.unisys.com                     3600
 bb.unisys.com                  server = sunnc.wwt.bb.unisys.com        3600
 sunnc.wwt.bbs.unisys.com                     3600
 bb.unisys.com                  server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 isf.unisys.com                 server = orion.ISF.unisys.com           3600
 orion.ISF.unisys.com                    3600
 isf.unisys.com                          3600
 isf.unisys.com                 server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 isf.unisys.com                 server = io.isf.unisys.com              3600
 io.isf.unisys.com                      3600
 gvl.unisys.com                        172800
 gvl.unisys.com                 server = gvlv2.gvl.unisys.com           3600
 gvlv2.gvl.unisys.com                  3600
 gvl.unisys.com                 server = burdvax.prc.unisys.com         3600
 burdvax.prc.unisys.com                   3600
 mcl.unisys.com                          43200
 mcl.unisys.com                 server = kauai.mcl.unisys.com           43200
 kauai.mcl.unisys.com                    43200
 mcl.unisys.com                 server = burdvax.prc.unisys.com         43200
 burdvax.prc.unisys.com                   3600
 mcl.unisys.com                 server = kronos.nisd.cam.unisys.com     43200
 kronos.nisd.cam.unisys.com     (dlen = 1152?)                  4096
ListHosts: error receiving zone transfer:
  result: NOERROR, answers = 256, authority = 0, additional = 3.

Bummer, an error.  Funny, it claims there isn't an error, yet it screwed up the
kronos address and knocked me out.  Apparently, this domain server is screwed.
Oh well, I guess that's really their problem because in the information it gave
us, it was able to provide all the answers we needed to figure out the next

Quick analysis of the above information shows that most of the servers were
connected to at LEAST two other servers.  Quite impressive:  A fault-tolerant
TCP/IP network.  Since it is fault tolerant, we can go ahead and use a
different machine to poke into the "mcl.unisys.com" domain.  Since "mcl" stands
for McLean, that's where we want to go.

Remember that NIC told us that kauai.mcl.unisys.com had an alias?  It was also
called "mcl.unisys.com".  Looking at the above list, we see toward the bottom
that mcl.unisys.com is also domain served by the computers
burdvax.prc.unisys.com and kronos.nisd.cam.unisys.com.  Let's connect to one of
them and see what we can gather!

Whenever a server starts acting screwy like kauai was doing, I make it a habit
of using IP numbers when they are available.  I'm going to connect to
burdvax.prc.unisys.com through its IP address of

> server
Default server: []

Now that we are connected, let's see the network information again, but this
time let's try something different and possibly more useful.  This time we will
use the -h command, which happens to describe the computer type (CPU) and the
operating system it runs on (OS) which will give us a better idea of what we
are dealing with.

> ls -h mcl.unisys.com
Host or domain name           CPU          OS
 maui.mcl.Unisys.COM           SUN-2/120    UNIX        43200
 cisco.mcl.Unisys.COM          CISCO GATEWAY CISCO              43200
 kauai.mcl.Unisys.COM          SUN-3/180    UNIX        43200
 voyager.mcl.Unisys.COM        SUN-4/330    UNIX        43200
 dial.mcl.Unisys.COM           SUN-3/260    UNIX        43200
 astro.mcl.Unisys.COM          SUN-3/60     UNIX        43200
 hotrod.mcl.Unisys.COM         Unisys 386   SCO/UNIX            43200
 oahu.mcl.Unisys.COM           VAX-11/785   UNIX        43200
 lanai.mcl.Unisys.COM          SUN-3/160    UNIX        43200
 mclean_is.mcl.Unisys.COM      386          NOVELL              43200

WOW!  Look at all those Suns!  I guess Unisys has no faith in their own
computers or something!  If only President Bush could see this display of a
company backing their product!  In fact, the only Unisys computer in this whole
lot is a cheesy 386 clone which probably is some guy's desktop machine.

Once again, there is some fascinating information here.  Let's run through it
really quick:

Maui is a Sun 2, which is a really old RISC computer.  You don't see many of
these around but they still can be useful for storing stuff on.  But then
again, it probably is faster than a PC!

Oahu is a Vax-11 which is apparently running Ultrix.  This may be where Unisys
hoards all their programmers since it isn't being used for serious networking
(at least, as far as we can tell).

Mclean_is happens to be the file server for a PC network.  We can't really tell
from this point how many computers are on this network, but it could be
possible it is used for public information trade, where secretaries or
receptionists use it to confirm trade and scheduling.

Hotrod is also a 386, made by Unisys even!  Oddly, it is running a copy of SCO
Unix, which means it is, no doubt, a personal computer someone uses for Unix
programming.  If Unisys were itself a part of the government, I'd think this
computer would have been a kludged bidding contract which they got stuck with
because they were aiming for lowest bid and were unfortunately not very picky.

Voyager is an interesting machine, which is apparently the most modern on this
network.  Since it is a Sun-4 computer (probably IPX) it would be a high-speed
graphics workstation.  This could be the machine where many CAD applications
are stored and worked on.  Another possibility is that Sun 4 computers were
extremely expensive when they purchased this network of Suns, and they
purchased this one machine to be the file server to the other Sun 3s and the
Sun 2.  If you were to gain access to one of the other machines, it's possible
you would have access to all of them.

Cisco is just a standard Cisco Router/Gateway box, linking that particular
network to the Internet.

Kauai is a messed up domain server, big deal.  It might work on the same
network as Astro and Lanai.

Dial is a Sun-3.  Is there something in a name?  This could be the
telecommunications dial-in for the network.  Maybe the same computer system has
a dialout attached to it.  It might even be possible that "dial" has a guest
account for people logging in so that they can easily connect to other
computers on the same network (probably not).

Astro and Lanai are also Sun 3 computers.  It isn't quite obvious what their
purpose is.  Essentially, we have the impression that they were all purchased
about the same time (explaining the large number of Sun-3 computers in this
network) and it is quite possible they are just linked up to the Sun 4 in a
file sharing network.  It is also possible they are older and fundamental to
the operation of Unisys's communication platform at this particular site.

There is one flaw that makes using the -h switch somewhat unreliable:
Sometimes people realize you can do this and take the time to remove or never
include the information about the individual machines on the network.
Therefore, it is always best for you to do a "ls <domain>" and check everything
out in case a computer has been removed.  Using "telnet" to connect to the
computer is usually a foolproof method of finding out what computer it is they
are talking about.

> ls mcl.unisys.com
Host or domain name             Internet address
 mcl.Unisys.COM                  server = kauai.mcl.unisys.com         3600
 kauai.mcl.unisys.com                   3600
 mcl.Unisys.COM                  server = burdvax.prc.unisys.com       3600
 burdvax.prc.unisys.com                 3600
 mcl.Unisys.COM                  server = kronos.nisd.cam.unisys.com   3600
 kronos.nisd.cam.unisys.com                   3600
 mcl.Unisys.COM                         43200
 maui.mcl.Unisys.COM                    43200
 cisco.mcl.Unisys.COM                  43200
 kauai.mcl.Unisys.COM                   3600
 voyager.mcl.Unisys.COM                43200
 dial.mcl.Unisys.COM                   43200
 LOCALHOST.mcl.Unisys.COM                     43200
 astro.mcl.Unisys.COM                   43200
 hotrod.mcl.Unisys.COM                43200
 oahu.mcl.Unisys.COM                    43200
 lanai.mcl.Unisys.COM                   43200
 mclean_is.mcl.Unisys.COM                 43200

Well, running down the list, it appears that there aren't any more computers
important to this domain that we don't know already.  LOCALHOST is just another
way of saying connect to where you are, so that isn't a big deal.  Hotrod being
separate from the rest of the machines seems apparent since its IP address is
x.x.x.125, which is quite separate from the others.  Even though this doesn't
have to be, it seems it is a wiring kludge -- probably for an office like I

The next step?  Go ahead and hack away!  This is where all those system hacks
people trade on the net and all those CERT Advisories become useful.  If you
become good hacking a single machine (Suns, for example), using nslookup will
help you identify those machines and make it easier for you to hack.

Looking for annex computers, libraries, guest machines, and other such
computers also becomes easy when you use nslookup, because the names and
computer types are there for your convenience.  Checking on sites by selecting
interesting "special purpose" machines with nslookup first can yield good
results.  People have called this "netrunning," and it sounds like as good a
name as any.

Of course, the other big problem when dealing with domain servers is trying to
identify them.  The largest list of domain servers can be found off of the
Department of Defense Network Listing (usually called hosts.txt) which is
available almost everywhere on the Internet through anonymous FTP.  Here is a
rundown on how to get the file:

[lycaeum][3]> ftp wuarchive.wustl.edu

220 wuarchive.wustl.edu FTP server (Version 6.24 Fri May 8 07:26:32 CDT 1992)
Remote host connected.
Username (wuarchive.wustl.edu:rack): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password (wuarchive.wustl.edu:anonymous):
230-  This is an experimental FTP server.  If your FTP client crashes or
230-  hangs shortly after login please try using a dash (-) as the first
230-  character of your password.  This will turn off the informational
230-  messages that may be confusing your FTP client.
230-  This system may be used 24 hours a day, 7 days a week.  The local
230-  time is Wed Jun  3 20:43:23 1992.
230-Please read the file README
230-  it was last modified on Mon Mar  2 08:29:25 1992 - 93 days ago
230-Please read the file README.NFS
230-  it was last modified on Thu Feb 20 13:15:32 1992 - 104 days ago
230 Guest login ok, access restrictions apply.

ftp> get /network_info/hosts.txt
200 PORT command successful.
150 Opening ASCII mode data connection for /network_info/hosts.txt (1088429 bytes).
226 Transfer complete.
Transferred 1109255 bytes in 182.95 seconds (6063.29 bytes/sec, 5.92 KB/s).

ftp> quit
221 Goodbye.

Now let's convert it to a file we can use effectively:  let's take out of that
huge list of only the machines that are domain servers:

[lycaeum][4]> grep -i domain hosts.txt > domains

Okay, now that we have done that, let's prove that this is a way of finding a
domain server without connecting to anyplace.  Let's just use the grep command
to search the file for a server in the mcl.unisys.com domain:

[lycaeum][5]> grep -i mcl.unisys.com domains

And there you have another way.  Everything we looked at is here: IP number,
the name, the "alias," the computer type, the operating system, and a brief
list of network protocols it supports, including the domain server attribute.
However, none of the other machines on the mcl.unisys.com network were
displayed.  The DoD isn't a complete list of network machines, only the network
machines that are vital to the functioning of the Internet (in the last year,
this list has grown from about 350K to 1.1 megabytes -- and this only reflects
the "new" networks, not including the addition of new machines onto old
networks; the Internet is definitely "in;"  I believe it was estimated 25%
growth per month!).

Obviously, this is very effective when going after university sites.  It seems
they have too many machines to take good care of security on.  Essentially, the
DoD list contains much the same information as NIC does, and is about a million
times more discreet.  I'm not sure if NIC is fully logged, but it does have a
staff Head of Security (*snicker*).

Well, that will pretty much wrap it up for this file.  Hope some of it was
useful for you.
[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]
© Copyleft 1985-2021, Phrack Magazine.