(this file can be get from http://hispahack.ccc.de)


                     SILENT CARRIERS AND LINK PROTOCOLS
                                      
                                                                By BadreL
   ______________________________________________________________________
   
   Introduction
   
   As we all know, "wardialing" is one of the best entertainments for
   hacking/phreaking lovers. Sometimes this activity makes us desperate
   due to the usual "login: password:" repetition that appears in nearly
   every CARRIER. It's also usual to find Carriers that present us with
   no message... just a "CONNECT xxxxx". These ones are usually very
   interesting as you will see in this document.
   
   We find many useful things, but we have always to confront a user name
   and password based authentification. Usually, we won't have a lot of
   information about which operating system runs that link, or what kind
   of machine are we in, since in nearly all cases, what your preferred
   wardialer screen displays is insufficient to determine it. So it would
   be a good idea to have more information about it.
   
   This document is not a "philosophal stone", nor gives the posibility
   to access the internet for free. Its purpose is to allow you to learn
   more about specific CARRIER types and to cover the steps you can
   follow in order to find out more about its features (link protocols
   that supports, authentication protocols used by the carrier or even
   network protocols supported by a determined connection). We will also
   describe some of these protocols and its treatment under LINUX.
   
   Specifically we will give enough explanations in order to find out if
   a link hides the PPP protocol (Point-to-Point Protocol), which
   supports several network layer protocols, not only IP (Internet
   Protocol) but also other from the OSI model, like IPX, and also from
   any others (AppleTalk, etc...). Before this link protocol was
   available, SLIP ("Serial Line Internet Protocol") was used to
   establish connections, but nowadays it's hardly used (although it is
   still used by some connections that we all know ;)). It has two main
   disadvantages with regard to PPP:
   
   a) The SLIP protocol misses a way to choose the network layer protocol
   to use in a connection, it only allows the use of the IP protocol.
   
   b) The SLIP protocolo doesn't allow authenticacion between the
   connected hosts; it just allows authentication through user and
   password. Therefore we can't be sure about the connected host
   identity.
   
   The PPP Link Protocol.
   
   Let's explain how the PPP link protocol works. You can find this in
   the RFC's, documents that specify the network protocols standards.
   
   1. INTRODUCTION.
   
   The PPP protocol consists of three main elements:
   
   a) A method to encapsule multiprotocol datagrams over the same link.
   
   b) A Link Control Protocol ("LCP") to establish, configure and check
   the data link.
   
   c) A Network Control Protocol family ("NCP") to establish and
   configure the different network layer protocols.
   
   From the preceding paragraph, data transmision between two hosts
   through PPP results in the following steps:
   
   a) PPP Link establishment and setup through the Link Control Protocol
   ("LCP").
   
   b) Network layer protocol establishment to use in the connection,
   through the NCP family.
   
   c) Encapsulation of the selected network protocol datagrams in link
   layer frames.
   
   2. PPP ENCAPSULATION.
   
   The PPP frame consists of three fields:
   
       Protocol Information Padding
       
   The PROTOCOL field consists of 1 or 2 bytes, and its value identifies
   the encapsuled datagram in the INFORMATION field of the frame. All the
   possible values must be odd numbers. Also all values must have the
   most significant byte less significant bit set to 1. Otherwise it will
   be considered as an unknown protocol. The values that can be found as
   protocols are the following, depending on the range:
   
   RANGE 0xxx-3xxx: Identifies specific packets from the network layer
   protocol... they can be the following:
   
       HEX VALUE PROTOCOL NAME
       0001 Padding Protocol
       0003 to 001f Reserved (transparency inefficient)
       0021 Internet Protocol
       0023 OSI Network Layer
       0025 Xerox NS IDP
       0027 DECnet Phase IV
       0029 Appletalk
       002b Novell IPX
       002d Van Jacobson Compressed TCP/IP
       002f Van Jacobson Uncompressed TCP/IP
       0031 Bridging PDU
       0033 Stream Protocol (ST-II)
       0035 Banyan Vines
       0037 Reserved (until 1993)
       0039 AppleTalk EDDP
       003b AppleTalk SmartBuffered
       003d Multi-Link
       003f NETBIOS Framing
       0041 Cisco Systems
       0043 Ascom Timeplex
       0045 Fujitsu Link Backup and Load Balancing (LBLB)
       0047 DCA Remote Lan
       0049 Serial Data Transport Protocol (PPP-SDTP)
       004b SNA over 802.2
       004d SNA
       004f IP6 Header Compression
       006f Stampede Bridging
       007d Reserved (Control Escape) [RFC1661]
       007f Reserved (compression inefficient) [RFC1662]
       00cf Reserved (PPP NLPID)
       00fb Compression on single link in multilink group
       00fd 1st choice compression
       00ff Reserved (compression inefficient)
       0201 802.1d Hello Packets
       0203 IBM Source Routing BPDU
       0205 DEC LANBridge100 Spanning Tree
       0231 Luxcom
       0233 Sigma Network Systems
       
   RANGE 4xxx-7xxx: Associated with low traffic volume protocols which
   haven't associated NCP.
   
   RANGE 8xxx-bxxx: Identifies frames belonging to the NCP family:
   
       HEX VALUE PROTOCOL NAME
       8001-801f Not Used - reserved [RFC1661]
       8021 Internet Protocol Control Protocol
       8023 OSI Network Layer Control Protocol
       8025 Xerox NS IDP Control Protocol
       8027 DECnet Phase IV Control Protocol
       8029 Appletalk Control Protocol
       802b Novell IPX Control Protocol
       802d Reserved
       802f Reserved
       8031 Bridging NCP
       8033 Stream Protocol Control Protocol
       8035 Banyan Vines Control Protocol
       8037 Reserved till 1993
       8039 Reserved
       803b Reserved
       803d Multi-Link Control Protocol
       803f NETBIOS Framing Control Protocol
       807d Not Used - reserved [RFC1661]
       8041 Cisco Systems Control Protocol
       8043 Ascom Timeplex
       8045 Fujitsu LBLB Control Protocol
       8047 DCA Remote Lan Network Control Protocol (RLNCP)
       8049 Serial Data Control Protocol (PPP-SDCP)
       804b SNA over 802.2 Control Protocol
       804d SNA Control Protocol
       804f IP6 Header Compression Control Protocol
       806f Stampede Bridging Control Protocol
       80cf Not Used - reserved [RFC1661]
       80fb Compression on single link in multilink group control
       80fd Compression Control Protocol
       80ff Not Used - reserved [RFC1661]
       
   RANGE cxxx-fxxx: It is used for the LCP frames (these are the most
   important ones... although it depends on the application ;)).
   
       HEXVALUE PROTOCOLNAME
       c021 Link Control Protocol (LCP)
       c023 Password Authentication Protocol (PAP)
       c025 Link Quality Report
       c027 Shiva Password Authentication Protocol (SPAP)
       c029 CallBack Control Protocol (CBCP)
       c081 Container Control Protocol
       c223 Challenge Handshake Authentication Protocol (CHAP)
       c281 Proprietary Authentication Protocol
       c26f Stampede Bridging Authorization Protocol
       c481 Proprietary Node ID Authentication Protocol
       
   The INFORMATION field length is specified by the Maximum Receiving
   Unit (MRU) option. And it is used to be 1500 bytes.
   
   3. CONNECTION ESTABLISHMENT.
   
   Let's see how does the PPP link works:
   
   The data transmission over a point to point link consists on that each
   line end continues sending LCP frames in order to configure and check
   the data link. The next image shows you the states transition which
   can be produced:
   
   Transition Graphic
   
   As we can see in the flow chart, before arriving at the network layer,
   i mean before the IP protocol negotiation (the most used) it is
   necessary to authenticate, and it is sure that in some carriers the
   remote host send an IPCP frame after failing to authenticate
   (obviously because we don't know the login/password ;)) trying to
   authenticate (this should not happen). This frame sends an 0.0.0.0 IP
   waiting for the host where the carrier is to start negotiating. After
   that frame the link is closed. It should be interesting to try to send
   another IP (not to check the "noipdefault" option but specicy the
   local IP). And... which local IP should we enter?. This is a bit
   difficult to know which local IP would be the correct, but it is not
   impossible... If we know any kind of information about the PPP server,
   auch as the server name (sometimes we can know this with the CHAP
   protocol as we will see below) or even with the information appearing
   in our screens... we can get into internet and search that word at
   http://www.ripe.net ("Database" section), GLIMPSE, you can specify a
   "seach by word" method in order to find details about a range or
   domain. una busqueda por palabras para encontrar detalles sobre un
   determinado range o dominio de ip's. This way knowing the relationship
   between the carrier an its domain (if exists) we can start playing ;).
   Some times we have carriers corresponding to INTRANETS which have no
   direct external access, but nowadays this is the best alternative so
   we can't forguet it ;).
   
   Relating to phases, the connection ESTABLISHMENT is based on the LCP
   frames trade untill two link points agree. This is an example:
   
   pppd[618]: sent [LCP ConfReq id=0x1 {mru 1500}]
   pppd[618]: rcvd [LCP ConfReq id=0x47 {mru 2052} {auth chap md5}]
   pppd[618]: sent [LCP ConfAck id=0x47 {mru 2052} {auth chap md5}]
   pppd[618]: rcvd [LCP ConfAck id=0x1 {mru 1500}]
   
   There are two CONFACK ("Configuration Acknowlegde") frames, one from
   the sender and the other from the receiver. From here we go to the
   authentication phase (if it exists); some carriers doesn't require
   authentication.
   
   Let's see what kind of frames can be sent at the connection
   establishment phase, because it is one of the most important parts in
   order to acquire information from a carrier to play :):
   
       CODE PACKET TYPE
       1 Configure-Request
       2 Configure-Ack
       3 Configure-Nak
       4 Configure-Reject
       5 Terminate-Request
       6 Terminate-Ack
       7 Code-Reject
       8 Protocol-Reject (*)
       9 Echo-Request (*)
       10 Echo-Reply (*)
       11 Discard-Request (*)
       12 Identification (*)
       13 Time-Remaining (*)
       
   The ones with a (*) are useful only for LCP. The others are useful
   also in the network layer negotiation, IPCP.
   
   And... How can we use all this?. It is very simple. We can make a scan
   with the carriers that we have found using the ppd demond from linux,
   which brings a lot of debug information, and even can be increased
   with the "kndebug n" option. With this information we can see the used
   AUTHENTICATION PROTOCOL, but it is clearly that the carrier must be
   based in the PPP link protocol. Also the authentication protocol
   doesn't need to be only one (it must have an order determined by the
   administrator that configured the carrier). Let's see an example on
   what we are commenting on:
   
   pppd[5491]: sent [LCP ConfReq id=0x1 {mru 1500}]
   pppd[5491]: rcvd [LCP ConfReq id=0x1 {mru 4542} {auth 0xc027 01 00 00
   03 00 00 00 0e}]
   pppd[5491]: sent [LCP ConfRej id=0x1 {auth 0xc027 01 00 00 03 00 00 00
   0e}]
   pppd[5491]: rcvd [LCP ConfAck id=0x1 {mru 1500}]
   pppd[5491]: rcvd [LCP ConfReq id=0x2 {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0x2 {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0x3 {mru 4542} {auth 0xc123 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0x3 {auth 0xc123 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0x4 {mru 4542} {auth chap md5}]
   pppd[5491]: sent [LCP ConfRej id=0x4 {auth chap md5}]
   pppd[5491]: rcvd [LCP ConfReq id=0x5 {mru 4542} {auth pap}]
   pppd[5491]: sent [LCP ConfRej id=0x5 {auth pap}]
   pppd[5491]: rcvd [LCP ConfReq id=0x6 {mru 4542} {auth pap}]
   pppd[5491]: sent [LCP ConfRej id=0x6 {auth pap}]
   pppd[5491]: sent [LCP ConfReq id=0x1 {mru 1500}]
   pppd[5491]: rcvd [LCP ConfReq id=0x7 {mru 4542} {auth 0xc027 01 00 00
   03 00 00 00 0e}]
   pppd[5491]: sent [LCP ConfRej id=0x7 {auth 0xc027 01 00 00 03 00 00 00
   0e}]
   pppd[5491]: rcvd [LCP ConfAck id=0x1 {mru 1500}]
   pppd[5491]: rcvd [LCP ConfReq id=0x8 {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0x8 {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0x9 {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0x9 {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0xa {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0xa {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0xb {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0xb {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0xc {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0xc {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP ConfReq id=0xd {mru 4542} {auth 0xc027 01 00 00
   02}]
   pppd[5491]: sent [LCP ConfRej id=0xd {auth 0xc027 01 00 00 02}]
   pppd[5491]: rcvd [LCP TermReq id=0x1 02]
   pppd[5491]: sent [LCP TermAck id=0x1]
   pppd[5491]: sent [LCP ConfReq id=0x1 {mru 1500}]
   last message repeated 2 times
   
   (*NOTE: We are taking information away about the frames which really
   would appear in order to make your reading more comfortable, here you
   have an example on how would appear the first frame:
   
   pppd[5491]: sent [LCP ConfReq id=0x1 {mru 1500} {asyncmap 0xa0000}
   {magic 0x1b40dc0b} {pcomp} {accomp}]
   
   If you want to know more about what the options listed means read the
   pages man ;)).
   
   In this trace we can see how configurations are traded. As they don't
   agree, the link is closed, but we have get enough information about
   the carrier. ******Let's explain what we have abobe which can frighten
   somebody X):******
   
   A default configuration is sent (specified at the pppd options file),
   with a 1500 MRU, and without an authentication protocol, the host in
   which the PPP server is installed answers with a {MRU 4542}
   configuration request (GUAU! it must be at least for ISDN minimo x))
   and a {auth 0xc027 01 00 00 03 00 00 00 0e} authentication, which is
   the SHIVA authentication protocol.
   
   Our host doen't "understand" the shiva protocol, or it isn't
   configured to, so it sends a ConfRej showing it doesn't accept the
   configuration, and it is stablished a new negotiation. In this case
   the server sends a ConfAck which corresponds with the first request;
   this can also be object of investigation, because if a configuration
   confirmation is done, it is possible that would be a way to prevent
   the authentication phase and arrive directly to the IPCP phase, but
   this probably will need a ppd client modify and this is more complex
   (NOTE: Just remind you that CISCO has detected a CHAP autentication
   protocol implementation failure that, according to them, with a
   certain knowledge on the protocol and making some changes on the pppd
   client we can obtain free access skipping the authentication ;).
   Details on this: March/31th/1998. I'm waiting anxious that moment ;).
   
   Ok... Let's continue: They continue trading negotiations and the
   server host continues changing the authentication until it takes the
   correct one. This way we can see all authentication protocols which
   are implemented in the server. Protocols used in the above example are
   (arranged):
   {auth 0xc027 01 00 00 03 00 00 00 0e} (SHIVA)
       {auth 0xc027 01 00 00 02} (SHIVA)
       {auth 0xc123 01 00 00 02} (?????)
       {auth chap md5} (CHAP MD5 - LINUX ALLOWS IT).
       {auth pap} (PAP - LINUX ALLOWS IT).
       
   The authentication protocol used by Infovia is PAP ("Password
   Autentification Protocol"); it is weaker than CHAP ("Challenge
   HandShake Auntentification Protocol"), and CHAP protocol can give us
   details on the machine we are handling as we will see :).
   
   CHAP Authentication Protocol.
   
   Let's describe how a CHAP authentication works and how can be
   configured under Linux:
   
   The CHAP authentication ("Challenge Handshake Autentification
   Protocol") is a local/remote host identification through a CLIENT NAME
   (our machine), SERVER NAME (the PPP server) and MESSAGE or PASSWORD
   asociated (It is a message which isn't encrypted in the chap-secrets
   configuration file). Authentication works this way:
   
   a) in order to authenticate the "peer" (I mean, our machine), a
   "secret" or "message" is searched for with CLIENT=name specified in
   the CHAP-Response frame and also with SERVER=local name.
   
   b) in order to authenticate the server, a secret is searched for with
   CLIENT=local name and SERVER=name specified in the CHAP-Challenge
   frame.
   
   Here we have an example on how to write the CHAP authentication file:
   # File /etc/ppp/chap-secrets
       # Client-Name        Server-Name
       Message                      IP
       CLIENT                 SERVER              "PASSWORD"
       x.x.x.x
       # end of file
       
   The IP field doens't need to be filled in the server, It is used to
   know if the CLIENT host has the correct assigned IP, and if It doesn't
   It is not allowed to get into the system. But it is possible that that
   field would be empty due to a dynamic IP configuration.
   
   By the way, we don't know the client's name that we must specify and
   which must be in the database (just like the typical "username") and
   also we don't know the message (the typical "password") and it is
   supposed that we don't know the server name... but here is the grace
   of this protocol:
   
   We can introduce as the NAME our LINUX machine's name, and a "*" as
   the SERVER, by doing this a CHAP-Challenge frame will come to us with
   the server name (WITHOUT ENCRYPTION!!!), and the associated message
   using an encryption algorithm through a hash MD5 code. So, if we put a
   file like this:
   # File /etc/ppp/chap-secrets
       # Client-Name                                   Server-Name
       Message                      IP
       MY_LINUX_MACHINE                 *                           GUEST
       # end of file
       
   It will send our Linux machine's name as the CLIENT name (just put
   darkstar, localhost... o whatever its name is, or even easier would be
   to put a '*') and it will give us the Server nama, and we would be
   able to know more things about what machine that supports the ppp
   server. Let's see an example on what i've commented:
   
   pppd[1056]: sent [LCP ConfAck id=0x4 {mru 4542} {asyncmap 0xa0000}
   {auth chap md5} {magic 0x9e3c186}]
   pppd[1056]: rcvd [CHAP Challenge id=0x1 {e77d1274}, name = "IBM8235"]
   pppd[1056]: sent [CHAP Response id=0x1{12089a928fde2519
   c9c0f0627d2f95bd}, name = "MY_LINUX_MACHINE"]
   pppd[1056]: rcvd [CHAP Failure id=0x1 ""]
   pppd[1056]: CHAP authentication failed
   
   Here we can see how the authentication attempt is done. After an
   agreement between the hosts is done in the LCP frames (CONFACK), the
   server name is received "IBM8235", and this is answered with the Linux
   machine name ("MY_LINUX_MACHINE"), the machine name can be obtained by
   consulting the next options:
   a) usehostname
       b) name
       c) local IP address specified with the host name
       d) if tou have not specified any of the above, it takes the
       machine's local name (/etc/hostname)
       
   >From this point it's time to start investigating... it's quite clear
   that IBM8235 isn't a very common name for a server, is it?. You start
   searching for info in the internet... (because i can guarantee you
   that it isn't the only one with that server name... there are more
   than ten and more than twenty...) and you find out that it is a
   "Remote Access Server" (nowadays a common one), that together with
   other SHIVA products (Lanrover, etc...) are the most used everywhere.
   All carriers where appears this:
   
   @Userid:
   Password
   
   are IBM8235 machines or similar. So now you know it, run your thc-scan
   and have a look at these ;). Be careful, they are not the only ones...
   there are also SILENT carriers (those in which appear nothing in the
   screen, just CONNECT or even those with "rubbish" that you don't know
   how to interpret... try all you can try... there could be a PAP, CHAP
   or similar under ;)).
   
   More information on this: http://www.shiva.com,
   http://www.networking.ibm.com.
   
   Sometimes these systems have default users, etc. although i can't
   guarantee you it ;). Any information on this topic would be
   appreciated.
   
   Here are some of the characteristics of these "little pots and
   pans"... let's see what is mounted out there.
   Information saved as "logfiles":
        User Name
            Login Date
            Logout Date
            Duration
            NAS Address
            NAS Port
            Bytes In
            Bytes Out
            PaksIn (Packets)
            PaksOut
       ODBC Accounting
        The Shiva AccessManager is shipped as standard with ODBC support.
            This will allow all reported accounting attributes to be
            exported in real time to an ODBC compliant database, such as
            Oracle or MS Access.
       Customer Set-Up and Customization
        The ODBC compliant database will need to be customized to accept
            the type of accounting data that is to be exported to it.
            Also, further customization of the database will be required
            to generate reports in the various formats that are needed by
            different organizations.
            The Shiva AccessManager allows different levels of accounting
            information to be reported to the ODBC database, depending on
            the requirements of a particular organization. There are
            three customer options as follows:
             1.Standard Call Accounting exports the following attributes
                 to the ODBC compliant database:
                  * User Name
                      * Login Date
                      * Logout Date
                      * Duration
                      * NAS Address
                      * NAS Port
                      * Bytes In
                      * Bytes Out
                      * PaksIn (Packets)
                      * PaksOut
                 2.Enhanced Call Accounting exports all the attributes
                 for option 1 in addition to the following:
                  IETF Attributes
                       * Acct Delay time(41)
                           * Acct Session ID (44)
                      Shiva Attributes
                       * Called Phone (1)
                           * Calling Phone (2)
                           * Customer ID (3)
                           * Type of Service (4)
                           * Link Speed (5)
                           * Links in Bundle (6)
                           * Link Protocol (8)
                           * Network protocol (9)
                           * Disconnect Reason (11)
                           * Server Switch (12)
                           * Function (14)
                      
                 3.Comprehensive Reports - exports all attributes for
                 options 1 and 2, plus the following IETF and Shiva
                 attributes supported by the Network Access Server:
                  * Acct Link Count
                      * Acct Multi Session Id
                      * Callback Id
                      * Callback Number
                      * Filter Id * Framed AppleTalk Link
                      * Framed AppleTalk * Framed AppleTalk Network Zone
                      * Framed Compression * Framed IP Address
                      * Framed IP Netmask * Framed IPX Network
                      * Framed MTU * Framed Route
                      * Framed Routing * Idle Timeout
                      * Login IP Host * Login LAT Group
                      * Login LAT Node * Login LAT Port
                      * Login LAT Service * Login Service
                      * Login TCP Port * NAS Identifier
                      * NAS Port Type * Port Limit
                      * Service Type * Session Timeout
       
   MICROSOFT CHAP Authentication Protocol.
   
   I must say that almost all carriers found ara mounted on the CHAP
   protocol from Microsoft ({AUTH MSOFT CHAP}), which detects Linux (pppd
   v2.2.0). We should investigate more on this protocol, because as all
   of us know, something that has developed Microsoft, shouldn't be very
   good ;). So, here is more feasible the idea of default users, although
   i have no information on this right now. Many times, after a CHAP
   MSOFT authentication comes a PAP one; it is very usual to find that,
   but the reality is that you can find a lot of things ;).
   
   More information I found on security related mailing-lists from
   ASCEND:
   
   The only difference between CHAP and MS-CHAP is that the "secret"
   isn't a string written by the user in Microsoft CHAP, but a derived
   one (using a hash code) from a string written by the user, and that
   the hash function is different.
   
   MS-CHAP makes a "hashing" with the user password using the DES or MD4
   encryption algorithm (it depends on the version) to convert it into a
   KEY value. This KEY value is stored in the NT Registry. CHAP-Challenge
   is encrypted using DES (and the key used for DES is that KEY value
   commented before); in order to generate the answer (CHAP-Response).
   
   It is not absolutely necessary for a cracker to have the user password
   to penetrate into a NT SERVER using MS-CHAP. All he/she needs is that
   KEY value which is allocated in the NT Registry. There is no way for a
   NT Server to know if the remote host started with the original user
   password or if it was a "stolen copy" from the KEY value. The only
   thing that worries to NT is the result of making a hashing with DES
   using the "Challenge" and the KEY value.
   
   If you think that DES and MD5 are equally acceptable, then MS-CHAP and
   CHAP are identical at security level untill this point.
   
   I must mention that there is an utility called "PWDUMP" or similar
   which is able to reveal the NT Registry contents. If this includes the
   hashed user passwords (what we have called KEY value), then something
   is wrong here -;).
   
   MS-CHAP also offers you the possibility for a user to change his/her
   password after authentication. If a cracker stoles one of these KEY
   velues and uses this utility to change the key value (knowing the
   original password), then he/she would be able to authenticate
   him/herself with a NT Syetem in order to have a complete access.
   
   Well, this is all the information i've found on this matter, if you
   find more information that would be interesting, write me ;).
   
   Wardialing under LINUX?.
   
   How can we scan under linux?
   
   Well, for those of you with no idea on shell scripting, here is a sort
   of wardialer for linux. It is not exactly a wardialer, but it works
   :). Feel free to improve this program, it is not very difficult ;). It
   is quite naff. The script is prepared to take a file (CARRIERS.LOG...
   yes! from THC-SCAN... the best!) and it extracts the 900 telephone
   numbers (free numbers here in Spain) found in the file and starts
   calling with a varied number of options quite easy:
   
(get the script from http://hispahack.ccc.de)
 ->   Script for Wardialing under LINUX.
                        ____________________________
   
   ______________________________________________________________________
   
   Thanks go to...
   
   Agradecer la colaboracion de LeC para realizar este documento, a el y
   su grupo por dar espacio en su web, a Syn que un dia me dijo "RTFM!"
   -;), y a aquellos que me aguantan dia a dia (|fit0|, BillSuCks,
   Case_Zer0, Darkcode, |Akrata|, Graffic, Necronoid...y los que se me
   olvidan siempre...;).
   
   For any criticism, doubts or suggestions you can write me here:
   badrelill0@hotmail.com
