CARRIERS SILENCIOSAS Y PROTOCOLOS DE ENLACE
By BadreL
Introduccion
Como todos sabemos, el "wardialing" es una de las diversiones mas usadas por cualquier amante del hacking/phreaking. Ahora bien, esta actividad muchas veces lleva a la desesperacion, debido sobre todo a la repeticion de los ya habituales "login: password:" que suelen aparecer en cualquier CARRIER comun. Tambien aparecen en muchas ocasiones Carriers que no dan ningun mensaje, unicamente aparece "CONNECT xxxxx". Estas suelen ser muy interesantes, como podreis comprobar a lo largo del documento. Se han encontrado muchas cosas, y de mucha variedad, pero siempre nos hemos encontrado con una autentificacion mediante un nombre de usuario y un password. Por lo general no se suele tener mucha informacion acerca de que sistema operativo mantiene dicho enlace, o que tipo de maquina, ya que en la mayoria de los casos los datos que aparecen en la pantalla de tu wardialer habitual no son suficientes para determinarlo. Y no seria mala idea tener algo mas de informacion al respecto.
Este documento no es ninguna "piedra filosofal", ni da la posibilidad de tener acceso a internet gratuito. Su intencion es que se conozca un poco mas determinados tipos de CARRIERS y el tratamiento que se puede hacer para averiguar algo mas acerca de sus caracteristicas (protocolos de enlace que puede esconder, protocolos de autentificacion que pueda usar, o protocolos de red a los que pueda dar soporte una conexion determinada). Tambien se describiran algunos de estos protocolos y su tratamiento en, como no, LINUX.
Concretamente se daran explicaciones suficientes para averiguar si un
enlace esconde tras de si el protocolo de enlace PPP (Point-to-Point
Protocol), que da soporte a varios protocolos de la capa de red, no
solo IP (Internet Protocol) sino tambien otros protocolos del modelo
OSI, como IPX, ademas de muchos otros (AppleTalk, etc...). Previo a
este protocolo de enlace siempre se han usado conexiones mediante el
protocolo SLIP ("Serial Line Internet Protocol"), pero este tiene ya
muy poco uso en la actualidad si bien se sigue usando en algunas
conexiones que todos conocemos ;). Tiene dos desventajas principales
respecto a PPP:
a) El protocolo SLIP no dispone de ningun metodo para informar acerca del protocolo de red a utilizar en la conexion, permitiendose unicamente el empleo del protocolo IP.
b) El protocolo SLIP no permite la autentificacion entre los hosts conectados, solo permite una autentificacion mediante usuario y password. Por lo tanto no se tiene certeza sobre la identidad del host con el que conectamos.
El protocolo de enlace PPP.
Pasemos a explicar la teoria sobre como funciona el protocolo de enlace PPP, lo cual se puede encontrar en los RFC's, documentos que especifican los estandares sobre protocolos de red:
1. INTRODUCCION.
El protocolo PPP consta de tres elementos principales:
a) Un metodo para encapsular datagramas multiprotocolo sobre el mismo enlace.
b) Un protocolo de control de enlace (LCP, "Link Control Protocol") para establecer, configurar y comprobar la conexion del enlace de datos.
c) Una familia de protocolos control de red ("NCP, "Network
Control Protocol") para establecer y configurar diferentes protocolos
de la capa de red.
A partir de lo anterior, la transmision de datos entre dos hosts mediante el protocolo PPP conlleva los siguientes pasos:
a) Establecimiento y configuracion del enlace PPP mediante el protocolo de control de enlace LCP.
b) Establecimiento del protocolo de la capa de red a usar en la conexion, mediante la familia NCP.
c) Encapsulado en tramas de la capa de enlace de los datagramas correspondientes al protocolo de red seleccionado.
2. ENCAPSULADO PPP.
La trama PPP consta de tres campos:
------------------------------------- | | | | | Protocolo | Informacion | Relleno | | | | | -------------------------------------
El campo PROTOCOLO consta de 1 o 2 bytes, y su valor identifica el datagrama encapsulado en el campo informacion de la trama. Todos los posibles valores deben ser impares. Ademas todos los valores deben tener el bit menos significativo del byte mas significativo igual a 1. Otra cosa sera considerada como protocolo desconocido. Respecto a los valores que se pueden encontrar del protocolo son los siguientes, en funcion del rango:
RANGO 0xxx-3xxx: Identifica el protocolo de la capa de red de paquetes especificos y pueden ser los siguientes:
Valor (en hex) Nombre del Protocolo
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
RANGO 4xxx-7xxx: Se asocia a protocolos con bajo volumen de trafico que no tienen NCP asociados.
RANGO 8xxx-bxxx: Identifica tramas pertenecientes a la familia NCP:
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 006f 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]
RANGO cxxx-fxxx: Se usa para tramas LCP (estos son los mas importantes... aunque dependiendo de la aplicacion ;)).
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
El campo INFORMACION tiene una longitud especificada con la opcion MRU (Unidad de recepcion maxima) y suele ser de 1500 bytes.
3. ESTABLECIMIENTO DE LA CONEXION.
Veamos como se produce un enlace PPP:
La transmision de datos sobre un enlace punto a punto consiste en que cada extremo de la linea vaya enviando tramas LCP para configurar y comprobar el enlace de datos. El grafo que especifica las transiciones de estado que se pueden producir lo teneis a continuacion:
Como vemos en el dibujo, antes de que se llegue a la capa de red, es decir a la negociacion del protocolo IP (lo mas usado), es necesario autentificar, si bien hay ciertos carriers en los que tras no poder autentificar el enlace (porque no sabemos el login/password, evidentemente ;)) el host remoto envia una trama IPCP, intentando hacerlo, cosa que no deberia ocurrir. Esta trama manda una ip 0.0.0.0 esperando que el host donde se encuentra el carrier comience la negociacion. Tras esa trama el enlace se cierra. Aun asi, esto podria ser interesante, y probar a mandar otra IP (no poner la opcion "noipdefault", sino especificar la ip local). Y que ip local ponemos? Esto es algo dificil de averiguar, pero no imposible...Si tenemos cualquier tipo de informacion sobre el servidor PPP, tal como el nombre del servidor, (cosa que podemos averiguar a veces con el protocolo CHAP como veremos luego) o alguna informacion que salga por pantalla, podemos ir a internet y hacer una busqueda en http://www.ripe.net, en la seccion "Database", GLIMPSE, se puede especificar una busqueda por palabras para encontrar detalles sobre un determinado rango o dominio de ip's. Asi, teniendo una relacion entre el carrier en cuestion y su dominio en internet (si lo tiene) se puede empezar a juguetear ;). En muchos casos se tienen carriers correspondientes a INTRANETS, que no tienen acceso directo al exterior, pero que aun asi se ve que es una de las alternativas de mas futuro para una empresa en la actualidad y no han de olvidarse ;).
En cuanto a las fases, decir que el ESTABLECIMIENTO de la conexion se basa en el intercambio de tramas LCP hasta que se llega a un acuerdo total entre los dos puntos del enlace. Este es un ejemplo:
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}]
Hay dos tramas CONFACK (Configuration Acknowlegde), una por parte del emisor y otra por parte del receptor. A partir de aqui se pasa a la fase de autentificacion, suponiendo que exista, ya que existen algunos carriers que no exigen autentificacion. Siempre hubo administradores digamos...despistados ;).
Veamos que tipo de tramas se pueden enviar en la fase de establecimiento de la conexion, ya que es una de las partes mas importantes acerca de la informacion que podemos extraer de un carrier sobre el que no teneniamos ni un solo dato con el que juguetear :):
Codigo Packet Type ------ ----------- 1 Configure-Request : Solicitud de Configuracion. 2 Configure-Ack: Confirmacion de Configuracion. 3 Configure-Nak: Confirmacion negativa de Configuracion. 4 Configure-Reject: Rechazo de Configuracion. 5 Terminate-Request: Solicitud de Terminacion. 6 Terminate-Ack: Confimacion de Terminacion. 7 Code-Reject: Rechazo de Codigo. 8 * Protocol-Reject: Rechazo de Protocolo. 9 * Echo-Request: Solicitud de Eco. 10 * Echo-Reply: Respuesta de Eco. 11 * Discard-Request: Solicitud de Rechazo. 12 * Identification: Identificador. 13 * Time-Remaining: Tiempo que queda para que se cierre.
Los que tienen * sirven solo para LCP. Los demas sirven tambien en la negociacion de la capa de red, IPCP.
Para que nos sirve todo esto? La cosa es bien sencilla. Podemos hacer un escaneo con los carriers que hayamos encontrado haciendo uso del demonio pppd de linux, que trae mucha informacion de depuracion, y que incluso se puede aumentar con la opcion "kdebug n". En esta informacion se puede ver el PROTOCOLO DE AUTENTIFICACION usado, en caso claro esta, de que el carrier se base en el protocolo de enlace PPP. Ademas el protocolo de autentificacion no tiene porque ser unico, teniendo un orden determinado por el administrador que haya configurado el carrier. Veamos un ejemplo de lo que se esta comentando:
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
(*NOTA: Estamos quitando informacion acerca de las tramas que realmente saldrian
por comodidad en la lectura, pero por ejemplo la primera trama tendria el
siguiente aspecto:
pppd[5491]: sent [LCP ConfReq id=0x1 {mru 1500} {asyncmap 0xa0000}
{magic 0x1b40dc0b} {pcomp} {accomp}]
Para saber mas acerca de que significan esas opciones estan las paginas
man ;)).
En esta traza vemos como se van intercambiando configuraciones. No se llega a un acuerdo por las dos partes, con lo cual se cierra el enlace, pero hemos conseguido bastante informacion acerca del carrier en si. Explicamos esto que tenemos aqui arriba que tanto puede asustar X):
Se manda una configuracion por defecto (especificada en el fichero de
opciones de pppd), con un MRU de 1500, y sin protocolo de autentificacion, a
lo que el host donde esta instalado el servidor PPP responde con una solicitud
de configuracion de {MRU 4542} (guau! debe ser para ISDN minimo x)) y una
autentificacion {auth 0xc027 01 00 00 03 00 00 00 0e}, que es el protocolo de
autentificacion SHIVA.
Nuestro host no "entiende" el protocolo shiva, o no esta configurado para ello, con lo cual manda un ConfRej indicando que no admite la configuracion, y se vuelve a establecer una nueva negociacion. En este caso el servidor manda un ConfAck que se corresponde con la primera solicitud, esto tambien puede ser objeto de investigacion, ya que si se hace una confirmacion de configuracion puede que haya algun modo de evitar la fase de autentificacion y llegar directamente a la fase IPCP, pero esto posiblemente necesitaria de una modificacion del cliente pppd, cosa algo mas compleja (NOTA: Recordar a los presentes que CISCO ha detectado un fallo en su implementacion de su protocolo de autentificacion CHAP que, segun ellos, con cierto conocimiento del protocolo y haciendo cambios en el cliente pppd se puede obtener el acceso saltandose por el morro la autentificacion ;). Detalles de esto: 31 de Marzo de 1998. Espero con ansiedad ese momento ;).
Bueno...sigamos: Se siguen intercambiando negociaciones, y el host servidor va cambiando de autentificacion hasta intentar dar con la correcta. ASi podemos ver todas los protocolos de autentificacion que hay implementados en el servidor. Asi pues, en este ejemplo anterior los protocolos usados son, por este orden:
{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 LO ADMITE).
{auth pap} (PAP - LINUX LO ADMITE).
El protocolo de autentificacion que se usa por ejemplo en Infovia es PAP (Password Autentification Protocol), y es muy debil en comparacion con CHAP (Challenge HandShake Auntentification Protocol), si bien el protocolo CHAP nos puede dar detalles sobre la maquina que estamos tratando como veremos a continuacion ;).EL Protocolo de autentificacion CHAP.
Una vez visto el modo en el que podemos saber la autentificacion que un determinado servidor usa, vamos a describir en que consiste una autentificacion CHAP y como se puede configurar en linux:
La autentificacion CHAP (Challenge Handshake Autentification Protocol) consiste en una identificacion de los hosts local y remoto mediante un NOMBRE DE CLIENTE (nuestra maquina), NOMBRE DE SERVIDOR (el servidor PPP en cuestion) y MENSAJE o PASSWORD asociado (Es un mensaje que no esta encriptado en el fichero de configuracion chap-secrets). La autentificacion funciona del siguiente modo:
a) para autentificar el "peer" (es decir, nuestra maquina), se busca un "secreto" o "mensaje" con CLIENTE=name especificado en la trama CHAP-Response y con SERVIDOR=local name.
b) para autentificar el servidor, se busca un secreto con CLIENTE=local name y SERVIDOR=name especificado en la trama CHAP-Challenge.
ASi pues, un ejemplo de como construir el fichero de autentificacion CHAP seria:
# Fichero /etc/ppp/chap-secrets # Nombre-Cliente Nombre-Servidor Mensaje IP CLIENTE SERVIDOR "PASSWORD" x.x.x.x # fin del fichero
El campo IP no tiene porque estar relleno en el servidor, sirve para ver si el host CLIENTE tiene la ip asignada correcta, y sino, no se permite la entrada al sistema. Pero es muy posible que ese campo este vacio debido a que se haga una configuracion de ip's dinamicas.
Ahora bien, nosotros no sabemos el nombre del cliente que debemos
especificar que este en la base de datos (algo asi como el tipico
"username") ni tampoco sabemos el mensaje ("el tipico password") y se supone
que tampoco sabemos el nombre del servidor...Pero aqui esta la gracia de
este protocolo:
Podemos poner como nombre del cliente el nombre de nuestra maquina LINUX, y poner un '*' en SERVIDOR, esto hace que nos llegue una trama CHAP-Challenge con el nombre del servidor (SIN ENCRIPTAR!!!), y el mensaje asociado usando el algoritmo de encriptacion mediante un codigo hash MD5. Asi pues, si ponemos un fichero como el siguiente:
# Fichero /etc/ppp/chap-secrets # Nombre-Cliente Nombre-Servidor Mensaje IP MI_MAKINA_LINUX * GUEST # fin de fichero
Mandara como nombre del CLIENTE el nombre de nuestra maquina Linux (poneis darkstar, localhost...o como se llame, o mas facil aun, poned '*') y nos dara el nombre del Servidor, con lo que podemos saber ya muchas cosas sobre que maquina soporta el servidor ppp. Asi pues, veamos un ejemplo de lo que he comentado:
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 = "MI_MAKINA_LINUX"]
pppd[1056]: rcvd [CHAP Failure id=0x1 ""]
pppd[1056]: CHAP authentication failed
Aqui podemos ver como se produce el intento de autentificacion. Tras llegar a un acuerdo entre los hosts en las tramas LCP (CONFACK) se recibe el nombre del servidor "IBM8235", a lo que se contesta con el nombre de la maquina LINUX (pongamos "MI_MAKINA_LINUX"), el nombre de la maquina se obtiene consultando el valor de las siguientes opciones:
a) usehostname b) name c) direccion IP local especificada con el nombre del host. d) en caso de que no se haya especificado ninguna de las anteriores se toma como nombre el nombre local de la maquina (/etc/hostname).
Claro...a partir de aqui uno empieza a hacer sus indagaciones...ya que IBM8235 no es un nombre muy comun que uno hubiera pensado para un servidor, verdad? Empiezas a buscar informacion por internet...(porque os puedo asegurar que no es el unico que tiene ese nombre de servidor, sino que juraria que hay mas de 10 y mas de 20...) y te encuentras con que es un "Remote Access Server" de lo mas usado en la actualidad, que junto con otros productos de la empresa SHIVA (Lanrover, etc...) son al parecer lo que se usa por todos lados. Todos los carriers donde aparece lo siguiente: @Userid: Password son maquinas IBM8235 o similares. Asi que ya sabeis, poned vuestro thc-scan a currar y echad un vistazo a estos ;). Ojo. No son los unicos, puede que los carriers SILENCIOSOS (aquellos en los que no sale nada por pantalla, solo CONNECT, o incluso aquellos en los que sale "basura" que no se sabe lo que es...probad en todos los que podais, por debajo siempre puede haber un PAP, CHAP...o similar. Investigad ;)). Para mas informacion, http://www.shiva.com, http://www.networking.ibm.com.
Y claro, hay ocasiones en los que estos sistemas tienen usuarios por defecto, y cosas por el estilo, ... aunque no os lo puedo asegurar ;). Cualquier informacion al respecto sera recibida con gusto.
A continuacion os dejo algunas de las caracteristicas de estos "cacharritos" para que os hagais una idea de lo que hay por ahi montado... Informacion que se guarda en los "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 TimeoutEl protocolo de autentificacion MICROSOFT CHAP.
En este apartado, decir que la mayoria de los carriers que se encuentran
estan montados sobre el protocolo CHAP de Microsoft ({AUTH MSOFT CHAP}), el
cual detecta Linux (version pppd 2.2.0). Habra que investigar mas sobre este
protocolo, porque como todos sabemos, lo que sea de Microsoft muy bueno no
puede ser ;). Aparte de que aqui si puede ser mas factible que existan usuarios
por defecto, aunque por ahora no tengo mas informacion al respecto. Muchas
veces tras una autentificacion CHAP MSOFT le sigue una PAP, es muy tipico
encontrarlo, pero la verdad es que te puedes encontrar muchas cosas ;).
Algunos datos mas que encontre en "mailing-lists" de seguridad de ASCEND:
"La unica diferencia entre CHAP y MS-CHAP es que el "secreto" en Microsoft CHAP
no es una cadena escrita por el usuario en si, sino otra derivada (mediante
un codigo hash) de una cadena escrita por el usuario, y que la funcion hash
que se usa es diferente.
MS-CHAP hace un "hashing" del password de usuario mediante el algoritmo de
encriptacion DES o MD4 (dependiendo de la version) para convertirlo en un
valor CLAVE. Este valor CLAVE es el que se almacena en el registro NT ("NT
Registry"). Se encripta el CHAP-Challenge usando DES (siendo la clave usada
para DES el valor CLAVE comentado) para generar la respuesta. (CHAP-Response).
Para un cracker no es absolutamente necesario tener el password del usuario
para penetrar en un NT SERVER que use MS-CHAP. Todo lo que necesita es ese
valor CLAVE que esta almacenado convenientemente en el Registro NT. No hay modo
alguno de que un NT SERVER sepa si el host remoto comenzo con el password del
usuario original o si tenia una "copia robada" del valor CLAVE y se salto el
primer paso por el morro. Todo lo que le preocupa es el resultado de hacer
un hashing mediante DES usando el "Challenge" y el valor CLAVE.
Si consideras que DES y MD5 son igualmente aceptables, entonces MS-CHAP y CHAP
son identicos a nivel de seguridad, al menos hasta este punto.
Aun asi, comentar que hay una utilidad al parecer llamada "PWDUMP" o similar
que es capaz de desvelar el contenido del Registro NT. Si esto incluye los
password de usuario "hasheados" (lo que hemos llamado valor CLAVE), entonces
aqui algo falla -;).
MS-CHAP tambien ofrece la habilidad para un usuario de cambiar su password una
vez autentificado. Si un cracker roba uno de estos valores CLAVE y usa esta
utilidad para cambiar el valor clave para el que conoce el password original,
entonces puede ser capaz de autentificarse a un Sistema NT para un acceso
completo."
Bueno, esta es la informacion encontrada hasta ahora al respecto, si encontrais
algo mas que pueda ser interesante, no dudeis en escribir y contarmelo ;).
Haciendo Wardialing en LINUX?.
Como hacemos para no morirnos intentando "escanear" en linux?
Bueno, para los que no tengais mucha idea de shell script, aqui os dejo una especie de "wardialer" para linux. No es exactamente eso, pero hace el apaño :). Quien lo quiera mejorar, que lo haga, no es dificil ;).Es bastante cutre. El script esta preparado para coger un fichero CARRIERS.LOG (sisi...del THC-SCAN, evidentemente ...el mejor :)) y a partir de ahi, el solito extrae los numeros 900 encontrados en el fichero y se pone a llamar, con varias opciones bastante intuitivas:
Script para realizar "wardialing" en Linux.
Algunos sitios que visitar...
Indice de RFC's mediante busqueda. Pagina para mas info sobre IBM8235 Productos SHIVA Informacion sobre dominios registrados, RIPE.
Agradecimientos: 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...;). Para cualquier critica, duda o sugerencia, e incluso informaciones que puedan ser de interes, aqui teneis:badrelill0@hotmail.com
Para ver el web en las mejores condiciones, usa una resolución de 800x600 y Netscape Navigator