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.

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:

Script for Wardialing under LINUX.

Some places to visit...

RFC's Index.

Information on the IBM8235.

SHIVA Products.

Informacion on registered domains, RIPE.


For any criticism, doubts or suggestions you can write me here:
badrelill0@hotmail.com


 
 
 

(C) 1997-2001 by !Hispahack
Para ver el web en las mejores condiciones, usa una resolución de 800x600 y Netscape Navigator