Serie Raw NXC Protocolos y Servicios TCP-UDP

Pgina 16 PC PASO A PASO N 11
0. Introduccin
Toda la existencia de la serie RAW se remonta
a hace ya un ao, cuando escriba por
amor al arte en lugar de hacerlo para ninguna
revista. Por aquel entonces escriba una
serie de tutoriales sobre tcnicas concretas
de hacking, algunos de los cuales podis
bajar directamente del foro de la revista en
www.hackxcrack.com. Un buen da,
me dispona a redactar un tutorial sobre
FTP Bounce, una tcnica que bsicamente
consi ste en uti l i zar un servi dor FTP
ajeno como puente para realizar conexiones
annimas a cualquier otra mquina,
cuando me di cuenta de que para poder
escribirlo tena que dar por hecho que los
l ectores conoc an el protocol o FTP
en profundidad, as como otros protocolos.
Viendo que el tema iba a ser demasiado
avanzado si no se conocan los conceptos
previ os, deci d comenzar una nueva
serie que tratase sobre protocolos, entre los
cuales incluira, por supuesto, el FTP.
Casualmente, me encontr entonces con
la revista, y fue as como naci la serie
RAW. :-)
Asi que, sin ms prembulos, voy al fin a
redactar el artculo que me llev a todo esto.
Para ello empezar detallando el funcionamiento
del protocolo, para luego explicar una serie de
tcnicas para explotar los problemas de
seguridad del mismo.
1. EL PROTOCOLO FTP
1. 1. Mecni smo bsi co del FTP
Si buscamos el trmino FTP en la base de
datos de RFCs (www. rfc-edi tor. org),
encontraremos una lista bastante extensa de
documentos que tratan directa o indirectamente
sobre este protocolo. Y no nos debera extraar
mucho, si nos fijamos en que el RFC 114
(ftp://ftp.rfc-editor.org/in-notes/rfc114.txt), donde
se encuentra la primera definicin del protocolo,
se remonta nada menos que al ao 1971!!
Desde luego, poco tiene que ver ese primer
protocolo de transferencia de archivos (File
Transfer Protocol) con el que utilizamos
actualmente, pero esto no deja de ser una
prueba de la necesidad e importancia de este
protocolo.
El RFC actual de FTP (ya que el 114 est ms
que obsoleto) es el RFC 959 (ftp://ftp.rfc-
editor.org/in-notes/rfc959.txt).
Entre la maraa de RFCs que tratan directa o
indirectamente sobre FTP, podramos hablar al
menos de 2 interesantes. El RFC 2577
(ftp://ftp.rfc-editor.org/in-notes/rfc2577.txt) nos
habla de algunos de los problemas de
seguridad del protocolo FTP, aunque de eso
ya os hablar yo con mucho ms detalle en
este artculo ;-). El RFC 2228 (ftp://ftp.rfc-
editor.org/in-notes/rfc2228.txt) nos habla de una
Por fin tenemos ante nosotros la primera parte de la SERIE RAW dedicada al PROTOCOLO
FTP. Vamos a hablar con un Servidor FTP de TU a TU -- Sin mediadores --
SERIE RAW: ENTENDIENDO LOS
PROTOCOLOS Y SU SEGURIDAD
RAW 5 : FTP (File Transfer Protocol)
PRIMERA PARTE
PC PASO A PASO N 11 Pgina 17
extensin con comandos adicionales para
hacer el protocolo ms seguro, aunque yo
personalmente no me he encontrado con ningn
servi dor FTP que l os i mpl emente :-).
Para aquellos a los que ni siquiera les suene
lo que es el FTP, lo resumo diciendo que es un
protocolo que permite que un usuario remoto
se conecte al disco duro de una mquina para
poder ver, bajar, y subir archivos al mismo. Por
supuesto, el administrador del servidor FTP
ser el que decida qu usuarios pueden bajar,
subir, y ver qu archivos.
1.1.1. Comandos FTP de alto nivel
El protocolo FTP se parece al IRC en el sentido
de que existe una capa de comandos por
encima de la capa raw, que es la que se utiliza
cuando conectamos a un servidor mediante
un cliente en consola (ventana MS-DOS o shell
de *NIX). El objetivo de este artculo es hablar
de la capa raw, por lo que har slo una pasada
rpida por los comandos de alto nivel.
Vamos a verlo todo con un ejemplo prctico.
Empezaremos abriendo una consola, es decir,
una ventana MS-DOS en Windows, o una shell
en Linux/Unix (si no sabes abrir una Ventana
de Comandos, lee los nmeros anteriores y/o
p r e g u n t a e n n u e s t r o f o r o - - >
www.hackxcrack.com).
Ahora vamos a conectar con un servidor FTP
clsico, que es el de Rediris. Para ello escribimos:
ftp ftp.rediris.es
Como vemos, nos aparece un texto de
bienvenida, y a continuacin nos pide el nombre
de usuario:
Name (ftp.rediris.es:pyc):
Como nos dice en el mensaje de bienvenida,
este servidor slo admite usuarios annimos.
Para entrar como usuario annimo, el nombre
de usuario que debemos utilizar es anonymous,
y como password podemos poner cualquier
cosa:
Name (ftp.rediris.es:pyc): anonymous
...
331 Any password will work
Password: a
Tras introducir el nombre de usuario y el
password, ya estamos dentro. A partir de ahora
podemos empezar a lanzar comandos para ver,
Serie Raw - Protocolo FTP - Serie Raw - Protocolo FTP - Serie Raw - Protocolo FTP
Ya hemos hablado...
Ya hemos hablado en anteriores nmeros sobre qu son
los RFC, si deseas ms informacin te recomendamos que
visites http://www.rfc-es.org/
En esta WEB, multidud de colaboradores estn traduciendo
al espaol los RFC. Tienes ya muchos a tu disposicin :)
!
En nuestra Web...
En nuestra WEB (www.hackxcrack.com), nada mas entrar, tienes
el enlace al Nmero 1 de esta publicacin. Descargars de forma
totalmente gratuita la revista en formato PDF donde se explican
bastantes cosas sobre los Servidores FTP y los Clientes FTP
!
subir, y bajar los archivos.
Empezaremos viendo qu archivos y directorios
hay en donde nos encontramos ahora mismo.
Para ello escribimos:
dir
Como vemos, nos muestra los archivos con el
mismo formato que un ls -la de Linux/Unix.
Podis repasar los artculos sobre Linux de
nmeros anteriores de la revista si no os aclaris
con este listado.
De momento nos interesa el directorio pub,
porque ah es donde tpicamente se encontrarn
los archivos disponibles para el pblico. As
que hacemos:
cd pub
Una vez en el directorio pub hacemos de nuevo:
dir
Y vemos que hay un directorio linux. Nos
metemos ah con:
cd linux
Hacemos un nuevo dir y vemos un directorio
distributions:
cd distributions
Ya estamos aqu, pero hemos empleado tanto
en comando cd que ya ni sabemos donde
estamos. Si escribimos ahora:
pwd
Nos dir en qu directorio nos encontramos en
estos momentos:
257 "/pub/linux/distributions" is your
current location
Queremos bajarnos la distribucin de Linux de
RedHat, as que buscamos su directorio, pero...
ojo! Como podemos ver, se trata de un link:
lrwxrwxrwx 1 infoadmi infoadmi 22
F e b 2 2 2 0 0 2 r e d h a t - >
../../../mirror/redhat
Por lo que si ahora hacemos:
cd redhat
Si a continuacin escribimos:
pwd
Nos responder lo siguiente:
257 "/mirror/redhat" is your current
location
Ya que hemos hecho un salto directo hasta ese
directorio en lugar de habernos movido paso
a paso con varios comandos cd.
Unos cuantos movimientos mas:
cd redhat
cd redhat-9-en
cd iso
cd i386
Y, tal y como vemos con un dir, ya hemos
llegado donde estn las imgenes ISO de los
3 CDs de Red Hat 9.0.
Vamos a bajarnos el primer CD, para lo cual
vamos a empezar por indicarle a nuestro cliente
de FTP que nos muestre el progreso del
download. Para ello escribimos:
hash
Si no hicisemos esto, mientras se bajasen los
cientos de megas que ocupa cada ISO nuestra
consola no mostrara ningn tipo de mensaje,
por lo que no podramos saber si se nos ha
colgado o si sigue bajando todava. La respuesta
ante ese comando:
Hash mark printing on (1024 bytes/hash
mark).
Nos dice que nos mostrar una marca cada
vez que mueva 1024 bytes, es decir, 1KB.
Otro paso importante es decirle a nuestro
cliente que los datos que vamos a bajar no
son texto, si no un archivo binario. Para ello
escribimos:
bin
En realidad este comando no suele ser
necesario, ya que se suele configurar
automticamente, pero nunca est de ms
i ndi carl o expl ci tamente para evi tar
desagradables sorpresas despus de varias
horas de download.
Una vez completados estos 2 pasos previos,
ya slo basta que hagamos:
get shrike-i386-disc1.iso
Y comenzar el download del primer CD deRed
Hat 9. :-)
local: shrike-i386-disc1.iso remote: shrike-
i386-disc1.iso
227 E nt e r i ng Pa s s i v e Mo de
(130,206,1,5,127,9)
150- Accept ed dat a connect i on
150 653312.0 kbytes to download
########################
########################
########################
########################
########################
########################
#######
Todos esos caracteres # son las marcas de 1KB
que activamos previamente con el comando
hash.
Una vez terminados nuestros downloads,
podemos cerrar la sesin con el comando:
bye
1.1.2. Cmo se transfieren los datos
Qu es lo que hacen el cliente y el servidor
de ftp cuando ejecutamos un comando
get (o un comando put, que es el equivalente
a get pero para subir archivos en lugar de
bajar)?
Cuando nos conectamos a un servidor
de FTP lo que estamos haciendo en principio
es establecer una conexin TCP/IP con su
puerto 21 (al menos as l o i ndi ca el
estndar, pero l uego cada uno puede
montar su servidor en el puerto que quiera).
A travs de esa conexin enviamos los
comandos y recibimos la respuesta a los
mismos (ver ilustracin en la pgina siguiente).
Todo esto es muy sencillo hasta aqu, sobre
todo para nosotros que ya somos expertos en
l a materi a de l os protocol os. Pero l a
complicacin viene cuando hacemos una de
estas 3 cosas:
- Pedir un listado de archivos (comando dir).
- Bajar un archivo (comando get).
- Subir un archivo (comando put).
El resultado de cada una de estas 3 acciones
puede implicar un envo masivo de datos,
por lo que, lo que se hace es establecer una
nueva conexin cada vez que hay que realizar
una de estas transferencias. El cliente
y el servidor se pondrn de acuerdo acerca de
cmo establecer esa nueva conexin TCP/IP
y, una vez establecida, ser a travs de esa
conexin por donde se enviarn los datos.
1.1.3. El famoso modo pasivo
Ya se ha hablado en la revista acerca de la
diferencia entre los modos pasivo y activo
(llammoslo as) de FTP, pero os lo recuerdo
brevemente.
Como he dicho en el punto anterior, el cliente
y el servidor se tienen que poner de acuerdo
sobre cmo establecer el canal de datos.
No hay que pensar mucho para deducir que
sl o hay dos formas de hacer esto:
- Que el cliente abra un puerto para que el
servidor se conecte a l para la transferencia
de los datos.
- Que sea el servidor el que abra el puerto
para que el cl i ente se conecte a l .
El primer sistema es el que se llama modo
activo, y el segundo es el modo pasivo. Ya
veremos ms adelante cmo se llega a este
acuerdo en detalle.
Ojo! No confundamos en esta ilustracin el
sentido de la flecha con el sentido del flujo de
los datos. La flecha representa el sentido del
establecimiento de la conexin, pero los datos
Si no has teni do... !
Si no has tenido oportunidad de leerte el nmero 1 de Hack
x Crack, este es el momento. Quedas advertido ;p
circulan en el mismo sentido independiente
mente de cmo se establezca la conexin, tal
y como vemos por las rayitas que imprimen
vel oci dad al archi vo del di bujo. :-)
1.2. Comandos RAW de FTP
Vamos ya con lo nuestro, que son los comandos
raw. ;-)
1.2.1. Establecimiento de la conexin
Una vez calentados los motores de nuestra
aplicacin de Telnet, lanzamos la siguiente
conexin:
telnet ftp.rediris.es 21
Como vemos, el puerto estndar para FTP es
el 21.
1.2.2. Autenticacin
Los datos de autenticacin circularn sin
ninguna encriptacin ni codificacin, por lo que
no es necesario montar ningn jaleo para enviar
el password como hacamos con el protocolo
SMTP (recordis la aplicacin base64?) o con
la codificacin de IPs en DCC.
Para establecer la conexin annima basta con
que lancemos dos comandos:
USER anonymous
PASS a
Si la conexin no fuese annima, pondramos
el nombre de usuari o y el password
correspondientes.
1.2.3. Listado de archivos a lo cutre
El funcionamiento de un simple DIR es bastante
ms complicado de lo que puede parecer en
un principio, por lo que de momento slo
veremos una forma sencilla de hacer el listado,
y ms adelante explicar cmo funciona
realmente el DIR.
Una vez que estamos dentro de Rediris, nos
encontraremos en el directorio raz (del FTP,
claro, no del sistema), as que si hacemos:
STAT .
Veremos el listado del directorio /, que es donde
nos encontramos. Supongo que no har falta
que os recuerde que . se refiere siempre al
directorio en el que te encuentras, y .. es el
directorio anterior al que te encuentras dentro
del rbol de directorios.
Podemos hacer tambin un listado con un path
absoluto:
STAT /pub/linux
1.2.4. Movindonos por los directorios
Para implementar internamente el comando
CD existen en realidad 2 comandos raw
di ferentes, que son: CWD y CDUP.
El comando CWD (Change Working Directory)
sirve para movernos directamente a cualquier
Sobre el directorio...
Sobre el directorio RAIZ de un Servidor FTP: Los que
hace tiempo siguen nuestra publicacin ya conocen
perfectamente esto, pero para los que no Cuando
instalamos en nuestro equipo un Software Servidor FTP,
uno de los parmetros que nos pide es el Directorio Raiz
(una carpeta que crearemos donde queramos en nuestro
disco duro). Cuando pongamos en marcha el Servidor FTP
y alguien del exterior se conecte a nuestro equipo aparecer
en esa carpeta (Directorio Raiz) y ver todo lo que hay en
esa carpeta, pero no podr escapar de ella para ver el resto
de nuestro disco duro (explicado en el nmero 1 de Hack
x Crack).
!
directorio, mientras que el comando CDUP
sirve para ir tan slo al directorio anterior
dentro del rbol directorios. Es decir, CDUP
es equivalente a CD ..
Para verlo con un ejemplo, recordemos que
acabamos de conectarnos al FTP de Rediris,
donde sabemos que hay un directorio pub.
As que podemos hacer directamente:
CWD pub
A l o que el servi dor nos responde:
250 OK. Current directory is /pub
Si ahora hacemos:
CDUP
Nos responder:
250 OK. Current directory is /
Desde aqu podemos hacer directamente:
CWD pub/linux
Nos responder diciendo:
250 OK. Current directory is /pub/linux
Pero an as nosotros podemos comprobar el
directorio en el que nos encontramos en
cualquier momento utilizando el comando:
PWD
Y nos responder:
257 "/pub/linux" is your current location
Tambin podemos hacer saltos a directorios
absolutos, como por ejemplo:
CWD /redhat
Al anteponer la / hacemos que el salto al
directorio sea directo, a pesar de que
estuviramos previamente en /pub/linux.
1.2.5. Borrado y renombrado de archivos
Generalmente, es muy raro que en las cuentas
annimas de FTP (en las que se entra con
usuario anonymous, como en la que estamos
usando de ejemplo) haya permisos de borrado
de archivos, o incluso simplemente permiso
para subir archivos.
A veces lo que si que podemos encontrar es
un nico directorio destinado a los uploads de
los usuarios annimos, donde s que habr
estos permisos.
En cualquier caso, a nadie le har gracia que
experimentis con estos comandos en su
servidor, por lo que os aconsejo que os montis
vuestro propio servidor para pruebas, o bien
que utilicis el de algn amigo.
Para borrar un archivo usaremos el comando
DELE:
DELE nombrearchivo
Y para renombrar el archivo nombre.old a
nombre.new tendremos que usar 2 comandos
consecutivos:
RNFR nombre.old
RNTO nombre.new
1.2.6. Creaci n y destrucci n de
directorios
Si tenemos los permisos necesarios, tambin
podremos crear nuestros propios directorios
con el comando MKD:
MKD nombredirectorio
O borrarlo con el comando RMD:
RMD nombredirectorio
1.2.7. Otros comandos
Par a empezar, el comando SYST
supuestamente nos muestra el sistema
operativo que corre en el servidor, pero aqu
el administrador o el software del servidor
pueden haber puesto cualquier cosa, por lo
que no es una fuente fiable de informacin.
Por ejemplo, ante un:
SYST
Podra responder algo como esto:
215 UNIX Type: L8
Otro comando es el NOOP que, como podris
imaginar, no hace absolutamente nada, pero
puede ser til para evitar ser expulsado del
servidor por exceso de idle (inactividad).
Si hacemos:
NOOP
Podemos encontrarnos una interesante
respuesta como esta:
200 Zzz...
Un comando que nos puede ser de mucha
ayuda es precisamente... el comando HELP:
HELP
Vemos que el servidor de Rediris nos responde
lo siguiente:
214-The following SITE commands are
recognized
CHMOD
IDLE
214 Pure-FTPd - http://pureftpd.org
Como vemos, nos dice 2 cosas. En primer lugar,
nos indica que hay 2 comandos adicionales
implementados en el servidor (CHMOD y IDLE),
y en segundo lugar nos indica el software que
utiliza el servidor, as como su pgina web.
Con respecto a los comandos adicionales,
tenemos aqu un ejemplo de los clsicos
comandos SITE, que son utilizados por algunos
servi dores de FTP para aumentar l a
funcionalidad. Algunos servidores, como
GLFTPD (www.glftpd.org y www.glftpd.com)
basan prcticamente toda su administracin en
los comandos SITE. Es decir, el administrador
configura el servidor desde la propia cuenta de
FTP, medi ante comandos especi al es.
Vemos que en Rediris hay 2 comandos SITE
disponibles para los usuarios annimos. Por
supuesto, es de suponer que el administrador
del server FTP de Rediris dispondr de
muchsimos comandos SITE ms que le
permitirn administrar todo el servidor
remotamente.
Por ejemplo, si hacemos aqu:
SITE IDLE 100
Haremos que el timeout por inactividad en
nuestra sesi n sea de 100 segundos.
Los comandos SITE dependen de cada software,
y son innumerables, por lo que se sale del tema
explicarlos aqu. :-)
1.2.8. Empezamos con la chicha: el
listado de archivos como dios manda
En realidad el comando DIR no funciona
mediante el comando raw STAT, si no con un
mecanismo ms complejo, tal y como expliqu
a grandes rasgos al principio del artculo.
Vamos a ver cmo conseguirlo, tanto utilizando
modo pasivo, como utilizando modo activo.
1.2.8.1. Listado en modo pasivo
En modo pasivo ser el servidor el que abra
elpuerto para establecer el canal de datos, por
lo que lo nico que tenemos que decirle
al servidor es que queremos establecer
un canal para alguna transferencia. Para ello
basta con que ejecutemos el comando
PASV:
PASV
A lo cual nos responder con 6 nmeros,
cada uno de ellos en base 256:
227 Entering Passive Mode
(130,206,1,5,190,189)
Los 4 primeros nmeros nos indican la
IP del servidor, y los dos siguientes nos
indican el nmero de puerto que ha
abierto el servidor para establecer el canal
de datos.
Si recordamos del artculo anterior la
decodificacin en base 256 sabremos que el
nmero 190.189 en base 256 equivale en
base decimal a:
190*256 = 48640
48640 + 189 = 48829
As que el puerto ser el 48829.
Ahora slo nos falta decirle al servidor qu
queremos que se transfiera a travs de ese
canal de datos. En este caso, lo que queremos
que transfiera es el listado de archivos de un
directorio, por lo que ejecutamos el comando
LIST:
LIST
Con esto el servidor ya no slo tiene el puerto
48829 a la escucha, si no que adems tiene
los datos preparados para ser enviados al
primero que se conecte a ese puerto... he
dicho al primero? ... ;-)
Ahora solo falta que lancemos un nuevo telnet
(sin cerrar el anterior):
telnet 130.206.1.5 48829
Y... hop! En la nueva ventana de telnet
aparecer el listado. :-)
1.2.8.2. Listado en modo activo
Espero que el modo pasivo no os pareciera
complicado, porque el activo lo es quiz an
ms.
En este caso somos nosotros los que tenemos
que tener un puerto abierto en escucha para
establecer el canal de datos. Para hacer esto
podemos utilizar el famoso netcat, que ya
controlaris gracias a otros artculos de la
revista: ;-)
nc -vv -l -p 5100
Este comando, como ya sabemos, pone en
escucha el puerto 5100.
Vamos a empezar codificando el nmero 5100
en base 256. Si recordamos el artculo anterior,
ser:
5100 / 256 = 19'...
5100 % 19 = 236
Por tanto, 5100 en base 256 ser 19.236.
Supongamos que nuestra IP pblica es
213.125.12.12. Si ahora ejecutamos en el
FTP el comando:
PORT 213,125,12,12,19,236
Le estaremos diciendo al servidor que hemos
abierto un puerto en escucha para establecer
un canal de datos. El puerto ser el 19.236 en
base 256, es decir, el 5100 en base 10. La IP
ser la que le hemos indicado, es decir,
213.125.12.12. No os suena esto de que
seamos nosotros los que especificamos la IP
y el puerto a los que se tiene que conectar a
algo que ya cont en el artculo sobre DCC? ;-)
A continuacin, le decimos al servidor qu
queremos que se transfiera a travs de ese
canal de datos. En este caso es el listado de
archivos, por lo que lanzamos el comando
LIST:
LIST
En ese instante, en nuestro netcat veremos
aparecer todo el listado. :-)
Un momento... como que no? Vaya... no te
funciona, eh? :-m
No ser que ests detrs de un router? Si es
as, es probable que tu router haga IP
masquerading, por lo que la IP que tienes
que indicar en el comando PORT no es tu IP
pblica, si no tu IP privada (la de tu red local).
Tu router automticamente modificar ese dato
para que lo que llegue al servidor de Rediris
sea en realidad tu IP pblica. Por tanto, si tu
IP privada fuese 192.168.1.1 en el ejemplo,
sta ser a l a secuenci a de comandos:
nc -vv -l -p 5100
PORT 192,168,1,1,19,236
LIST
1.2.9. Listado de nombres
Si queremos un listado ms simple, en el que
slo se nos muestren los nombres de los
archivos, y no todos sus permisos, podemos
utilizar el comando NLST en lugar de LIST.
Sera as para modo pasivo:
PASV
227 E nt e r i ng Pa s s i v e Mo de
(130,206,1,5,190,189)
NLST
telnet 130.206.1.5 48829
Y as para modo activo:
nc -vv -l -p 5100
PORT 192,168,1,1,19,236
NLST
El NLST lo utiliza internamente el comando
MGET para manejar ms fcilmente la lista de
archi vos para el downl oad ml ti pl e.
Hemos tratado...
Hemos tratado MUCHAS veces en esta publicacin todo
lo relacionado con IPs Pblicas, IPs Privadas, etc. Si tienes
dudas pregunta en nuestro foro :)
!
1.2.10. Bajando archivos (get)
Para implementar en raw el comando get hay
que hacer alguna cosilla ms que para el dir.
La cuestin est en que el estndar proporciona
varios sistemas diferentes de representacin
de la informacin, aunque bsicamente
podemos considerar slo 2:
Ascii (tipo A) Se utiliza para transmisiones
de texto, como por ejemplo los listados, y no
es vlido para transmitir archivos binarios,
como por ejemplo un ejecutable.
Binario (tipo I) Es el modo que se utiliza
habitualmente para bajar un archivo. Es el
modo que se activa cuando ejecutamos el
comando bin.
Por tanto, lo habitual es que el servidor est
por defecto en tipo A, y que cuando queramos
hacer un get o un put de un archivo le
indiquemos que utilice el tipo I.
Si tenis curiosidad acerca del motivo por el
cual se utilizan diferentes representaciones
para el texto y para los archivos, tened en
cuenta que el cdigo ascii estndar consta
tan slo de 128 carcteres, los cuales se pueden
representar con slo 7 bits, mientras que los
datos de un archivo estn formados por bytes,
es deci r, necesi tan 8 bits para ser
representados.
As que sta sera la secuencia de comandos
para hacer un download del archivo lco.iso en
modo pasivo:
TYPE I
200 TYPE is now 8-bit binary
PASV
227 Ent e r i ng Pas s i v e Mode
(130,206,1,5,190,189)
RETR lco.iso
telnet 130.206.1.5 48829 > lco.iso
150- Accept ed dat a connect i on
150 3430 kbytes to download
226-Fi l e successful l y transferred
226 250.9 seconds (measured here),
13.66 Kbytes per second
Aqu observamos una diferencia importante con
respecto a los listados, y es que en el telnet
que abrimos para conectar con el canal de
datos hacemos una redireccin de salida a
fichero (> lco.iso). Con eso conseguimos que
almacene los datos recibidos directamente sobre
el archivo lco.iso en nuestro disco duro.
As de fcil se hara en un sistema Linux/Unix.
Si, en cambio, queris guardar los datos en un
archivo en sistemas Windows, tendris que
configurar vuestra aplicacin de telnet para que
guarde el log de la sesin, y despus
renombrar el archivo .log a la extensin que
tuviese el archivo original.
Esto mismo en modo activo:
nc -vv -l -p 5100 > lco.iso
TYPE I
200 TYPE is now 8-bit binary
PORT 192,168,1,1,19,236
200 PORT command successf ul
RETR lco.iso
150-Connect i ng t o port 61427
150 3430 kbytes to download
226-Fi l e successful l y transferred
226 250.9 seconds (measured here),
13.66 Kbytes per second
1.2.11. El resume
Imaginemos que estamos bajando una ISO de
700MB, y cuando llevamos ya bajados 670MB
perdemos la conexin por cualquier motivo.
Tendramos que volver a comenzar el download
desde cero? Gracias a Dios, el protocolo FTP
nos da un comando para evitar que esto ocurra:
el comando REST.
Supongamos que tenemos un download a
medias de un archivo que ocupa 10MB, es decir,
SI TE GUSTA LA INFORMTICA.
SI ESTAS CABREADO CON GINDOUS ;)
SI QUIERES PROGRESAR DE VERDAD
PC P
PC P
ASO
ASO
A
A
P
P
ASO
ASO
SOR SORTEA TEA CADA CADA MES UN S.O. MES UN S.O.
SUSE LINUX PR SUSE LINUX PROFESSION OFESSIONAL 8.2 AL 8.2
SIMPLEMENTE ENVIA SIMPLEMENTE ENVIA LA LA P PALABRA ALABRA
PCCON PCCON AL AL 5099 5099
DESDE DESDE TU MOVIL TU MOVIL
PRECIO DEL PRECIO DEL MENSAJE: 0,90 + IV MENSAJE: 0,90 + IVA. V A. VALIDO P ALIDO PARA ARA (MOVIST (MOVISTAR - VODAFONE AR - VODAFONE Y Y AMENA) AMENA)
EL EL PREMIO PUEDE SER CANJEABLE POR UN JUEGO PREMIO PUEDE SER CANJEABLE POR UN JUEGO
DE PC O CONSOLA DE PC O CONSOLA QUE NO SUPERELOS 85 QUE NO SUPERELOS 85
EL EL GANADOR SALDRA GANADOR SALDRA PUBLICADO PUBLICADO AQU 2 NMEROS DESPUES DE LA AQU 2 NMEROS DESPUES DE LA PUBLICACIN. PUBLICACIN.
Incluye 7 CDs y 1 DVD
Manual de Instalacin.
Manual de Administracion
10 * 1024 * 1024 = 10485760 Bytes. Si
nuestro archivo ocupa slo 987501 Bytes,
que es hasta donde pudimos bajar en la anterior
sesin, sta ser la secuencia de comandos
para que haga el resume:
TYPE I
PASV
REST 987501
RETR lco.iso
telnet 130.206.1.5 48829 > lco.iso
1.2.12. Subiendo archivos (put)
Aqu se complica un poco ms la cosa, ya que
ya no nos limitamos a establecer una conexin
de datos con el servidor, si no que adems
tenemos que transferir un archivo nosotros
mismos a travs de esa conexin.
El comando para subir archivos es STOR, y su
sintxis es la misma que la del comando RETR.
As que la diferencia ms importante con RETR
es que tenemos que aparnoslas para
transferir el archivo automticamente a travs
del canal de datos. Para ello podemos utilizar
la redireccion de entrada desde fichero,
que es lo contrario de lo que hacamos con el
get.
Vamos a ver cmo se hara esto en modo
pasivo:
TYPE I
PASV
STOR lco.isonc 130.206.1.5 48829 <
lco.iso
Como vemos, aqu no hemos utilizado telnet
para conectar, si no netcat, ya que la
redireccin de entrada no funciona con
telnet.
Para hacer esto mismo en modo activo:
nc -vv -l -p 5100 < lco.iso
TYPE I
PORT 192,168,1,1,19,236
STOR lco.iso
1.2.13. Bye bye...
Para terminar con los comandos RAW, tenemos
el comando QUIT:
QUIT
que, como podemos imaginar sin mucho
esfuerzo, sirve para implementar el comando
BYE, es deci r, para cerrar l a sesi n.
Pero aqu no termina la cosa, ya que an falta
la segunda parte del artculo, que es en la
que explico diversas tcnicas para explotar las
carencias de seguridad de este protocolo. As
que estad bien atentos a la revista el prximo
mes, que ahora viene lo ms interesante. ;-)
Autor: PyC (LCo) // Ilustraciones: MariAn (LCo)
La media actual de participantes es de SOLO 230 personas: este es el sorteo ms facil de ganar que existe !!! ANIMATE Y PARTICIPA !!!
- Aprenderemos a conseguir claves de FTP por
diversos mtodos
- Aprenderemos a utilizar la popular herramienta
Snort como sniffer
- Aprenderemos lo que es el hammering
- Aprenderemos a utilizar un servidor de FTP
como puente para establecer conexiones
annimas a otros servicios en otras mquinas
- Descubriremos los secretos de la Scene del
Warez, las boards de FXP, los Dumps...
- Aprenderemos el funcionamiento interno del
protocolo FXP
- Capturaremos conexiones de FTP de otros
usuarios
- Aprenderemos a abrir puertos en un firewall
utilizando el protocolo FTP
2. Problemas de seguridad en FTP
Como lo prometido es deuda, aqu tenis la
continuacin del artculo sobre FTP. Como ya
anticip en el nmero anterior, en el que
expliqu el funcionamiento del protocolo, en
esta segunda parte mostrar algunos de sus
probl emas de seguri dad i nherentes.
Insisto en que slo hablar de problemas
inherentes al protocolo, por lo que no entrar
en detallar exploits para ningn bug de una
aplicacin en concreto. Por supuesto, como
cualquier aplicacin actual, los servidores y
clientes de FTP tambin tienen un largo historial
con los ms variopintos bugs clsicos (buffer
overflow, DoS, etc, etc). Pero todo esto son
temas aparte, que nada (o poco) tienen que
ver con el protocolo en s mismo.
Igual que, por ejemplo, el protocolo SMTP
permite que el cliente especifique cualquier
di recci n de ori gen, aunque sta no
sea real (lo expliqu en el nmero 8 de la
revista), el protocolo FTP tambin permite otras
muchas cosas que pueden implicar ciertos
problemas de seguridad, aunque tambin
pueden ser uti l i zadas para fi nes ms
constructivos, como explicar por ejemplo
cuando hable sobre FXP en este artculo.
As que, sin ms dilacin, pongmonos ya manos
a la obra. :-)
Nota de Hack x Crack: Hay muchas Webs donde puedes
informarte sobre los ltimos acontecimientos
relacionados con lo Seguridad Informtica. Una de ellas
es sin duda http://www.vsantivirus.com/
RAW 6 : FTP
(File Transfer Protocol)
Segunda Parte.
El camino recorrido con esta serie (SERIE RAW) ha sido largo y terriblemente provechoso.
Hemos conseguido tratar DE TU A TU con los temidos protocolos y a dominar temas que
la mayora de mortales ni tan siquiera sabe que existen. Vamos a por todas con el FTP!!!
Nota de HackxCrack !
2.1. CAPTURA DE CLAVES DE FTP
Para los que hayis seguido fielmente todos
los nmeros de mi serie RAW, este primer
punto ser evidente, pero creo conveniente
comentarlo, no solo como repaso, si no tambin
para los nuevos lectores. ;-)
Como expliqu en el nmero anterior,
los passwords de autenticacin en FTP se
env an en texto plano, si n ni ngn
ti po de codi fi caci n ni encri ptaci n.
Por tanto, si tenemos alguna herramienta
que nos permita capturar todo el trfico que
circula por nuestra red, podremos capturar
todos los passwords de FTP que sean enviados
dentro de nuestra red local. Esta herramienta
es precisamente un sniffer.
En Windows podis utilizar, por ejemplo, el
sniffer IRIS. En Linux tenis una gran oferta
de sniffers, empezando por el clsico snort,
que puede funcionar tambin como IDS
(Sistema de Deteccin de Intrusos), y teniendo
tambin gran variedad de sniffers con interfaz
grfi co, como por ejempl o Ethereal.
Para no aburrir a los que siguen mi serie desde
el principio, esta vez en lugar de mostrar el
ejemplo con IRIS, lo mostrar con un sniffer
para Linux. Y para que aprendis an ms, no
lo haremos con un sniffer grfico, si no con
snort desde una shell. :-)
Una vez compilado e instalado snort (se sale
del tema del artculo explicar cmo hacer esto),
slo tendremos que lanzar este comando desde
una consola:
snort -v -d port 21
El usuario que ejecute este comando tiene que
ser root. Os comento rpidamente que la opcin
-v sirve para que muestre el contenido de los
paquetes que captura, la opcin -d para que
muestre el campo de datos de los paquetes, y
no slo la cabecera, y port 21 es una
expresin que le indica que slo muestre los
paquetes que circulen a travs del puerto 21
Te la recomendamos no solo por la velocidad con que
actualiza sus contenidos sino porque pone a tu disposicin
muchos artculos que sin duda harn las delicias de
cualquier persona interesada por el tema. Est
principalmente orientada a temas vricos, pero en los
ltimos tiempos los virus/gusanos utilizan precisamente
bugs del Sistema Operativo para su propagacin, de
manera que encontrars todo tipo de informaciones y en
perfecto castellano :)
SERIE RAW: FTP (II) - SERIE RAW: FTP (II) - SERIE RAW: FTP (II) - SERIE RAW: FTP (II)
Como ya debes saber... !
- Como ya debes saber a estas alturas, una SHELL
es una Ventana de Comandos, esa pantallita negra donde
puedes escribir comandos. Si no tienes ni idea, descrgate
de forma gratuita el nmero uno de esta revista
(www.hackxcrack.com) y recuerda que cualquier duda
puedes exponerla en el foro.
- En este artculo se detalla el trabajo con un sniffer
para Linux, puedes hacer lo mismo desde cualquier otro
sniffer para Windows. Recuerda que en nmeros anteriores
ya hemos trabajado con sniffers para Windows.
- En este artculo se habla de compilar el snort
p a r a Li n u x . Nu e s t r o f o r o d e LI NUX
(www.hackxcrack.com) est cada vez ms activo, lgico
si pensamos que cada vez estamos haciendo ms referencias
a este Sistema Operativo en nuestros artculos. Pues ya
sabes, si no tienes ni idea de compilar el snort en Linux o
tienes cualquier duda al respecto, psate por el foro y entre
todos nos ayudaremos :)
- Una ltima cosa como puedes ver, poco a poco
intentamos que experimentes nuevas sensaciones y, si
quieres seguir aprendiendo debers tomarte esta invitacin
como algo prioritario. Si hasta ahora has pasado de
instalarte Linux, no lo dejes por mucho ms tiempo todo
lo que hasta ahora se ha explicado en PC PASO A PASO
(incluido en este nmero 12) puede hacerse tanto desde
Windows como desde Linux, pero llegar un momento en
que ciertos temas nicamente podrn tratarse desde Linux
y ese da lamentars no tener ni idea de por donde empezar.
Que no te pille el toro, atrvete con LINUX!!!
(tanto si es de origen, como si es de destino).
Os recuerdo que el puerto 21 es el puerto
estndar para FTP.
Desde que ejecutemos este comando, se nos
mostrarn en pantalla todos los paquetes
relacionados con el puerto 21 que circulen en
toda nuestra red local. Normalmente, esto ser
poco prctico, ya que no podemos estar todo
el da pendientes de la consola esperando que
aparezca el paquete que contiene el password,
por lo que lo mejor es dejarlo un tiempo
corriendo, y mirar despus en los logs de
snort. El directorio por defecto para los logs
de snort es /var/log/snort, aunque podemos
especificar nosotros el directorio que queramos
mediante la opcin -l <nombre_directorio>.
En esta captura podemos ver 2 consolas. En
la primera (la que tiene el foco), vemos la
salida que muestra snort al actuar como sniffer
del puerto 21, y en la segunda vemos una
sesin de FTP. El password que hemos
introducido ha sido hxcpass. Como podemos
ver en la consola de snort, se ve claramente
el paquete en el que enviamos el comando
PASS hxcpass.
2.2. CRACKEO DE CLAVES DE FTP.
Antes de meternos con lo realmente interesante,
vamos a insistir un poco ms en el tema de
los passwords, tambin para aclarar uno de
los trminos que se escuchan a menudo
relacionados con el FTP, que es el del
hammering.
Pero no nos precipitemos; vamos a ver primero
las 2 formas de crackear passwords de FTP,
aparte de la captura directa que hemos visto
antes:
2.2.1. Crackeo local.
Si tenemos acceso al disco duro de alguien que
utiliza un cliente de FTP, en el cual tenga un
site manager en el que almacene direcciones
y login/password de varias cuentas, podremos
coger el archivo del cliente de FTP donde
almacene los sites y utilizar alguna herramienta
de crackeo especfica para ese software.
Por poner un ejemplo, en:
http://link.box.sk/link.php3?rid=30953&url=h
ttp%3A%2F%2Fnewdata.box.sk%2Ftdwl%2F
flashfxp.pc.0.1.zip tenis un crackeador de
passwords para el archiconocido cliente
FlashFXP.
Si no encontraseis la herramienta adecuada
para ese cliente, siempre os queda la posibilidad
de importar el archivo con los sites a vuestro
propio cliente, y sacar los passwords mediante
un sniffer, tal y como expliqu en el punto 2.1.
Este tipo de herramientas pueden ser muy tiles
cuando habi s ol vi dado l os datos de
autenticacin de alguna cuenta y los necesitis,
normalmente porque tenis que acceder desde
otro sitio, con otro cliente en el que no tenis
los datos introducidos en el site manager.
2.2.2. Crackeo online.
Si, en cambio, lo que queremos es conseguir
acceso a un servidor de FTP remoto, tendremos
que hacer un crackeo de cuentas por uno de
los 3 sistemas clsicos:
- Fuerza bruta
- Diccionario
- Mtodos mixtos
El crackeo por fuerza bruta consiste en probar
todos los posibles passwords hasta, a base de
miles de pruebas, dar con un password que
funcione.
El crackeo por diccionario consiste en probar
una serie de passwords tpicos y confiar en que
el administrador haya sido tan poco original de
utilizar uno de esos passwords. Existen en la
red miles de archivos con diccionarios de
passwords en todos los idiomas.
Los mtodos mixtos son muy variados:
generacin de fechas, combinaciones de
palabras de diccionario, etc.
En cualquier caso, existen defensas contra
esto, y una de las clsicas es el anti-
hammering. Si alguna vez habis intentado
acceder a un servidor FTP que estuviera lleno
de usuari os y no se pudi ese entrar,
probablemente os habris encontrado con que
despus, a pesar de que ya haba hueco en el
servidor, ste os haba baneado y no permita
el acceso a vuestra IP. Esto probablemente se
habr debido a que no configurasteis bien
vuestro cliente de FTP, y ste hizo un
hammering al servidor, el cual se defendi
baneando vuestra IP para impediros el acceso.
En qu consiste el hammering, y por qu
los servidores intentan evitarlo? Generalmente,
los servidores FTP suelen tener limitado el
nmero de usuarios simultneos, por lo que
los clientes de FTP suelen incorporar un
mecanismo para reintentar la conexin cada
cierto tiempo si se da el caso de que el servidor
est lleno.
El problema aparece si el cliente de FTP est
configurado para que esos reintentos sean
instantneos, es decir, sin dejar un tiempo
prudencial entre cada reintento. Lo que ocurre
entonces es que el servidor de FTP se encuentra
con que ese usuario est intentando conectar
con una insistencia de varios intentos por
segundo. La respuesta ante tal falta de
educacin suele ser el baneo a esa IP para
que no pueda volver a acceder a ese servidor.
Los motivos por los que el hammering no es
deseable son bsicamente 3:
- En primer lugar, el hammering consume
recursos en el servidor de forma innecesaria
(tanto ancho de banda, como recursos de la
mquina).
- En segundo lugar, si hay varios usuarios
intentando entrar, sera como intentar colarse
por la fuerza, por lo que es una falta de
educacin, la cual adems podra llevar a que
los dems usuarios, queriendo tener igualdad
de oportunidades, hiciesen tambin hammering
contra el servidor, por lo que el problema se
multiplicara.
- En ltimo lugar, que es el que nos interesa
ahora, cuando se lanza un intento de crackeo
de passwords mediante cualquiera de los 3
sistema mencionados antes (fuerza bruta,
diccionario, u otros mtodos), ste slo podr
ser efectivo si se pueden lanzar muchos intentos
de conexin lo ms rpido posible, por lo que
si se evita el hammering, se estar evitando
tambin la posibilidad de un crackeo de
passwords en el servidor.
Por supuesto, como nada es perfecto en este
mundo (y menos an la seguridad informtica),
siempre hay forma de saltarse las protecciones
anti-hammering. Por ejemplo, aqu podis ver
una forma de saltarse la proteccin anti-
hammering del popular servidor FTP para
W i n d o w s S e r v - U :
http://www.securiteam.com/exploits/6W00H1
P0AO.html
2.3. FTP BOUNCE
Vamos a entrar al fin de lleno con una tcnica
realmente interesante. ;-)
Esta tcnica ha sido utilizada desde tiempos
remotos, e incluso ha llevado a la necesidad
de escribir un RFC con recomendaciones para
evitar este tipo de ataques: ftp://ftp.rfc-
editor.org/in-notes/rfc2577.txt
Para comprender el funcionamiento de este
ataque, debemos recordar el funcionamiento
del FTP activo (o no pasivo). En este tipo de
transferencia, es el cliente el que especifica al
servidor la IP y el puerto donde debe conectarse
para establecer el canal de datos. Vaya... no
os recuerda eso a algo? quiz a las mil tcnicas
que expliqu sobre DCC, donde tambin se
especificaban manualmente la IP y el puerto?
:-D
Si en lugar de darle al servidor de FTP nuestra
IP, le damos la de cualquier otra mquina, y
como puerto le damos el de algn servicio que
tenga esa mquina, el servidor de FTP se
conectar a ese servicio de esa mquina,
pensando que en realidad se est conectando
a nuestra mquina para establecer un canal de
datos para una transferencia.
Vemoslo mejor con un ejemplo:
Supongamos que el malfico usuario PyC tiene
una cuenta (puede ser tambin una cuenta
anonymous) en el servidor de FTP ftp.lco.es.
Resulta que tiene tambin una cuenta de
correo gratuita que se ha creado en
www.hotpop.com para sus prfidos planes.
Esa cuenta de correo funciona mediante POP3
(para la recepcin) y SMTP (para el envo).
Estos 2 protocolos ya fueron explicados en la
serie RAW, en los nmeros 7 y 8 de la revista
respectivamente. ;-)
Lo que quiere hacer PyC es utilizar el servidor
de FTP ftp.lco.es como intermediario (bouncer)
para enviar un email annimo al usuario
Zer0Cul.
Vamos a ver paso a paso cmo lo consigue:
2.3.1. PyC prepara el archivo de
comandos SMTP
El primer paso ser crear un archivo de texto
que contenga la secuencia de comandos
SMTP que quiere ejecutar sobre el servidor
smtp de hotpop (smtp.phreaker.net).
Ll amar a este archi vo, por ejempl o:
ftpbouncemail.txt.
Muestro aqu el contenido del archivo:
EHLO pyc
AUTH PLAIN
AKI5Y65sY24GcGhyZTYbZXIubmV0ADJIbJIvcHljAAB=
MAIL FROM: <pyc_lco@phreaker.net>
RCPT TO: <Zer0Cul@hotmail.com>
DATA
Subject: ftp bounce
From: pyc_lco@phreaker.net
To: Zer0Cul@hotmail.com
probando ftp bounce
.
QUIT
2.3.2. PyC sube el archivo creado al
servidor FTP
A continuacin, se conecta al servidor de FTP
en ftp.lco.es, y una vez dentro va al directorio
de Upload, en el que tiene permisos de
escritura (puede subir archivos). En ese
directorio, sube el archivo ftpbouncemail.txt.
2.3.3. PyC lanza los comandos RAW para
el FTP bounce
Para hacer esto, a PyC slo le falta un dato,
que es la IP del servidor de SMTP, la cual
puede conseguir por cualquier sistema clsico
de traduccin de DNS a IP. Por ejemplo, desde
Linux, ejecutara en una consola:
host smtp.phreaker.net
Y obtendra la IP. En este caso concreto, hay
3 IPs asociadas al mismo DNS, por lo que
cualquiera de las 3 nos servira. La IP que nos
quedamos es: 204.57.55.209.
El primer comando RAW a enviar ser:
PORT 204,57,55,209,0,25
Con eso estamos diciendo al servidor, que el
canal de datos para la prxima transferencia
se establecer cuando el servidor conecte al
puerto 25 de la IP 204.57.55.209 que, por
supuesto, no es la nuestra (como debera ser
si estuviramos haciendo algo legal), si no la
del servidor SMTP de hotpop. ;-)
La forma de enviar comandos RAW depende
del cliente de FTP que utilicemos. Pongo 3
ejemplos:
- Desde telnet (tal y como ense en el
anterior artculo), simplemente escribimos
el comando tal cual. :-)
- Desde FlashFXP, el clsico cliente de FTP
para Windows, con el shortcut Control-R
nos aparecer una ventanita sobre la que
podemos introducir directamente el comando
RAW.
- Desde un cliente FTP de consola en
Linux/Unix, escribimos quote seguido del
comando RAW. En este caso ser a:
quote port 204, 57, 55, 209, 0, 25
Una vez lanzado el comando PORT, ya slo
nos falta decirle al servidor que ese canal de
datos lo queremos para bajar un archivo,
desde el servidor hasta la IP que especificamos
en el comando PORT (que debera ser la
nuestra, pero nosotros le hemos engaado
dndole la IP del servidor SMTP). Si ahora
hacemos:
RETR ftpbouncemail.txt
El contenido del archivo que creamos con los
comandos SMTP ser enviado al puerto 25 del
servidor SMTP.
Desde el punto de vista del servidor SMTP,
alguien habr establecido una conexin TCP/IP
con su puerto 25, por lo que interpretar que
todo lo que se enve a travs de esa conexin
sern comandos SMTP.
As que el escenario que tenemos es el
siguiente:
Una conexin TCP/IP establecida entre un
servidor SMTP y un servidor FTP donde:
- El servidor FTP (que acta como cliente
en esta conexin) cree que se trata de un
canal de datos de FTP.
- El servidor SMTP (que acta como servidor
en esta conexin) cree que se trata de una
sesin de comandos SMTP.
Por tanto, al estar ambas mqui nas
engaadas, el servidor FTP no tendr ningn
problema en transmitir los comandos SMTP, y
el servidor SMTP no tendr ningn problema
en i nterpretarl os y ejecutarlos. ;-)
Si hemos repasado el nmero 8 de la revista,
donde la serie RAW trataba sobre el protocolo
SMTP, ya sabris que lo que hacen los
comandos del archivo ftpbouncemail.txt es
precisamente enviar un e-mail a la direccin
Zer0Cul@hotmail.com.
2.3.4. Nuestro amigo Zer0Cul lee su
correo y... Oh! Sorpresa!
Cuando el dueo de l a di r ecci n
Zer0Cul@hotmail.com abra su cuenta de correo
(usualmente, utilizando un cliente POP3), se
encontrar con nuestro e-mail, en el cual no
aparecer nuestra IP, si no la IP del servidor
FTP que utilizamos como bouncer. ;-D
En la imagen vemos el e-mail que ha recibido
Zer0Cul, mostrando las cabeceras completas.
2.4. EL MI STERI O DEL FXP
DESVELADO
El FXP es una de esas cosas que muchos usamos
pero pocos sabemos cmo funciona, y eso que
es realmente sencillo! En realidad la idea del
FXP es muy parecida a la del FTP Bounce.
Si ahora mismo ests pensando: pues no sern
tantos los que usan el FXP si yo ni siquiera se
lo que es... no te preocupes, que ahora mismo
te explico qu es y para qu sirve. :-)
Antes de empezar con este tema, he de dejar
clara una cosa, para evitar problemas que sin
duda podran surgir. Voy a hablar a continuacin
de un tema oscuro, sobre el que los implicados
siempre han guardado un celoso silencio, as
que quiero dejar claro que mi intencin no es
aqu la de desvelar ningn secreto, y menos
an hacer ningn tipo de publicidad, si no que
podis considerarme simplemente como un
criminlogo que habla sobre los casos que ha
estudiado. Por hablar de ellos no est incitando
a la gente a que forme parte de ninguna
mafia, ni tampoco est desvelando secretos
internos de esa mafia (entre otras cosas,
porque yo no pertenezco a ella). Simplemente
hablo de lo que he podido observar desde
fuera, y sin contar nunca nada que no pudiera
conocer cualquiera que investigase el tema por
su cuenta.
2.4.1. Un secreto a voces
Sabis lo que es la Scene del Warez?
Los que no lo sepis, vais a encontrar aqu una
informacin realmente interesante, as que
estad bien atentos, porque os voy a hablar
sobre un secreto a voces. :-)
Y los que lo sepis, podis estar tranquilos, ya
que no voy a desvelar ningn secreto que no
pueda saber cualquiera con dos dedos de frente
que dedique 5 minutos a investigar sobre el
tema por su cuenta. :-)
Imaginad que trabajis en una importante
distribuidora discogrfica que recibe las ltimas
novedades del mercado antes de que stas
estn a la venta. Un buen da conocis a otro
to que por su trabajo tiene acceso a las ltimas
pelculas del mercado. Quedis entonces de
acuerdo en intercambiaros discos de msica a
cambio de pelculas. Por supuesto, lo hacis a
travs de Internet, por lo que tenis que ripear
el audio (MP3) y el vdeo (DivX). Pero pronto
te das cuenta de que no das a basto, ya que
tu compaero quiere ms y ms, y tu no eres
capaz de ripear todos los discos que llegan
diariamente a tu tienda. Por suerte, pronto
conoces a un chaval que resulta ser coleccionista
compulsivo, y se compra todas las novedades
que salen al mercado. As que llegas a un
acuerdo con l para repartiros el trabajo a la
hora de ripear los discos, para que as no se
haga el mismo trabajo dos veces.
Imaginaos ahora esto mismo, pero a una escala
mucho mayor, con miles de personas de todo
el planeta puestas de acuerdo para ripear
absolutamente todo, pero sin que se haga el
mismo trabajo dos veces. Pues eso es
precisamente la Scene. :-)
Pero no confundis esto con las famosas redes
P2P (E-Mule, y compaa), ya que no tiene
nada que ver. La Scene es algo perfectamente
organizado, mientras que las redes P2P son un
completo caos. Os muestro algunas diferencias:
- Unicidad: Cualquiera puede coger el disco
de Bisbal que se compr ayer y pasarlo a MP3
y luego distribuirlo a travs de E-Mule. En
cambio, esto es imposible en la Scene, ya que
est todo regulado de forma que nadie pueda
aportar algo si otra persona aport ya ese
mismo producto. Cada producto que se aporta
a la Scene recibe el nombre de release.
- Calidad: Lo que aportes a la Scene tiene que
pasar unos estrictos controles de calidad
( r es ol uc i n, f or mat o, i nf or mac i n
complementaria, fidelidad al original, ...). En
cambio, en las redes P2P te puedes encontrar
autnticas basuras, como: pelculas mal ripeadas,
msica con chasquidos y ruidos, discos
i ncompl et os, f ormat os i ncmodos o
incompatibles, canciones sin ttulos, etc.
- Veracidad: En las redes P2P puedes encontrar
los famosos fakes, que son cosas que no son
lo que dicen ser. Por ejemplo, te tiras un da
entero bajando una pelcula para luego descubrir
que es otra totalmente diferente bajo un ttulo
que no le corresponde, o puedes encontrar
supuestas aplicaciones que resultan ser virus
o troyanos, etc, etc. En la Scene todo esta
regulado para garantizar la autenticidad, adems
de conocer la identidad del que ha hecho la
release. Para ello, cualquier release ha de estar
acompaada de un archivo de informacin
acerca del producto y de la persona o grupo
que la ha aportado. Por supuesto, nunca
seutilizan nombres reales. ;-)
Muchas de las releases que circulan por las
redes P2P salen precisamente de la Scene, as
que en cierto modo podramos considerar a las
redes P2P como el escaln ms bajo, donde
llegan slo las sobras de lo que se produce
en la Scene (me da a mi que me voy a buscar
ms de un enemigo con este artculo... 0:-)
Hay quien confunde todo este pirateo
organizado con mafias como la del famoso
Top-Manta, pero nada tienen que ver por un
sencillo motivo: la finalidad. La finalidad de la
Scene no es el lucro, si no el crear una basta
red para compartir productos con una garanta
de calidad para el disfrute personal. En cambio,
en el Top-Manta la calidad no es precisamente
una finalidad, si no una traba que dificulta
producir ms en menos tiempo.
2.4.2. El mecanismo de distribucin
Y por qu os cuento todo esto ahora? Pues
ahora mismo encajo todas las piezas. :-)
Est claro que el mecanismo de distribucin
de la Scene no puede ser el mismo que el de
las redes P2P, ya que este mecanismo es catico
en s mi smo. No hay ni ngn ti po de
centralizacin, si no que cada uno va pasando
cualquier cosa a cualquiera, y no se puede
establecer ningn tipo de control sobre lo que
circula.
En el caso de l a Scene, donde est
perfectamente regulado lo que puede y no
puede circular, es necesario centralizar de
alguna manera la distribucin. Para ello hay
una serie de servidores distribuidos por
todo el planeta que son, por as decirlo,
certificados por la Scene. Por tanto, esos
servidores garantizan que todo su contenido
es nicamente producto de la Scene, con las
ventajas que eso conlleva (unicidad, calidad,
veracidad...). Por supuesto, a estos servidores
slo pueden acceder los miembros de la
Scene. :-(
Teniendo en cuenta la cantidad de gente que
pertenece a la Scene, esos servidores tienen
que tener un gran ancho de banda (del orden
de los 100Mbps tpicamente), pero an as
nunca es suficiente, por lo que es necesario
distribuir todo utilizando un gran nmero de
servidores.
Ahora bien... cmo se hace esta distribucin
entre todos los servidores? Estos servidores
suelen pertenecer a grandes organizaciones e
instituciones, por lo que no puede haber
permanentemente (la Scene no descansa en
las 24 horas del da) un miembro de la Scene
al teclado de cada servidor moviendo cosas de
un lado a otro.
La solucin consiste en tener una serie de
miembros cuya finalidad es precisamente la
de distribuir a travs de los servidores, pero...
trabajando desde casa. ;-)
Esta gente, que se denominan Couriers, suelen
disponer en su casa de conexiones normales
(mdem, adsl, cable...) por lo que de ninguna
manera podran transferir los datos de un
servidor a otro directamente a travs de su
conexin casera. En lugar de eso, lo que hacen
es dar una serie de instrucciones a los servidores
para que ellos mismos se transfieran los datos
entre s, sin que tenga que circular nada a
travs del cuello de botella que supondra el
modesto ancho de banda casero del Courier.
El protocolo utilizado para que los servidores
se transfieran datos entre s es precisamente
el FXP (Fi l e eXchange Protocol ).
2.4.3. Las boards de FXP y los Dumps
En realidad, la vida de los miembros de la Scene
no es precisamente un camino de rosas. Hay
que realizar un trabajo constante simplemente
para permanecer en ella, pero con eso no basta,
ya que por el mero hecho de pertenecer a la
Scene no tienes acceso a todo, si no que tienes
que ir trabajndote por tu cuenta el acceso a
los distintos servidores: cuanto ms trabajas,
ms consigues.
Por eso, surgi un movimiento paralelo a la
Scene, que es el de las boards de FXP. Una
board consiste en un grupo de gente,
tpicamente miembros de la Scene, que se
dedican a intercambiar todo aquello a lo que
cada uno tiene acceso, sin los sufrimientos que
conlleva el conseguir esto mismo a travs de
los mecanismos clsicos de la Scene. Para ello,
se montan sus propios servidores para realizar
el intercambio. Estos servidores suelen ser
menos potentes (menor ancho de banda, menor
capacidad de disco, menos fiables, etc),
pero se ajustan a sus necesidades, ya que
tambin el nmero de usuarios es mucho
menor.
Como los miembros de las boards no suelen
disponer de las infraestructuras de la Scene
(acceso a grandes servidores, contactos, etc),
no les queda ms remedio que aparselas por
otros medios... y es ah donde aparecen los
Dumps.
Los servidores que se utilizan en las boards
para el intercambio y distribucin no pertenecen
a un miembro de la board que lo haya cedido
amablemente, si no que suelen ser servidores
de empresas o instituciones que han sido
hackeados por los miembros de la board.
Estos servidores hackeados para el fin de ser
utilizados como medio de distribucin son los
llamados Dumps.
Aqu es donde entra precisamente el tema de
la fiabilidad que mencion antes, ya que,
dependiendo de la calidad del creador de los
Dumps, ser ms o menos fcil que el
administrador legtimo de la mquina se de
cuenta del hackeo y cierre el Dump. Por eso,
la vida de los Dumps en muchos casos no es
muy larga.
Claro que... tambin existen otro tipo de
administradores... Imaginaos que un buen da
descubrs que en vuestro disco duro han
aparecido misteriosamente 100 pelculas de
estreno en DivX, 400 discos en MP3, y los
ltimos juegos del mercado. Al da siguiente,
el contenido ha sido renovado, apareciendo
cada da las ltimas novedades en el disco
duro de tu ordenador... sin que t muevas un
dedo! Es un sueo?? Pues no! Es
precisamente lo que se encuentran los
administradores de sistemas que descubren
que les han montado un Dump en su servidor.
Por eso, algunos administradores consideran
un chollo el que utilicen su disco duro como
medio de almacenaje para gran cantidad de
productos que, sin duda, pueden interesar al
propio administrador. En caso de que haya
algn problema... los delincuentes son los que
han creado el Dump, y l es slo una pobre
vctima. :-)
2.4.4. Comandos RAW para FXP
Antes de explicaros la secuencia de comandos
RAW que se utiliza para hacer un FXP, os
propongo como ejercicio que tratis de pensarlo
vosotros mismos. Despus, podis comprobar
si habis acertado leyendo lo que os explico a
continuacin. :-)
Supongamos que tenemos dos servidores:
Ll enoServer y Vaci oServer. El servi dor
LlenoServer est lleno de cosas interesantes,
y el servidor VacioServer est vaco por lo que,
por un simple principio de smosis, habr de
ser rellenado raudamente por un simptico
Courier llamado PyC. Vamos a ver paso a paso
cmo lo consigue.
2.4.4.1. PyC entra en LlenoServer
En primer lugar, PyC entrar en el primer servidor
por el mecanismo clsico de login en FTP (ya
sabes: USER y PASS...)
2.4.4.2. PyC entra en VacioServer
Si somos unos valientes y lo estamos haciendo
mediante Telnet, tendremos que utilizar otra
ventana de Telnet para hacer esta segunda
conexin.
El software preparado para hacer FXP (como
el archiconocido FlashFXP) permite realizar las
2 conexi ones en una sol a apl i caci n.
2.4.4.3. PyC entra en los directorios
adecuados
PyC tendr que situarse dentro del directorio
de LlenoServer donde estn los archivos que
quiere transferir al otro servidor, y dentro de
VacioServer tendr que situarse en el directorio
que tenga permisos de Upload.
2.4.4.4. PyC le dice a LlenoServer que
quiere establecer un canal de datos
Aqu empieza lo interesante. El truco del FXP
consiste en conseguir establecer un canal de
datos entre los dos servidores, por lo que el
primer paso es decirle al servidor que contiene
los archivos que queremos establecer un canal
de datos.
Lo que queremos saber es qu puerto nos abrir
LlenoServer para el canal de datos, para luego
decrselo a VacioServer, as que el comando
que ej ecutamos en Ll enoServer ser
simplemente:
PASV
A lo cual el servidor nos responder con una
IP (la suya) y un nmero de puerto, que es
preci samente l o que queremos. :-)
(130,206,1,5,190,189)
2.4.4.5. PyC le dice a VacioServer
que quiere establecer un canal de datos
Ahora el que decide cmo se crear el canal
no es el servidor, si no t. Por tanto, en este
caso no puedes establecer el canal mediante
modo pasivo. Lo que tienes que hacer es
establecer un canal utilizando la IP de
LlenoServer y el puerto que ste nos devolvi
tras ejecutar el comando PASV.
El comando sera, por tanto:
PORT 130,206,1,5,190,189
2.4.4.6. PyC le dice a VacioServer
que quiere utilizar el canal de datos para
subir un archivo
Supongamos que el archivo que queremos
mover se llama lco.nfo. Bastar con que le
digamos a VacioServer:
STOR lco.nfo
2.4.4.7. PyC le dice a LlenoServer
que quiere utilizar el canal de datos para
bajar un archivo
Aqu, al contrario, haremos:
RETR lco.nfo
y... hop! El archivo comienza a FXPearse :-)
Tambin podramos hacer lo mismo invirtiendo
el sentido del canal de datos (desde VacioServer
hacia LlenoServer), as que os propongo como
ejercicio que pensis cmo sera.
2.5. PORT STEALING
Esta tcnica es similar a las que expliqu en el
artculo de DCC, y que titulaba como
DCC Send Hi jacki ng y DCC Chat
Hijacking.
Si somos observadores, nos habremos dado
cuenta de un detalle interesante, y es que, para
que funcione todo lo que he explicado hasta
ahora, el servidor de FTP debe permitir que un
canal de datos sea utilizado por una IP distinta
a la del usuario que estableci ese canal. Es
decir, al hacer por ejemplo un FXP, la IP desde
la cual se establece el canal de datos es la del
courier (PyC), mientras que la IP que
efectivamente se conecta al canal de datos es
la IP del otro servidor.
Por supuesto, no todos los servidores permiten
esto. De hecho, suele ser un parmetro de
configuracin en cualquier software de servidor
FTP. Si permites que esto ocurra, estars
facilitando una gran variedad de ataques (FTP
Bounce, Port Stealing, ...). En cambio, si no lo
permites, no se podr hacer FXP a tu servidor.
Por tanto, a la hora de configurar un servidor
de FTP, cuando te encuentres con este
parmetro, slo has de plantearte una pregunta:
Quiero que mi servidor pueda hacer FXP?
Si la respuesta es SI, entonces configura tu
servidor para que permita conexiones con IPs
diferentes.
Si la respuesta es NO, entonces cierra esa
posibilidad.
En caso de que nos encontremos con un
servidor que SI permita esto, tendremos abiertas
las puertas para el Port Stealing. Claro que...
en realidad la cosa es mucho peor, ya que lo
que nunca se podr impedir desde el servidor
es que se haga un Port Stealing contra el
cliente, y no contra el servidor. Pero... mejor
no nos preci pi temos. Vamos a ver
detenidamente cules son las 2 formas de
hacer un Port Stealing, o Hijacking, en FTP.
2.5.1. Port Stealing contra el servidor
Supongamos que nos encontramos con un
servidor que permite hacer FXP. Por tanto,
permite que se conecte a un canal de datos
una IP diferente a la del usuario que lo
estableci. En ese caso... qu nos impide
tericamente conectarnos al canal de datos
que establ ezca otro usuario? Pues,
tericamente, nada. :-)
Ahora bien, en la prctica, la cosa es bastante
ms complicada. Pero vamos a verlo con un
ejemplo.
En esta ocasin, nuestro hroe PyC trabaja
como espa, y su misin es desbaratar los
planes de la oscura nacin de Pollilandia
(www.pollilandia.cjb.net), que pretende dominar
nuestra nacin.
Por suerte, PyC conoce la IP del servidor
principal de los servicios de inteligencia de
Pollilandia, y adems tiene el login y el password
de FTP de un agente de los Pollos (consigui
todo esto gracias a un DCC Chat Hijacking y
un poco de ingeniera social). Por desgracia,
este agente no tiene acceso a los documentos
importantes, si no simplemente a una cuenta
personal en la que se ha dedicado a almacenar
fotos de pollas desnudas (ejem... espero que
deis el significado correcto a esa palabra...).
Pero esto ser suficiente para nuestro
protagonista. :-)
L
o primero que hace PyC es conectarse al s
ervidor FTP utilizando la cuenta del agente. U
na vez dentro, tiene que conseguir lanzar un m
ontn de peticiones para establecer un canal d
e datos mediante modo pasivo. Es decir, ha d
e lanzar un montn de comandos PASV. Si n
o est por Telnet, si no utilizando un cliente
de FTP, puede dedicarse a hacer un reload
para ver el contenido del directorio, o bien
dedicarse a bajar todas las fotos de pollas que,
supuestamente, ocuparn pocos KBs, por lo
que se establecern varios canales de datos en
poco tiempo (este segundo mtodo ser, sin
duda, menos sospechoso por si acaso el admin
revisa los logs del servidor).
El objetivo de ejecutar muchos PASV es
precisamente el mismo que el que explicaba
en el artculo sobre DCC: averiguar qu puertos
nos ofrece el servidor para transferir los datos.
En el mejor de los casos, PyC habr encontrado
algn tipo de patrn: que los puertos que
ofrece el servidor en cada canal de datos pasivo
son consecutivos, que se encuentran dentro de
un rango relativamente pequeo, o bien que
son totalmente aleatorios.
Lo ms habitual es que los puertos sean
totalmente aleatorios, por lo que normalmente
ser realmente complicado hacer un Port
Stealing contra el servidor, ya que habra mas
de 60.000 puertos a muestrear. En cambio, si
se ha encontrado algn patrn en los puertos
que ofrece el servidor por cada comando PASV,
entonces podremos hacer un muestreo de esos
puertos exactamente igual que hacamos con
el DCC.
Supongamos que PyC ha encontrado esta serie
de respuestas ante cada comando PASV que
ha ejecutado:
227 Entering Passive Mode (130,206,1,5,190,172)
Como vemos, los puertos son casi consecutivos.
Despus de un comando PASV, el puerto que
abrir en el prximo no distar ms de 10 con
respecto al anterior. Por cada PASV que
ejecutramos, bastara con muestrear los 10
puertos siguientes para intentar capturar el
prximo canal de datos que intentase establecer
otro usuario.
Supongamos que en el servidor de los Pollos
est conectado, a la vez que PyC, el temible
General PolloDios, lder de los Pollos, con acceso
a todos los documentos secretos. Si se
encontrase bajando en esos momentos un
documento importante, sta sera la secuencia
de comandos que ejecutara su cliente de FTP:
PASV
(130,206,1,5,190,186)
RETR perfido.plan
Pero como nuestro protagonista PyC conoca
ya el patrn de los puertos que abre el servidor
de los Pollos, estaba muestreando el puerto
48826 (os propongo como ejercicio que
comprobis que este es el puerto que ha abierto
el servidor, segn la secuencia de comandos
que os acabo de mostrar), por lo que consigui
establecer l la conexin con el canal de datos,
y colarse en lugar del General PolloDios.
Automticamente, en el cliente de Telnet de
PyC aparecieron los contenidos del prfido plan
de l os Pol l os. Ahora ya sol o fal taba
desbaratarlo...
Ha quedado muy bonito, si, pero... me temo
que tenemos que ser un poco ms
realistas. ;-)
Los problemas del Port Stealing
Existen bsicamente 4 problemas que hacen
que todo esto no sea tan fcil, y son los
siguientes:
- En primer lugar, ya he comentado que la
mayora de los servidores de FTP no siguen
ningn patrn a la hora de ofrecer puertos
para los canales pasivos, si no que ofrecen
puertos totalmente aleatorios. Esto hace
que sea prcticamente imposible hacer un
muestreo de puertos efectivo, a no ser que se
hiciese de forma distribuida y adems se tuviese
algo de suerte.
- En segundo lugar, todo esto era mucho ms
sencillo con DCC por un factor que ya coment
en ese artculo: el factor humano. El tiempo
que transcurre entre que un usuario de IRC
recibe una peticin de DCC (la tpica ventana
que te pregunta si decides aceptar el envo de
un archivo) y entre que la acepta y comienza
la transferencia, es un tiempo que no depende
de una mquina, si no de una persona que
tiene que leer el aviso y decidir si lo acepta o
no. Este tiempo puede ser incluso de varios
segundos, por lo que hay un tiempo realmente
grande para colarse antes de que el usuario
legtimo acepte la peticin.
En cambio, en el caso del FTP, el tiempo que
transcurre entre un comando PASV y el
siguiente comando (LIST, NLST, RETR, o
STOR) es realmente pequeo. A no ser que
sepamos el nmero exacto de puerto y hagamos
un escaneo masivo a ese puerto, ser
relativamente difcil que consigamos colarnos
antes.
- En tercer lugar, como acabo de decir, despus
de un comando PASV hay 4 posibles comandos:
LIST, NLST, RETR, y STOR. Esto puede
suponer un problema, ya que cuando nosotros
capturamos un canal de datos, no tenemos ni
i dea de para qu va a ser uti l i zado.
En los dos primeros casos: LIST, y NLST, no
habr mucho problema, ya que bastar con
que hagamos un Telnet al puerto adecuado y
recibiremos el listado de archivos.
En el tercer caso, con el comando RETR, en
cambio, recibiremos una ristra de bytes, y
tendremos que ser un poco astutos para saber
de qu demonios se trata. Como ya coment
en el artculo sobre DCC, cada tipo de archivo
tiene una cabecera diferente, por lo que podis
llegar a saber de qu tipo de archivo se trata.
Lo que ya no podris saber es el nombre del
archivo, pero eso generalmente no suele ser
un dato de vital importancia.
Pero... y si os quedis esperando como bobos
a que empiecen a llegar los datos y no llega
nada de nada? Entonces probablemente es que
ese canal de datos era para un STOR, por lo
que en ese caso deberas ser TU el que enviase
algo a travs de ese canal (ya veremos esto en
un ejemplo ms adelante). No hay forma de
saber si un canal de datos se utilizar para
recibir o para enviar datos, por lo que una
buena idea sera hacer un programa que tratase
de recibir datos, y si no recibiese nada en un
margen de tiempo, comenzase entonces a
enviarlos l.
- Por ltimo, tenemos un problema que s que
haba tambin con el DCC, y es que el usuario
legtimo no podr conectarse con el canal
de datos que acaba de establecer, por lo
que siempre resultar bastante sospechoso.
2.5.2. Port Stealing contra el cliente
En este segundo caso, al menos segn mi
experiencia, la probabilidad de xito es mucho
ms alta. Y es que, si bien los servidores de
FTP suelen estar bien programados para evitar
este tipo de ataques, los programadores de
clientes de FTP parece que no asistieron a
clase ese da, y muchos son realmente inseguros
en este sentido.
Tanto este tipo de ataque, como el FTP Bounce,
podran ser evitados si tan slo los servidores
de FTP estuviesen configurados para forzar a
que sus usuarios utilizasen siempre modo
pasivo. De hecho, el RFC 2577, el cual
mencion en el artculo anterior, recomienda
expresamente el uso del modo pasivo.
Pero este no es el motivo por el que digo que
muchos clientes de FTP no estn bien
programados.
El motivo es simplemente que utilizan puertos
consecutivos para el FTP activo. Ahora lo
veremos ms detenidamente.
A pesar de ser una tcnica ms efectiva que
la del hijacknig contra el servidor, tiene un
requisito que la anterior no tena, y es que
aqu hay que conocer al usuario cuyas
conexiones queremos capturar. Si recordamos
el artculo sobre DCC, estas son las 3 variables
que debemos conocer para tener xito en un
hijacking:
- La IP de la vctima.
- El puerto que utilizar la vctima para su
canal de datos.
- El instante en el que la vctima abrir ese
canal de datos.
Existe una forma idnea para conseguir
simultneamente los 3 datos que necesitamos,
y consiste simplemente en abrir una cuenta a
la vctima en nuestro propio servidor.
Vamos a verlo continuando con el ejemplo.
Una vez que PyC estudi con detenimiento los
detalles del plan de los Pollos, se dio cuenta de
que parte del plan consista en que el General
PolloDios enviase al servidor un boletn diario
de rdenes que deban bajar todos sus agentes
para ejecutarlas. As que PyC decidi capturar
el prximo boletn de rdenes de PolloDios,
para modi fi carl o a su conveni enci a.
Gracias a las increbles habilidades de ingeniera
social de PyC, ste descubri que el General
PolloDios era el fan nmero uno de Jackie-
Chan, por lo que mont un servidor FTP con
todas sus pelis en DivX, y consigui abrir en l
una cuenta a PolloDios.
Ahora su esperanza era que PolloDios no utilizase
modo pasivo, pero... en cuanto se conect
PolloDios PyC comprob desconsolado que, en
efecto, utilizaba modo pasivo. :-(
Pero eso no era problema! PyC record que
es un problema habitual el de los servidores de
FTP con modo pasivo cuando se encuentran
detrs de un firewall, sobre todo si el servidor
no se aloja en el puerto 21, que es el estndar
de FTP, por lo que decidi informar a todos los
usuarios de su FTP de que el modo pasivo no
funcionara en su servidor, debido a que ste
se encontraba detrs de un firewall. As que
ahora todos los usuarios, incluido PolloDios,
estaban forzados a utilizar modo activo. ]:-)
Lo nico que tena que hacer ahora PyC era
fijarse atentamente en los logs de pantalla
de su servidor. Su objetivo era conseguir que
PolloDios estableciese muchos canales de
datos, para poder buscar el patrn que seguan
los puertos que utilizaba en los comandos
PORT, por lo que parti las pelis de Jackie-
Chan en archivos RAR de 1MB, para que tuviese
que estar constantemente estableciendo
canales diferentes. Esta fue la secuencia de
comandos PORT que ejecut PolloDios en el
servidor de PyC:
PORT 22,69,22,69,19,236
PORT 22,69,22,69,19,237
PORT 22,69,22,69,19,239
PORT 22,69,22,69,19,242
PORT 22,69,22,69,19,243
Vaya! Esto si que son puertos consecutivos. :-D
Y es que resulta que muchos clientes de FTP
utilizan puertos consecutivos en los comandos
PORT. Pero... por qu a veces hay un pequeo
sal to?. . . no ser que Pol l oDi os se
encuentra al mismo tiempo conectado a otro
servidor de FTP con el mismo cliente, y ste
est alternando los puertos entre uno y otro?
A ver qu pasa si muestreamos ahora el puerto
5108. . . (que podi s comprobar que
sera el siguiente puerto al ltimo que utiliz
PolloDios).
Resul t a que, despus de ej ecut ar:
PORT 22,69,22,69,19,243
en el servidor de PyC, el cliente de FTP de
PolloDios ejecut:
PORT 22,69,22,69,19,244
STOR ordenes.pollodios
en el servidor de los Pollos.
Pero PyC ya estaba preparado, y haba
ejecutado previamente:
telnet 22.69.22.69 5108 > ordenes.pollodios
Por lo que, en el momento en que PolloDios
ejecut el comando:
El cliente de Telnet de PyC se col antes que
el servidor FTP de los Pollos, consiguiendo dos
cosas:
- Evitar que PolloDios enviase el boletn al
servidor.
- Ver el contenido del boletn.
Est e era el cont eni do del archi vo
ordenes.pollodios:
ORDEN: Disparar tortilla atmica T-22
COORDENADAS: N-35, E-87
Vaya, vaya... as que quera lanzarnos una
tortilla atmica... pues les pagaremos con su
propia moneda. ;-)
PyC modific ligeramente el boletn, cambiando
las coordenadas para que fuesen las del cuartel
general de los Pollos: N-22, E-69. Llam al
nuevo archivo: ordenes.pyc.
Como PolloDios vio que la transferencia del
boletn haba fallado (ya que la haba capturado
PyC, aunque l desconoca que ese era el
motivo), decidi reintentarlo, pero esta vez
utilizando modo pasivo, para ver si ah se
encontraba el problema. As que ejecut en el
servidor de los Pollos:
PASV
Pero lo que no saba es que PyC ya estaba
preparado, y haba lanzado inmediatamente un
Port Stealing contra el servidor de los Pollos,
haciendo:
telnet 130.206.1.5 48829 < ordenes.pyc
Por lo que el boletn que aparicin en el disco
duro del servidor de los Pollos no fue el de
PolloDios, si no el de PyC, que apareci no con
el nombre que le haba dado PyC (ordenes.pyc),
si no con el nombre que haba especificado
PolloDios en su comando STOR, es decir:
ordenes.pollodios.
Inmediatamente, los agentes Pollo comenzaron
a conectarse al servidor para bajar el ltimo
boletn de rdenes y, sin pensrselo dos veces,
lanzaron la tortilla atmica sobre el cuartel
general de los Pollos, tal y como indicaban
sus rdenes, terminando as para siempre
con la amenaza de los temibles Pollos
colonialistas. ;-D
2.5.3. Resumen del Port Steal i ng
Quiz no han quedado del todo claros los efectos
de los diversos tipos de Port Stealing, ya que
son 4 diferentes:
- Contra el servidor, y contra un comando
RETR, LIST, o NLST
- Contra el servidor, y contra un comando
STOR
- Contra el cliente, y contra un comando RETR,
LIST, o NLST
- Contra el cliente, y contra un comando
STOR
Resumo en una tabla lo que se puede conseguir
con cada uno de los 4:
2.6. APERTURA DE PUERTOS EN
FIREWALLS
Os habis fijado cuando he comentado que
algunos servidores FTP no funcionan en modo
pasivo si ests detrs de un firewall?
Seguramente os habr extraado el detalle
que he mencionado de que esto ocurre cuando
el servidor no se aloja en el puerto 21. Ahora
mismo os explico a qu se debe esto, porque
precisamente con esto est relacionada la
tcni ca que expl i car a conti nuaci n.
2.6.1. Servidores de FTP detrs de un
firewall
Si sois un poco avispados, se os habr pasado
por la cabeza una idea, sobre todo si estudiasteis
con detenimiento mi artculo sobre DCC. Y es
que en ese artculo explicaba que, si ests
detrs de un firewall, tienes que abrir
explcitamente una serie de puertos en el
firewall para que pueda funcionar el DCC. Pero
entonces, qu ocurre con el FTP, donde los
servidores abren puertos aleatoriamente cada
vez que se quiere abrir un canal de datos en
modo pasivo? Evidentemente, no se pueden
abrir 64.000 puertos en el firewall, entre otras
cosas, porque entonces el firewall no servira
para nada. Y lo que tampoco es solucin es
restringir el nmero de puertos para FTP a un
intervalo limitado, ya que entonces estaramos
favoreciendo enormemente los ataques de Port
Stealing contra el servidor.
Ent onc es , c ul es l a s ol uc i n?
Como ya mencion
en el ar t c ul o
anterior, el protocolo
F T P h a s i d o
considerado siempre
como uno de los
p r i n c i p a l e s
p r o t o c o l o s d e
Int er net , desde
luego, mucho ms
importante que DCC.
Por t ant o, l os
f i rewal l s suel en
i mpl ement ar un
mecanismo especial
que per mi t e el
c o r r e c t o
funcionamiento del FTP con puertos aleatorios.
Cualquier firewall decente ser capaz de analizar
los paquetes que circulen a travs de l que
tengan como puerto de origen el 21, que es el
estndar de FTP. Cuando detecte el firewall que
ese paquete es una respuesta a un comando
PASV, ste buscar automticamente dentro
del mensaje de respuesta el nmero de puerto
que se ha devuelto. Automticamente, el firewall
abrir dinmicamente ese puerto de forma
temporal, hasta que se establezca una conexin
con el mismo.
Probablemente os habris encontrado alguna
vez con algn servidor de FTP que no funciona
en modo pasivo (probablemente algn Dump).
Lo ms probable es que ese servidor no se
encuentre en el puerto 21 (como se suele hacer
con los Dumps, para que sean ms difcilmente
detectables) y que tenga precisamente este
problema.
2.6.2. Clientes de FTP detrs de un
firewall
El mismo problema tenemos con los clientes,
pero esta vez con el modo activo. Cmo
puede funcionar un comando PORT utilizando
puertos aleatorios si est detrs de un firewall?
Pues el firewall tendr que incorporar un
mecanismo anlogo, que analice esta vez los
paquetes que tengan como puerto de destino
el 21, y que contengan un comando PORT. El
firewall abrir dinmicamente el puerto
especi fi cado en el comando PORT.
2.6.3. Apertura de puertos utilizando
comandos PORT
Entonces... qu ocurrir si creamos nosotros
nuestros propios comandos PORT a nuestra
conveniencia? Pues, tericamente, que
conseguiremos abrir el puerto que queramos
en el momento que queramos. :-)
Bastar con que nos conectemos a un servidor
FTP cualquiera, como por ejemplo el de
Rediris del que ya os habl, y una vez dentro
ejecutemos por ejemplo:
PORT 192,168,1,1,0,25
Donde 192.168.1.1 es la IP de la mquina en
la que nos encontramos. Con slo enviar este
comando al servidor de Rediris, habremos
abierto el puerto 25 de nuestra mquina para
que alguien del exterior se conecte a l.
Esto no tiene mucho sentido hacerlo en tu
propio PC de casa, pero puede ser un problema
por ejemplo en una empresa en la que los
empleados tengan limitado el acceso hacia y
desde el exterior, o bien puede ser una
herramienta que utilice alguien que ha
conseguido hackear parcialmente tu mquina
para conseguir abrir nuevos puertos para
troyanos o cualquier otro servicio.
Por supuesto, hay firewalls que estn
preparados para evitar este tipo de ataques,
pero os aseguro que hay muchos que no lo
estn. Sin irnos muy lejos, algunas versiones
de iptables de Linux, as como algunos routers
ADSL.
2.7. POSIBLE DoS?
Por ltimo, os planteo un ejercicio interesante
cuyos resultados, sinceramente, desconozco.
0:-)
Hace tiempo, jugando un poco con el FTP
Bounce, se me ocurri una idea un tanto
rebuscada. La idea consista en provocar un
bucle infinito en un servidor de FTP
aprovechando su vulnerabilidad de FTP Bounce.
Imaginemos que tenemos cuenta en un servidor,
cuyo login y password es:
login: PyC
password: LCo
Tenemos un directorio Upload con permisos de
escritura, donde podemos subir nuestros
archivos.
La IP del servi dor es 215.22.69.22.
Pues bien, en primer lugar creamos un archivo
de texto con el si gui ente conteni do:
USER PyC
PASS LCo
CWD Upload
PORT 215,22,69,22,0,21
RETR bucle.dos
Llamaremos a este archivo: bucle.dos.
Si ahora subimos este archivo al directorio
Upload del servidor, y a continuacin ejecutamos
e s t a s e c u e n c i a d e c o ma n d o s :
PORT 215,22,69,22,0,21
RETR bucle.dos
Lo que debera ocurrir es que, debido al FTP
Bounce, el servidor se conectase a s mismo
para enviar la secuencia de comandos que
contiene nuestro archivo, la cual a su vez lo
que hara sera volver a conectarse a s mismo,
y as hasta el infinito.
Personalmente, slo hice esta prueba una vez,
y no funcion, probablemente porque el servidor
no era vulnerable a este tipo de ataques. Pero
apuesto a que habr algn software que s que
sea vulnerable, por lo que os propongo como
ejercicio que hagis pruebas hasta que deis
con algn servidor vulnerable, y analicis los
resultados.
Si lo hacis, de paso me contis los resultados,
que tengo curiosidad. Ya sabis que me podis
encontrar por EfNet. ;-)
Autor: PyC (LCo)
1 . - E L P R O C E S O D E
INVESTIGACIN
1.1. LA FILOSOFA DE LA SERIE RAW
Al ser ste el primer artculo de la serie, tendr
que esmerarme aqu un poco ms para dejar
claros unos cuantos conceptos.
Lo que se pretende conseguir con esta serie
es una comprensin en profundidad del
funcionamiento de los protocolos que funcionan
sobre TCP/IP, y que utilizamos a diario en
Internet (http, ftp, pop3, smtp, irc, ...).
Al igual que el castellano o el ingls son
lenguajes pensados para ser utilizados
directamente por el ser humano, los protocolos
que utilizamos en Internet (o en nuestra red
local) han sido pensados para ser usados
directamente por las mquinas en sus
comunicaciones, y no directamente por el ser
humano. Pero esto no impide que unas mentes
enfermas como las nuestras utilicen tambin
estos protocolos an sin ser mquinas. :-)
Y cual es el fin de esto? Pues el fin principal
es, sin duda, el ansia de saber cmo funcionan
las cosas, en lugar de limitarnos a utilizarlas.
Es decir, el sustituir nuestra idea de los enanitos
transportando paquetes de datos, por conceptos
claros del funcionamiento real de las cosas.
Por supuesto, adems de esta finalidad tan
potica, tenemos tambin otras muchas
aplicaciones ms "prcticas", como ya se ver
en otros artculos como el que me motiv a
iniciar esta serie, o en el apartado final de este
artculo, que saca unas cuantas conclusiones
relacionadas con la seguridad en POP3.
Si nuestro cliente de correo (ya sea un cliente
de correo respetable, o Outlook) es capaz de
conectarse a un servidor de correo y enviar y
recibir mensajes, por qu no vamos a poder
hacerlo nosotros? Hurguemos en las tripas de
los clientes de correo hasta que seamos capaces
de sustituirles! :-D
Evidentemente, aunque conozcamos en detalle
el funcionamiento de estos protocolos, no nos
bastar con dibujar un crculo en el suelo y
vocalizar con voz profunda los comandos que
hemos de enviar al servidor, si no que
necesitaremos siempre alguna herramienta
bsica que nos permita establecer una conexin
con el servidor (de correo en este caso) y
enviarle los comandos, as como poder leer
sus respuestas a los mismos. Para ello
podemos utilizar, por ejemplo, un cliente
de Telnet cualquiera. Esto ser as para
toda la serie. :-)
Por si no lo sabis, cualquier sistema operativo
trae su propio cliente de Telnet, por lo que
SERIE RAW: CONOCIENDO
PROTOCOLOS Y SU SEGURIDAD.
RAW1 pOP3
(protocolo de recepcion de correo electronico)
-Aprenderemos a encontrar informacin sobre protocolos (RFCs)
-Aprenderemos a instalar y manejar rpidamente un sniffer
- Obtendremos una Cuenta POP3 GRATUITA y REDIRECCIONABLE
- Investigaremos el funcionamiento del POP3, uno de los protocolos
ms empleados en la recepcin de emails.
- Capturaremos las CLAVES de acceso de una sesin POP3
- Empezaremos a perderle el miedo al TELNET
- Y mucho ms :)
basta que desde una consola (ya sea una shell
de Linux/Unix, o una ventana MS-DOS en
Windows) escribas "telnet" y pulses enter para
que se abra la aplicacin de Telnet de vuestro
sistema.
Ya hemos explicado... !
Otra forma de abrir el telnet (en Windows
2000/XP) es ejecutarlo directamente. Vamos
al Menu Inicio --> ejecutar, escribimos telnet
y pulsamos aceptar
con lo que obtendremos directamente una
ventana de comandos donde se est ejecutando
nuestro teltet en modo texto.
Si nunca has abierto un Cliente Telnet, debes
estar preguntndote qu es lo que tienes delante
de tus ojos a parte de una inspida e indescifrable
ventana negra pues aunque no lo parezca,
tienes ante ti una herramienta que te permite
conectarte a cualquier servidor y bueno, mejor
sigue leyendo y lo vers por ti mismo.
Antes de continuar, vamos a familiarizarnos un
poco con nuestro nuevo juguete. Lo primero,
como siempre, es pedir ayuda escribiendo un
interrogante y pulsando enter (con esto
accedemos a la ayuda del prpio programa)
Aunque al principio todo esto no te suene de
nada, leete las opciones un par de veces.
Ummm, hay una interesante puesto que nos
ofrece ms informacin: display, pues venga,
escribe display y pulsa enter
PROTOCOLOS - POP3 - PROTOCOLOS - POP3 - PROTOCOLOS - POP3 - PROTOCOLOS - POP3
Ya hemos explicado mil veces cmo abrir una Ventana de
Comandos (o Shell, o Ventana MS-DOS, llmalo como
quieras) desde Windows, consulta los anteriores nmeros
que es muy fcil (para Windows XP: Menu Inicio -->
Ejecutar y escribimos cmd.exe)
Aqu hay una informacin MUY IMPORTANTES
que es "Eco local deshabilitado". Cuando
estemos conectados a un servidor (en este
caso nos conectaremos a un servidor de mail
tipo POP3), nosotros le enviaremos comandos
a ese servidor remoto y l nos contestar; si
tenemos deshabilitado el ECO, nuestros
comandsos NO APARECERN en la pantalla,
por lo tanto es muy recomendable activarlo.
Cmo lo activamos? Pues muy sencillo, fjate
en la pantalla anterior (donde vimos el comando
display) y vemos otro comando interesante:
"set", que nos ofrece entre otras cosas la
posibilidad "set ?" (esto nos mostrar una lista
de opciones para este comando). Venga, escribe
"set ?" (sin comillas, por favor) y pulsa enter.
Podemos ver la opcin "localecho" (habilita eco
local). Pues esa es la opcin que deseamos :)
Recuerda que estas son opciones del comando
set, por lo tanto escribe "set localecho" (sin
comillas) y pulsa enter. Veremos que obtenemos
un mensaje de confirmacin.
A l r e s t o d e
o p c i o n e s d e l
comando set, dales
un vistazo para que
e mp i e c e n a
sonarte
No cierres... !
1.2. DOCUMENTACIN
Pero, por dnde empezamos? Cmo voy a
saber yo lo que hace mi cliente de correo? Yo
slo veo una ventana con un botn muy grande
que pone ENVIAR y muchas cosas ms. Cmo
puedo saber lo que hace cuando le doy a esos
botones? Lo que voy a explicar aqu son
precisamente las dos formas que tenemos de
averiguar el funcionamiento interno de estas
aplicaciones.
La primera opcin es documentarse ya que,
por suerte, hay a disposicin de todo el mundo
documentacin completa y detallada de todos
los protocolos utilizados en Internet. Toda la
documentacin oficial de protocolos de Internet
se encuentra reunida en los llamados RFCs
(Request For Comments), a los cuales se
puede acceder sin ningn problema desde, por
ejemplo, www.rfc-editor.org.
Ah tenemos la base de datos oficial de
documentos RFC. Desde esta web podemos ir
a la opcin RFC SEARCH y escribir, en el caso
concreto de este documento, que trata sobre
POP3, pues lo que queremos buscar: "POP3".
Cada una de las entradas que aparecen tras la
bsqueda es un documento RFC que podemos
leer directamente desde aqu. :-)
Es importante que nos fijemos en el campo
"More Info (Obs&Upd)", donde nos indican si
este documento est obsoleto, si ha convertido
en obsoleto algn otro, o si algn otro
documento complementa el tema con ms
detalles.
Por ejemplo, para nuestra bsqueda de POP3,
tenemos la siguiente tabla de resultados:
NO CIERRES ESTA VENTANA TELNET, que despus
la utilizaremos :)
Aqu vemos que el
RFC1939 es el documento
q u e c o n t i e n e l a
especificacin general del
protocolo POP3, pero que
est a i nf or maci n es
a mp l i a d a p o r l o s
documentos RFC1957, y
RFC2449. Vemos que el
RFC1734 nos da adems
i nf or maci n sobr e el
mecanismo de autenticacin
de POP3.
Lo lgico en este caso es
empezar l eyendo el
RFC1939. Lo ms probable
es que encontremos en l
todo lo que necesitamos, pero si por cualquier motivo necesitsemos ampliar informacin, ya
sabemos dnde hacerlo.
Si lo tuyo no es el ingls, puedes probar suerte en el grupo de traduccin de RFCs al
castellano, en http://www.rfc-es.org/ , aunque me temo que de momento los documentos traducidos
son muy pocos y, adems, un consejo personal, nunca leis un documento tcnico en una lengua
que no sea la original. ;-)
Los RFCs al principio pueden dar un poco de miedo, pero en general suelen ser fciles y rpidos
de leer para una persona con unos mnimos conocimientos bsicos. En caso de que no podis
con ellos, siempre podis utilizar al omnisciente Google para encontrar algn documento ms
orientado al pblico mortal. :-)
Si, an as, lo vuestro sigue sin ser la documentacin tcnica, todava os quedan dos opciones
ms. La primera, leer el siguiente punto, y la segunda, por supuesto, seguir todos los nmeros
de esta revista, que te lo da ya todo masticado. ;-D
1.3. AIREINEGNI
Existen bsicamente dos formas de hacer las cosas: por las buenas, y por las malas.
Por mucho que ciertas "entidades" intenten esforzarse en ocultarnos el funcionamiento de las
cosas, siempre habr alguien suficientemente curioso y suficientemente inteligente como para
hurgar hasta dar con la solucin. En eso consiste precisamente la Ingeniera Inversa (o Aireinegni,
como me gusta a mi llamarla). :-)
Imagnate que te compras una calculadora y, ya que la has pagado y es tuya, quieres saber cmo
funciona. En vista de que no encuentras ninguna informacin al respecto en los manuales ni
en ningn otro lugar, no te queda ms remedio que coger un destornillador y abrirla para ver
que hay dentro. Pero... mierda! No tiene tornillos! Los japoneses se han propuesto esta vez
evitar a toda costa que descubras cmo funciona su cacharro. Pero no podrn contigo! Vas a
por la sierra mecnica y cortas cuidadosamente la carcasa de la calculadora y... Oh, sorpresa!
descubres que en su interior hay 27 japoneses acondroplsicos sacando numeritos de unas cajas
de cartn. Ahora ya sabes cmo funciona tu flamante calculadora :-) (eso si, ahora a ver como
vuelves a cerrar la carcasa para que no se
caigan los enanitos).
Por tanto, la ingeniera inversa consiste en
hurgar en el interior de las cosas hasta deducir
cmo estn hechas y cmo funcionan.
La ingeniera inversa es la base del cracking
(el arte/ciencia de desproteger las copias de
software), pero ha sido tambin ampliamente
utilizada en temas de redes, como el que nos
ocupa a nosotros en estos momentos. Un
ejemplo tpico es el de Samba, que implementa
el protocolo SMB de Microsoft (el famoso
NetBios de Windows) sobre plataformas
Unix/Linux, y que fue desarrollado mediante
ingeniera inversa.
Pero... de qu me sirve a mi esto para mi
misin actual, que es saber cmo funciona el
protocolo POP3? Cmo puedo hacer ingeniera
inversa para conocer un protocolo? Pues para
eso tenemos una herramienta que espero que
conozcis, que es un sniffer. Un sniffer es
bsicamente una aplicacin que nos muestra
los datos que circulan a travs de nuestra
conexin de red.
Cada vez que utilizamos nuestro cliente de
correo para reci bi r correo, estaremos
estableciendo una conexin con un servidor
y envi ndol e una seri e de comandos
para realizar esta tarea. Como el sniffer
captura todo el trfi co que ci rcul a a
travs de nuestras conexiones, capturar
tambin todo el trfico correspondiente
a la conexin con ese servidor gracias
al cual reci bi mos nuestro correo. Si
confi guramos correctamente nuestro
sniffer para que filtre todos los datos
que captura y nos muestre slo los referentes
a esa conexin en concreto, tendremos
una captura de una sesin completa de
conexin entre nuestro cliente de correo
y el servidor desde el que recibimos el
correo. Nos bastar ahora con analizar
esa captura para deducir el funcionamiento
del protocolo que utilizan nuestro cliente
y el servi dor para comuni carse. :-)
1.3.1. CAPTURA DE UNA SESIN POP3
CON EL SNIFFER IRIS
Vamos a ver un ejemplo concreto de esto. Ya
que el espacio para mi artculo es reducido, he
escogido un sniffer muy sencillo, que es el IRIS,
para ver de forma rpida, y sin entrar en
detalle, cmo hacer una captura de una sesin
completa (en este caso, una sesin POP3).
Utilizar Iris 1.0, a pesar de que hay ya una
versin 4.0.5, ya que para lo que vamos a
hacer nos sirve cualquier versin.
En nuestra Web... !
No pretendo dar un cursillo de manejo de IRIS,
por lo que iremos directamente al grano.
Suponiendo que habis instalado y configurado
IRIS correctamente (no tiene ms misterio que
seleccionar vuestra tarjeta de red), voy a dar
una serie de pasos para capturar la sesin
POP3:
1. 3. 1. 1. Confi guraci n del fi l tro
Supongo que, igual que yo, y que cualquier
otro flipado de la informtica (llmalo geek, si
lo prefieres), en tu PC habr ahora mismo
corriendo un cliente de IRC, 4 clientes de FTP,
un navegador, un servidor FTP, etc, etc. En
resumen, que como te pongas a capturar el
trfico de tu red va a aparecer ah desde las
conversaciones que tienes con el gordo peludo
ese que dice ser una preciosa sueca de ojos
verdes, hasta los chorizos de bytes que
componen la foto del bomboncito de la semana.
Por tanto, lo primero que hay que hacer es
decirle a IRIS que filtre slo el trfico que nos
interesa. Para eso tenemos en la columna de
la izquierda una serie de iconos, que son las
En nuestra Web (www.hackxcrack.com) encontrars la
versin 4.0.5 del IRIS. De paso puedes mirarte la pgina
oficial de programa, que nunca viene mal ;)
(http://www.eeye.com)
funciones bsicas del programa. Lo que nos
interesa ahora es el icono Filters. Se nos abrir
una ventana para editar la configuracin de
los filtros. Ah vamos a la pestaa Ports, donde
podemos hacer un filtrado por puertos. En la
lista Well Known Ports seleccionamos POP3,
y aparecer ahora en la lista Filtered Ports,
que es donde estn los puertos que hemos
seleccionado para filtrar. Es importante que
est activada la opcin Inclusive ya que, en
caso contrario, mostrara todos los puertos
excepto los escogidos.
1.3.1.2. Capturando!
Para comenzar la captura, basta con pulsar
sobre el icono Start/Stop Capture, que es
el que parece un botn de PLAY (tambin lo
tenis en el men Capture).
En la versin... !
A partir de este momento, ya estamos
capturando. Lgicamente, no veremos nada,
ya que slo nos mostrar lo que hemos filtrado,
es decir, los datos de las conexiones POP3, y
de momento no tenemos ninguna conexin
POP3 establecida.
As que este es el momento en el que abrimos
nuestro cliente de correo y le decimos que
reciba los mensajes del servidor. Volvemos a
la ventana de IRIS y... magia! se ha llenado
de numerajos y letras. :-)
Una vez que hemos terminado de recibir los
mensajes, podemos dar a Stop en IRIS. Si no
le das al STOP, no podrs hacer el Decode en
el siguiente apartado.
1.3.1.3. Interpretacin
de la captura
Se sale por completo de
este artculo analizar los
paquet es reci bi dos,
aunque os lo recomiendo
como magnfico ejercicio para comprender
perfectamente el protocolo TCP/IP (importante
si hacis esto que prestis atencin, entre otras
cosas, a los Flags del TCP Header), as que
nos limitaremos a utilizar una til herramienta
de IRIS que lo que hace es mostrarnos
directamente la sesin completa, olvidndonos
de los detalles de cada paquete.
De los iconos de la columna de la izquierda
vamos ahora al icono Decode. Pulsamos ahora
el icono Decode Buffer Packets, que lo tenemos
tambin en el men Decode, y nos aparecer
la sesin que acabamos de capturar (POP3
(110)). Hacemos doble click, y nos aparecer
la sesin completa en un formato "legible". Lo
En la versin 4.0.5 del IRIS, cuando pulses sobre filters
vers la opcin EDIT FILTERS. Pulsa sobre ella y vers
una ventana muy parecida a la anterior. Elimina todos los
puertos de la seccin FILTERED PORTS (pulsando el
botn REMOVE ALL *eliminar todos*) y aade el
POP3(110) que lo tienes a la derecha en la seccin WELL
KNOWN PORTS *puertos conocidos* -solo tienes que
pulsar el mouse dos veces sobre POP3(110)- ;p
que aparece en rojo son las respuestas del
servidor, y en azul los comandos que ha enviado
nuestro cliente de correo. Por tanto, lo que
aparece en azul es precisamente lo que
buscbamos! :-D
2. Y AL FIN, EL DICHOSO POP3
Vamos ya a la prctica!
Lo primero de todo es, por supuesto, tener
una cuenta de correo POP3 en cualquier
servidor, ya sea gratuito o de pago. Podis
buscar en Google "pop3 gratuito" para encontrar
cualquier servidor que os de una cuenta POP3.
Bueno, venga, vamos a crear juntos una cuenta
POP3 gratuita. Nos vamos por ejemplo a
http://www.hotpop.com/ y nos aparecer una
Web en la cual hay un botn llamado Signup!,
ya sabes, plsalo ;)
Lee en perfecto Ings todo el contrato ;p, abajo
del todo selecciona las dos casillas y finalmente
pulsa PROCEED
Ahora un
d i mi n u t o
formulario.
No s o t r o s
c o m o
u s u a r i o
h e m o s
p u e s t o
yosoygenial
y como dominio BonBon.net, as que nuestra
di recci n de mai l POP3 gratui ta ser
yosoygenial@BonBon.net :) Tu pon lo que
quieras pero no copies el nuestro o NO PODRS
CREAR la cuenta ;p
El nico punto que te puede hacer dudar es
eso de Authorization Code (Cdigo de
Autorizacin), simplemente escribe ese cdigo
en la casilla inmediatamente inferior Confirm
Authorization (Confirmar Autorizacin) y
ya est. Otro punto que quizs (a algunos) les
impida crear una cuenta es eso de Reminder
Question (Pregunta), es una pregunta que
te har el sistema en caso de que olvides tu
calve, pues pon una pregunta cualquiera y lo
importante es que en la casilla siguiente
Reminder Answer (Respuesta a la
pregunta anterior) pongas una respuesta
SIN DEJAR ESPACIOS EN BLANCO, puesto que
en caso contrario el sistema no lo admitir
como opcin vlida.
Todo esto es muy sencillo y me da hasta
vergenza explicarlo, pero bueno, esto es PC
PASO A PASO no? ;)
Ahora, pulsaremos el botn NEXT (abajo del
todo) y aparecer una ventana donde
seleccionaremos qu servicio queremos. Solo
podemos seleccionar una opcin, BASIC, la
nica que es FREE! (gratuita). Pues venga,
seleccionamos BASIC y pulsamos NEXT.
Ahora nos aparecer un formulario en que
introduciremos los datos que queramos,
volveremos a pulsar next, rellenaremos otro
formulario, pulsaremos next y llegaremos a
una ventana muy interesante.
Hemos seleccionado este proveedor de cuentas
POP3 precisamente porque te permite hacer
forwarding, es decir, redireccionar. Esta pantalla
te explica en perfecto Ingles las ventajas de
poder redireccionar el correo, soluciona (por
ejemplo) un problema muy comn en Espaa:
Imagina que hoy te conectas a Internet
mediante Terra y dentro de unos meses decides
cambiar de proveedor, el mail de Terra dejar
de existir por mucho que ruegues a Telefnica
que te lo deje activo. Si en lugar de utilizar el
mail de Telefnica hubieses utilizado el que
acabamos de crear, solo tendras que
redireccionar el correo hacia la nueva cuenta
de correo de tu nuevo ISP (Proveedor de
Internet), as de sencillo. Bueno, adems sirve
para otras cosas, como no dar a nadie tu
verdadera direccin de correo; si das la que
acabas de crear, cualquier mail que recibas
puedes redireccionarlo a la TUYA (la que te da
tu ISP).
Te dejamos que pienses en ello, mientras, como
para seguir este texto no necesitamos
redireccionar nada, pulsaremos sobre "I want
to keep my mail on the server and use a POP
Client" para empezar de una vez por todas a
utilizar nuestra nueva, permanente y gratuita
Cuenta POP3 :)
Listo!!! Ahora si introduces tu direccin (en
nuestro caso yosoygenial@BonBon.net) y tu
clave acceders a un menu que te permite
configurar tu cuenta. Por ahora lo dejaremos
tal y como est, pero pulsaremos sobre la
opcin POP CLIENT SETTINGS
Con lo que obtendremos los datos necesarios
para poder acceder a nuestra cuenta.
Estos son los datos con los que configuraras
tu Cliente de Correo (por ejemplo el Outlook)
y que nosotros utilizaremos para ejercitarnos
con el Telnet y entender qu es lo que ocurre
cada vez que nos bajamos el correo :)
2.1. ESTABLECIMIENTO DE LA CONEXIN
Mirando la pantalla anterior, podemos ver que
el nombr e del ser vi dor POP3 es
popbonbon.net. Tenemos que abrir una
conexin con ese servidor en el puerto 110,
que es el puerto de POP3, para lo cual podemos
escribir desde una consola (shell de Linux/Unix,
o ventana MS-DOS en Windows) lo siguiente:
telnet pop.bonbon.net 110
Con esto se nos abrir una aplicacin de Telnet
que conectar automticamente con el servidor
de correo, en el puerto de POP3.
S ya tenemos... !
Si ya tenemos el TELNET abierto (y nosotros lo tenemos
activo desde el punto 1.1 de este artculo, recuerdas?
Donde te advertimos que NO CERRASES la ventana
TELNET), entonces, en lugar de utilizar la anterior
instruccin simplemente escribiremos "o pop.bonbon.net
110" (sin comillas) y pulsaremos enter. El resultado ser
idntico.
-- o es el comando OPEN: abrir/establecer conexin
-- pop.bonbon.net es el nombre de dominio donde hemos
creado la cuenta de correo. Ese nombre de dominio
corresponde a una IP y esa IP corresponde a un PC dnde
hay un programa (servidor de mail) que atiende las peticiones
al puerto 110. Si no te queda claro, leete de nuevo el nmero
uno de hack x crack, en concreto el curso de TCP/IP por
cierto, recuerda que el nmero uno puedes bajrtelo GRATIS
de nuestra Web en formato PDF o pedirlo por correo -->
www.hackxcrack.com
Si todo ha ido bien, el servidor nos devolver
una respuesta parecida a esta:
+OK hel l o f r om popgat e(2. 23. 11).
Siempre que la respuesta empiece por +OK es
que todo ha ido bien. :)
Siempre que la respuesta empiece por -ERR
es que algo ha ido mal. :(
A partir de ahora... !
2.2. AUTENTICACIN
Lo primero de todo es identificarnos con nuestro
nombre de usuario y nuestro password. Si
nuestro cliente de Telnet no tiene eco local,
es conveniente que lo activemos antes de
escribir nada, ya que si no no podremos ver el
texto que escribimos nosotros mismos. Esto
ya lo dijimos al principio de este artculo y es
MUY IMPORTANTE. Aqu tienes como ejemplo
el cliente de Telnet de Windows 9x, donde el
eco local se activa en la opcin Preferencias
del men Terminal.
Este es el cliente telnet de Este es el cliente telnet de W Windows 9X indows 9X
Ya estamos preparados para escribir el primer
comando, que va a ser precisamente el que le
diga al servidor cual es nuestro nombre de
usuario.
Suponi endo que nuestro usuari o es
yosoygenial, escribimos:
USER yosoygenial --> este es nuestro user,
tu debes poner el tuyo ;p
(Por supuesto, todas las lneas se terminan con
Intro...). Si todo ha ido bien, la respuesta
habitual ser algo as:
+OK password required.
Ahora tenemos que escribir el password que,
supongamos que es superclave:
PASS superclave --> esta es nuestra clave,
tu debes poner la tuya ;p
Si todo ha ido bien, ya estamos dentro de
nuestra cuenta de correo! Llegados a este
punto, las respuestas del servidor pueden ser
muy diferentes, pero tienen que empezar
siempre por +OK, ya que si algo ha salido mal
en la autenticacin, no estaremos en nuestra
-- 110 es el puerto que escucha el Servidor de Correo
Remoto. Si te intentases conectar en otro puerto, o no se
establecera la conexin o estaras conectndote a otro tipo
de servicio (puerto 80 para Servidor Web, puerto 21 para
servidor FTP tienes una buena lista en el nmero 6 de
PC PASO A PASO).
A partir de ahora YA ESTAMOS CONECTADOS al
Servidor Remoto (en este caso un Servidor POP3). Los
comandos que introduciremos a continuacin NO SON
COMANDOS TELNET, sino comandos de POP3, es decir,
comandos que entender el Servidor de Correo.
No hay que confundirse con esto!!! Haciendo una analoga
entre un telfono y un TELNET diremos que, para establecer
una comunicacin con un telfono primero hay que
descolgar e introducir un nmero al que llamar (en TELNET
en lugar de un nmero introducimos un comando, en este
caso o pop.bonbon.net 110). Pero una vez establecida la
comunicacin, cuando desde el otro lado una persona
descuelga el auricular, dejamos tranquilo el teclado del
telfono y empezamos a hablar en el idioma adecuado, en
nuestro caso Espaol (en TELNET exactamente igual, una
vez establecida la conexin con un Servidor Remoto nos
olvidamos de los Comandos Telnet y empezamos a "hablar"
en el lenguaje de nuestro interlocutor, en este caso un
Servidor que habla POP3).
cuenta :(
2.3. LECTURA DE LOS
MENSAJES
2.3.1. Comando STAT
Como deca, una vez
dentro de nuestra cuenta, el servidor nos
responder de forma diferente segn haya o
no mensajes sin leer en el servidor. En caso
de que no haya mensajes sin leer, la respuesta
puede ser algo parecido a esto:
+OK maildrop ready, 0 messages (0 octets)
(3885111 6291111)
Esto nos di r a que hay 0 mensajes.
En realidad, la forma correcta de hacer esto,
es mediante el comando:
STAT (introducimos el comando y pulsamos
enter)
Por qu es ms "correcta" esta forma? Porque
las especificaciones de POP3 no obligan a que
el servidor nos de esta informacin cada vez
que conectamos, por lo que la forma de
asegurarnos es utilizar el comando especificado
para ello en el protocolo.
Tras este comando, nos debera responder con
2 nmeros, el primero de los cuales ser el
numero de mensajes que hay en el servidor
(en tu cuenta, claro), y el segundo ser el
tamao en bytes de los mismos. Siguiendo con
el ejemplo de que no haya mensajes en el
servi dor, esta ser a una respuesta:
+OK 0 0
2.3.2. Comando
LIST
Antes de segui r
vamos a enviarnos
un mail a nuestra
nueva y reluciente
cuenta de correos, ya sabes, abre tu Cliente
de Correo (Eudora, Messenger, Outlook, Kmail...)
y envate un par de mails diciendo lo guapo
que eres y esas cosas).
Cerramos el cliente de correo y ahora que ya
hemos estrenado la cuenta, la cosa ser
diferente. Volvemos al Telnet y tras completar
la autenticacin (despus del comando PASS)
podramos tener algo como esto:
+OK maildrop ready, 2 message (2163 octets)
STAT
+OK 2 (2163)
Como vemos, hay dos mensajes, de 2163 bytes
(octetos).
Cuando hay ms de un mensaje, podemos ver
el tamao individual de cada mensaje con el
comando:
LIST
Tras esto, obtendramos una lista de los
mensajes, con el tamao de cada uno.
Si queremos ver el tamao concreto de un
mensaje, podemos pasar el nmero de mensaje
como argument o al comando LIST:
LIST 1
Y nos dar slo el tamao del mensaje 1.
2.3.3. Comando RETR
Una vez que ya sabemos los mensajes que hay,
podemos ver el contenido de los mismos. Viendo
el tamao de cada mensaje podemos hacernos
una idea de si el mensaje contendr slo texto,
o tambin un attachment (archivo adjunto). En
caso de que queris ver un mensaje con
attachment, habra que entrar en el tema de
la decodificacin de binarios, y me temo que
esto se saldra del tema. :-(
As que vamos a ver un simple mensaje de
texto. Continuando con el ejemplo anterior, 2
mensajes de 1283 y 880 bytes, por el tamao
deducimos claramente que los mensajes
contienen slo texto y, adems, muy poco
texto. Por qu digo que es muy poco texto?
Porque de esos 956 bytes, la mayora sern la
cabecera del mensaje, como veremos ahora.
Vamos a utilizar el comando RETR para ver el
contenido completo del mensaje 1, de la
siguiente manera:
RETR 1
Si el mensaje existe, y todo ha ido bien, a
continuacin el servidor nos soltar a pelo el
contenido completo del mensaje. Si no tenis
configurado vuestro cliente de correo para
que muestre las cabeceras completas, la
respuesta os sonar a chino, pero si no, lo que
veris ser exactamente lo que veis cada vez
que recibs un mensaje. Explicar las cabeceras
si que se sale del espacio disponible para este
artculo, as que si realmente os interesa podis
investigar por vuestra cuenta. Lo que ms nos
interesar en principio son los 3 tpicos campos
que podemos ver siempre que recibimos un
email: From (el "supuesto" emisor del
mensaje), To (el destinatario del mensaje), y
Subject (el asunto del mensaje). Buscando
en el chorizo que compone la cabecera podris
encontrar esos tres campos sin problemas.
CABECERA CABECERA
MENSAJE MENSAJE
El cuerpo... !
El cuerpo del mensaje original contiene dos frases:
- Aqu estamos pasando el rato y probando acentos
- Aqu estmos pasndo l rto y probndo acntos
Como curiosidad, fjate que en la Ventana telnet las tildes
son sustituidas por smbolos y letras. Si recogieses los
mails mediante un Cliente de Correo, veras que aparecera
el mensaje original perfectamente construido (con tildes).
Por qu ocurre esto? Por qu no vemos las tildes en el
Telnet?
Como ya hemos ido aprendiendo, todo funciona mediante
estndares, y el correo electrnico no es diferente. En
principio un Cliente de Correo solo puede leer
(entender/interpretar) caractres ASCII. En la pgina 58
del nmero 3 de Hack x Crack ya os dimos una tabla ASCII,
puedes comprobar que para una letra acentuada NO EXISTE
traduccin ASCII, por lo tanto, cuando se introduce un
valor no interpretable mediante ASCII, este es transformado
(traducido) a lo que podemos llamar un ASCII-Extendido
(una ASCII ampliado).
Esta transformacin la hace el Cliente de Correo
directamente y de forma transparente para el usuario.
Cuando envas en un mail la vocal i acentuada, el Cliente
(Outlook por ejemplo) ENVIAR la cadena "=ED" en
lugar de "" ummm entonces por qu cuando recibo
2.3.4. Comando TOP
Y si en lugar de 956 bytes el mensaje ocupa
30000 bytes y an as queremos ver, por
ejemplo, quien nos enva ese mensaje?
Tenemos que tragarnos los 30KB de mensaje
solo para buscar un dato de la cabecera? Para
evitar eso tenemos precisamente el comando
TOP.
Este comando nos permite ver slo las primeras
lneas de un mensaje, sin necesidad de bajar
el mensaje entero. As, si escribimos:
TOP 2 20
El servidor nos mostrar las 20 primeras lneas
del mensaje nmero 2. Podremos as ver la
cabecera para hacernos una idea de si nos
i nteresa o no el resto del mensaje.
Este comando me fue muy til hace aos,
cuando utilizaba una cuenta shell con espacio
limitado la cual se me saturaba cada vez que
alguien me enviaba un archivo adjunto
relativamente grande. Cuando intentaba recibir
mi correo desde la cuenta shell, slo poda
recibir los mensajes que haba antes del mensaje
grande, ya que al llegar a ese punto daba un
error y no haba manera de recibir el resto de
mensajes. Mi nica solucin, aparte de dar el
coazo al administrador del sistema, era
conectarme por Telnet al servidor POP3, ver
mediante el comando TOP si ese mensaje
gordo me interesaba, o lo poda borrar
directamente, y arreglar el entuerto sin
necesidad de conectarme a mi cuenta shell
saturada.
2.3.5. Comandos DELE y RSET
Pero, cmo borraba ese dichoso mensaje que
me estaba saturando la cuenta? Pues para eso
tenemos el comando DELE, que lo que hace
es precisamente eliminar un mensaje del
servidor. Este comando es muy importante, ya
que el proceso que sigue un cliente de correo
(a no ser que se configure para que acte de
otra manera) al recibir el correo es el siguiente:
1- autentificarse para entrar en la cuenta
(USER y PASS, u otros si stemas de
autenticacin que no puedo explicar por falta
de espacio, como son APOP y AUTH)
2- ver los mensajes que hay en el servidor
(STAT y LIST, y posiblemente otros comandos
que tampoco expl i car, como UIDL)
3- bajar los mensajes al PC local del usuario
(RETR)
4- borrar los mensajes ya bajados del servidor,
ya que los tiene ya el usuario en su PC (DELE)
5- salir de la cuenta (QUIT)
Por tanto, una vez se hace un RETR de un
mensaje, es habitual que queramos liberar el
espacio en el servidor, ya que ese mensaje ya
lo hemos ledo. Para borrar el mensaje nmero
3, por ejemplo, haremos:
DELE 3
Si por cualquier motivo nos arrepentimos de
haber borrado algn mensaje, podemos
echarnos atrs, siempre y cuando estemos
todava en la misma sesin, utilizando el
siguiente comando:
RSET
Este comando anular todos los DELE que se
hayan hecho en esa sesin.
2.3.6. Comando QUIT
Un premio para el que adivine qu hace este
comando...
La nica consideracin a tener en cuenta es
que, cuando se cierra la sesin con QUIT, es
el momento en el que se hacen efectivos los
comandos DELE, por lo que a partir de este
momento los mensajes que se hayan borrado
sern ya irrecuperables.
un mail veo la i acentuada? Pues porque Outlook, cuando
recibe esa cadena, la transforma de nuevo en "". Es como
un traductor automtico.
Si quisiesemos profundizar en el problema, deberamos
hablar del standar MIME (Multipurpose Internet Mail
Extensions Encoding), la IETF (Internet Engineering Task
Force), cmo es tratada la cabecera de un mail (en estricto
USA-ASCII), cmo es tratado el mensaje (depende de la
codificacin especificada en la cabecera) y unas cuantas
cosas ms poco a poco llegaremos :)
2.4. CONCLUSIONES DE SEGURIDAD
En POP3 hay bsicamente 3 mecanismos
diferentes de autenticacin, de los cuales slo
he explicado uno por falta de espacio. Este
mecanismo es el que utiliza los comandos
USER y PASS, como hemos vi sto.
Supongo que entre vosotros habr unos cuantos
avispados que se habrn frotado las manos al
descubrir que los passwords llegan hasta el
servidor sin ningn
tipo de codificacin ni encriptacin (cosa que
no ocurre cuando se realiza la autenticacin
mediante los comandos APOP o AUTH).
En efecto, si vuestro PC est en una red local
con varios usuarios, e instalis un sniffer en
vuestro PC, podris ver sin ningn problema
todos los passwords de correo de los usuarios
que utilicen cuentas con este tipo de
autenticacin. Por supuesto, no slo podris
ver los passwords, si no tambin el resto de
la sesin POP3, que incluye el contenido de
todos los mensajes.
Suponiendo que consiguieseis robar algn
password por este sistema, o por cualquier
otro, y quisieseis ver el correo de la pobre
vctima sin que sta se entere, est claro que
no podris hacerlo utilizando un cliente de
correo por las buenas, ya que ste borrar los
mensajes una vez ledos, de tal forma que el
usuario legtimo de la cuenta de correo no
podr leerlos despus de que los hayas
"interceptado" t y eso, aparte de ser una
putada, cantara mucho tras varios das sin
recibir un slo mensaje. Una solucin a esto
sera ver el correo tal y como os he explicado,
utilizando un cliente de Telnet, y escribiendo
vosotros mismos los comandos que os interesen,
es decir, cualquiera menos el comando DELE,
que sera el que jodera el invento. Por supuesto,
otra solucin sera configurar vuestro cliente
de correo para que no borre los mensajes una
vez ledos, pero... eso sera menos divertido,
verdad? ;-)
PyC_LCo (La Corporacin)
PC P
PC P
ASO
ASO
A
A
P
P
ASO
ASO
1. Documentacin
Como ya vimos en el nmero anterior de la
serie RAW, hay bsicamente 3 formas de
investigar el funcionamiento de un protocolo.
Como breve resumen, os las recuerdo:
1- Leer los documentos tcnicos adecuados
(RFCs)
2- Realizar ingeniera inversa mediante un
sniffer
3- Seguir fielmente cada artculo de la serie
RAW en la revista HackXCrack. ;-)
Con respecto al primer punto, podis comprobar
que, si buscamos el trmino "SMTP" en la Web
of i c i al de l os doc ument os RFC
(http://www. rfc-edi tor. org), nos
aparecern una cantidad importante de
entradas, por lo que es fcil que nos perdamos.
En realidad, es fcil encontrar el documento
adecuado si recordamos lo que ya cont sobre
el campo "More Info (Obs&Upd)", pero os
ahorrar el trabajo, dicindoos que el documento
que a nosotros nos interesa ahora es el RFC
2821 (ftp://ftp.rfc-edi tor.org/i n-
notes/rfc2821.txt). Si, an as, os habis
molestado en mirar los resultados de la
bsqueda (espero que no seis tan vagos como
para no haberlo hecho), habris visto un montn
de documentos que incluyen en su ttulo el
trmino "service extension". Como ya
veremos a lo largo del artculo, SMTP es un
protocolo con unas funciones muy bsicas que
se ampla de forma modular con una serie de
extensiones opcionales, que estarn o no
implementadas dependiendo de cada servidor,
y que son precisamente las llamadas "service
extension".
Podemos ver que estudiar el protocolo SMTP
es bastante ms complicado que estudiar el
POP3 (por algo empezamos la serie RAW por
POP3 ;-), ya que no slo tenemos un RFC de
79 pginas con la funcionalidad "bsica", si no
adems un buen taco de documentos sobre
cada una de las "service extension". Pero
RAW2: SMTP (Protocolo de
envio de correo
electronico)
- Conoceremos el funcionamiento del transporte de correo electrnico.
- Recordaremos el funcionamiento de Telnet.
- Aprenderemos a codi fi car y decodi fi car passwords de correo.
- Capturaremos claves de correo mediante un sniffer.
- Aprenderemos a suplantar la personalidad de cualquier cuenta de correo.
- Enviaremos mensajes a destinos imposibles.
- Aprenderemos a detectar si nos hacen a nosotros alguna de estas cosas. ;-)
- Y mucho ms!
tranquilos, que en este artculo os lo daremos
ya todo masticadito. ;-D
2. Mecanismo bsico del correo
electrnico
Antes de continuar, es importante que tengis
bien claro que lo explicado en este artculo (y
en el anterior) no es aplicable a las cuentas
de correo por Web.
Como vimos en el artculo anterior, el protocolo
POP3 se utiliza tan slo para la recepcin del
correo electrnico y, como veremos ahora,
SMTP es el protocolo que se utiliza para el
envo. Para comprender por qu se utilizan dos
protocolos diferentes para un mismo servicio
(el correo electrnico, o e-mail), vamos a ver
de forma rpida el funcionamiento del correo
electrnico mediante una "historieta" de
ejemplo.
En nuestra historia hay 3 personajes: Pringaete,
Macizorra, y Musculitos.
Pringaete Macizorra Musculitos Pringaete Macizorra Musculitos
Nuestro amigo Pringaete ha decidido armarse
de valor y declarar su amor a Macizorra y, como
es bastante cortado, el mejor medio que ha
encontrado para hacerlo es el correo electrnico.
Para ello dispone de una cuenta de correo en
un ISP llamado Buanad, y conoce la direccin
de correo de Macizorra, en un ISP llamado
JotMail. As que Pringaete escribe en su cliente
de correo (Eudora, Outlook, Kmail, o el que
sea) el siguiente mensaje:
From: pringaete@buanadu.es
To: macizorra@jotmail.com
Subject: te amo
Estas mu buena. Quieres salir conmigo?
Fdo: Pringaete
Cuando ya ha redactado su bonita declaracin
de amor, pulsa el botn ENVIAR y unos enanitos
mgicos meten el mensaje en una caja de
zapatos y lo llevan volando hasta la bella
Macizorra... o no es as? No habamos quedado
en el artculo anterior en que los enanos mgicos
slo se utilizan para construir calculadoras
japonesas, y no para transportar paquetes?
Vamos a ver entonces que es lo que ocurre en
realidad desde el instante en que Pringaete
pulsa el botn ENVIAR.
2.1. El PC de Pringaete se conecta con el
servidor SMTP de Buanad.
Lo primero que hace el cliente de correo de
Pringaete cuando ste pulsa el botn ENVIAR,
es conectarse al servidor SMTP de Buanad.
Cuando Pringaete configur su cliente de correo,
tuvo que introducir un par de datos, que eran:
la direccin del servidor POP3 de Buanad
(para poder recibir su correo, tal y como vimos
en el artculo anterior), y la direccin del
servidor SMTP de Buanad (para poder enviar
su correo, tal y como veremos ahora). As que
su cliente sabe perfectamente dnde debe
conectarse. Una vez establecida la conexin,
el cliente enva una serie de comandos al
servidor de Buanad, los cuales veremos en
detalle ms adelante y, una vez enviados esos
comandos, cierra la conexin y se olvida para
siempre del tema, dejando el problema en
manos del servidor de Buanad.
SERIE RAW: PROTOCOLO SMTP - SERIE RAW: PROTOCOLO SMTP - SERIE RAW
La conclusin a la que hemos llegado es que
nuestro cliente de correo no tiene que
preocuparse de cmo localizar el servidor de
Jotmail, en donde se encuentra la cuenta de
correo del destinatario, Macizorra, si no que
delega por completo en el servidor de SMTP
para el cual fue configurado (el de Buanad),
el cual se encargar, en los siguientes pasos
que veremos ahora, de transportar el mensaje
hasta su destino final.
2.2. El servidor SMTP de Buanad busca
el servidor SMTP de Jotmail.
Esto lo cuento muy brevemente, ya que lo que
nos interesa a nosotros en este artculo es el
primer paso, que ya he explicado, es decir, la
conexin entre el cliente de correo y el servidor
de SMTP. A partir de ese momento, ya no
tendremos control sobre lo que ocurre con
nuestro mensaje, por lo que lo que realmente
nos interesa es precisamente hasta ese punto.
Como bien dice el epgrafe, una vez que
Pringaete ha cerrado la conexin entre su
cliente de correo y el servidor SMTP de Buanad,
ste ltimo se encargar de transportar el
mensaje hasta el servidor de Jotmail, que es
desde donde podr leerlo Macizorra. Para ello
utiliza un mecanismo del clsico servicio de
DNS (DNS MX, o DNS Mail eXchanger
mecanism) en el que no entraremos en detalle.
Estad atentos a la revista, porque es probable
que dedique algn nmero de la serie RAW a
explicar de un tirn varios protocolos tan
sencillos que no merecen un artculo dedicado,
entre los cuales podr encontrarse el protocolo
DNS.
Puede ser que el servidor de Buanad no pueda
localizar directamente el servidor de Jotmail,
para lo cual tendr que utilizar algn otro
servidor de SMTP intermedio, al cual localizar
igualmente mediante el mecanismo DNS MX.
Estos servidores intermedios pueden ser de
dos tipos:
- Relays: Cuando se limitan a hacer de
intermediarios sin realizar ninguna modificacin.
- Gateways: Cuando, adems de transportar
el mensaje, realizan alguna modificacin
necesaria para que ste llegue hasta el destino
final, normalmente por diferencias en los
protocolos utilizados.
2.3. El mensaje llega a la cuenta de Jotmail
de Macizorra.
Hasta que el mensaje de Pringaete llega a la
cuenta de Jotmail de Macizorra, ste puede
haber pasado por varios servidores SMTP
intermedios.
Sin importar cual haya sido el camino que ha
seguido el mensaje, finalmente llegar hasta
el servidor SMTP de Jotmail, el cual se limitar
a almacenar el mensaje en su disco duro, en
espera de que Macizorra se conecte por POP3
(o cualquier otro protocolo de recepcin de
correo electrnico) a su cuenta para bajarlo a
su PC.
Como ya vimos en el artculo anterior, el mensaje
quedar almacenado en el disco duro del
servidor hasta que el cliente POP3 de Macizorra
ejecute el comando DELE.
2.4. Macizorra lee el mensaje.
Una vez que el mensaje est ya en la cuenta
de correo de Macizorra, ste quedar
almacenado en el disco duro del servidor de
Jotmail hasta que Macizorra decida un buen
da comprobar si tiene algn mensaje, para lo
cual conectar mediante POP3 desde su cliente
de correo hacia el servidor POP3 de Jotmail,
tal y como vimos en el artculo anterior. Tambin
podra utilizar otro protocolo de recepcin de
correo (como IMAP), ya que una vez que el
mensaje est almacenado en el disco duro, ya
slo depende de los protocolos que tenga
implementados el servidor de correo para
permitir la recepcin. Desde luego, lo que est
claro es que en nada influye el hecho de que
el mensaje haya sido enviado mediante SMTP
para que luego sea ledo por POP3, IMAP, o
cualquier otro sistema.
3. El protocolo SMTP en detalle
Una vez visto el mecanismo de transporte de
mensajes a grandes rasgos, ya slo queda
entrar en detalle en lo que es el protocolo en
s. Para ello, empezamos por ver la respuesta
de Macizorra a Pringaete:
From: macizorra@jotmail.com
To: pringaete@buanadu.es
Subject: Ajo y Agua
Lo siento, Pringa, pero ya estoy saliendo con
Musculitos. Es una pena, porque si no fuese por
el...
Fdo: Macizorra
Vamos a ver en detalle lo que hace el cliente
de correo de Macizorra para llevar la desgraciada
noticia al pobre Pringaete.
3. 1. Establ eci endo l a conexi n
En el momento en que Macizorra pulse el botn
ENVIAR de su cliente de correo, ste establecer
una conexin TCP/IP con el puerto 25 del
servidor SMTP de Jotmail.
Si queremos hacer esto mismo nosotros, ya
sabemos cual es l a herrami enta que
necesitamos... el todopoderoso Telnet! :-)
Os recuerdo cmo podemos establecer la
conexin con el puerto 25 mediante Telnet.
Supongamos que la direccin de nuestro
servidor SMTP (la que nos indican cuando
damos de alta una cuenta de correo, para que
podamos configurar el cliente Outlook, Eudora,
Kmail, o el que sea) es: smtp.jotmail.com.
Windows 9x:
Para establecer la conexin con el puerto 25
mediante Telnet en Windows 9x (95, 98, Me),
haremos lo siguiente:
Desde el men de Inicio vamos a Ejecutar,
y ah escribimos:
telnet smtp.jotmail.com 25
Una vez conectados, no olvidis activar el eco
local, lo cual podemos hacer desde el men
Terminal de la aplicacin de Telnet, en la opcin
Preferencias.
Windows 2000/XP:
Para hacer esto mismo en Windows XP o
Windows 2000, vamos al men de Inicio,
Ejecutar, y escribimos:
telnet
Una vez dentro de la aplicacin de Telnet,
escribimos:
set localecho
Con lo que activamos el eco local, y ya slo
nos falta escribir:
o smtp.jotmail.com 25
Para establecer la conexin con el servidor.
Linux/Unix:
Desde una consola (shell) simplemente
escribimos:
telnet smtp.jotmail.com 25
Una vez conectados, el servidor SMTP nos
enviar un breve saludo. Lo nico importante
de este saludo es que tiene que empezar por
220 si todo ha ido bien.
Por ejemplo:
220 smtp03.jotmail.com ESMTP
Por cierto, que en este ejemplo esa coletilla de
ESMTP nos indica que el servidor soporta
service extension, lo cual nos ser til para
saber cmo debemos proceder a continuacin,
tal y como explicar en el siguiente punto.
3.2. Saludando con el comando EHLO (y
no es una errata)
Si, ya se que "Hola" se dice "Hello" en ingls.
Entonces por qu este comando se llama
EHLO y no HELLO o HELO?
Pues hay un buen motivo, y es que este
comando se llama EHLO a propsito,
precisamente para diferenciarlo de otro
comando llamado HELO.
El comando HELO era el que se utilizaba en
tiempos remotos para iniciar el dilogo en una
sesin SMTP, pero en la actualidad ste
comando ha sido sustituido por el comando
EHLO, que tiene el mismo objetivo, pero
i ncorpora adems faci l i dades para l a
implementacin de las service extension, tal
y como veremos ahora.
Para mantener la compatibilidad, cualquier
servidor SMTP debe soportar tambin el uso
de HELO, pero lo habitual es que cualquier
cliente salude siempre con EHLO.
Que para qu sirve esto de saludar a una
mquina?
Si recordamos un poco lo que he explicado
antes sobre el camino que segua el mensaje
de Pringaete hasta llegar a Macizorra, sabremos
que bsicamente un servidor SMTP puede recibir
dos tipos de conexiones:
- Conexiones de un cliente (como t,
como yo, y como Pringaete).
- Conexiones de otro servidor de SMTP
(aquellos que se usan como intermediarios para
transportar un mensaje).
Al saludar al servidor le estamos diciendo de
dnde venimos nosotros, es decir, si somos un
cliente de ese mismo servidor, o si traemos un
mensaje desde otro lado.
Para indicar esto lo que hacemos es indicar en
el saludo un nombre de dominio. Por ejemplo:
EHLO jotmail.com
Con esto le estamos diciendo que el dominio
desde el que queremos enviar el mensaje es
jotmail.com.
Vamos a ver la diferencia entre HELO y EHLO:
HELO
Al identificarte con:
HELO jotmail.com
Simplemente estas diciendo: "Hola, vengo desde
Jotmail.com".
Una vez enviado este saludo, podrs empezar
directamente a enviar los mensajes que quieras.
EHLO
Al identificarte con:
EHLO jotmail.com
Ests diciendo: "Hola, vengo desde Jotmail.com,
y adems puedo manejar service extensions".
Una vez enviado este saludo, el servidor SMTP
te enviar una lista de service extension que
puedes utilizar (porque el servidor las tiene
i mpl ementadas). Conoci endo ya l as
caractersticas adicionales que puedes utilizar
en ese servidor, puedes empezar a enviar los
mensajes que quieras, utilizando o no esas
caract er st i cas segn t e convenga.
En algunos casos, estas caractersticas
adicionales (las service extension) no estn
slo para que las use quien quiera, si no que
pueden tambin ser de uso obligatorio. Un
ejemplo tpico de esto es el de las service
extension de autenticacin, que sirven para
exigir un password para poder entrar en la
cuenta de correo.
Pero como.... Qu el usar un password para
poder enviar e-mails es slo una caracterstica
opcional?? Pues, por increble que parezca,
no has ledo mal: el protocolo SMTP no
exige el uso de ningn password, por lo
que cualquier servidor SMTP que no tenga
implementada esta service extension permitir
que cualquiera enve mensajes desde ese
servidor, sin necesidad de tener ninguna cuenta.
3.3. Nos autenticamos? (Tampoco es
una errata. Si os suena mal, mirad el
diccionario :P)
Si os habis enterado un poco de que va el
tema (si no, es por mi culpa, ya que no me
habr explicado con claridad), estaris ahora
pensando que una posible forma de saltarse
la autenticacin es utilizar el comando HELO
en lugar de EHLO, ya que sera algo as como
decirle al servidor:
"Mira, me encantara identificarme con un
password, pero es que resulta que mi cliente
de correo es tan antiguo que no me permite
hacer eso. As que entro por las buenas, vale?
;-)"
Podemos pensar que cualquier administrador
de un servidor SMTP ser lo suficientemente
avispado como para no permitir esto, as que
lo normal es que cualquier servidor que requiera
el uso de autenticacin no permita iniciar una
sesin sin password, incluso habiendo iniciado
la sesin con HELO. Claro que, pensar que
cualquier administrador es lo suficientemente
avispado es pensar mucho, y yo mismo puedo
contaros el caso de un servidor SMTP de un
ISP espaol (cuyo nombre no voy a dar :-P)
que requiere autenticacin, pero slo la exige
si se inicia la sesin con EHLO, por lo que
basta con que utilices HELO en lugar de EHLO
para utilizar ese servidor gratuitamente. 0:)
En el caso de que no tengamos que
autenticarnos, bien porque el servidor no tenga
implementada esa service extension (que, por
cierto, viene documentada en el RFC 2554:
ftp://ftp.rfc-editor.org/in-notes/rfc2554.txt), o
bien porque sea opcional, todo es mucho ms
sencillo (y ms divertido ;-)
As que, si hemos tenido la suerte de dar con
un servidor SMTP que no exige autenticacin,
podemos pasar directamente al punto 3.4. Si
no, tendremos que seguir aqu para ver cmo
solucionar este paso.
3.3.1. Cmo sabemos si tenemos que
autenticarnos?
Que cmo sabemos si el servidor requiere
autenticacin? Slo lo sabremos si saludamos
con EHLO, pues ser entonces cuando el
servidor nos de la lista de service extension
que tiene implementadas.
Si en la lista que nos devuelve el servidor tras
el EHLO, se encuentra una lnea con la palabra
AUTH: mal rol l o. Este servi dor ti ene
i mpl ementada l a servi ce extensi on de
autenticacin.
Como ejemplo de esto vamos a ver la respuesta
que nos da el servidor de cuentas gratuitas del
que hablbamos en el nmero anterior
(www.hotpop.com):
220 smtp-1.hotpop.com ESMTP Postfix
ehlo bonbon.net
250-smtp-1.hotpop.com
250-PIPELINING
250-SIZE 3000000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250 8BITMIME
Como vemos, una de las service extension que
tiene implementadas es la de autenticacin.
Vamos a intentar enviar un mensaje sin
autenticarnos. Lo que viene a continuacin ya
lo veremos explicado en detalle ms adelante,
de momento slo quedaos con la idea de lo
que ocurre al intentar enviar un e-mail sin
habernos autenticado:
mai l f r om: maci zor ra@j ot mai l . com
250 Ok
rcpt to: pringaete@buanadu.es
550 <macizorra@jotmail.com>: Sender address
rejected: Access Deni ed: Thi s server
is for HotPOP.com users ONLY, email
support@HotPOP.com for assi stance.
Como vemos, nos deniega el acceso a esa
operacin (Access Denied), por lo que no hay
ms narices que autenticarse.
En realidad este error se ha producido no slo
por no habernos autenticado, si no porque
para colmo la direccin del origen del mensaje
(macizorra@jotmail.com) ni siquiera
pertenece a una cuenta de este servidor SMTP.
Si hiciesemos la misma prueba, pero utilizando
como origen una cuenta que si que pertenezca
a este servidor, la respuesta ser diferente:
mai l f rom: yosoygeni al @bonbon. net
250 Ok
rcpt to: pringaete@buanadu.es
550 <pringaete@buanadu.es>: Recipient
address rejected: Relaying Denied: Authent
i cat e wi t h POP f i r s t or cont act
support@HotPOP.com
Aqu ya vemos como claramente nos dice que
tenemos que autenticarnos.
3.3.2. Si no hay ms remedio, habr que
autenticarse
Si no hay ms narices, vamos a ello.
Para que pueda realizarse la autenticacin,
tanto el cliente (nuestro programa de correo
electrnico: Eudora, Outlook, Kmail...) como
el servidor (el servidor de correo) tienen que
ponerse de acuerdo con qu sistema de
autenticacin utilizar.
Hay muchos sistemas de autenticacin, algunos
ms seguros que otros, tal y como especifica
el estndar SASL (Simple Authentication and
Security Layer). Podis ver una lista completa
de los sistemas de autenticacin soportados
p o r e l e s t n d a r e n
http://www.iana.org/assignments/sasl-
mechanisms , as como una especificacin
de este estndar en el RFC 2222 (ftp://ftp.rfc-
Cmo se ponen de acuerdo en cual de todos
estos sistemas utilizar? Pues simplemente el
cliente va probando los sistemas que conoce,
y sigue probando hasta que alguno le parezca
bien al servidor, ante lo cual responder con
un cdigo 235, por ejemplo:
235 ok, go ahead (#2.0.0)
Si lo que queremos hacer es realizar una
conexin SMTP mediante un cliente de Telnet,
entonces no tenemos que complicarnos ms
la vida aqu, ya que podemos utilizar el sistema
ms sencillo de autenticacin, que es el PLAIN.
Ahora mismo os explicar como funciona. ;-)
En cambio, si vuestro objetivo es capturar con
un sniffer una sesin SMTP ajena (espero que
sea por una buena causa :-P), entonces os
tocar rezar para que el sistema de autenticacin
no sea de los ms seguros, porque si no os
veris en serias dificultades para extraer la
informacin que deseis "tomar prestada" de
la captura de vuestro sniffer.
Autenticacin PLAIN:
Tenemos una pequea aplicacin que nos va
a solucionar todos los problemas que podamos
tener con la autenticacin, y se encuentra en:
http://www.fourmilab.ch/webtools/ba
se64/. Esta sencilla aplicacin, que est
disponible tanto en ejecutable para Win32 como
en cdigo fuente para cualquier otro sistema
operativo (vaaaale... aceptamos Win32 como
sistema operativoooo...), nos sirve para codificar
y decodificar cualquier texto con el sistema de
codificacin base64, que es el que se utiliza
para la autenticacin.
Vamos a ver rpidamente su uso:
Decodificando en base64:
Si tenemos una captura de una sesin SMTP
realizada con un sniffer (os recuerdo que en
www.hackxcrack.com os podis bajar la
ltima versin del sniffer IRIS, cuyo manejo
explicamos en el nmero anterior), nos
interesar decodificar el texto que envi el
cliente de correo que contena el password
codificado. Para ello, creamos un archivo de
texto con el password codificado que hemos
capturado, al cual llamaremos password.txt.
A continuacin, hacemos lo siguiente, segn
el sistema que utilicemos:
- En Windows:
men Inicio -> Ejecutar -> command.com
Se nos abri r una ventana Ms-Dos.
Vamos al directorio en el que tenemos la
aplicacin que nos hemos bajado para base64.
En ese directorio escribimos:
base64 -d password.txt
- En Linux/Unix:
Desde una consola (shell), vamos al directorio
donde tenemos la aplicacin que nos hemos
bajado para base64, y desde ese directorio
escribimos:
base64 -d password.txt
En ambos casos, lo que nos devolver el
programa ser el resultado de decodificar el
texto en base64. Si todo ha salido bien, nos
devolver un nombre de usuario seguido de
su password. ;-))))
Codificando en base64:
Si, en cambio, lo que queremos es realizar
nuestra propia sesin SMTP a pelo utilizando
un cliente de Telnet, lo que necesitaremos es
precisamente lo contrario. Conocemos el nombre
de usuario y el password, y lo que necesitamos
ahora es codificarlo para poder enviarlo al
servidor SMTP. Para ello, creamos un archivo
de texto que contenga el nombre de usuario
seguido del password, separados por un espacio,
por ejemplo (recordemos el artculo de POP3,
en el nmero anteri or de l a revi sta):
yosoygenial pedo67
Y a este archivo lo llamamos password.txt.
El procedimiento ahora es el mismo, pero lo
que tenemos que ejecutar es lo siguiente:
base64 -e password.txt
Nos devolver el texto codificado tal y como
se lo tenemos que enviar al servidor.
Suponiendo que el texto codificado es este:
IHlvc295Z2VuaWFsIHBlZG82Nw==
Entonces slo tenemos que escribir esto en
nuestro cliente de telnet:
AUTH PLAIN IHlvc295Z2VuaWFsIHBlZG82Nw==
Y... hop! Estamos dentro :-)
3.3.3. Repasemos...
El resumen de todo este barullo es el siguiente:
1- Saludamos con EHLO:
EHLO bonbon.net
2- Si el servidor requiere autenticacin, en la
respuesta al saludo habr una lnea que
contendr la palabra AUTH.
3- Si tenemos que autenticarnos, codificaremos
el usuario y el password con la aplicacin de
base64, y escribimos al servidor:
AUTH PLAIN <el chorizo que nos haya
salido al codificar el usuario y el
password>
3.4. Al fin estamos dentro y empezamos
a redactar el dichoso mail
Se acabaron todos los preliminares para entrar
en la cuenta. A partir de aqu todo ser mucho
ms sencillo, y acabaremos en unos minutejos
:-) (porque no pienso entrar en detalle en el
formato de las cabeceras, ni en el envo de
attachments, que si no ocupo ya toda la
revista :-P).
La redaccin de un mensaje es realmente
sencilla. Slo hay 3 pasos, tal y como iremos
viendo.
El primero de todos consiste en decirle al
servidor, mediante un simple comando (MAIL
FROM), quin es el emisor del mensaje. En
realidad, esto es una patraa, ya que puedes
poner aqu cualquier direccin que se te ocurra,
aunque ni siquiera exista.
Esto en teora se usa ms que nada para que,
en caso de cualquier problema, el servidor sepa
a qu direccin tiene que devolver el mensaje.
En el caso de nuestra querida Macizorra, a la
cual tenamos ya casi olvidada, esto ser lo
que podra enviar en este punto su cliente de
correo:
MAIL FROM: maci zorra@j otmai l . com
Claro que tambin es probable que su cliente,
en lugar de esto, deje este comando en blanco,
es decir:
MAIL FROM:
Y esto para qu? Tal y como se explica en el
RFC, el dejar en blanco este parmetro sirve
para evitar posibles problemas de bucles
infinitos, ya que podra darse el caso de que
un mensaje de devolucin a su vez tuviese que
ser devuelto, por lo que se podra armar un
buen jaleo.
3.5. Seguimos, con el destinatario del
mensaje
A continuacin, le decimos al servidor cul es
el receptor del mensaje. En el caso de Macizorra
ser esto l o que envi ar al servi dor:
RCPT TO: pringaete@buanadu.es
Tras enviar este comando, pueden ocurrir 2
cosas:
- Si no se siguieron bien los pasos anteriores
para entrar en la cuenta, lo ms probable es
que el servidor nos responda diciendo que no
admite RELAY, es decir, que slo quiere que
lo utilicen los usuarios registrados. En ese
caso... ajo y agua :-(
- Si, en cambio, nos responde con un
250 Ok
Entonces una de dos: o seguimos bien los
pasos anteriores para entrar en la cuenta, o
hemos tenido la increible coa de dar con un
servidor que admite RELAY y eso, hoy da, es
un chollo.
Y por qu digo "hoy da"? Pues porque la era
dorada del SMTP ya pas. :'-(
Pero realmente hubo una era dorada! Hace
unos aos, la inmensa mayora de servidores
SMTP no i mpl ementaban si stemas de
autenticacin, por lo que cualquiera poda
utilizarlos para enviar mensajes a diestro y
siniestro, con la increible libertad no slo de
utilizar el servidor sin ser un usuario registrado,
si no adems... de poder enviar mensajes en
nombre de cualquiera! Si, eso es, mensajes en
los que la direccin de origen poda ser
spoofeada o i ncl uso estar en bl anco.
Por suerte o por desgracia, esta increble
inseguridad que antes estaba generalizada
ahora es rara de encontrar, debido sobre todo
a los odiados spammers, que aprovechaban
estas vulnerabilidades para sus aviesos fines.
3.6. Por ltimo, el mensaje en s :-)
El ltimo paso! Ya solo falta enviar el mensaje
en si.
Pero... entonces dnde va el subject y todas
esas cosas? Pues todo eso va incluido en el
propio mensaje, y es lo que constituye la
cabecera del mismo.
Por tanto, un mensaje se compone de una
cabecera y un cuerpo, que es donde va el
mensaje en si tal y como nosotros lo leemos.
Para empezar a escribir el mensaje, tanto la
cabecera como el cuerpo, simplemente tenemos
que escribir el comando:
DATA
Ante lo cual nos responder el servidor con
un cdigo 354:
354 go ahead
3.6.1. Cabecera del mensaje
No voy a entrar en detalles sobre todos los
campos de las cabeceras, as que resumo slo
los ms importantes:
From:
Esta es la direccin de origen del mensaje.
Probad a poner una direccin que no sea la
vuestra, a ver que pasa ]:-)
Seguid leyendo, seguid... que ms tarde os
explicar algo interesante sobre esto. ;-)
To:
Direccin de destino del mensaje. Esta no
es la direccin a la que llegar el mensaje, si
no la direccin que aparecer en el cliente de
correo del que lo lea! Es decir, donde se
especifica la direccin de destino no es aqu,
si no cuando se ejecut el comando RCPT
TO. Por tanto, modificando este campo puedes
conseguir el misterioso efecto de enviar un
email a un amigo y que, cuando este lo abra,
la direccin de destino que el vea no sea la
suya, si no la de cualquier otro. De nuevo, os
aconsejo que sigais leyendo, porque en nuestra
historieta veremos tambin un ejemplo prctico
de esto ;-)
Subject:
Pues eso, el subject o asunto del mensaje
:-P
Subject: Ajo y Agua
3.6.2. Cuerpo del mensaje
Despus de la cabecera, normalmente
tendremos que dejar una lnea en blanco para
que lo que viene a continuacin no se interprete
como parte de la cabecera.
En el cuerpo del mensaje ir no slo el texto,
si no tambin los attachments (archivos
adjuntos), los cuales irn codificados mediante
algn sistema que se especificar en la cabecera.
No podemos meternos con el tema de los
attachments, ya que nos iramos demasiado
por las ramas (quiz en algn otro artculo?
:-m).
Musculitos. Es una pena, porque si no fuese
por el...
Fdo: Macizorra
3.6.3. Fin de mensaje
Para terminar el mensaje, basta con dejar una
lnea en la que tan slo haya un punto, seguido
de un Intro.
.
Ante esto, el servidor responder con un cdigo
250:
250 Ok
3.7. Y si algo hubiese salido mal?
Al igual que en POP3, el protocolo SMTP permite
hacer un "Undo", es decir, anular el e-mail que
se ha redactado para empezar de cero antes
de que sea enviado. El nombre del comando
es exactamente el mismo que en POP3, as
como su funcionamiento:
RSET
3.8. Se acab!
Una vez terminado el proceso de redaccin del
mensaje, ya slo falta salir del servidor y, de
nuevo, lo haremos con el mismo comando que
en POP3:
QUIT
4. Resumen de todo lo visto: EL
MENSAJE DE MACIZORRA A
PRINGAETE
Vamos a ver de un tirn toda la sesin SMTP
que estableci el cliente de Macizorra con el
servidor de Jotmail, para lo cual, antes de
nada, recordamos cual era el e-mail que quera
enviar:
Subject: Ajo y Agua
el...
Fdo: Macizorra
Y esta es la sesin, tal y como hemos ido
viendo paso por paso:
220 smtp03.jotmail.com ESMTP
EHLO jotmail.com
250-smtp03.jotmail.com
250-PIPELINING
250-SIZE 3000000
250-VRFY
250-ETRN
250 8BITMIME
AUTH PLAIN IG1hY2lab3JyYSB0b3lidWVuYQ==
235 ok, go ahead (#2.0.0)
MAIL FROM:
250 ok
250 ok
DATA
354 go ahead
Subject: Ajo y Agua
el...
Fdo: Macizorra
.
250 Ok
QUIT
221 smtp03.jotmail.com
4.1. Y ahora, los deberes
Os dejo como ejercicio una pregunta: Cul
es el password de la cuenta de correo de
Macizorra? Si habis comprendido bien lo que
he explicado sobre la autenticacin, tenis que
ser capaces de extraer esa informacin a partir
de la captura de la sesin SMTP que os acabo
de copiar. ;-)
5. Pringaete contraataca
Nuestro amigo Pringaete es un tipo duro, y
ante los problemas no se pone a llorar y patalear,
si no que busca soluciones. Adems, es un
hombre sin escrpulos, por lo que no se va a
cortar un pelo a la hora de contraatacar. Y es
que resulta que Pringaete es un asiduo lector
de los cuadernos de HackXCrack y, ms
concretamente, de la serie RAW, por lo que
el chaval control a de protocol os. ;-)
El listo de Pringaete se las ha apaado con un
mnimo esfuerzo de ingeniera social para
conseguir la direccin de correo de Musculitos,
que es:
mus c l eman@r equet ev i s i on. net
As que se le ocurre enviar este mensaje a
Macizorra:
From: mus c l e man@re que t e v i s i on. ne t
Subject: Fue bonito mientras dur
Lo siento, Maci, pero he descubierto que no me van
las mujeres, as que lo nuestro se termin. Un besito.
Fdo: Musculitos
Pero... Cmo va a enviar Pringaete un e-mail
en nombre de Musculitos? Necesitar robarle
su cuenta de correo? Pues no! Es mucho ms
sencillo que eso.
Lo nico que tiene que hacer nuestro audaz
protagonista es modificar el campo FROM de
la cabecera del mensaje. :-)
Vamos a ver entonces cmo quedara la sesin
SMTP de Pringaete para enviar este mensaje
spoofeado (es decir, con una direccin de
origen falsa):
220 smtp.buanadu.es ESMTP
EHLO buanadu.es
250-smtp.buanadu.es
250-PIPELINING
250 8BITMIME
A U T H P L A I N
I HByaW5nYWV0ZSBzb3l mcmVhaw==
235 ok, go ahead (#2.0.0)
MAIL FROM:
250 ok
RCPT TO: macizorra@jotmail.com
250 ok
DATA
354 go ahead
From: muscleman@requetevision.net
Subject: Ajo y Agua
Lo siento, Maci, pero he descubierto que no me van
las mujeres, as que lo nuestro se termin. Un besito.
Fdo: Musculitos
.
250 Ok
QUIT
221 smtp.buanadu.es
5.1. Ms deberes
Pues estamos con lo mismo... cul es ahora
el password de la cuenta de correo de
Pringaete? ;-)
6. La gran paliza
Como yo de machista no tengo ni un pelo, no
creis que os voy a hacer creer que nuestra
amiga Macizorra por estar buena tiene que
ser tonta, si no precisamente todo lo
contrario. :-)
Resulta que, casualmente, Macizorra es tambin
una asidua lectora de la serie RAW, por lo
que sigui mi consejo, en el artculo anterior,
de configurar su cliente de correo para ver las
cabeceras completas. As que, ya que nuestra
amiga jams dud de la virilidad de su amado
Musculitos, en cuanto ley ese mensaje qued
un poco mosca, por lo que decidi revisar
detenidamente la cabecera.
Y qu fue lo que descubri? Pues que en la
cabecera del mensaje haba, entre otras,
esta lnea:
Received: from 217-124-12-15.buanadu.es
(HELO buanadu.es) (pringaete@217.124.12.15
with plain)
Vaya, vaya... pero si 217.124.12.15 es
precisamente la IP de Pringaete... y no solo
eso, si no que hasta son tan amables de
decirnos que el usuario que envi ese e-mail
no fue muscleman, si no pringaete...
Y ahora probabl emente os estari s
preguntando: Cmo puede ser que ponga
eso en la cabecera, si Pringaete no escribi
nada parecido en la cabecera cuando redacto
el mensaje?
Pues resulta que la cabecera que llega a
Macizorra no es slo la que escribi Pringaete
a la hora de redactar el e-mail, si no que a
sta se suman varias lneas generadas por
el propio servidor de correo, o incluso por
los posibles servidores intermedios (os acordis
de los relays y los gateways?) por los que pas
el mensaje.
As que, al da siguiente, Pringaete abre su
correo ansiosamente, esperando recibir alguna
declaracin de amor de una supuestamente
decepcionada Macizorra, cuando recibe lo
siguiente:
Fr om: mus cl eman@requet evi s i on. net
To: soyhombremuerto@funeral.net
Subject: la cagaste, majo
Se te ha visto el plumero. Vas a ver como te dejo
la cara. :-)
Fdo: Musculitos
Pringaete qued bastante estupefacto, no slo
por la terrible amenaza, si no tambin por el
hecho de que el destinatario del mensaje no
e r a l , s i n o u n t a l
"soyhombremuerto@f uneral . net",
y en cambio ese mensaje le haba llegado
m g i c a me n t e a s u c u e n t a d e
"pri ngaete@buanadu.es". Eso sl o
poda significar una cosa: Musculitos tambin
es un asiduo lector de la serie RAW y conoce
los oscuros misterios del protocolo SMTP.
(glups...)
Y, cmo ha conseguido Musculitos que
reciba Pringaete un e-mail supuestamente
no destinado a su cuenta? Pues, simplemente,
cambiando el campo TO de la cabecera
del mensaje. Por no poneros toda la sesin,
os pongo slo lo que habra a partir del
MAIL FROM:
MAIL FROM:
250 Ok
250 Ok
DATA
354 go ahead
Fr om: mus c l e man@re que t e v i s i on. ne t
To: soyhombremuerto@funeral.net
Subject: la cagaste, majo
Se te ha visto el plumero. Vas a ver como te dejo la
cara. :-)
Fdo: Musculitos
.
250 Ok
QUIT
221 smtp014.requetevision.net
6. 1. Para termi nar, l os deberes
Pues esta vez no puedo pediros que saquis
el password de la cuenta de correo de
Musculitos, ya que no he copiado la sesin
completa, as que lo nico que puedo poneros
como deberes es que tratis de reconstruir la
cara del pobre Pringaete. ;-)
Autor: PyC (LCo)
Ilustraciones: MariAn (LCo)
PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL
HAY MUCHOS MAS EN
http://pclog.buscalogos.com/
PERSONALIZA TU MOVIL
QUIERES COLABORAR CON PC PASO A PASO?
PC PASO A PASO busca personas que posean conocimientos de
informtica y deseen publicar sus trabajos.
SABEMOS que muchas personas (quizs tu eres una de ellas) han creado
textos y cursos para consumo propio o de unos pocos.
SABEMOS que muchas personas tienen inquietudes periodsticas pero
nunca se han atrevido a presentar sus trabajos a una editorial.
SABEMOS que hay verdaderas obras de arte creadas por personas
como tu o yo y que nunca vern la luz.
PC PASO A PASO desea contactar contigo!
NOSOTROS PODEMOS PUBLICAR TU OBRA!!!
SI DESEAS MS I NFORMACI N, env anos un mai l a
empleo@editotrans.com y te responderemos concretando nuestra oferta.
Tambin necesitamos urgentemente alguien que se ocupe de la
publicidad y de la web de esta editorial, para ms informacin
envanos un mail a empleo@editotrans.com
1. Introduccin
Un mes ms, nos enfrentamos a los protocolos
ms importantes de la red, pero en este caso
se trata de un protocolo muy especial. Y afirmo
esto principalmente por dos motivos. En primer
lugar, porque es un protocolo que utilizamos
constantemente (cada vez que visitamos una
pgina web, cada vez que escribimos un e-
mail, cada vez que conectamos con un FTP,
cada vez que hacemos Telnet a una mquina,
etc, etc). Y en segundo lugar porque, por
primera vez en la ya veterana serie RAW, no
se trata de un protocolo basado en TCP, si no
en el an desconocido UDP!
En realidad el protocolo DNS puede funcionar
tanto con TCP/IP como con UDP/IP, pero en
la prctica el UDP es el que se utiliza, salvo
para ciertas circunstancias especiales que ya
veremos ms adelante.
En vista de la novedad que esto supone,
me veo obligado a comenzar el artculo
explicando brevemente en que consiste el
protocolo UDP, para luego pasar a los
detalles del sistema y el protocolo DNS, y
por l ti mo termi nar expl i cando l o
devastadores que pueden llegar a ser los
ataques contra el sistema DNS. All vamos!
2. El protocolo UDP/IP vs
TCP/IP
No es plan ahora de explicar detalladamente
en qu consisten estos dos protocolos, ya que
esto sera tema no para otro artculo, si no
para una serie completa, as que nos
conformaremos con pillar slo un poco la idea.
Como ya sabemos, todos los datos en TCP/IP
circulan a travs de una conexin entre un
cliente y un servidor. Los datos podrn circular
siempre que se mantenga activa esa conexin,
y si sta se cierra habr que establecer una
nueva conexin si se desea continuar la
comunicacin. Esto significa que el protocolo
TCP/IP es un protocolo orientado a conexin.
Pero si lo pensamos detenidamente, nos
daremos cuenta de que en realidad no se
establece nunca ninguna conexin fsica entre
el cliente y el servidor. En Internet no hay unas
simpticas telefonistas recibiendo todas las
peticiones de conexiones en espera de enchufar
el cable que une el cliente con el servidor, si
no que en realidad todo est conectado con
todo. Por tanto, las conexiones que se establecen
son virtuales.
Fig 1.- Esquema del protocolo TCP/IP,
orientado a conexin
En cambio, en el protocolo UDP/IP, no es
necesario establecer una conexin virtual para
permitir la comunicacin, ya que se trata de un
protocolo no orientado a conexin. En este
SERIE RAW (8)
DNS (Domain Name System)
Todo l l ega, y en esta ocasi n l e ha tocado el turno al PROTOCOLO DNS.
Por primera vez en la Serie RAW vamos a ver un protocola basado en UDP :)
El sistema DNS es el alma de Internet, aprende con nosotros su funcionamiento!!!
caso, el cliente enva los datos directamente
a la IP del servidor, sin ninguna seguridad de
si ste escuchar su peticin, o incluso de si
ste existe. A costa de esta escasa fiabilidad,
el sistema es ms rpido y sencillo que en el
caso de un protocolo orientado a conexin.
Fig 2.- Esquema del protocolo UDP/IP,
no orientado a conexin
En el caso que nos ocupa, que es el del
protocolo DNS, que suele utilizar el protocolo
UDP para el transporte de los datos (igual que
FTP, HTTP, y todos los que hemos visto hasta
ahora utilizaban TCP para el transporte de los
datos), podemos tener cierta certeza de que
el servidor ha escuchado nuestra peticin, ya
que ste responder con otro bloque de datos
en el que nos dar la respuesta a nuestra
solicitud.
El que ya no sabr si esa respuesta nos ha
llegado o no es el propio servidor, ya que
nosotros no le enviaremos ninguna confirmacin
de que la hemos recibido, pero eso ya es
problema nuestro, y en caso de que no nos
l l egase l a respuesta probabl emente
reintentaramos la solicitud.
3. EL SISTEMA DNS
Entramos ya de lleno en el asunto, y
empezaremos con una breve introduccin
(aunque espero que la mayora sepis ya en
qu consiste el DNS), para luego pasar a detallar
la arquitectura y el funcionamiento del protocolo.
Por supuesto, antes de nada os digo cuales
son los RFCs que definen el protocolo, que son
el RFC 1034, y el RFC 1035 (ftp://ftp.rfc-
editor.org/in-notes/rfc1034.txt y ftp://ftp.rfc-
editor.org/in-notes/rfc1035.txt)
Como ya sabemos, cualquier mquina conectada
de forma directa a Internet tiene una direccin
nica que la identifica.
Estas direcciones consisten en un nmero de
32 bits, que se suele representar mediante 4
dgitos separados por puntos. Cada uno de
estos dgitos est en base 256, es decir, estn
comprendidos entre 0 y 255.
Por supuesto, estoy habl ando de l as
direcciones IP. Con 32 bits se pueden
direccionar ms de 4 mil millones de mquinas.
Quiz esto nos pueda parecer mucho, pero en
realidad esta cifra se est convirtiendo en un
problema, ya que se est quedando insuficiente
para el crecimiento exponencial de la red, por
lo que ste es uno de los motivos por el que
se est implantando el sistema IPv6 que
sustituir al actual protocolo IPv4 (y tambin
a otros tantos relacionados directamente), y
que utilizar direcciones de 128 bits, lo cual
permitir direccionar nada menos que varios
sixtillones de mquinas, lo cual es de esperar
que sea suficiente mientras la raza humana
si ga confi nada en el pl aneta Ti erra.
Todo esto os lo cuento para que pensis en el
terrible problema que sera para cualquier
persona tener que acordarse de todos esos
nmeros, o bien tener que consultarlos cada
vez que se quisiera acceder a una mquina,
como si de una gua telefnica se tratase (de
hecho, este sistema de gua telefnica fue el
utilizado en los comienzos de la red Arpanet,
ahora convertida en Internet, en la cual exista
un nico fichero HOSTS.TXT que contena
todas las direcciones de todas las mquinas de
la red). A los seres humanos, en general, no
se nos dan muy bien los nmeros, ya que
preferimos utilizar las palabras. De ah surgi
la necesidad de realizar un sistema de traduccin
de todos esos numerajos a palabras ms
intuitivas y ms cmodas para el uso de los
humanos. Gracias a este sistema, podemos
Serie Raw - DNS - Serie Raw - DNS - Serie Raw - DNS - Serie Raw - DNS - Serie Raw - DNS
escribir en nuestro navegador www.google.com
en lugar de escribir 216.239.39.99 o, lo que
sera peor an:
11011000111011110010011101100011
(que es la direccin IP de Google en binario).
Adems, este sistema de traduccin de IPs a
nombres nos permite tambin no tener que
depender de los cambios de ubicacin de los
servidores. Si, por ejemplo, la IP de Google
cambiase, nosotros no tendramos ni que
saberlo, ya que su nombre seguira siendo el
mismo independientemente de la IP, y sera
problema del sistema DNS el aparselas para
que la nueva IP estuviese asociada a
www.google.com.
3.1. Arquitectura del sistema DNS
Esto que en pri nci pi o puede parecer
relativamente sencillo, no lo es tanto, teniendo
en cuenta que se trata de traducir miles de
millones de direcciones que pueden estar
apareciendo, desapareciendo, o cambiando
constantemente.
Y el resultado de estas traducciones tiene que
estar accesible para todos y cada uno de los
cientos de millones de usuarios de la red. Por
tanto, este sistema requiere ante todo una
arquitectura inteligente que permita llevar a
cabo esta labor sin dar lugar a congestiones
o cual qui er otro ti po de probl emas.
Empecemos imaginando el caso ms sencillo:
un nico servidor DNS en Internet que
mantuviese el registro de la base de datos de
traducciones de direcciones IP a nombres.
Cada vez que visitamos una pgina web, cada
vez que escribimos un email, cada vez que
conectamos con el IRC, cada vez que entramos
en un FTP y, en resumen, cada vez que
hacemos prcticamente cualquier cosa en
Internet, necesitamos realizar una traduccin
de nombres a IPs. Esto ocurre igual para cada
uno de los millones de usuarios de Internet.
Esto supondra que cada usuario lanzara varias
peticiones de traduccin por minuto, lo cual,
multiplicado por el nmero de usuarios de la
red, supondra miles de millones de conexiones
por minuto. Por supuesto, esto es totalmente
imposible de mantener para cualquier servidor.
Y ni que decir tiene del problema que surgira
si ste servidor se cayese, se estropease, o
tuviese cualquier otro problema...
Podemos pensar en una primera solucin que
suavizara bastante las cosas, y es que las
mquinas de cada cliente fuesen almacenando
en su propia memoria las traducciones ya
solicitadas previamente, para no tener que
solicitar una traduccin cada vez que se quisiese
realizar una conexin con la misma mquina.
As surge el concepto de cache de direcciones,
que es un sistema que en efecto se utiliza,
aunque de forma bastante ms compleja, ya
que se realiza a muchos niveles, y no slo en
la mquina del cliente. Pero analicemos la nueva
situacin. Supongamos que, en el mejor de los
casos, el 80% de las conexiones fuesen con
mquinas cuya IP ya se tradujo anteriormente,
por lo que no habra que volver a solicitar la
traduccin. En ese caso, an ese 20% de
conexiones seguiran generando un trfico de
miles de millones de conexiones, imposible de
soportar por ningn servidor.
Por tanto, la nica solucin consiste en
descentralizar el sistema de traduccin. Quiz
se os haba ocurrido desde el principio como la
solucin ms obvia, pero... os habis parado
a pensar en l os i nconveni entes de l a
descentralizacin?
Esto implicara algn mecanismo para mantener
la coherencia de la base de datos de
traducciones, ya que sta ya no se encontrara
ubicada en un nico lugar, si no repartida a lo
largo y ancho del planeta Tierra. De alguna
forma, se tiene que conseguir mantener la
coherencia en una base de datos en la que
aparecen, desaparecen, y se modifican datos
constantemente (cada da se conectan nuevas
mquinas a la red, y otras tantas cambian de
direccin).
La solucin empleada consiste en una estructura
jerrquica tal y como se muestra en el siguiente
grfico:
Pgina PC PASO A PASO N 14
Fig 3.- Ejemplo de jerarqua del sistema
DNS.
Como vemos, en primer lugar existe un dominio
raz (root, tambin representado por un simple
punto .). En este dominio raz existen
actualmente 14 servidores que contienen todos
ellos una base de datos con las direcciones IP
de los servidores del nivel inmediatamente
inferior, es decir, de los servidores de los
dominios .com, .net, .org, .es, etc, etc. En
estas mquinas no hay ms informacin que
esa, por lo que los servidores raz no tienen
ni idea de lo que puede haber por debajo de
cada uno de esos dominios. Por ejemplo, sta
podra ser una tabla ficticia de la base de datos
de un servidor raz:
Esas direcciones IP corresponden a servidores
DNS de cada uno de esos dominios. Estos
dominios que estn por debajo del raz se
denominan TLD (Top Level Domain), y existen
ms de 200 actualmente. Podis ver una lista
de los TLDs correspondientes a cada pas en
h t t p : / / www. i s o . c h / i s o / e n / p r o d s -
services/iso3166ma/02iso-3166-code-lists/list-
en1.html. Aparte de estos, estn los TLDs
genricos, como .com, .edu, .gov, etc. Para
cada TLD, habr varios servidores que
mantendrn una misma copia de otras tablas,
que sern las tablas con las direcciones de los
servidores DNS de los niveles inferiores. Por
ejemplo, para un servidor .gov habra una
entrada correspondiente al servidor de DNS del
dominio nasa.gov, y otra para el servidor de
DNS del dominio whitehouse.gov:
En el dominio nasa.gov, por ejemplo, podramos
encontrarnos con que los servidores son ya una
hoja, es decir, un extremo final dentro de la
jerarqua en rbol del sistema DNS. Por tanto,
aqu las tablas ya no se referiran a otros
servidores DNS de subdominios inferiores, si
no ya a mquinas concretas. Por ejemplo:
Tambin podra tratarse de una tabla mixta, en
la cual, por ejemplo, la entrada jpl.nasa.gov
correspondiese a otro servidor de dominio, y
el resto de entradas de la tabla fuesen ya
mquinas concretas.
Por tanto, el concepto fundamental que hay
que comprender es que cada nivel de la
jerarqua delega por completo en los niveles
inferiores, por lo que es problema de nasa.gov
el cmo gestione su nivel y, si quisiera, podra
aadir o eliminar nuevos subniveles en cualquier
momento, sin tener que informar al nivel raz,
ni a ni ngn otro ni vel superi or a l .
Pero entonces, cuando nosotros configuramos
nuestra conexin a Internet, y tenemos que
especificar las direcciones de los servidores
DNS, estamos introduciendo las IPs de los
servidores raz? Este sera un razonamiento
lgico por lo que hemos visto hasta ahora,
pero en realidad sera una solucin muy poco
efectiva, debido principalmente a dos problemas.
En primer lugar, los cientos de millones de
usuarios de Internet tendran que acceder a
alguno de los 14 servidores raz cada vez que
quisieran solicitar una traduccin. Teniendo en
cuenta el sistema de cache, esto slo ocurrira
pocas veces, ya que existen relativamente
pocos dominios de primer nivel, o TLDs (.com,
.es, .gov, etc), y en cuanto se accediese a una
sola direccin de un determinado dominio, ya
quedara almacenada en nuestra cache la
di recci n de su servi dor de domi ni o.
Pero segn fusemos bajando en la jerarqua
iran ocurriendo cada vez ms y ms solicitudes
por cada usuari o, y tambi n menos
coincidencias de cache.
Por tanto, al final, se tendra una red saturada
de peticiones redundantes, en las cuales
millones de usuarios pediran una y otra vez
las mismas direcciones (pensad, por ejemplo,
cuntos usuarios diferentes habrn solicitado
alguna vez la traduccin de www.google.com,
www.hotmail.com, o cualquier otra direccin
popular).
Pero, aparte de la saturacin de la red, estara
el problema de la saturacin del propio cliente,
ya que ste tendra que realizar varias peticiones
cada vez que tuviese que realizar una
traduccin.
Por ejemplo, si tuviese que traducir el nombre
antwrp.gsfc.nasa.gov tendra que realizar en
primer lugar una conexin con el servidor raz,
en segundo lugar una conexin con el servidor
.gov, en tercer lugar, con nasa.gov, y por ltimo
con gsfc.nasa.gov, el cual le dara la IP
correspondiente a ese nombre. Desde luego,
este si stema ser a muy poco pti mo.
Fig 4.- Ventana de configuracin de
servidores DNS al instalar una conexin
a Internet con un ISP.
Esas IPs no corresponden a servidores raz, si
no a servidores del propio ISP.
La solucin a todo esto consiste en utilizar
servidores de DNS comunes a todos los usuarios
de un mismo ISP (proveedor de Internet, como
Telefnica, Ya, Madritel, Ono, etc). Por tanto,
cuando un usuario de un ISP quiera realizar
una traduccin, la solicitar siempre al servidor
DNS de su ISP. ste ser el que realice todas
las tareas anteriormente descritas. Pero, cual
ser la gran ventaja? Que al ser este servidor
comn para miles de usuarios a los cuales habr
atendido previamente sus peticiones, dispondr
el servidor de una cache bastante completa
que reducir enormemente el nmero de
accesos a otros servidores DNS. Todas las
pginas populares (como Google, Hotmail, etc),
as como las direcciones de los servidores DNS
de los TLDs (como los .com, .net, .org...) se
encuentran sin duda en la cache de los
servidores DNS de todos los ISPs, y su
traduccin normalmente no tiene que ser
solicitada a los servidores de dominio
correspondientes.
Fig 5.- Interaccin tpica entre un usuario
y el servidor DNS de su ISP
Por supuesto, todo esto representara una
situacin ideal, pero en la prctica los contenidos
de cache muchas veces no reflejan la realidad,
al haberse efectuado cambios, por lo que los
servidores DNS han de encargarse de actualizar
sus contenidos de cache con los servidores
que garantizan que sus contenidos estn
actualizados, que son los llamados servidores
authori tati ve de cada subdomi ni o.
Estos servidores authoritative, que son los que
guardan las tablas de traduccin reales para
cada dominio (y no copias de cache), se dividen
en dos tipos: maestro, y esclavos. Para cada
dominio habr un nico servidor authoritative
maestro, y uno o varios esclavos. Cada entrada
de las tablas de traduccin tiene asociado un
parmetro TTL (Time To Live) que indica
durante cunto tiempo se garantiza que esa
informacin es correcta. Cuando se supere el
tiempo de TTL de una entrada, los servidores
esclavos conectarn con el maestro para
comprobar si los datos que contienen son
correctos o han sido modificados. Por tanto,
basta con que se realicen todos los cambios
en el servidor authoritative maestro para
que estos se propaguen automticamente
al resto de servidores authoritative del
dominio.
3.2. Qu ocurre cuando realizamos
una peticin de traduccin?
Teniendo en cuenta esta estructura jerrquica,
vamos a ver el proceso completo desde que
solicitamos, por ejemplo, una pgina web,
hasta que conocemos su direccin IP para que
nuestro navegador pueda realizar la conexin.
Veamos que pasara si, por ejemplo, pusieramos
en nuestro navegador la URL:
http://neworder. box. sk/smsread. php?
newsid=6586
3.2.1. Nuestro navegador analiza la URL
No todo lo que hay en esa URL es susceptible
de ser preguntado al servi dor DNS.
Para empezar, el prefijo HTTP:// es slo una
informacin para que el navegador sepa con
qu protocolo debe acceder a esos contenidos.
E n s e g u n d o l u g a r, e l s u f i j o
/smsread.php?newsid=6586 es slo un nombre
de directorio, que el navegador debe conocer
para solicitarlo al servidor web, una vez que
tenga la IP del mismo, tal y como vimos en el
artculo sobre HTTP del ltimo nmero de la
revista.
Por tanto, la consulta que tendr que realizar
finalmente el navegador al servidor DNS ser
esta: neworder.box.sk.
3.2.2. Nuestro navegador solicita la
traduccin al servidor DNS de nuestro ISP
Aqu terminara la parte visible del proceso para
nosotros, ya que los siguientes pasos seran
asunto de otras mquinas que se pelearan
para conseguir una respuesta, mientras nosotros
nos rascamos la barriga tranquilamente.
Por tanto, todos los esfuerzos de nuestro
navegador consisten en solicitar al servidor DNS
de nuestro ISP la traduccin del nombre que
indicamos en el anterior paso.
Esto es lo que se llama una traduccin
recursiva, ya que nosotros solicitamos la
traduccin de un nombre, y sta nos es devuelta
en una sola respuesta, sin que tengamos que
seguir nosotros uno a uno todos los pasos para
realizar la traduccin.
Fig 6.- Nuestra mquina enva un
datagrama UDP al servidor DNS de
nuestro ISP solicitando la traduccin del
nombre.
3.2.3. El servidor DNS de nuestro ISP
busca en su cache
Ahora la pelota ya est en el tejado del servidor
DNS de nuestro ISP, pero como ste es muy
listo, antes de armar ms jaleo y pasar la pelota
a otro, lo primero que hace es buscar en su
cache a ver si algn otro cliente (o quiz t
mismo en el pasado) ha solicitado antes esa
traduccin, por lo que podra darnos una
respuesta inmediata.
Si no encuentra ese nombre en su cache, no
tendr ms remedio que pasar la pelota.
7.- El servidor nos responde directamente
con la traduccin, ya que tena el dato
en cache.
Suponiendo que no hubiera encontrado la
traduccin en su cache, tendra que hacer una
serie de consultas bajando por la jerarqua en
rbol hasta llegar a la traduccin del nombre
deseado. Al tener que realizarlo paso a paso,
se trata de una traduccin iterativa, al contrario
de la traduccin recursiva que solicitbamos
nosotros como clientes del ISP.
Lo ms lgico sera que el servidor de nuestro
ISP empezase por buscar en su cache si tiene
la direccin del servidor DNS del dominio .box.sk.
En caso de que no fuese as, buscara la direccin
del servidor DNS del dominio .sk, que es ya un
TLD.
Suponiendo que no tuviese en cache ninguno
de estos datos, continuamos viendo el proceso.
consulta a un servidor del dominio raz
Nuestro servidor tendr que empezar por
conectarse con uno de los 14 servidores raz
para solicitar las direcciones de los servidores
DNS del TLD (dominio de primer nivel) .sk. No
tiene problemas para hacer esto, ya que todos
los servidores DNS, aunque tengan su cache
totalmente vaca, conocen siempre las
di recci ones de l os servi dores ra z. Es
responsabilidad de los administradores de los
servidores DNS el mantener al da las direcciones
de los servidores raz.
Fig 8.- El servidor de nuestro ISP consulta
con el servidor raz, y ste le da la lista
de servidores del TLD .sk
El servidor raz le devolvera una lista con las
direcciones de todos los servidores DNS del
TLD .sk. De esa lista, nuestro servidor escogera
uno cualquiera, y continuara el proceso.
El algoritmo de nuestro servidor para escoger
una de las direcciones podra ser tan simple
como escoger siempre el primero de la lista
que le devuelva el servidor raz. Esto podra
suponer un serio problema, ya que la carga del
primer servidor sera enorme, mientras que los
dems servidores prcticamente no se usaran.
Para evitar esto, el servidor raz no nos dar la
lista siempre en el mismo orden, si no que la
dar en un orden aleatorio, por lo que el
primero de la lista ser siempre uno diferente.
Normalmente, estas direcciones que nos ha
devuelto el servidor raz quedarn almacenadas
en la cache de nuestro servidor.
consulta al servidor DNS del TLD .sk
Una vez escogido un servidor DNS del TLD,
consulta con ste el siguiente paso en la
jerarqua, es decir, la direccin de los servidores
DNS del dominio .box.sk.
De nuevo, nuestro servidor escoger uno de
la lista para la siguiente consulta, y almacenar
la lista devuelta en su cache.
Fig 9.- Nuestro ISP consulta con el
servidor del TLD .sk, el cual le da la lista
de servidores del dominio .box.sk.
consulta al servidor DNS de .box.sk
Por ltimo, slo falta consultar al servidor que
definitivamente debera conocer la IP de la
mquina a la que queremos acceder:
neworder.box.sk. En esta ocasin, el servidor
DNS del dominio .box.sk normalmente nos
devolver una sola IP, aunque si se trata de
pginas con mucha carga, podra estar repartida
sta en varias mquinas con copias exactas
(mirrors) de la pgina, por lo que nos
devolveran una lista de IPs, de la cual escogera
una nuestro servidor.
Fig 10.- Nuestro ISP consulta con el
servidor de .box.sk, y ste finalmente le
da la IP de neworder.box.sk
3.2.7. El servidor DNS de nuestro ISP nos
devuelve la traduccin
Una vez que ya ha completado todas las
consultas iterativas, nuestro servidor DNS nos
enviar un mensaje UDP conteniendo la
respuesta a nuestra consulta. :-D
Fig 11.- El servidor de nuestro ISP nos
responde con un datagrama UDP.
3.3. Ti pos de recursos en DNS
Segn leais todo lo anteriormente explicado,
probablemente os habr surgido una duda, y
es: cmo sabemos si la respuesta que nos da
un servidor es la IP de otro servidor o bien la
IP de una mquina? Eso quiz sea posible
saberlo segn el contexto, pero los datos que
estn almacenados en las tablas de los
servidores DNS carecen de ningn contexto,
por lo que tiene que estar tambin almacenado
con cada entrada de la tabla un dato que
indique a qu se est refiriendo.
El tipo de cada entrada de estas tablas es uno
de los parmetros de lo que se define como
RR (Resource Record), y es un dato que ha
de ser enviado en cada respuesta junto con la
traduccin.
Pero no slo existen dos tipos de RRs que
definan si se trata de una IP de una mquina
o de un servidor DNS, si no muchos otros.
La l i s t a c ompl et a l a t eni s en
http://www.i ana.org/assi gnments/dns-
parameters , pero tranquilos, que os voy a
resumir aqu los ms importantes. :-)
NS (Name Server) La direccin se refiere
a la IP de un servidor DNS. (ej: .box.sk)
A (Address) La direccin se refiere a la IP
de una mquina. (ej: neworder.box.sk)
PTR (Pointer) Se trata de una entrada
inversa, es decir, en lugar de ser la IP
correspondiente a un nombre, es el nombre
correspondiente a una IP.
MX (Mail Exchange) La
direccin se refiere al servidor de
correo de un dominio concreto.
vimos algo sobre esto en el artculo
sobre SMTP, en el nmero 8 de la
revista.
Segn el tipo de RR, la cabecera
ser diferente. Se pueden ver las
cabeceras para todos los tipos en
el RFC 1035.
Por tanto, en nuestro ejemplo
anterior, el usuario consultaba al
servidor DNS de su ISP una direccin
de tipo A, mientras que el servidor
DNS de su ISP realizaba una serie de consultas
de tipo NS a varios servidores, hasta que al
final al ltimo le haca una consulta de una
direccin tipo A.
3.4. Detalles del protocolo RAW
Para ver en crudo el protocolo DNS vamos a
utilizar ingeniera inversa para analizar una
sesin DNS. Pongo sesin entre comillas
porque debemos recordar que DNS funciona
mediante UDP, por lo que no existe una conexin
establecida, si no que cada mensaje es
independiente. Yo he usado para el ejemplo el
sniffer Ethereal, que es un sniffer grfico para
Linux. Simplemente he puesto en captura el
sniffer y he escrito en la consola de Linux:
host www.hackxcrack.com
Este comando sirve tpicamente para resolver
un nombre. Suponiendo que la direccin
solicitada no se encuentre en el archivo
/etc/hosts ni en ningn tipo de cache, este
comando lanzar una solicitud de traduccin a
un servidor DNS, el que est configurado por
defecto en el sistema.
3.4.1. Consulta
Fig 12.- Captura de pantalla de Ethereal, mostrando
la consulta realizada al servidor DNS.
Vamos a ver la captura de pantalla de Ethereal:
En la ventana de arriba tenemos la lista de
paquetes recibidos. Los dos primeros no tienen
ningn interes, ya que es simplemente una
consulta de ARP a la direccin broadcast para
buscar la direccin MAC de mi router. Si no
habis entendido ni una palabra, quiz es que
hara falta algn artculo sobre el protocolo
MAC. ;-)
Los que nos interesan ahora son los dos
paquetes siguientes. Si hemos visto capturas
de sesiones TCP sabremos que suele haber
una serie de paquetes adicionales que no
contienen datos, que son los que se utilizan
para establecer y para cerrar la conexin. En
este caso vemos que la cosa es mucho ms
sencilla, ya que slo hay 2 paquetes: una
consulta, y su consiguiente respuesta.
Esto, por supuesto, es debido a que se trata
del protocolo UDP, que no es orientado a
conexin.
En la ventana de en medio vemos los detalles
del paquete UDP que hemos enviado nosotros
como consulta.
Como vemos, no slo se enva el nombre que
queremos traducir, si no tambin una cabecera
con una serie de datos necesarios para la
consulta.
El pri mer dato de l a cabecera es el
identificador de transaccin (transaction
ID) que consiste en 2 bytes que identifican un
par consulta-respuesta, es decir, la respuesta
a esta consulta tendr que tener el mismo
identificador de transaccin, para que el cliente
sepa que esa respuesta es precisamente la
que est esperando a esa pregunta.
Vemos que se envan tambin dos bytes con
una serie de flags, es decir, una serie de bits
que, segn estn a 0 o a 1 tendrn un
significado u otro.
El primer flag indica que el paquete enviado
se trata de una consulta, y no de una
respuesta. Para ello, hay que poner ese flag
a 0.
El segundo flag se codifica mediante 4 bits. En
este caso, 0000, se trata de una consulta
estndar, que son las que utilizaremos
normalmente.
Despus, tenemos un flag a 0 que indica que
el mensaje no est truncado, lo cual es lo
habitual.
Despus, vemos un flag con valor 1 que indica
que la solicitud que hacemos queremos que
sea recursiva. Si estuviese a 0, la solicitud
sera iterativa, y en ese caso nuestra mquina
tendra que realizar uno a uno todos los pasos
para resolver el nombre, tal y como vimos que
haca el servidor DNS de nuestro ISP. Como,
por supuesto, queremos delegar esta ardua
tarea en nuestro ISP, que para eso est,
activaremos este flag.
Finalmente, el ltimo flag indica que exigimos
que la respuesta contenga informacin para
garantizar su autenticidad.
Despus de los flags hay 4 campos ms que
indican cul ser el contenido de los datos
siguientes. En este caso, se tratar nicamente
de una consulta.
Despus de la cabecera, est el nombre de la
consulta: www.hackxcrack.com, y por ltimo
se codifica el tipo de consulta que, en este
caso, es tipo A.
3.4.2. Respuesta
Con respecto a la respuesta del servidor, hay
que explicar unas cuantas cosas ms.
Fig 13.- Cabecera de la respuesta.
En primer lugar, podemos comprobar que, en
efecto, el identificador de transaccin es
el mismo que el de la consulta anterior (11aa,
en hexadecimal).
A continuacin, tenemos los dos bytes de flags,
cuyo significado en este caso es diferente. Al
ser 1 el primer bit, lo cual quiere decir que se
trata de una respuesta, y no de una consulta,
el significado del resto de bits se interpretar
de forma diferente.
Despus de los 4 bits del identificador del tipo
de consulta vemos que hay un bit a 0 que
i ndi ca que el servi dor DNS no es
authoritative, lo cual es lgico, ya que se
trata del servidor DNS de nuestro ISP, y ste
normalmente no ser authoritative para los
dominios que consultemos. El prximo flag
nuevo que vemos es el llamado Recursion
Available que, como vemos, est a 1 ya que,
por supuesto, el servidor DNS de nuestro ISP
tiene que aceptar solicitudes recursivas,
que son las que le harn siempre sus clientes.
El siguiente flag, Answer authenticated,
indica que no se ha utilizado autenticacin,
lo cual es un asunto que no veremos por falta
de espacio. Por ltimo, un cdigo de error
codificado con 0000 nos indica que todo ha
ido correctamente y no hay ningn error.
Los prximos 4 campos nos indican que aparte
de esta cabecera habr un RR de respuesta,
dos RRs de autoridad, y dos RRs adicionales.
Por supuesto, vamos a ver todo esto ahora
mismo.
El campo de datos comienza con una replicacin
de la consulta que realizamos nosotros
previamente.
A continuacin, se encuentra el primer RR,
que es el de respuesta.
Fig 14.- RR de respuesta.
Como vemos, el tipo de este RR es A (Host
Address), y vemos que se encuentra tambin
el campo TTL (Time To Live) del que hablamos
anteriormente, que indica durante cunto
tiempo, como mximo, ser valida esta
traduccin. La IP 217.174.193.62 es la tan
ansiada respuesta a nuestra consulta, es decir,
la IP asociada al nombre www.hackxcrack.com.
Despus del RR de respuesta, se encuentran
dos RRs de autoridad, que son los que
exigimos en nuestra consulta para garantizar
la autenticidad de los datos.
Fig 15.- RRs de autoridad.
Como vemos, el tipo de estos RRs es NS,
ya que se trata de servidores DNS, y
no de di recci ones de mqui nas. En
estos RRs de autoridad slo se incluye los
nombres de los servidores authoritative, pero
no sus direcciones IP. stas se encuentran
traducidas en los 2 RRs adicionales que
completan la respuesta.
Fig 16.- RRs adicionales.
Con todo lo que hemos visto hasta ahora, nos
damos cuenta de que el protocolo DNS es
complicado de manejar en su forma cruda
(RAW), ya que la mayora de los campos se
encuentran codificados, as que he considerado
que, ms interesante que saber manejarlo, es
el saber interpretarlo a grandes rasgos.
Supongo que recordaris que he mencionado
que en ciertas ocasiones se utilizaba TCP en
lugar de UDP. Esto suele ocurrir en 2 situaciones
concretas. En primer lugar, en las transacciones
que realizan los servidores de un dominio para
mantener la coherencia en sus bases de datos
(esclavos solicitando entradas caducadas al
maestro), y en segundo lugar en las solicitudes
con una longitud mayor de 512 bytes,
lo cual es poco habitual.
4. Algunos problemas de
seguridad del sistema DNS
4.1. Ataques DoS
El 21 de Octubre del ao 2002 se registr
uno de los mayores ataques contra toda
la red Internet, que consisti precisamente
en un ataque DoS distribuido contra los
13 servidores raz del sistema DNS. El
ataque dur aproximadamente una hora,
y slo consigui afectar con cierta
seriedad a 7 servidores.
Debido a esto, las consecuencias del ataque
no fueron demasiado importantes, ya que slo
un pequeo porcentaje de solicitudes qued
sin respuesta durante ese breve periodo de una
hora.
En principio, nos puede parecer que debi
tratarse de un problema terrible, pero en realidad
no lo fue tanto. En primer lugar, tal y como ya
hemos visto, el nmero de accesos directos a
los servidores raz es relativamente pequeo,
ya que la mayora de los servidores DNS ya han
realizado gran nmero de consultas previas a
los servidores raz, por lo que tienen en su
cache prcticamente cualquier consulta que
pudiesen necesitar de los servidores raz. Por
supuesto, estas caches tienen un tiempo de
vida (recordemos el parmetro TTL), pero en
slo una hora que dur el ataque el nmero
de nuevas consultas tuvo que ser muy reducido.
Por otra parte, los expertos afirman que el
sistema DNS puede funcionar sin problemas
siempre y cuando funcionen 5 de los 14
servidores raz, y en este caso no se vieron
afectados 6 servidores, por lo que el sistema
poda soportar la carga.
Un problema potencial de los servidores raz es
que no tienen una distribucin geogrfica
adecuada, ya que 10 de ellos estn situados
en Estados Unidos. Actualmente, est en marcha
un plan para mejorar esta distribucin y, por
ejemplo, el decimo cuarto servidor raz fue
instalado nada menos que en Espaa. :-D
Fig 17.- Localizacin geogrfica de 13 de
los 14 servidores raz del sistema DNS. El
decimo cuarto se ubica en Espaa.
4.2. Envenenamiento de cache DNS
Llegamos al fin a una tcnica realmente
interesante y bastante avanzada, pero muy
peligrosa por sus consecuencias, y que no
recomiendo en absoluto que sea utilizada.
Se os ha ocurrido pensar que ocurrira si
alguien consiguiese engaar al servidor DNS
de vuestro ISP al hacerse pasar por un servidor
authoritative? Pues, como habris adivinado,
la cache de vuestro servidor se llenara de
traducciones falsas que l considerara como
vlidas.
Cuando vosotros o cualquier otro cliente
solicitase una de estas traducciones a vuestro
servidor, ste os respondera con la traduccin
falsa que almacen en su cache. Imaginad por
ejemplo que la IP que solicitis es la de vuestro
banco, o la de vuestra cuenta de correo.
El atacante podra haber creado una pgina
exactamente con la misma apariencia que la
pgina de LOGIN para entrar en vuestra cuenta
del banco o vuestra cuenta de correo, y haber
ubicado esa pgina en su propia mquina.
Bastara con que envenenase la cache de
vuestro servidor DNS hacindole creer que ese
banco o ese servidor de correo se ubicaba en
su propia mquina, para que cualquier usuario
que intentase acceder a esa pgina accediese
en realidad a la mquina del atacante,
introduciendo confiadamente sus datos de
usuario y password.
Por supuesto, como pillen al atacante se le
puede caer el pelo, ya que puede causar
autnticos estragos, teniendo en cuenta que
un servidor DNS puede servir a miles de
usuarios.
Por otra parte, otro inconveniente para el
atacante es que tiene que repetir el mismo
ataque cada cierto tiempo, ya que los contenidos
en cache, como ya sabemos, tienen un tiempo
de vida (TTL), y transcurrido ese tiempo el
servidor envenenado volvera a solicitar las
traducciones caducadas.
Fi g 18. - Esquema bsi co de un
envenenamiento de cache. Si la respuesta
del atacante llega antes que la del servidor
authoritative, ser sta la que se tome
por vlida.
Pero, cmo es posible engaar a un servidor
DNS? Pues la respuesta depende de qu
software utilice el servidor. La inmensa mayora
de servidores DNS del mundo utilizan el popular
software BIND, por lo que nos centraremos
slo en ste.
Para responder a esta pregunta tendremos que
empezar por analizar el problema. Pensemos
antes de nada en los mecanismos que se utilizan
para comprobar la autenticidad de una respuesta
DNS. En primer lugar, al utilizarse como protocolo
de transporte UDP, no habr que colarse
dentro de ninguna conexin, lo cual es la primera
ayuda para el atacante. Colarse en una sesin
TCP es bastante complicado, ya que no basta
con conocer las IPs de origen y destino, as
como los puertos de origen y destino, si no
que tambin es preciso conocer los nmeros
de secuencia TCP. Sera necesario un artculo
sobre el protocolo TCP para que comprendis
esto, as que quedaos simplemente con la idea
de que es muy complicado colarse dentro de
una conexin TCP. En cambio, en el caso de
UDP, no hay nmeros de secuencia, por lo que
basta con saber las IPs de origen y destino,
as como los puertos de origen y destino.
En el caso que nos ocupa, la IP de destino
ser la del servidor vctima, ya que ste ser
el que realizar una consulta al servidor
authoritative, cuya respuesta dar el atacante
en lugar de ste.
La IP de origen es la del servidor
authoritative autntico, que el atacante
tendr que spoofear, es decir, enviar sus
paquetes con esa IP en lugar de con su propia
IP.
Se sale del tema del artculo explicar las tcnicas
de IP spoofing.
Con respecto a los puertos, el tema es bastante
ms complicado, ya que si bien el puerto de
origen sabemos que es el 53 (puerto UDP de
DNS) el puerto de destino ser un puerto
aleatorio que utiliz el servidor vctima para
su consulta.
En la prctica existen formas de averiguar este
puerto, debido a que BIND no utiliza siempre
puertos aleatorios para sus consultas, si no
que repite el mismo nmero de puerto.
Y ya est todo con eso? Bueno, hemos hablado
de como spoofear una respuesta UDP genrica,
pero en nuestro caso nos encontramos con el
caso concreto del protocolo DNS, y este
protocolo aade un elemento adicional de
seguridad, que es el de los identificadores
de transaccin (transaction IDs).
Una respuesta, aunque tericamente provenga
del servidor authoritative y utilice el mismo
puerto UDP, no ser aceptada como vlida si
tiene un identificador de transaccin diferente
al de la consulta. Y aqu, en la prediccin del
identificador de transaccin, es donde el tema
depende de qu software utilice el servidor
vctima.
Hasta el ao 1997, cuando el CERT (Computer
Emergency Response Team) comunic el
pertinente aviso de seguridad sobre BIND, ste
utilizaba identificadores de transaccin
secuenciales, y no aleatorios, por lo que
predecir el identificador era una tarea totalmente
trivial.
En cambio, actualmente es de esperar que
todos los servidores hayan actualizado sus
versiones de BIND y no creo que quede en el
mundo uno solo que an utilice identificadores
secuenciales.
A pesar de que los identificadores pasaron a
ser aleatorios, existen gran cantidad de teoras
matemticas y estadsticas sobre los nmeros
pseudo-aleatorios, que son los que en
realidad genera un ordenador, y estas teoras
permiten calcular la probabilidad de xito segn
el sistema de generacin de nmeros utilizado.
En primer lugar, aunque no hay que contar con
ello si el servidor cuenta con un administrador
eficiente, BIND puede generar mltiples
consultas para consultar un slo dominio, por
lo que recibir varias respuestas del mismo
servidor authoritative.
Esto da lugar a que el atacante no tenga que
adivinar un identificador de transaccin nico,
si no que le bastara con adivinar uno de los
muchos identificadores que habra utilizado el
servi dor en sus ml ti pl es consul tas.
Analizando esto desde el punto de vista
estadstico, nos encontramos con la interesante
paradoja del cumpleaos (birthday
paradox) que afirma que en un grupo de 23
personas, la probabilidad de que dos de ellas
tengan la misma fecha de cumpleaos es
superior al 50%.
A mi me gusta ms expresar esta idea desde
un punto de vista mucho ms grfico, que
consiste en imaginar un parking con 365 plazas,
en el cual entrasen 23 coches con las luces
apagadas, y pensar en la probabilidad de que
dos de ellos se estrellasen al intentar ocupar la
misma plaza.
Esta misma idea estadstica se puede aplicar al
caso que nos ocupa aunque, por supuesto,
manejando diferentes cifras.
As, se llega a la conclusin de que con slo
enviar 700 respuestas spoofeadas, la
probabilidad de que alguna de ellas coincida
en el identificador de transaccin es cercana
al 100%.
Fig 19.- Esquema detallado de un ataque
de envenenamiento. En el paso 1, el
atacante hace repetidas solicitudes del
dominio que se quiere envenenar. En el
paso 2, el servidor de la vctima consulta
ese dominio repetidas veces con el
servidor authoritative. En el paso 3, es el
atacante el que responde hacindose
pasar por el servidor authoritative. En
este caso, el atacante se ha ayudado de
un DoS al servidor authoritative que le
impide enviar las respuestas legtimas,
por lo que no hay conflicto entre
respuestas fal sas y autnti cas.
Pero claro... el servidor authoritative legitimo,
y no slo el atacante, responder tambin a
la vctima. Aqu nos encontramos con un
conflicto en el que unas veces podr ganar el
atacante, y otras el servidor authoritative,
segn quin consiga dar antes su respuesta.
Por eso, este tipo de ataques aumentan mucho
su efectividad si se combinan con ataques DoS
a los servidores authoritative, ralentizando o
incluso anulando sus respuestas.
Si tratamos con servidores bien configurados
que no hagan mltiples consultas para un slo
dominio, tendremos que entrar de lleno en
complicadsimas teoras matemticas cuya
explicacin se sale por completo de lo que
puede abarcar este artculo. A modo de ejemplo,
os comento que con el sistema de generacin
de nmeros pseudo-aleatorios de BIND 8.x
se puede tener una certeza del 100% de
adivinar el identificador de transaccin con tan
slo 3 paquetes! :-O
En cambio, con BIND 9.x la cosa es ya mucho
ms complicada, ya que incluso con 5000
paquetes la probabilidad de xito es slo del
20%. Esto es debido a que el sistema
generador de nmeros pseudo-aleatorios es
matemticamente mucho ms impredecible y,
por tanto, mucho ms eficiente.
Autor: PyC (LCo)
PC P PC PASO ASO A A P PASO ASO
1. Un poco de historia
Cuando en el ao 1965 Ted Nelson acu el
trmino hipertexto, difcilmente podra
imaginar la extensin que llegara a alcanzar
su idea. En realidad, aunque la idea de crear
un sistema de texto con enlaces es muy anterior,
no fue hasta 1989-1990 cuando Tim Berners-
Lee, informtico del CERN (Organizacin Europa
de Investigacin Nuclear), desarroll el primer
sistema web para que los cientficos del
CERN pudieran compartir informacin. El
navegador que utilizaban estos cientficos para
acceder al sistema fue precisamente el primer
navegador web de la historia, se llamaba
WorldWideWeb (posteriormente llamado
Nexus).
Aun hoy podemos ver una copia de esta primera
pgina tal y como era en el ao 1992 (no hay
una copia de la pgina en su primera aparicin)
en la direccin:
http://www.w3.org/History/19921103-
hypertext/hypertext/WWW/TheProject.html.
Quiz nos pueda parecer ahora algo totalmente
cotidiano, e incluso increblemente simple, el
concepto del hipertexto y la www, pero hay
que imaginarse la visin que se podra tener
de estas cosas hace 40 aos, cuando slo
pertenecan a la ciencia-ficcin. Sin irme tan
lejos, yo an recuerdo cuando vi por primera
vez la pelcula BIG, en el ao 88 (poco antes
de que comenzase todo), y me qued
maravillado con la idea de que pudiese existir
un libro electrnico con el que pudieses
interactuar escogiendo diversos finales, etc.
(algo as como los Elige tu propia aventura
pero en plan futurista).
A pesar de que el primer navegador fue grfico,
ste slo exista para plataforma NeXT, por lo
que los usuarios que tuviesen otros sistemas
tenan que conformarse con un simple navegador
en modo texto. No fue hasta 1993 cuando
apareci la primera versin del antes popular
navegador Mosaic para X-Windows, que era
quiz por aquel entonces la plataforma ms
extendida entre los usuarios de Internet
(formada en su mayor parte por cientficos y
algunos estudiantes). A partir de la aparicin
de Mosaic (que pocos meses despus tambin
estaba disponible para PC y Macintosh) comenz
la gran explosin de la WWW, con un crecimiento
exponencial de vrtigo.
Mi primer contacto con la WWW fue en el ao
1995 y, a pesar de que ya existan navegadores
grficos, di mis primeros pasos con el navegador
en modo texto Lynx, en un sistema VMS (uno
de esos muchos sistemas operativos que suenan
a chino para la mayora). No fue hasta el ao
siguiente cuando entr en contacto por primera
vez con un navegador grfico, Netscape, al
conectar por primera vez desde mi casa con un
modem ltimo modelo de 14400, y el entonces
popular Trumpet Winsock. Recuerdo tambin
cmo hice entonces mi primera pgina web,
escribiendo cdigo HTML a pelo en el bloc de
notas de Windows... Que tiempos!!! XDDD
RAW 7 : http
(HyperText Transfer Protocol)
De nuevo nos adentramos en el conocimiento de los protocolos, esta vez le toca el turno
al HTTP, para que nos entendamos, el que utilizamos al visualizar una Web :)
2. Documentacin
No se puede hablar del protocolo HTTP sin
hablar de otras cosas ntimamente ligadas,
como son el lenguaje HTML, el estndar MIME,
etc. Si bien la especificacin del protocolo
propiamente dicho se encuentra en el RFC
2616 ( f t p: / / f t p. r f c - edi t or. or g/ i n-
not es/r f c2616. t xt ), para t ener una
documentacin completa sobre el tema no
basta con centrarse en los RFCs, si no que hay
que documentarse tambin adecuadamente
sobre estos otros aspectos.
Podis encontrar en Google o en cualquier
librera miles de tutoriales de HTML.
Por poner un ejemplo, tenis uno en:
http://www.davesite.com/webstation/html/
(lo nico que he hecho para encontrar esta
pgina ha sido pinchar en el primer resultado
que me daba Google al buscar html tutorial
--> http://www.googl e.com <--).
Con respecto al MIME, se encuentra tambin
definido en varios RFCs. En la pgina:
http://www.mhonarc.org/~ehood/MIME/ podis
encontrar una lista de RFCs que especifican
ste estndar. Si no queris leeros los 5
captulos completos (RFC 2045, RFC 2046,
RFC 2047, RFC 2048, y RFC 2049) podis
haceros una idea bsica leyendo el ya obsoleto
RFC 1521 (ftp://ftp.rfc-edi tor.org/i n-
notes/rfc1521.txt).
Pero empecemos aclarando un poco este barullo.
Qu relacin guardan entre s el HTTP, el
HTML, y el MIME?
El HTTP (HyperText Transfer Protocol) no es
ms que un protocolo que funciona sobre TCP/IP.
Al igual que los dems protocolos que hemos
ido viendo a lo largo de la serie RAW, el protocolo
HTTP est formado por una serie de comandos
y una serie de respuestas que el servidor
proporciona a esos comandos. Los comandos
son muy pocos, pero la complicacin del
protocolo se encuentra en los llamados
campos de cabecera que son, en cierto modo,
como los parmetros que se pasan con cada
comando y con cada respuesta.
El HTML (HyperText Mark-up Language), como
supongo que todos sabris, es un lenguaje de
representacin de hipertexto. Podramos decir
que el HTTP es como un FTP muy simple pero
limitado a transferir slo un tipo de contenidos.
En FTP puedes transferir cualquier tipo de
archivos, y en HTTP transfieres bsicamente
slo cdigo HTML.
Con respecto al MIME (Multipurpose Internet
Mail Extensions), hay que tener en cuenta que
el lenguaje HTML permite la inclusin de
cualquier tipo de contenidos (texto en diferentes
idiomas, incluidos algunos como el japons que
no utilizan los mismos caracteres que el ingls,
imgenes en diferentes formatos, audio, vdeo,
etc., etc.). El MIME es un estndar para la
representacin de estos contenidos, que no
slo es usado en la WWW, si no tambin en
Serie RAW - HTTP - Serie RAW - HTTP - Serie RAW - HTTP - Serie RAW - HTTP - Serie RAW
Para los nuevos... !
Para los nuevos lectores, simplemente recordarles que
hemos explicado ampliamente en nmeros anteriores qu
son los RFC. En http://www.rfc-es.org encontrars los
RFC que han sido traducidos al Espaol, si el ingls no es
lo tuyo, esta Web es de visita obligada. Por cierto, si eres
un portento en esto de las traducciones puedes aportar tu
granito de arena ofrecindote a traducir alguno de los
muchos RFC que todava no han sido traducidos :)
En el nmero 12... !
En el nmero 12 de PC PASO A PASO recomendamos la
lectura de un artculo que, a pesar de su antigedad, explica
de forma muy amena trminos como MIME, ASCII, ISO,
UUENCODE, UUDECODE, BASE64 No dejes de
l e e r l o , p u e d e s e n c o n t r a r l o e n
http://bitassa.com/articles/babel.html
cualquier entorno de Internet que sea
susceptible de transportar diferentes contenidos.
De hecho, si repasis los nmeros anteriores
de la serie RAW, veris que ya coment algo
acerca del MIME en los artculos sobre POP3
y SMTP. HTTP y MIME no son totalmente
compatibles. En el apndice 19.4 del RFC
2616 podis encontrar detalladas las
di ferenci as entre ambos estndares.
Como podis suponer, con este artculo os
ahorrar el leer toda esta documentacin si lo
nico que queris es tener una visin global
sobre el tema, y no queris convertiros en los
nuevos gurus de la www. :-D
Me centrar tan slo en el protocolo HTTP, ya
que el MIME y el HTML mereceran artculos
aparte, aunque no de la serie RAW, ya que no
son protocolos. ;-)
3. Arquitectura HTTP
El protocolo HTTP ha sufrido algunas
modi fi caci ones desde su apari ci n, y
actualmente se encuentra en su versin 1.1.
* La primera versin, HTTP/ 0.9, era un
protocolo muy simple para la transmisin de
datos sin formato, poco ms que un FTP
simplificado.
* La versin HTTP/ 1.0 (RFC 1945) soportaba
ya los contenidos MIME, pero no estaba
preparada para soportar algunas caractersticas
avanzadas de la www, como la cache, los virtual
hosts, etc.
* La actual versin HTTP/ 1.1 surge de la
necesidad de dar soporte a estas caractersticas.
En el apndice 19.6.1 del RFC 2616 se
detallan las diferencias entre HTTP/ 1.0 y
HTTP/ 1.1.
Una conexin bsica de HTTP consiste en una
peticin de un cliente, y una respuesta del
servidor. Tpicamente, esta peticin suele ser
una URL, y la respuesta suele ser el contenido
HTML de esa pgina web.
En cambio, la arquitectura puede ser ms
compleja (uno de los motivos por los cuales se
hizo conveniente la aparicin de HTTP/ 1.1),
incluyendo varias mquinas intermediarias en
la comunicacin. Estos intermediarios pueden
ser bsicamente de 3 tipos: proxies, gateways,
y tneles.
Un tnel es simplemente un intermediario que
retransmite todo lo que recibe sin siquiera tener
que comprender ninguno de los contenidos que
circulan a travs de l. Un gateway, en cambio,
puede realizar traducciones de protocolos cuando
l as arqui tecturas a ambos l ados son
incompatibles, pero los contenidos no se vern
afectados y las traducciones sern transparentes
para ambas mquinas. Por ltimo, un proxy,
puede modificar los datos transferidos,
modificando, por ejemplo, las cabeceras de las
Para los lectores novatos !
Cada vez que abres el Internet Explorer (o cualquier otro
navegador de Internet) y le metes una direccin Web (por
ejemplo www.mocosoft.com) ests estableciendo una
conexin bsica de HTTP. Tu eres el CLIENTE (el que
pide) y el SERVIDOR WEB (el que sirve) donde est
alojada la pgina www.mocosoft.com responder a tu
peticin envindote (sirvindote) el contenido HTML de
la pgina. Tu "querido" Internet Explorer interpretar ese
cdigo HTML y mostrar el resultado en tu monitor.
4. Niveles de conexin
Hacer todo el estudio del protocolo HTTP con
un cliente de Telnet puede ser
duro, ya que a veces nos bastar
una herramienta que abstraiga
algunos parmetros que no nos
interesen.
Todos conocemos la herramienta
principal de ms alto nivel de la
que disponemos para manejar el protocolo
HTTP: los navegadores (browsers). Existe
una cantidad enorme de navegadores para
todos los sistemas y arquitecturas, y no slo
Internet Explorer (IE), como parece que muchos
quieren hacernos creer.
Ya que menciono IE, os recuerdo que es una
de las aplicaciones ms inseguras que existen
hoy da. Para que comprobis que mi afirmacin
no es gratuita, os propongo que hagis el
experimento de visitar las ms importantes
pginas de seguridad informtica, y realizar
una bsqueda de la cadena Internet Explorer.
Os pongo como ejemplo una lista de pginas
de seguridad que he consultado, y el nmero
de avisos de seguridad que aparecen en esa
pgina sobre IE:
- www.securityfocus.com (569 coincidencias)
- www.securitytracker.com (301 coincidencias)
- www. c e r t . o r g ( 1 5 3 8
coincidencias)
- www.theregister.co.uk (447
coincidencias)
- www.hispasec.com (superado el
l mi te de 50 coi nci denci as)
- neworder.box.sk (superado el
lmite de 20 coincidencias en la
seccin de exploits, el lmite de
30 coincidencias en la seccin de exploits
antiguos, el lmite de 20 coincidencias en la
seccin de artculos, y el lmite de 20
coincidencias en la seccin de noticias breves)
peticiones (recuerdas cuando explicamos en
nmeros anteriores a navegar annimamente
mediante proxy? ;p)
Otra de las caractersticas avanzadas de la
arquitectura que permite manejar el protocolo
HTTP/ 1.1 es la cache. En el escenario anterior,
en el que un cliente conecta con un servidor
a travs de varias mquinas intermedias, puede
que la respuesta que reciba el cliente no
provenga directamente del servidor final,
aunque esto habr de ser transparente para
el usuario. Alguna de las mquinas intermedias
podra tener una copia de la respuesta del
servidor ante esa peticin, y enviarla
directamente al cliente sin necesidad de recorrer
de nuevo todo el camino de ida y de vuelta
hasta el servidor final.
Normalmente, las mquinas intermedias tendrn
en cache las respuestas que ya han sido
solicitadas previamente por otros clientes (o
incluso por ese mismo cliente), aunque pueden
incluso tener copias de cache de las pginas
Ms sol i ci tadas di stri bui das en CD.
El tema de la cache en HTTP es realmente
complejo, y podra duplicar la extensin de
este artculo, por lo que lo obviar, al no ser
necesario para una comprensin bsica del
protocolo.
Por supuesto, entre todas esas entradas, alguna
se habr colado que no sea un aviso de
seguridad, pero podis realizar el experimento
por vosotros mismos y comprobar que la
inmensa mayora de las coincidencias son
referentes a la seguridad de IE.
Tenis muchas alternativas a IE en sistemas
Windows, y no solo Netscape, como tambin
intentan hacernos creer (de hecho, Netscape
ser quiz ms seguro que IE, pero por mi
experiencia personal puedo afirmar que funciona
realmente mal). Yo personalmente, en Windows
me quedo con el navegador Opera. La versin
shareware (gratis, para que nos entendamos)
es totalmente funcional y simplemente aade
un banner de publicidad en una de las esquinas.
En realidad se puede utilizar perfectamente
con el banner, que molesta poco, pero si queris
quitarlo no tenis ms que pagar el mdico
precio del registro. Porque claro, doy por hecho
que estoy hablando con gente legal, y que no
se os ocurrir visitar http://astalavista.box.sk
para buscar un serial number de Opera y
registrarlo gratuitamente... :p
En Linux uso tambin Opera, por costumbre
ms que nada, pero tenis tambin un
amplsimo repertorio de navegadores (Mozilla,
Konqueror, Gal eon, Net scape, et c).
Centrndonos de nuevo en el tema, si queremos
utilizar un navegador (sea el que sea) como
herramienta HTTP, tenemos que conocer
perfectamente el formato de una URL (Uniform
Resource Locator), que es el siguiente:
ht t p: / / hos t [ : puer t o] [ / pat h] [ ?cons ul t a]
* El campo host es el nico obligatorio, y es
donde ponemos la direccin del servidor HTTP.
Podemos poner bien una direccin IP
(217.174.193.62), o bien un nombre DNS
(www.hackxcrack.com).
* El campo puerto normalmente no ser
necesario, ya que el puerto por defecto para
HTTP es el 80. En cambio, si es necesario,
podemos especificar cualquier otro puerto.
* El campo path es un nombre de directorio
relativo al directorio configurado como raz para
el servidor web. Esto es totalmente transparente
al usuario, por lo que desde el punto de vista
del cliente se puede decir que se trata de un
directorio absoluto. En realidad, como ya
sabemos, existen formas de saltarse esto del
directorio raz del servidor web, y acceder a
cualquier otro directorio de la mquina. ;-)
* El campo consulta es opcional, y es slo para
pginas de contenido dinmico (PHP, ASP, CGI,
...) en las que se puedan introducir parmetros.
A partir de ahora... !
A partir de ahora, si eres de los que poseen una mente
inquieta, te recomendamos que cuando visites una pgina
Web no pierdas de vista el campo direccin de tu navegador.
Podrs ver "en directo" lo "interesantes" que pueden ser
al gunas pet i ci ones( vease i magen si gui ent e)
Por otro lado, recuerda que cuando introduces en tu
Navegador una di recci n Web (por ej empl o
www.astalavista.com), el Navegador intenta por defecto
acceder al puerto 80. No tienes mas que probarlo, escribe
por ejemplo http://www.astalavista.con:80 en tu navegador
y vers que el resultado es el mismo que si escribieses
http://www.astalavista.com. Lo que no sabe todo el mundo
es la cantidad de Servidores Web que hay en Internet tras
otros puertos, si has seguido el curso del Servidor Web
APACHE (en anteriores nmeros de PC PASO A PASO)
sabes que puedes activar un Servidor Web en cualquier
puerto, por ejemplo en el puerto 4415 no te imaginas la
cantidad de Servidores Web que en el Puerto 80 tienen
pginas Web de lo ms normalitas y en "otros puertos"
tienen las pginas interesantes ;p
Si www.astalavista.com tuviese una web oculta en el puerto
9010, para acceder a ella tendras que introducir en tu
navegador www.astalavista.com:9010. Ya, ahora me pedirs
una lista de Webs "ocultas", pues lo siento pero eso sera
suficiente para que esta revista fuese repudiada en ciertos
crculos, sera como publicar el acceso a uno de los muchos
FTP de los que utiliza la scene si quieres adentrarte en
este tema, empieza por trabajarte los foros de FXP ;)
Cmo? Qu no sabes lo que es eso? Pues repasa los
anteriores nmeros de PC PASO A PASO ;p
La combinacin de un navegador de los de
toda la vida, y un sniffer, puede ser una
herramienta muy til para estudiar el
funci onami ento del protocol o HTTP.
Existen tambin herramientas intermedias entre
esto y un simple cliente de Telnet, como por
ejemplo la aplicacin SamSpade, que no slo
puede ser descargada como aplicacin para
usar localmente en tu PC, si no que tambin
puede ser utilizada online desde el propio
servidor de SamSpade: www.samspade.org.
En la imagen podemos
ver la configuracin de
la herramienta Browse
Web i ncl ui da en
SamSpade, en la que
c onf i gur a mos l a
aplicacin para que se
c o n e c t e a
www.withehouse.org
hacindole creer que
nuestro navegador es
un Internet Explorer 5.0
(cuando en realidad
nuestro cl i ente es
SamSpade), y que la pgina de la que venimos
es www.alqaeda.org. En el parmetro Request
Type podemos especificar el comando HTTP a
enviar. Ms adelante veremos cada uno de estos
comandos en detalle.
Por ltimo, como no, hay que mencionar el
cliente de Telnet como aplicacin universal
para el estudio de los protocolos. ;-) Si utilizamos
el cliente de Telnet tenemos que tener en cuenta
dos aspectos. El primero, es que el puerto por
defecto para HTTP es el 80. Y por ltimo, que
no podemos incluir el path al lanzar la conexin
mediante Telnet, si no slo el host. Para incluir
un path, tendremos que hacerlo una vez
establecida la conexin con el servidor, enviando
la cabecera adecuada, tal y como veremos ms
adelante.
5. El protocolo HTTP
Una vez establecida la conexin (asumimos que
estamos trabajando con un cliente de Telnet),
el servidor se queda en espera de que enviemos
un comando, al cual responder despus tal y
como iremos viendo.
comandos RAW, para luego hablar de los campos de cabecera. Por ltimo,
hablar sobre as respuestas del servidor.
Empiezo, por tanto, mostrndoos la sesin completa de http. Os
recuerdo que a lo largo de toda la serie RAW he utilizado el color
azul para indicar lo que enva el cliente al servidor, y el color rojo
para las respuestas del servidor al cliente. El color verde lo utilizo
para comandos de consola, enviados fuera de la conexin TCP/IP.
GET / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; UNIX) Opera 6.11 [en]
Host: www.hackxcrack.com
Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
Accept-Charset: windows-1252, utf-8;q=1.0, utf-16;q=1.0, iso-8859-1;q=0.6, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Co o k i e : p hp bb2my s q l _d a t a =a %3B1%5B%5e t c
Cache-Control: no-cache
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers
HTTP/1.1 200 OK
Date: Thu, 09 Oct 2003 14:59:29 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3 mod_perl/1.26
Last-Modified: Fri, 23 May 2003 19:52:13 GMT
Teniendo en cuenta que el RFC 2616, que
especifica el protocolo HTTP /1.1, consta de
175 pginas, no podemos hacer en este
artculo una especificacin detallada y
precisa del protocolo, por lo que nos
limitaremos a ver casos tpicos y relativamente
sencillos.
En primer lugar, tenemos que tener en cuenta
que no todos los servidores aceptan todos los
comandos HTTP. Cuando un servidor no acepte
un determinado comando, nos responder con
un error 405 (method not allowed). Si ni
siquiera conoce ese comando, nos responder
con un error 501 (Not Implemented). Slo
los comandos GET y HEAD han de ser
implementados obligatoriamente por cualquier
servidor.
El protocolo HTTP consta de muy pocos
comandos RAW (tan slo 8, de los cuales slo
hay 2 cuya implementacin es obligatoria).
Toda la complejidad del protocolo no se
encuentra en los propios comandos, si no en
los parmetros adicionales que se envan con
cada peticin y con cada respuesta. El nmero
de estos parmetros vara de una peticin a
otra, y se encuentra cada parmetro separado
en una lnea diferente. A cada una de estas
lneas se las denomina campos de cabecera
(header fileds). Cuando un campo de
cabecera no se especifica explcitamente, el
estndar define una serie de decisiones a tomar
por defecto tanto por parte del servidor
como por parte del cliente, por lo que no existe
un nmero fijo de campos de cabecera
obligatorios.
Para tratar de explicaros de forma ordenada
todo este barullo que se encuentra repartido
por varios documentos diferentes, y de forma
bastante catica, he decidido empezar
mostrando un ejemplo bsico de sesin
completa, capturada con un sniffer, para luego
ir explicndola paso a paso. Para esta
explicacin empezar por comentar los 8
Para los nuevos lectores !
TELNET? SNIFFER? Qu es eso? Cmo se utiliza?
En los nmeros anteriores mostramos paso a paso como
utilizar estas herramientas, si es la primera vez que lees
esta revista y no dominas el tema seguro que ya te has
perdido. La solucin ideal pasa por comprar los nmeros
atrasados de PC PASO A PASO, claro, pero estamos
estudiando una alternativa que esperamos poder poner en
marcha a mediados de Noviembre (mximo Diciembre).
Lo que tenemos pensado es hacer en una especie de FAQ
y colgarla en la Web (www.hackxcrack.com), en realidad
ser un archivo que todo el mundo podr descargar y
contendr esos artculos ya publicados y de nivel bsico
que todo nuevo lector deber tener muy a mano. No
vamos a liberar los PDF de todos los nmeros publicados,
ser simplemente una recopilacin de todo lo que creemos
imprescindible para que cualquier nuevo lector pueda seguir
la revista.
Accept-Ranges: bytes
Content-Length: 6291
Content-Type: text/html
Age: 0
...AQUI VENDRIA UN MONTON DE CODIGO HTML...
GET /i magenes/LOGOPCPASOAPASO1. j pg HTTP/1. 1
Referer: http://www.hackxcrack.com/
If-Modified-Since: Thu, 03 Apr 2003 06:06:09 GMT
If-None-Match: "710029-10d4-3e8bcf51"
Cookie: phpbb2mysql_data=a%3A2%3A%etc
HTTP/1.1 304 Not Modified
Date: Thu, 09 Oct 2003 14:59:30 GMT
Etag: "710029-10d4-3e8bcf51"
Buf!! Como podis imaginar, tenemos mucho trabajo por delante! ;)
5.1. Comandos RAW de HTTP
Enumerar a continuacin todos los comandos HTTP, aunque nos
centraremos sobre todo en el comando GET, que es el ms importante.
Mientras explique los comandos, probablemente habr muchas cosas que
os suenen a chino. No os preocupis, porque ms adelante explicar todo
en detalle.
5.1.1. Comando GET
Este es, sin duda, el comando HTTP ms utilizado, ya que es el que se
usa cuando queremos descargar una pgina web de un servidor. Vamos
a ver dos formas di ferent es de conect arnos a l a URL
http://www.hackxcrack.com/entrada/entrada.htm mediante Telnet:
Conexin directa:
Lo primero ser lanzar el telnet al servidor:
telnet www.hackxcrack.com 80
A continuacin, el comando sera:
GET /entrada/entrada.htm HTTP/1.1
Como vemos, indicamos slo el PATH, separado
por un espacio del protocolo a utilizar que, en
este caso, y prcticamente en cualquier caso,
ser siempre HTTP/1.1.
Despus de esta lnea, debemos indicar aparte
el HOST para completar la URL:
GET /entrada/entrada.htm HTTP/1.1
Esto permite referenciar otros HOSTs a partir
de uno dado, siempre que ste lo permita.
Si el host especificado no es vlido, el servidor
responder con un error 400 (Bad Request).
Este campo Host que hemos visto que sigue
al propio comando es precisamente uno de los
campos de cabecera que menci on.
En el ejemplo de sesin completa que puse al
pri nci pi o podemos ver l o si gui ente:
GET / HTTP/1.1
En este caso, la pgina solicitada es la raz del
servidor.
Conexi n a travs de un proxy:
Si conectasemos a travs de un proxy, por
ejemplo 127.0.0.1, tendramos que especificar
no slo el PATH, si no tambin el HOST como
parmetro del comando GET. Utilizar esta IP
como proxy no es ninguna tontera (para los
que se puedan quejar de que no ponemos IPs
reales en los artculos), ya que podramos estar
utilizando una aplicacin como MultiProxy
(www.multiproxy.org utilidad explicada en
nmeros anteriores-) que crea un proxy virtual
en nuestro propio PC que lo que hace es manejar
dinmicamente listas de proxies externos.
Si tenemos, por ejemplo, un multiproxy en el puerto 8080 de nuestra
mquina, empezaremos con el siguiente Telnet:
telnet 127.0.0.1 8080
A continuacin, lanzaremos la siguiente peticin:
GET http://www.hackxcrack.com/entrada/entrada.htm HTTP/1.1
** No he probado este ejemplo concretamente con Multiproxy. Lo nico
que comento es el mtodo genrico para conectar a travs de un
proxy.
5.1.2. Comando OPTIONS
Este comando nos permite conocer las caractersticas de la comunicacin
entre nuestro cliente y un recurso determinado del servidor.
Si, por ejemplo, enviamos:
OPTIONS * HTTP/1.1
El recurso solicitado es *, que es equivalente a no especificar ningn
recurso. Esto equivale a hacer un simple PING al servidor para ver si
responde.
Si queremos enviar un comando OPTIONS a un proxy en concreto dentro
de una cadena, en lugar de enviarlo al servidor final al que supuestamente
estamos conectados, podemos utilizar el campo de cabecera Max-
Forwards, tal y como veremos ms adelante.
5.1.3. Comando HEAD
Es similar al comando GET, pero con la diferencia de que el servidor en
su respuesta no incluir los datos a enviar (tpicamente el cdigo HTML),
si no tan slo la cabecera. Con esto se puede comprobar si una URL es
vlida, cul es el tipo de contenidos, si ha de ser renovada la copia de
cache debido a algn cambio, etc.
5.1.4. Comando POST
Este comando permite que el cliente solicite el envo de datos al servidor,
en lugar de solicitar una recepcin de datos. Es, por ejemplo, el mtodo
utilizado para subir un mensaje a un foro web. Si el mensaje ha sido
aadido con xito al foro, el servidor nos responder con un cdigo 201
(Created).
El comando POST debe incluir, por supuesto,
un cuerpo de datos con su cabecera, igual que
hace el servidor cuando nos enva una pgina
solicitada. Ms adelante veremos cmo
construye el servidor estas cabeceras.
5.1.5. Comando PUT
Este comando es el inverso a GET, ya que
permite especificar una URL sobre la que se
escribirn los datos incluidos en la propia
peticin. Si no exista previamente ese recurso,
el servidor nos responder con un cdigo 201
(Created), en cambio, si ya exista y ha sido
modificado, nos responder con un cdigo
200 (Ok), o un cdigo 204 (No Content).
Si el servidor no comprende los contenidos
enviados, responder con un error 501 (Not
Implemented).
Lo importante que hay que comprender en este
punto es la diferencia entre los comandos POST
y PUT. En el comando POST, la URL
especificada es la de algn recurso que sea
capaz de procesar los datos, por ejemplo, un
script CGI, PHP, o ASP. Este script decidir qu
hacer con los datos enviados. En cambio, en el
comando PUT la URL especificada ser
directamente sobre la que se escribir.
5.1.6. Comando DELETE
Como es fcil adivinar, sirve para eliminar el
recurso especificado en la URL. Por supuesto,
este comando no funcionar con la inmensa
mayora de URLs. XDD
5.1.7. Comando TRACE
Es prcticamente como un PING, no slo hacia
el servidor final, si no tambin hacia alguno de
los proxies intermedios si se utiliza el campo
de cabecera Max-Fordwards. El servidor que
haya de responder, lo har con un cdigo 200
(Ok), y la respuesta tendr como tipo de
contenidos message/http. Esta respuesta
puede ser utilizada por el cliente para hacer
diversos diagnsticos.
5.1.8. Comando CONNECT
Este comando se utiliza en los proxies que
pueden funcionar como tunel SSL. Esto es un
tema muy complicado, as que mejor lo
dejamos, que no es plan de escribir un
libro. xD
5.2. Campos de cabecera
La peticin se puede completar con una serie
de campos adicionales, cada uno enviado en
una lnea, que permiten indicar al servidor los
tipos de contenidos que acepta el cliente, el
lenguaje, los sistemas de codificacin, etc.
Vamos a ver slo alguno de los ms
importantes. Muchos de los que no veremos
ser debido a que son parte del complejo
sistema de cache que ocupara por si slo todo
un artculo. A continuacin muestro una lista
bastante completa de campos de cabecera, en
los que sealo aquellos que comentar:
Accept, Accept-Charset, Accept-Encoding,
Accept-Language, Accept-Ranges, Age,
Allow, Authorization, Cache-Control,
Connection, Content-Encoding, Content-
Language, Content-Length, Content-
Location, Content-MD5, Content-Range,
Content-Type, Date, ETag, Expect, Expires,
From, Host, If-Match, If-Modified-Since, If-
None-Match, If-Range, If-Unmodified-Since,
Las-Modified, Location, Max-Forwards,
Pragma, Proxy-Authenticate, Proxy-
Authorization, Range, Referer, Retry-After,
Server, TE, Trailer, Transfer-Encoding, Upgrade,
User-Agent, Vary, Via, Warning, WWW-
Authenticate.
5.2.1. Accept:
Permite especificar el tipo de contenidos
que aceptar el cliente. Consiste en una lista
de tipos/subtipos de contenidos. Por tanto, si
especificamos */* significa que aceptamos
cualquier tipo de contenido.
Por ejemplo:
Accept: text/html, image/png
Especifica al servidor que slo aceptamos texto
HTML e i mgenes en formato PNG.
En cambio, si enviamos:
Accept: */*
Indicamos al servidor que aceptamos cualquier
tipo de contenidos.
Y si enviamos esto:
Accept: text/html, text/plain, image/*
Indicamos que aceptamos texto HTML, texto
plano, y cualquier formato de imgenes.
Podemos especificar, adems, prioridades en
los formatos. Por ejemplo, si preferimos que
las imgenes nos sean enviadas en formato
PNG, enviaremos:
Accept: image/png, image/*; q=0.1
Esto significa que la prioridad para cualquier
formato de imagen que no sea image/png, es
0.1. El valor de prioridad por defecto es 1, por
lo que, al no especificar un valor de prioridad
para image/png, se asume que este es 1, el
cual es mayor que 0.1. Por tanto, la peticin
anterior sera equivalente a esta:
Accept: image/png; q=1, image/*; q=0.1
El valor de prioridad (q) puede tomar cualquier
valor comprendido entre 0 y 1, con hasta 3
decimales, por lo que podemos especificar listas
de pri ori dades bast ant e compl ej as.
Podemos especificar prioridades de forma mucho
ms sencilla, simplemente mediante el orden
en que especificamos los tipos aceptados. Por
ejemplo:
Accept: text/html, image/png, */*
Especifica al servidor que preferimos siempre
texto HTML a cualquier otra cosa, y en segundo
lugar, imgenes PNG. En cambio, si no se nos
puede enviar ninguna de esas dos cosas,
tambin nos conformamos con cualquier otro
tipo de contenido (*/*).
Los tipos bsicos estn especificados en el
RFC 2046, y son los siguientes: text, image,
audio, video, application. Aunque tambin se
puede hablar de otros tipos ms complejos,
como el multipart, en los que no voy a entrar
en detalle.
Si queris la lista completa de tipos actualmente
registrados, la mantiene el IANA (Internet
Assigned Numbers Authority), y la podis
consultar por FTP en ftp://ftp.isi.edu/in-
notes/i ana/assi gnments/medi a-types/
5.2.2. Accept-Charset:
Especifica al servidor las tablas de caracteres
que acepta nuestro cliente. El formato es el
mi smo que en Accept. Por ejempl o:
Accept-Charset: iso-8859-1, unicode-1-
1; q=0.8
Indica al servidor que preferimos caracteres
segn el estndar iso-8859-1, pero que
aceptamos tambin unicode-1-1 (aunque con
menor prioridad).
En el nmero anterior de la revista ya se habl
algo sobre estos estndares de juegos de
caracteres.
Como ejemplo, en
http://www.htmlhelp.com/reference/charset/
tenis la tabla de caracteres del estndar iso-
8859-1.
** No incluimos fotos de la tabla porque
ocupara varias pginas de la revista y en el
foro de hack x crack despus nos echan bronca
por desperdiciar espacio :)
5.2.3. Accept-Encoding:
Especifica al servidor el tipo de codificacin de
datos que puede comprender nuestro cliente.
Para hacer nuestras pruebas lo mejor es que
utilicemos slo la codificacin identity, es decir,
sin ninguna codificacin. As, podremos ver en
texto plano todos los datos recibidos, y
analizarlos con mayor facilidad. La codificacin
identity es la que se asume cuando no se indica
nada, y deben implementarla todos los
servidores. Si an as queremos especificarlo,
enviaremos:
Accept-Encoding: identity
Si queremos experi mentar con otras
codificaciones, el formato es el mismo que en
los casos anteriores. Por ejemplo:
Accept-Encoding: gzip; q=1, compress;
q=0.8, identity; q=0.5, *; q=0.1
Con esto indicamos al servidor que preferimos
la codificacin gzip, seguida de la compress,
seguida de la identity y, en ltimo caso,
aceptamos cualquier otra codificacin existente.
Si el servidor no es capaz de enviar una
respuesta en ninguna de las codificaciones
especificadas, responder con un error 406
(Not Acceptable).
5.2.4. Accept-Language:
Especifica al servidor el idioma en que preferimos
que nos sea enviado el texto. Por supuesto,
para que nos sea enviado en un determinado
lenguaje, el servidor tiene que tener prevista
esta situacin y tener traducciones de los
contenidos a diversos idiomas.
No slo se pueden especificar idiomas, si no
tambin subtipos dentro del idioma. Por
ejemplo:
Accept-Language: en-gb; q=1, en; q=0.5,
*; q=0.1
Indicamos as al servidor que preferimos el
idioma ingls de Gran Bretaa (en-gb). Existen
otros subtipos, como por ejemplo el en-US,
que es ingls de Estados Unidos. Como segunda
opcin, admitimos cualquier tipo de ingls,
aunque no sea en-gb. Por ltimo, con mnima
prioridad, aceptamos cualquier otro idioma.
Si no se especifica nada en Accept-Language,
el servidor asume que no hay preferencias de
idioma, y enviar el que ms le convenga.
5.2.5. Authorization:
Si intentamos acceder a una pgina cuyo
contenido requiera la autenticacin de un
usuario, el servidor nos responder con un
error 401 (Unauthorized). En esta respuesta
incluir adems un campo de cabecera WWW-
Authenticate, en el cual nos dar los datos
necesarios para que realicemos la autenticacin.
A continuacin, tendremos que volver a pedir
la pgina, pero incluyendo los datos de
autenticacin, lo cual se hace mediante esta
lnea de cabecera. El sistema de autenticacin
de HTTP viene especificado en el RFC 2617.
5.2.6. Connection:
Permite especificar al servidor si queremos que
la conexin se cierre una vez enviada la
respuesta:
Connection: close
O si queremos mantenerla abierta para
posteriores peticiones:
Connection: Keep-Alive
Por defecto, se considera que se mantiene en
el estado Keep-Alive, por lo que slo es
necesario indicar explcitamente cundo se
desea cerrar la conexin.
5.2.7. User-Agent:
Esta lnea de cabecera permite indicar al servidor
informacin sobre nuestro navegador, como el
software utilizado, su versin, el sistema
operativo, o incluso algunas compatibilidades.
Por ejemplo:
User-Agent: Mozilla/4.0 (compatible;
MSIE 5.0; Linux 2.4.18-14 i686) Opera
6.11 [en]
Todo esto es lo que enva por defecto Opera
6.11 para Linux cada vez que se conecta a una
pgina web. Como vemos, da informacin no
slo sobre la versin exacta del navegador, si
no tambin sobre el sistema operativo y el
microprocesador.
5.2.8. Referer:
Si os ha preocupado ver que cada vez que
Imagina la cantidad... !
Imagina la cantidad de informacin que obtiene de ti
cualquier Servidor Web cuando te conectas a una Web
alojada en dicho Servidor :p
Como todas las cosas, esta es un arma de doble filo. Puede
utilizarse para, por ejemplo, saber la resolucin de tu
pantalla y servirte una pgina Web adaptada a dicha
resolucin (eso es bueno), pero tambin puede utilizarse
para saber, por ejemplo, la versin exactade tu navegador
y servirte una pgina que explote un bug de esa versin
del navegador y colarte un troyano (eso ya no es tan bueno
verdad?)
visitis una pgina web se enva informacin
acerca de vuestro sistema y vuestro software,
supongo que ms os asustar saber que adems
se enva la ltima URL que visitasteis. Si
enviamos:
Referer: http://www.hackcrack.com/
Indicamos al servidor que estuvimos en esa
pgina, antes de estar en la suya.
Esto puede suponer un gran riesgo de
seguridad, ya que se podran colar datos
importantes, como por ejemplo parmetros
enviados en una URL (incluso datos de
autenti caci n de otras pgi nas web).
5.2.9. Allow:
Este campo de cabecera se incluye en las
respuestas con cdigo 405 (Method Not
Allowed), que se enva cuando el cliente
intenta utilizar un comando que el servidor no
acepta. El servidor informar al cliente mediante
este campo de cules son los mtodos que si
que acepta. Por ejemplo:
Allow: GET, HEAD, POST
Informa al cliente de que slo est permitido
utilizar esos tres comandos. El campo Allow
tambin puede ser incluido como respuesta a
un PUT, indicando as qu mtodos se pueden
utilizar sobre el nuevo recurso recin creado.
5.2.10. Content-Encoding:
Este campo acompaa a cualquier mensaje en
el que se enven datos, tanto si es una respuesta
del servidor a un GET, como si son los datos
subidos por el cliente en un PUT o un POST.
Si bien el campo Accept-Encoding indica qu
tipos de codificacin aceptamos para la prxima
recepcin, el campo Content-Encoding indica
qu tipo de codificacin se ha utilizado para
un envo. Evidentemente, la codificacin
indicada en Content-Encoding debera ser
compatible con alguna de las especificadas
previamente por la otra mquina en su campo
Accept-Encoding.
Por ejemplo:
Content-Encoding: gzip
Indica que se ha utilizado la codificacin gzip
en los datos enviados a continuacin. Para ello,
la peticin de esos datos tuvo que incluir un
campo de cabecera como el siguiente:
Accept-Encoding: gzip; q=1, compress;
q=0.5, identity; q=0.1
Es decir, de alguna forma tena que incluir la
codificacin gzip entre las admisibles. En este
caso concreto, adems, era la codificacin
preferida, as que todos contentos. :-)
Si no se especifica un campo Content-
Encoding, se asume que no se ha usado
codificacin, es decir, que se ha usado
codificacin identity.
5.2.11. Content-Language:
La misma relacin que existe entre el Accept-
Encoding y el Content-Encoding, existe
entre el Accept-Language y el Content-
Language.
5.2.12. Content-Length:
Indica la longitud en bytes de los datos enviados.
Por ejemplo:
Indica que los datos enviados (tpicamente una
pgina web) ocupan 1500 Bytes.
5.2.13. Content-Type:
Este campo combina la respuesta a los campos
de cabecera Accept y Accept-Charset, ya
que puede indicar cul es el tipo de datos
enviado, as como el juego de caracteres.
Por ejemplo:
Content-Type: text/html; charset=ISO-
8859-4
Aunque muchas veces slo se indicar el
tipo/subtipo de los datos. Por ejemplo, en la
captura de sesin de ejemplo, vemos que sta
es la respuesta:
5.2.14. Date:
Como podemos imaginar, indica la fecha y la
hora a la que se gener el mensaje en cuestin.
Si os queris complicar la vida, en el punto
3.3.1. del RFC 2616 se muestran en detalle
los formatos de fechas aceptados, pero supongo
que a la mayora os bastar con un ejemplo,
as que no tenis ms que mirar la captura de
sesin del ejemplo:
Date: Thu, 09 Oct 2003 14:59:29 GMT
Como vemos, la hora siempre se da con
respecto al GMT (Greenwich Mean Time, es
decir, la hora en el meridiano 0).
5.2.15. Expect:
Este campo lo utiliza un cliente cuando quiere
solicitar al servidor un determinado tipo de
accin. Por ejemplo, se usa cuando el cliente
espera que el servidor le enve un cdigo 100
(Continue). Todo esto lo veremos ms
adelante cuando comentemos las respuestas
del servidor. Cuando el servidor no pueda
satisfacer las expectativas del cliente,
responder con un error 417 (Expectation
Failed).
5.2.16. Max-Forwards:
Este campo de cabecera se utiliza en los
comandos OPTION y TRACE cuando se quiere
acceder a una mquina intermedia dentro de
la cadena que nos comunica con el servidor
final. Como vimos al principio, para llegar a un
servidor nuestras peticiones pueden estar
pasando por una serie de proxies y routers. La
forma de acceder a estos puntos intermedios
es mediante esta cabecera.
En este campo se indica como parmetro un
nmero, que es el nmero de pasos intermedios
a dar. Cada vez que pasa por un proxy esta
peticin, el proxy restar en una unidad este
nmero, y pasar el mensaje al prximo proxy.
Cuando el mensaje llegue con valor 0 a uno de
los proxies de la cadena, ste ya no realizar
ms restas, ni retransmitir el mensaje, si no
que lo devolver con la respuesta pertinente.
Este es un claro ejemplo de modificacin de
las cabeceras por parte de los proxies.
Por ejemplo:
Max-Forwards: 3
Indica que a este mensaje habr de responder
el tercer proxy de la cadena. Si el servidor final
estuviese casualmente conectado por menos
de 3 proxies, sera ste el que respondera.
5.2.17. Proxy-Authenticate:
Este campo se incluye en la respuesta de un
proxy que requiere autenticacin. El campo
WWW-Authenticate requiere autenticacin
al usuario con el servidor final, y el campo
Proxy-Authenticate requiere autenticacin
con uno de los proxies intermedios de la cadena.
El campo Proxy-Authenticate se incluye en
las respuestas con cdigo 407 (Proxy
Authentication Required).
5.2.18. Proxy-Authorization:
Si bi en a WWW-Authenti cate se
responde con Authorization, a Proxy-
Authenticate se responde con Proxy-
Authorization.
5.2.19. Retry-After:
Este campo se puede incluir en las respuestas
con cdigo 503 (Service Unavailable),
indicndonos tpicamente en segundos el tiempo
que nos recomienda el servidor que esperemos
antes te rei ntentar l a peti ci n. Por
ejemplo:
Retry-After: 120
Nos indica que conviene que esperemos al
menos 2 minutos antes de reintentar la peticin.
Tambin se podra indicar una fecha, en lugar
de un tiempo en segundos.
5.2.20. Server:
Este es un campo de cabecera de respuesta
muy interesante. En l se incluye informacin
acerca del servidor, la cual puede ser til
para alguien que quiera realizar algn
tipo de ataque contra el servidor, ya
que lo primero que necesitar conocer es el
software que utiliza el servidor. Por ejemplo,
en la captura de sesin vemos:
Server: Apache/1.3.26 (Unix) PHP/4.2.3
mod_perl/1.26
El servidor nos indica no slo qu software
uti l i za, si no tambi n el nmero de
versin completo, el sistema operativo
(Unix), as como algunos mdulos instalados.
Como vemos, es una informacin bastante
precisa que puede facilitar en gran medida un
ataque contra el servidor.
5.2.21. WWW-Authenticate:
Ya he mencionado antes la funcin de este
campo de cabecera. Os recuerdo que en el RFC
2617 se detalla el mecanismo de autenticacin
en HTTP.
5.3. Respuestas del Servidor
Ante cada peticin realizada por el cliente, el
servidor siempre nos dar una respuesta con
el siquiente formato:
HTTP/x.x cdigo respuesta
Donde HTTP/x.x es la versin de HTTP, cdigo
es un nmero que identifica el tipo de respuesta,
como veremos ms adelante, y respuesta es
una frase de respuesta aclaratoria del cdigo
devuelto.
Por ejemplo, si intentamos acceder a una URL
que no existe en un servidor, nos puede
responder algo como esto:
HTTP/1.1 404 Sorry, the page you
requested was not found.
5.3.0. Cdigos de respuesta
Segn el primer dgito del cdigo de respuesta,
podemos saber si se trata de una respuesta
correcta, de error, informativa, etc. Este es el
significado de ese primer dgito:
1xx Los cdigos que empiezan por 1 son
informativos, es decir, la peticin ha sido
recibida sin problemas, y el servidor se limita
a darnos algn tipo de informacin. Ya veremos
ms adel ante el si gni fi cado de esto.
2xx Estas son las respuestas ms habituales,
ya que son las que devuelven los datos
solicitados por una peticin recibida y procesada
con xito. Por ejemplo, es la que se enva cada
vez que reci bi mos una pgi na web.
3xx Estas son las respuestas de redireccin,
que indican que para procesar la peticin es
necesario realizar acciones previas. Ya lo
veremos ms adelante.
4xx Supongo que todos estari s
familiarizados con los cdigos que empiezan
por 4 (sobre todo con el 404 y el 403), ya que
son los errores de cliente. Es decir, se envan
cada vez que el cliente intenta hacer algo que
no est permitido o que no tiene sentido para
el servidor.
5xx Estos son los errores del servidor,
que se dan cuando un cliente enva una peticin
vlida pero, por el motivo que sea, el servidor
no puede procesarla.
A continuacin, os muestro la lista completa
de cdigos de respuesta:
100: Continue
101: Switching Protocols
200: OK
201: Created
202: Accepted
203: Non-Aut hori t at i ve Informat i on
204: No Content
205: Reset Content
206: Partial Content
300: Multiple Choices
301: Moved Permanently
302: Found
303: See Other
304: Not Modified
305: Use Proxy
307: Temporary Redirect
400: Bad Request
401: Unauthorized
402: Payment Required
403: Forbidden
404: Not Found
405: Method Not Allowed
406: Not Acceptable
407: Proxy Authenti cati on Requi red
408: Request Time-out
409: Conflict
410: Gone
411: Length Required
412: Precondition Failed
413: Request Entity Too Large
414: Request-URI Too Large
415: Unsupported Media Type
416: Requested range not sati sfi abl e
417: Expectation Failed
500: Internal Server Error
501: Not Implemented
502: Bad Gateway
503: Service Unavailable
504: Gateway Time-out
505: HTTP Version not supported
Veremos ahora en detalle el significado de
algunas de estas respuestas.
5.3.1. HTTP/1.1 100 Continue:
Cuando el cliente desea enviar datos en un
PUT o un POST, tendr que pedir permiso
previamente al servidor. Para ello, en su peticin
incluir el siguiente campo de cabecera:
Expect: 100-Continue
Cuando el servidor reciba la peticin con este
campo, tendr que responder bien con:
HTTP/1.1 100 Continue
O bien con:
HTTP/1.1 417 Expectation Failed
En el primer caso, el cliente sabr que el servidor
le da permiso para enviar los datos. En el
segundo caso, el servidor le denegar el permiso.
La accin por defecto a tomar por el cliente
cuando no recibe ninguna respuesta, es asumir
que tiene permiso. Si luego la recepcin falla,
ya lo notificar el servidor posteriormente.
5.3.2. HTTP/1.1 200 Ok:
Esta es la respuesta ms comn, ya que es la
que se da cada vez que se recibe una pgina
web. En este caso, cuando es una respuesta
a un comando GET, los datos de la pgina
acompaan a esta respuesta, precedidos por
los campos de cabecera necesarios para
especificar el tipo de los datos (Content-
Type), su longitud (Content-Length), etc,
etc.
Si, en cambio, es respuesta a un comando
HEAD, todas estas cabeceras se enviarn igual
(Content-Type, etc), pero no se enviarn los
datos HTML de la pgina.
Si se trata de una respuesta a un comando
POST el servidor indicar aqu el resultado de
la accin llevada a cabo.
Si se trata de una respuesta a un comando
TRACE contendr de vuelta el mensaje que
envi el cliente al servidor (o proxy).
5.3.3. HTTP/1.1 201 Created:
Ya vimos anteriormente que esta respuesta se
utilizaba en los comandos PUT y POST, cuando
se creaba un nuevo recurso como consecuencia
de la ejecucin del comando.
5.3.4. HTTP/1.1 204 No Content:
Esta respuesta se enviar cuando un comando
se haya procesado con xito, pero no sea
necesario enviar ningn tipo de datos.
5.3.5. HTTP/1.1 300 Multiple
Choices:
Cuando el servidor encuentra ms de una
posible localizacin para el recurso solicitado,
indicar as al cliente las alternativas que tiene.
Normalmente, el navegador que utilicemos
escoger una de las opciones de forma
transparente al usuario.
5.3.6. HTTP/1. 1 301 Moved
Permanently:
Cuando la localizacin de un recurso ha
cambiado y ya no se encuentra en esa URL, el
servidor nos indicar la nueva localizacin y,
normalmente, nuestro navegador pedir esa
nueva URL de forma transparente al usuario.
5.3.7. HTTP/1.1 304 Not Modified:
A pesar de que esta respuesta forma parte del
complejo sistema de cache que he comentado,
merece la pena mencionarla. Esta respuesta se
da cuando solicitamos una pgina de la cual
tenamos una copia en nuestra cache. Si nuestra
copia de cache se corresponde con la que hay
an en el servidor, ste no tendr que
retransmitirnos la pgina entera (con un
HTTP/1.1 200 Ok), si no que bastar con
que nos devuelva esta respuesta para que
sepamos que podemos confiar en la copia de
cache.
Podemos ver un ejemplo de esta respuesta en
la captura de sesin de ejemplo.
5.3.8. HTTP/1.1 400 Bad Request:
La sintaxis de la peticin del cliente es incorrecta,
y por tanto no la puede procesar el servidor.
5.3.9. HTTP/1.1 401 Unauthorized:
El servidor exige autenticacin para que el
cliente pueda acceder a ese recurso. Esta
respuesta tendr que ir acompaada de un
campo de cabecera WWW-Authenticate que
incluya los datos necesarios para que el cliente
pueda realizar la autenticacin.
5.3.10. H T T P / 1 . 1 4 0 3
Forbidden:
Seguro que todos os habris encontrado ms
de una vez con un error 403 que, slo superado
por el 404, yo creo que es el ms habitual. El
servidor no permite el acceso a ese recurso,
porque el cliente no tiene privilegios para ello.
Es lo que ocurre, por ejemplo, cuando se
intenta acceder a un directorio cuyos contenidos
no quieren ser mostrados por el servidor.
Ojo! Que no hay que fiarse. Si realmente no
quieren que accedas a esos contenidos, muchas
veces tratarn de engaarte, haciendo que la
respuesta a esa peticin sea un error 404 en
lugar de un 403, para que ceses en tu
empeo pensando que ni siquiera existe ese
recurso ;p
5.3.11. HTTP/1.1 404 Not
Found:
Quin no conoce el archiconocido 404? Es la
respuesta que da el servidor cuando intentas
acceder a una URL que no conoce. :-)
5.3.12. HTTP/1.1 405 Method
Not Allowed:
Ya mencion anteriormente que esta respuesta
se usa cuando se enva al servidor un comando
que ste no acepta por algn motivo. Como
ya dije, esta respuesta debe venir acompaada
de un campo de cabecera Allow para indicarnos
los comandos que s podemos utilizar.
5.3.13. HTTP/1.1 407 Proxy
Aut hent i cat i on Requi r ed:
Como ya coment, esta respuesta nos la da
un proxy cuando requi ere que nos
autentiquemos. Para ello, incluir un campo
de cabecera Proxy-Authenticate, del mismo
modo que ocurre con el campo WWW-
Authenti cate y l a respuest a 401.
5.3.14. H T T P / 1 . 1 4 1 4
Request-URI too long:
La longitud de una peticin puede llevar a
problemas de seguridad, como los conocidos
bugs de buffer overflow. Por tanto, tanto el
cliente como el servidor tienen que estar
preparados para peticiones de cualquier longitud
y, en caso de que se supere la longitud mxima
que pueden procesar, devolver un error, en
lugar de tratar de procesarla con los problemas
que eso conllevara. En la prctica, una gran
mayora de aplicaciones han pecado incluso
repetidas veces de no estar preparadas para
este tipo de situaciones.
5.3.15. H T T P / 1 . 1 4 1 7
Expectation Failed:
Ya habl sobre esta respuesta, que se da cuando
un servidor no puede responder a la peticin
expuesta por el cliente en un campo Expect,
por ejemplo cuando se desea que el servidor
d el visto bueno a un comando PUT (Expect:
100-Continue).
5.3.16. HTTP/1.1 500 Internal
Server Error:
Esta es la respuesta genrica de error cuando
el servidor no puede procesar una peticin
vlida.
5.3.17. HTTP/1.1 501 Not
Implemented:
Esta respuesta se da cuando el servidor no
conoce el comando que ha enviado el cliente.
A diferencia del error 405 (Method Not
Allowed), en el caso del 405 s que se conoce
el comando, pero el servidor no permite su uso.
En cambio, en este caso, el comando es
totalmente desconocido para el servidor.
5.3.18. HTTP/1.1 503 Service
Unavailable:
El servidor no puede procesar ninguna peticin
en ese instante, quiz por una sobrecarga, o
por encont rarse en mant eni mi ent o.
Supuestamente, en un futuro el servidor podra
volver a responder a las peticiones, por lo que
es conveniente que el servidor incluya un campo
de cabecera Retry-After que indique al cliente
el tiempo que aconseja esperar antes de
reintentarlo.
6. Resumen
Por ltimo, vamos a repasar todo este barullo
con la captura de sesin que tenamos de
ejemplo. Como habris podido comprobar, es
difcil estructurar todo para hacer una explicacin
sencilla y coherente, ya que todo est
relacionado con todo, y a su vez con otros
aspectos externos (como el HTML o el MIME).
En consecuencia, la documentacin de este
protocolo es, en mi opinin, bastante catica,
y para redactar este artculo he tenido que
estar con una docena de RFCs abiertos
simultneamente para consulta, as como otras
referencias.
Espero que haya merecido la pena, y que al
menos este artculo os sirva como referencia
para hacer un estudio ms detallado realizando
vuestras propias capturas con un sniffer, y
analizando los resultados con esta gua
abreviada que he escrito.
Vamos a tratar de comprender ahora esa sesin
de ejempl o que pusi mos al pri nci pi o.
Para hacer esta captura, escrib en mi navegador
la URL www.hackxcrack.com. Por tanto, al no
haber indicado un path, mi navegador (Opera)
solicit en primer lugar el raz (/) del servidor,
de la siguiente forma:
GET / HTTP/1.1
Por supuesto, no bastaba con lanzar el comando, si no que adems mand
una serie de campos de cabecera.
El primer campo enviado, User-Agent, ya sabemos que identifica nuestro
navegador que, en este caso, es Opera para Linux:
A continuacin, enviamos una serie de campos para especificar el formato
en el que queremos recibir los datos, lo cual hacemos mediante:
Con esto, indicamos al servidor que preferimos que el texto est en formato
HTML, las imgenes en PNG, JPEG, GIF, o X-XBitMap (en este orden de
preferencia) y, por ltimo, que aceptamos cualquier otro tipo de contenido.
Indicamos tambin que preferimos los juegos de caracteres Windows-
1252, utf-8, utf-16. En segundo lugar, tambin aceptamos iso-8859-1 y,
por ltimo, si el servidor no soporta ninguno de esos caracteres, aceptaramos
cualquier otro.
Adems, aceptamos una serie de codificaciones, que seran deflate, gzip,
x-gzip, e identity (este ltimo no sera necesario indicarlo explcitamente).
Al enviar *;q=0 estamos diciendo que no admitimos otra codificacin que
no sea una de las propuestas.
Estos campos de cabecera:
Co o k i e : p hp b b 2my s q l _d a t a =a %3B1%5B%5e t c
Cache-Control: no-cache
Forman parte de los que no he querido comentar por falta de espacio,
por lo que vamos a olvidarnos de ellos. Por supuesto, podis estudiar su
significado en el RFC 2616.
Por ltimo, el campo:
Indica al servidor que la conexin ser persistente, es decir, que despus
de esta peticin pueden venir otras, por lo que no deseamos que cierre
l a conexi n TCP/IP despus de sati sfacer esta peti ci n.
Vamos a ver ahora qu nos respondi el servidor:
Empez con un cdigo de respuesta 200, por lo que la peticin fue
procesada correctamente y el servidor nos enva los datos solicitados:
HTTP/1.1 200 OK
A continuacin, nos da una serie de datos informativos, como la fecha
y hora, los datos del servidor, y otra serie de datos referidos a temas que
no he explicado por falta de espacio pero que, de nuevo, podis estudiar
por vuestra cuenta en el RFC 2616:
Date: Thu, 09 Oct 2003 14:59:29 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3 mod_perl/1.26
Last-Modified: Fri, 23 May 2003 19:52:13 GMT
ETag: "390062-1893-3ece7bed"
Accept-Ranges: bytes
Age: 0
Por ltimo, nos da informacin acerca de los contenidos (el cdigo HTML
de la pgina servida) que nos enva. En primer lugar, nos dice la longitud
en Bytes (6291), y a continuacin el tipo de contenidos de que se trata
que, en este caso, es texto HTML.
Despus de esto vendra todo el chorizo de cdigo HTML que contiene
la pgina servida.
Dentro de este cdi go HTML se encontraba l o si gui ente:
<td wi dth="218" hei ght="121" val i gn="top"><di v
align="right"><img src="imagenes/LOGOPCPASOAPASO1.jpg"
width="144" height="105" /></div></td>
Nuestro navegador, al analizar este cdigo, se dio cuenta de que tena
que solicitar al servidor la URL /imagenes/LOGOPCPASOAPASO1.jpg, por
lo que hizo una nueva peticin:
GET /i magenes/LOGOPCPASOAPASO1. jpg HTTP/1. 1
Esta vez incluy como campo de cabecera
adicional el Referer, diciendo que la ltima
URL que visitamos fue precisamente la que
pedi mos ant er i or ment e, es deci r,
www.hackxcrack.com:
Referer: http:
A continuacin, enva una serie de campos de
cabecera adicionales referidos al sistema de
cache, ya que mi navegador ya tena una copia
de esa imagen en su cache:
If-Modified-Since: Thu, 03 Apr 2003
06:06:09 GMT
If-None-Match: "710029-10d4-3e8bcf51"
Con estos datos, el servidor se dio cuenta de
que nuestra copia de cache era la misma que
tena el, por lo que no era necesario que volviese
a enviarnos la imagen en cuestin, as que nos
respondi con un:
HTTP/1.1 304 Not Modified
Tras lo cual, nuestro navegador cogi del disco
duro nuestra copia de cache de la imagen y la
incluy en la pgina que nos tena que mostrar.
Como vemos, nos result conveniente utilizar
una conexin persistente, ya que dentro del
cdigo HTML enviado por el servidor se incluan
nuevas URLs que tenamos que solicitar al
servidor, por lo que resultaba mucho ms
efectivo hacerlo en una nica conexin TCP/IP,
en lugar de tener que abrir una nueva cada vez
que se quisiera solicitar una imagen o cualquier
otro contenido incluido en el cdigo HTML de
la pgina.
Autor: PyC (LCo)
0.- Introduccin
Como promet en el nmero anterior, aqu est
el artculo sobre DCC, para completar todo lo
referente a los protocolos relacionados con
IRC.
Este artculo va a ser bastante diferente a los
anteriores. Para empezar, no se basa en ningn
RFC ya que, tal y como podemos comprobar
buscando la palabra DCC en http://www.rfc-
editor.org/rfcsearch.html , no existe ningn
RFC que especifique el funcionamiento de este
protocolo. El funcionamiento del protocolo DCC
es muy simple, por lo que para detallarlo slo
emplear la primera mitad del artculo. Es en
la segunda mitad del artculo donde se
encuentra la principal diferencia con otros
artculos de la serie, puesto que esta parte
estar enteramente dedicada a tcnicas para
explotar este protocolo.
Por tanto, en esta ocasin no me limitar tan
slo a detallar el funcionamiento de un
protocolo, si no tambin a detallar sus
problemas de seguridad.
Todas estas tcnicas para abusar del
DCCfueron ideadas por m, aunque seguro que
a ms de un lector, en cuanto lea la primera
parte en la que explico el funcionamiento bsico
del protocolo, se le ocurrirn las mismas ideas,
ya que son bastante simples (aunque no por
ello menos efectivas). Por tanto, todo lo aqu
contado es el fruto de mis experimentos
personales, as que puedo garantizar que todo
lo explicado funciona y, adems, que ningn
animal fue daado para realizar los experimentos
en el laboratorio. ;-)
1.- FUNCIONAMIENTO DEL DCC
1.1. Funcionamiento bsico del DCC a
grandes rasgos
Para los que an no sepan de qu demonios
trata este artculo, os explicar rpidamente
en qu consiste el DCC.
Los usuarios de IRC (Internet Relay Chat) no
slo tienen la posibilidad de conversar con otros
serie raw: conociendo
protocolos y su seguridad
raw 4: dcc
direct client to client
protocol
Funcionamiento del Protocolo DCC
Codificacin de Decodificacin de IPs
DCC --> Inseguro y Peligroso:
-- Obtencin de IPs -- FXP en DCC
-- Obtencin de Puertos -- Puenteando un DCC
-- DCC Send Hijacking -- Escaneo mediante Fserver
usuarios de la misma red, si no que adems
pueden hacer muchas otras cosas, como enviar
archivos, montar servidores de archivos, chat
por voz, utilizar una pizarra comn para escribir
o di bujar, o i ncl uso vi deoconferenci a.
Todas estas virgueras se consiguen mediante
un protocolo encapsulado en el propio protocolo
de IRC, que es el DCC.
En realidad, la mayora de estas virgueras son
slo implementadas por unas pocas aplicaciones
de IRC, y estn muy poco extendidas.
Como sabr cualquier asiduo al IRC, las dos
utilidades tpicas del DCC son: DCC Chat y DCC
Send.
Ambos tienen en comn una caracterstica, y
es que funcionan mediante una conexin punto
a punto entre los dos usuarios, y no a travs
del servidor de IRC. Por eso precisamente el
protocolo se llama Direct Client to Client. ;-)
Os recuerdo que en IRC todo circula a travs
del servidor. Por ejemplo, cuando escribimos
un mensaje privado a un usuario, en realidad
estamos enviando este mensaje primero al
servidor de IRC, para que luego el servidor lo
enve a su vez al usuario correspondiente.
Pensad en el problema que sera si esto no
fuese as. Para empezar, en algunas redes
(como en el IRC-Hispano) las IPs de los usuarios
no son visibles, por lo que sera imposible
establecer ningn tipo de conexin entre 2
usuarios sin la intervencin del servidor, que
es el nico que conoce las IPs de todos los
usuarios. Como segundo ejemplo, an
suponiendo que las IPs fuesen pblicas,
imaginaos lo que sera si para decir una simple
frase en un canal con 100 usuarios vuestra
modesta conexin casera (56K, 256K, o poco
ms) tuviese que establecer una conexin con
cada uno de los 100 usuarios para enviarles la
frasecita de marras.
Volviendo al DCC, ste protocolo es el que
permite realizar cualquier tarea que requiera
una conexin punto a punto entre 2 usuarios.
Las dos utilidades ms sencillas que se nos
pueden ocurrir en las que se necesite una
conexin punto a punto son:
1- Enviar archivos: menuda locura sera
si tuvisemos que enviar un archivo de 700MB
a travs del servidor de IRC mientras otros
3000 usuarios estn enviando simultneamente
sus ISOs.
Chat privado: las queries, o chats privados
entre dos usuarios de IRC, funcionan tambin
a travs del servidor de IRC (as que eso de
privado...), pero hay varios motivos para que
no queramos que nuestra conversacin pase
por un punto intermedio. Los motivos principales
son dos: en primer lugar, la privacidad, y en
segundo lugar, el no depender de las limitaciones
tcnicas del servidor intermedio.
Cuando hablo de
l i mi t a c i o ne s
t cni cas del
s e r v i d o r
intermedio me
ref i ero, ante
t odo, a dos
problemas bien
conocidos por
t o d o s l o s
usuarios de IRC,
que son: el lag,
Serie Raw - DCC - Serie Raw - DCC - Serie Raw - DCC - Serie Raw - DCC - Serie Raw - DCC
y los splits. En un DCC Chat, es decir, un chat
privado entre 2 usuarios mediante una conexin
punto a punto, y no a travs del servidor de
IRC, el lag que haya depende tan slo de la
conexin de los dos usuarios, y no de la del
servidor de IRC. Adems, si ocurre un split en
la red de IRC, o incluso si uno de los usuarios
se cae, el DCC Chat sigue funcionando sin
enterarse.
1.2. Establecimiento de la conexin
El establecimiento de la conexin en DCC es
diferente a la del resto de protocolos que hemos
visto hasta ahora en la serie RAW. Y es que no
basta con hacer un telnet a un puerto
determinado en el que hay escuchando un
servidor, si no que tenemos que realizar unas
gestiones previas para que ese puerto se
abra en la mquina a la que nos queremos
conectar.
Esto se debe a que el establecimiento de
conexin se realiza a travs del servidor de
IRC. Recordemos que un usuario de IRC no
tiene por qu conocer la IP de otro usuario,
as que si queremos establecer una conexin
punto a punto tendremos primero que
preguntarle la IP del otro usuario al servidor.
Para los que os hayis frotado las manos
pensando que esto se podra aprovechar para
sacar IPs haciendo falsas consultas al servidor,
o para los que os hayis llevado las manos a
la cabeza ante la inexactitud de lo que acabo
de decir, dejad todos las manos quietas! Lo
he explicado as para que pillis rpidamente
el concepto, pero lo que ocurre en realidad no
es que un usuario consulte la IP de otro usuario,
si no justo todo lo contrario. Lo que hace el
usuario es decirle al servidor: dile mi IP a este
usuario. As nos aseguramos de que mediante
DCC slo se podrn conseguir las IPs de los
usuarios que voluntariamente quieran.
Pero an sigo sin contar toda la verdad, ya que
en realidad todo esto es mucho ms divertido.
Lo que decimos al servidor no es exactamente
dile mi IP a este usuario, si no mi IP es sta,
anda, ve y dselo a este usuario. Por tanto, la
IP que llega hasta un usuario con el que quieres
establecer una conexin DCC, no es la IP que
conoce el servidor, si no la que t le digas...
sea cual sea...
Una vez realizadas las gestiones previas (que
consisten, resumiendo, en decirle al otro usuario
nuestra IP y un puerto para que pueda
conectarse), ya se podr establecer una
conexin TCP/IP de toda la vida que, por
supuesto, se puede realizar mediante Telnet.
Como ya dijimos, existen bsicamente 2 tipos
de mensajes DCC (todos los dems los vamos
a ignorar, por no estar tan extendidos):
- DCC Send
- DCC Chat
El DCC Send es una peticin que dice al
servidor IRC: quiero enviar ste fichero a ste
usuario.
El DCC Chat es una peticin que dice al servidor
!
Lag y Splits
Split es cuando uno (o varios) servidores que forman parte
de la RED IRC se "desconectan" temporalmente del resto
de servidores que forman esa RED. Para no ocupar 2
pginas explicando los detalles, mejor te miras este enlace
http://www.ayuda-irc.net/splits.shtml, est perfectamente
expuesto con imgenes y todo :)
Lag es cuando por el motivo que sea se produce un retraso
desde que escribes un mensaje hasta que el resto de usuarios
lo reciben y viceversa (desde que otro usuario escribe un
mensaje hasta que tu lo recibes). Las causas pueden ser
muchas, desde que tu conexin deja de responder
temporalmente hasta que el servidor de IRC al que ests
conectado est saturado.
IRC: quiero establecer un chat privado con
ste usuario.
En ambos casos, hay que aadir la siguiente
coletilla: para ello, dile que se conecte a ste
puerto en sta IP. Es decir, el que lanza la
peticin de DCC es siempre el que acta como
servidor para la conexin TCP/IP que se
establecer, bien en el envo del archivo, o
bien en el chat privado.
Para los que, al leer la definicin de DCC
Send, se hayan preguntado cmo funciona
entonces un fserver, les aclaro que las
peticiones que se hacen a un fserver no tienen
nada que ver con las peticiones de DCC, si no
que son simples comandos parseados por
un script que automatiza el lanzamiento de
peticiones DCC Send desde el fserver. Para los
que no sepis lo que es un fserver, no os
preocupis, que esto no tiene mucho que ver
con el tema. :-)
Para explicar mejor todo el proceso de conexin,
voy a poner un ejemplo, en el cual el usuario
PyC quiere enviar un archivo al usuario Scherzo.
1.2.1. PyC lanza la peticin al servidor
de IRC
Tanto PyC como Scherzo estn conectados al
mi smo ser vi dor de IRC (condi ci n
imprescindible), por lo que PyC le lanza al
servidor de IRC la consabida peticin: quiero
enviar ste fichero a ste usuario. Para ello,
dile que se conecte a ste puerto en sta IP.
(Por supuesto, ms adelante veremos el formato
real de esta peticin XD).
1.2.2. El servidor de IRC devuelve la
peticin al usuario Scherzo
A continuacin, el servidor de IRC simplemente
retransmite esa peticin a Scherzo: Oye, que
PyC me ha dicho que quiere enviarte ste
archivo. Si quieres, conctate a su IP, que es
sta, en ste puerto.
1.2.3. El usuario Scherzo acepta la
peticin
En este momento, Scherzo debe decidir si quiere
recibir ese archivo de PyC. Para ello, en su
aplicacin cliente de IRC le aparecer una
ventana preguntndole si desea aceptar el DCC.
Si no acepta, aqu se acab la historia. Pero
vamos a suponer que si que acepta.
!
Fserver es un servidor de ficheros pueden (o no) incluir
los programas de CHAT y sirve para compartir tus archivos
con otros usuarios, tienes sobre este tema mucha informacin
e n I n t e r n e t , p o r e j e m p l o e n
http://www.readysoft.es/home/ihidalgo/intermedio/filese
rver.html
Ya sabes, utiliza el mejor buscador de Internet:
www.google.com
1.2.4. Scherzo establece la conexin
TCP/IP con PyC
Una vez aceptada la peticin, la aplicacin
cliente de IRC de Scherzo establecer una
conexin TCP/IP de las de toda la vida con la
IP y puerto que se especific en la peticin.
Si nuestro cliente de IRC es nuestro amado
Telnet, podemos lanzar manualmente la
conexin abriendo otro Telnet (aparte del que
usamos para conectar al servidor de IRC),
mediante:
telnet ip puerto
Donde ip es la ip que se nos especific en la
peticin DCC, y puerto es el que se nos
especific en la peticin DCC.
1.2.5. PyC enva el archivo a Scherzo a
travs de la conexin establecida
Pues eso, inmediatamente despus de
establecer la conexin, empezar a transmitirse
el archivo a travs de esa conexin establecida.
En el caso de
que, en lugar de
DC C S e n d ,
hubi ese si do
DCC Chat ,
llegados a este
punto, en lugar
de transmitirse
e l a r c h i v o ,
comenzara una
comuni caci n
interactiva, donde cada usuario recibira lo que
el otro escribiese a travs de esa conexin
establecida.
1.3. Comandos RAW Para DCC
No hemos visto an cmo son en realidad esas
peticiones que el usuario lanza al servidor.
Estas peticiones son, por supuesto, comandos
RAW que forman parte del protocolo IRC,
sobre el cual trataba mi anterior artculo.
Si recordamos algo sobre ese artculo, sabremos
ya que los comandos que utilizamos en nuestro
cl i ente de IRC no son di rectamente
comprensibles por el servidor, ya que nuestro
cliente hace un parseo y lo convierte al formato
propio del servidor, que es el que llamamos
formato RAW.
Como rpido recordatorio, si queris hacer
pruebas con los comandos RAW, podis utilizar
el comando QUOTE de vuestro cliente de IRC.
Todo lo que pongis despus de un /quote
ser enviado en RAW al servidor.
El comando RAW ms verstil es el PRIVMSG,
as que podis probar, por ejemplo, lo siguiente:
/quote privmsg PyC: hola, PyC! Como
molan tus articulos!!! ;)
Si no utilizis un cliente de IRC, si no un Telnet
a pelo, os recuerdo que lo mismo se hara
escribiendo:
PRIVMSG PyC: hola, PyC! Como molan
tus articulos!!! ;)
El comando PRIVMSG no se usa slo para
hacer privados a otros usuarios, si no tambin
para la conversacin rutinaria en los canales.
Por ejemplo con:
/quote privmsg #hackxcrack: buenas :D
Estari s envi ando un sal udo al canal
#hackxcrack. Por supuesto, para que este
texto aparezca, tendris que estar en el canal,
o bien el canal tendr que tener modo n.
Recordemos tambin que el CTCP (Client To
Client Protocol) funciona encapsulado en el
comando PRIVMSG. Un ejemplo bsico de
CTCP es el siguiente:
/quote pri vmsg PyC: VERSION
Pues ahora vamos a rizar el rizo un poco ms.
Si bien el CTCP no es ms que un tipo de
mensaje PRIVMSG, resulta que el DCC es a
su vez un tipo de mensaje CTCP. Por lo que
al final, resulta que el DCC tambin funciona
mediante el famoso PRIVMSG. Bonito
trabalenguas. :-)
Si consideramos que el protocolo CTCP
comprende todos los comandos que se pueden
ejecutar en un servidor de IRC que implican
una comunicacin entre 2 usuarios, podemos
definir dentro de estos comandos un
subconjunto, que es el formado por aquellos
comandos que realizan una comunicacin
directa entre 2 usuarios estableciendo una
conexin especfica entre ambos. Este
subconjunto es lo que llamamos DCC (Direct
Client to Client).
Veamos ya un ejemplo de comando RAW para
DCC, y luego lo explicaremos en detalle:
/quote privmsg PyC:DCC CHAT chat
3645183495 4510
Y esos numerajos? No habamos quedado
en que lo que se enviaba en una peticin era
la IP y el puerto? Yo no veo la IP por ninguna
parte...
Pues, aunque no la veas, ah est, pero
codificada. Y, por supuesto, yo os enseo
ahora mi smo cmo decodi fi carl a. :-)
Codificacin de IPs
Os apetece estudiar un poco de aritmtica
modular? Estoy seguro de que, dicho as, no
os apetece lo ms mnimo. XD
Pero es precisamente eso lo que debemos
saber para codificar y descodificar las IPs en
una peticin de DCC.
Desde el punto de vista matemtico, una
direccin IP es un nmero de 4 cifras en base
256.
La base que utilizamos nosotros a diario es la
base 10; por eso, cada cifra de un nmero
esta comprendida entre 0 y 9. Por ejemplo, si
queremos representar el nmero 256 en base
10, separando las cifras por puntos, sera sta
su representacin: 2.5.6.
Si queremos representar el mismo nmero en
base 256, tenemos que tener en cuenta que
cada cifra podr valer ahora entre 0 y 255, y
no slo entre 0 y 9, as que sta sera la
representacin del nmero 256 en base 256,
separando las cifras por puntos: 1.0.
Curioso, eh? El nmero 10 se representa como
1.0 en base 10, y el nmero 256 se representa
como 1.0 en base 256. Esto ocurre con todas
las bases. Si conocemos la base 2, tambin
conocida como binario, sabremos que el
nmero 2 se representa como 1.0 (supongo
que conoceris el clsico chiste que dice: existen
10 clases de personas, las que saben binario,
y las que no). Si conocemos tambin la base
hexadecimal, o base 16, sabremos que el 16
se representa como 1.0. Y as con todas las
bases. :-)
Siguiendo con este curso intensivo de aritmtica
modul ar, veamos como ej empl o l a
representacin del nmero 256 en binario:
100000000, y en hexadecimal: 100.
Para que podis convertir cualquier nmero a
cualquier base, os explico brevemente el
!
Donde el smbolo recordamos que es el ascii 1, el cual
podemos escribir mediante la combinacin de teclas:
Alt + 1. Os recuerdo tambin que en algunas aplicaciones
no funciona esta combinacin de teclas, por lo que una
solucin es buscar una aplicacin en la que si que funcione,
y pastear el ascii desde ah.
mecanismo. Recordis cuando estudiabais los
nmeros en el cole y os hablaban de centenas,
decenas, y unidades? El nmero 256 se podra
descomponer de l a si gui ente forma:
256 = 2*100 + 5*10 + 6*1
La cifra 2 es la de las centenas, el 5 la de las
decenas, y el 6 la de las unidades. En realidad,
los nmeros que multiplican a cada cifra son
simplemente potencias de la base, es decir, en
este caso potencias de 10. Por ejemplo, 10
0
= 1, 10
1
= 10, 10
2
= 100.
Aplicando la misma regla, la direccin IP
217.69.22.7 se podra representar como:
217*256
3
+ 69*256
2
+ 22*256
1
+ 7*256
0
Si realizamos esta suma nos sale, en decimal,
el nmero 3645183495.
Atiza! Si es el mismo numerajo que sala en
la peticin de DCC que puse hace dos horas!
(es que estoy perdiendo un poco el tiempo en
IRC mi entras escri bo el art cul o 0:-)
Por tanto, sta es la frmula que hay que
utilizar para codificar una IP en una peticin
de DCC, cuya codificacin no es ms que la
representaci n de l a IP en base 10.
Decodificacin de Ips
Para el proceso inverso, que es obtener una IP
a partir de su codificacin en base 10, no hay
ms que invertir la frmula. Aqu es donde
vemos por qu a todo esto se le llama aritmtica
modular. Y es que necesitamos operar con el
mdulo para ir obteniendo las 4 cifras que
forman la IP.
En nuestro ejemplo, el nmero del que partimos
es el 3645183495. Pues bien, empezamos
dividiendo este nmero por el primero de los
factores, que es 256
3
, es decir:
3645183495/256
3
= 217...
Como vemos, no nos sale un nmero entero,
pero la parte entera de ese nmero es 217,
que es precisamente la primera cifra de la
IP.
As que nos quedamos con ese 217 y seguimos
operando, pero ahora con el resto de esa
divisin. Para obtener el resto podemos aplicar
directamente un operador de mdulo si
estamos programando en algn lenguaje, o
con una buena calculadora. Por ejemplo, en el
lenguaje C el operador de mdulo es el %
(ojo! Este % no tiene nada que ver con el
que suele haber en las calculadoras). Si lo
estamos haciendo a mano podemos obtener
el mdulo haciendo:
217*256
3
= 3640655872
3645183495 3640655872 = 4527623
Que es lo mismo que se obtiene si hacemos:
3645183495 % (256*256*256) = 4527623
A continuacin, obtenemos la segunda cifra
haciendo:
4527623 / 256
2
= 69...
Hallamos el nuevo resto:
4527623 % (256*256) = 5639
Seguimos:
5639 / 256
1
= 22...
Hallamos el nuevo resto:
5639 % 256 = 7
Y este ltimo resto es precisamente la ltima
cifra. :-)
Por tanto, la IP nos queda: 217.69.22.7
Es muy fcil programar una pequea aplicacin
que codifique y decodifique IPs, as que os lo
propongo como ejercicio. ;-)
1.3.1. Comando RAW para DCC Chat
Os recuerdo el ejemplo:
/quote privmsg PyC:DCC CHAT chat
3645183495 4510
Ya sabemos qu es el primer nmero: la IP
codificada en base 10.
El segundo nmero es el puerto, sin ningn
tipo de codificacin. Es decir, en el momento
en que lanzamos esta peticin de DCC, nuestra
aplicacin cliente de correo abrir el puerto
4510 en espera de que el usuario PyC se
conecte a l.
Si, en lugar de utilizar un cliente de IRC (como
mIRC, kVirc, etc) estamos utilizando Telnet a
pelo, la cosa es ms complicada. Tendremos
que abrir el puerto por medios ms rsticos,
por ejemplo utilizando netcat. Ya se explic
como abrir un puerto en escucha con netcat
en el nmero 8 de HackxCrack, en el artculo
sobre Reverse Shell.
Si estamos detrs de un firewall, es probable
que tengamos problemas con DCC, ya que no
es fcil abrir puertos dinmicamente detrs de
un firewall. Para solucionar el problema,
tenemos que abrir en el firewall unos puertos
dedicados a DCC y, al mismo tiempo, configurar
nuestro cliente de IRC para que utilice slo
esos puertos para DCC, en lugar de utilizar un
rango aleatorio muy amplio, como suelen venir
configurados por defecto (lo cual, por cierto,
es ms seguro, tal y como veremos ms
adelante).
Por ejemplo,
en mIRC,
nos vamos al
men Fi l e-
>Op t i o n s -
> D C C -
>Opti ons y
ah
configuramos
el rango de
puertos donde
pone DCC
ports.
En el ejemplo de la imagen, se utilizarn los
puertos 5100, 5101, y 5102 para lanzar las
peticiones de DCC.
En segundo lugar, configuramos la tabla NAT
del firewall para que abra esos puertos hacia
nuestro PC. En la siguiente imagen est como
ejemplo la tabla NAPT de un router ADSL
SpeedStream para abrir los 3 puertos del
ejemplo:
En esta tabla
tambin est
abi er t o el
puerto 21 de
FTP, y el 113
de IDENT, y
otro que no
os qui er o
ensear :P,
per o t odo
esto es otra
historia...
1.3.2. Comando RAW para DCC Send
Este es un ejemplo de peticin para DCC Send:
/quote pri vmsg PyC :DCC send
"yonki.jpg" 1042580430 4511 56711
Vemos que aparece el nombre del archivo
Si utilizas Windows XP ... !
Si utilizas Windows XP puede ser que tengas activado el
Firewall que incorpora Windows, pues ya sabes, mejor lo
desconectas (esto ya se ense en anteriores nmeros). Si
no sabes de qu estamos hablando psate por nuestro foro
(www.hackxcrack.com) y pregunta sobre el tema.
Si utilizas un firewall por soft (por ejemplo el ZONE
ALARM *www.zonelabs.com*) pues lo mismo, hay que
configurarlo correctamente o desconectarlo temporalmente.
Si no sabes como configurarlo pregunta en el foro y seguro
que la pea te ayuda con el tema.
yonki.jpg, y un numerajo ms que en el DCC
Chat. Los dos primeros numerajos son la IP
y el puerto, exactamente igual que en DCC
Chat. El tercer numerajo es simplemente el
tamao del archivo en Bytes.
Como ejercicio os propongo que decodifiquis
esta IP. ;-)
Pues bien... seguro que con todo esto que os
he contado ya habr aparecido en vuestras
mentes pervertidas alguna idea maliciosa para
sacar provecho del DCC pero, por si acaso,
os voy a ahorrar el trabajo contando mis ideas
maliciosas. ]:-)
2. INSEGURIDAD EN DCC
2.1. Pasos previos
Para poder llevar a cabo algunos de los
experimentos que voy a contar a continuacin,
es necesaria una investigacin previa para
conseguir ciertos datos del usuario que
usaremos (bonita redundancia), bajo su
consentimiento, espero, para realizar los
experimentos.
Para comprenderlo vamos a ver un escenario
de ejemplo, en el cual hay 3 personajes:
Zer0Cul, Ac1dBrn, y PyC.
Zer0Cul y Ac1dBrn, como su nombre indica,
son 2 representantes cualesquiera de la
conocida especie de los lamers, mientras que
PyC es un fornido y poderos.... esto... no,
quiero decir que PyC no es ms que un joven
del montn, del grupo de los frikis. ;-)
Supongamos que Zer0Cul quiere hacer un DCC
Chat a Ac1dBrn para urdir sus prfidos planes
de hackers. As que lanza la peticin de DCC
Chat, ve cmo Ac1dBrn la acepta, y comienza
el parloteo... Lo que no sabe Zer0Cul es que
en realidad con quien esta chateando no es
con Ac1dBrn, si no con PyC, que ha capturado
la conexin. ;)
Ahora que ya os he puesto un poco en situacin,
y os he abierto el apetito, vamos a ponernos
en el pellejo de PyC.
Para conseguir capturar esa conexin, PyC ha
necesitado antes de nada recopilar una serie
de datos acerca de Zer0Cul (el que ha lanzado
la peticin de DCC). La mejor forma de conseguir
estos datos es mediante ingeniera social
(ingsoc), una de las armas ms poderosas.
Pero qu datos se necesitan? Pues los dos
datos que circulan en una peticin de DCC
Chat, es decir: la IP de Zer0Cul, y el puerto
que abre Zer0Cul para la peticin de DCC Chat.
Cmo conseguir la IP de Zer0Cul
No puedo hacer aqu un tutorial completo de
obtencin de IPs, as que me limitar a explicar
lo ms bsico.
En primer lugar, si la red de IRC en la que
estamos no encripta las IPs, como en el caso
de EfNet, nos bastar con escribir en nuestro
cliente de correo:
/dns Zer0Cul
En caso de que la red tenga encriptacin de
IPs, la forma ms sencilla es conseguir
establecer una conexin DCC con Zer0Cul
mediante ingeniera social. Este mtodo tiene
la ventaja de que tambin nos servir para el
siguiente punto, que es la obtencin del puerto.
Aqu se pueden plantear 2 casos: que
consigamos que acepte una peticin
nuestra de DCC, o que consigamos que l
mismo nos lance una peticin de DCC.
Para conseguir lo primero, muchas veces
podemos aprovechar el autoaccept del cliente
de correo de Zer0Cul. Ningn cliente autoacepta
archivos .EXE, pero se puede probar con
archivos inofensivos, como .TXT. En cualquier
caso, tantear el autoaccept es un riesgo ya
que, si no acertamos, el to ya estar alerta y
ser prcticamente imposible conseguir despus
que acepte un DCC mediante ingsoc. As que
recomiendo utilizar el autoaccept slo cuando
se sabe con seguridad qu tipo de archivos
autoacepta.
Tanto si ha sido aprovechando el autoaccept,
como si ha sido mediante ingsoc, una vez que
est establecida la conexin de DCC tenemos
que comprobar rpidamente las conexiones
que tenemos establecidas. Para ello podemos
utilizar el comando netstat desde una shell
de Linux/Unix, o desde una ventana MS-DOS.
Al ejecutar netstat veremos algo como esto:
Podemos ver 2 conexiones: la primera es la
conexin que tenemos establecida con el
servidor de IRC, por lo que no nos interesa
ahora; en cambio, la segunda es precisamente
la conexin de DCC que hemos establecido
con Zer0Cul, por lo que ah tenemos su IP
visible (si, eso que he pixelado para que no
veis la IP de mi amigo :P). Por cierto, Poseidn
es el nombre de la mquina en la que estoy
ahora mismo. A que mola poner nombres de
dioses griegos a las mquinas de tu red local?
Incluso cumple con las recomendaciones del
RFC1178! ;-)
Otra forma de comprobar la IP cuando nos
acepta un DCC, sobre todo si sospechamos
que no nos va a dar tiempo a hacer un netstat
(bien porque enviamos un archivo muy
pequeo, o porque no podemos estar
pendientes del momento en que acepta) es
tener un sniffer escuchando en nuestros
puertos de DCC, y luego buscar los paquetes
de esa conexin en el log del sniffer. Os recuerdo
que en el primer artculo de la serie RAW
expliqu cmo manejar un sniffer.
En el segundo caso, que es que sea l el que
nos lance la peticin de DCC, no hay ningn
misterio, siempre y cuando utilicemos el software
adecuado. Ni siquiera hace falta que aceptemos
el DCC, ya que su IP se encontrar visible en
la propia peticin, antes de establecer ninguna
conexin. El ms famoso cliente de IRC, mIRC,
no nos servir para esta tarea, ya que no nos
muestra los datos de una peticin de DCC. Por
tanto, tenemos las siguientes opciones:
-En cualquier sistema: utilizar un cliente de
Telnet. :-)
En Linux: podis utilizar Kvirc o XChat.
En Windows: podis utilizar algn script sobre
mIRC que s que muestre las peticiones de DCC
compl etas, como por ejempl o IRCap.
En Windows, si no nos gusta utilizar
scripts: podemos tener un sniffer escuchando
en el puerto de IRC (tpicamente el 6667) y
cuando nos llegue la peticin de DCC, que
mIRC nos mostrar incompleta, ver el paquete
completo en el log del sniffer.
Cuando nos llegue la peticin veremos algo
como esto en nuestra ventana de Status:
[ 18: 38] Zer 0Cul - DCC Chat
(62.36.131.206)
-
Zer0Cul H4x0r@DDzACj.AQs89f.virtual
DCC CHAT chat 1042580430 4510
Ah podemos ver que la IP de Zer0Cul es
62.36.131.206 (como ejercicio os propongo
que lo comprobis decodificando la IP), y que
el puerto que ha utilizado para la peticin es
el 4510.
Cmo obtener los puertos de DCC de
Zer0Cul
El tema de los puertos se puede complicar
mucho ms. El problema est en que no hay
un puerto nico para DCC, si no que
normalmente se utiliza un puerto aleatorio
dentro de un rango, que es precisamente el
que os ense cmo configurar en mIRC.
Nos encontramos aqu con algo sorprendente,
y es que el DCC es mucho ms inseguro si
tenemos un firewall. Esto se debe a que, tal
y como vimos anteriormente, si nuestro firewall
no nos permite abrir puertos dinmicamente
para DCC, no tendremos ms remedio que
abrir un determinado nmero de puertos en la
tabla NAT del firewall. Este nmero suele ser
pequeo, ya que nadie pierde el tiempo en
abrir 200 puertos que no va a usar, adems
del peligro que eso conlleva. Por tanto, la gente
que est detrs de un firewall (por ejemplo,
los usuarios de ADSL con router en multipuesto)
suele tener un nmero pequeo de puertos
para DCC.
As que nuestra tarea consiste en averiguar el
rango de puertos que tiene configurado Zer0Cul
para DCC. Para eso, tenemos que conseguir
que nos enve varios DCC (cuantos ms, mejor)
y hacer estadsticas de los puertos que vemos
en cada peticin.
Si no conseguimos estas estadsticas tendremos
que utilizar en los pasos sucesivos alguna
herramienta que muestree puertos por fuerza
bruta pero esta solucin, aparte de que nos
secar los sockets en un periquete, muchas
veces no ser lo suficientemente rpida como
para que nos de tiempo a capturar la conexin.
2.2. DCC Chat Hijacking
Esta tcnica que voy a explicar se puede utilizar
tambin para capturar conexiones de datos de
FTP, tal y como veremos en el prximo artculo
de la serie que, si todo va segn lo previsto,
tratar sobre FTP.
Es precisamente lo que hizo PyC en el ejemplo
que os plante hace un rato.
Antes de capturar conexiones ajenas, vamos a
ver cmo podemos capturar nuestras propias
conexiones.
Para ello, le pedimos a un amigo, por ejemplo
Scherzo, que nos lance una peticin de DCC
Chat.
Si su peticin es algo as:
Scherzo LCo@DDzACj.AQs89f.virtual
DCC CHAT chat 1042580430 5510
Lo primero que haremos ser decodificar su IP
que, en este caso, ser 62.36.131.206. Ahora
ya podemos lanzar el telnet:
telnet 62.36.131.206 5510
Con esto establecemos la conexin de DCC
Chat con Scherzo. Para ver lo que escribimos
nosotros mismos os recuerdo que tenis que
activar el eco local en vuestro cliente de Telnet.
Y cuando nos escriba Scherzo... veremos que
el texto que escribe Scherzo nos llega a pelo,
y en ningn lugar aparece ninguna informacin
sobre el nick o la IP de la persona que nos
est hablando... ]:-)
Supongamos que nos encontramos ahora en
el escenario de ejemplo, y estamos en el pellejo
de PyC. Ya hemos recopilado la informacin
necesaria: IP de Zer0Cul, y puertos que utiliza
para DCC. Ahora lo que nos hace falta es un
tercer dato, que es realmente vital, y es saber
cundo lanzar Zer0Cul la peticin de DCC
Chat a Ac1dBrn.
Podramos hacer un muestreo constante de los
puertos en espera de que lance alguna peticin,
pero esto, aparte de que cantara en cualquier
IDS, nos consumira muchos recursos. Por
tanto, es mejor que estemos pendientes de un
parmetro que nos indica la actividad de nuestro
querido Zer0Cul, que es su IDLE. :-)
Es fcil programar un script que haga un
muestreo del IDLE de un usuario y te avise
cada vez que ste se pone a 0, pero tambin
podis hacer el muestreo a mano. Y es que,
a diferencia de las capturas en FTP, que
requieren una gran velocidad, las capturas de
DCC tienen la gran ventaja del amplio margen
de tiempo disponible.
La razn de esto es que, a no ser que Ac1dBrn
tenga autoaccept, habr un margen de tiempo
entre que reciba la peticin de Zer0Cul hasta
que la acepte. Este margen de tiempo muchas
veces es de varios segundos, ya que es un
factor humano, as que contamos con todo ese
tiempo para colarnos nosotros antes que
Ac1dBrn. :-)
Os recuerdo que para ver el IDLE de un
usuario, si no estis en el mismo servidor que
ese usuari o, basta con que hagi s:
/whois Zer0Cul Zer0Cul
Es decir, un whois con su nick repetido. Si
estis en el mismo servidor, bastar con poner
el nick una vez:
/whois Zer0Cul
Cada vez que Zer0Cul escriba algo en cualquier
canal, o en cualquier privado, su idle se pondr
a 0. Pero tambin ocurrir esto cuando lance
una peticin de DCC. Por tanto, podemos
muestrear los puertos de DCC cada vez que
se ponga a 0 su idle. Por supuesto, todo esto
se puede automatizar mediante software, as
que os propongo como ejercicio (para los que
queris sacar un 10) que hagis una aplicacin
que automatice todo esto.
Evidentemente, si Zer0Cul es tan simptico de
decir algo as como: Oye, Ac1dBrn, te voy a
enviar un DCC Chat, as que acptalo entonces
no hace falta muestrear el idle ni ms leches.
XD
En cual qui er
c a s o , l o
importante es
que sepis que
el cliente de IRC
de Zer0Cul no
realiza ningn
t i p o d e
comprobacin
sobre la IP del
que se conecta
al DCC Chat por
lo que, si sois
ms rpi dos
estableciendo la conexin que Ac1dBrn pulsando
el botoncito de ACCEPT, entonces seris
vosotros los que ocupis el puerto que tena
abierto Zer0Cul en espera de la conexin de
Ac1dBrn.
Lo ms interesante es que, tal y como vimos,
en la conexin de DCC Chat se enva el texto
a pelo, sin ninguna informacin sobre los nicks
o las IPs. Por tanto, cuando en vuestro cliente
de IRC aparece el nick del interlocutor en la
ventana de DCC Chat, es porque el propio
cliente pone el nick del interlocutor, asumiendo
que ste ser siempre el de aquel al que se
l anz l a peti ci n de DCC Chat. ]:-)
Esto es lo que ve Zer0Cul en una conexin que
intent hacer con CHICOPOP, y que fue
capturada por PyC.
Y esto es lo que ve el propio PyC en la misma
sesin, desde Telnet. Como podis comprobar,
no hay ninguna informacin sobre los nicks.
2.3. DCC Send Hijacking
La idea es exactamente la misma que con el
DCC Chat, pero la diferencia es que aqu no se
trata de una sesin interactiva, si no que
inmediatamente despus del establecimiento
de la conexin comienza la transmisin del
archivo.
Si hacis la captura mediante un cliente de
Telnet, recordad activar el LOG para luego
poder ver el fichero. Bastar con que renombris
el archivo .log a la extensin adecuada.
No podis conocer la extensin original del
archivo, ni su nombre, ya que la peticin (en
la cual iba incluido el nombre del archivo con
su extensin) no os lleg a vosotros, si no al
receptor legtimo. Por tanto, tendris que
analizar el archivo para deducir su extensin.
Evidentemente, no me voy a poner aqu a
hablar sobre las cabeceras de los distintos
formatos de archivos, ya que se saldra bastante
del tema, y esta revista sera ms gorda que
una biblia. :-)
2.4. IP Spoofing en DCC
No hay que ser muy listo para darse cuenta de
que spoofear la IP en una peticin de DCC es
absolutamente trivial. Si vuestro problema es
que no sabis lo que es el IP spoofing, os
aclaro en un segundo que consiste simplemente
en enviar, con algn fin, paquetes con una IP
falsa, es decir, que no es vuestra IP real.
El IP spoofing clsico consiste en modificar el
campo de IP de origen en la cabecera de los
datagramas IP, l o cual ti ene muchos
inconvenientes que no viene al caso comentar.
Pero en este caso la modificacin no se hace
a nivel de red, si no dentro del propio protocolo
DCC.
Veamos algunas ventajas que se pueden sacar
del hecho de poner una IP que no es la nuestra
en una peticin de DCC.
!
Como puedes ver, en cada artculo te "proponemos" que
investigues sobre temas que quizs nunca te has planteado.
Busca informacin sobre las cabeceras de archivo y vers
que cada tipo de archivo (.exe, .avi, .zip, .mp3 ) est
perfectamente definido gracias a su cabecera.
Y cual es la utilidad de hacer FXP en DCC?
Pues eso depende de vuestra imaginacin,
pero se me ocurren un par de ejemplos.
En primer lugar, si tienes una mquina con
una conexin rpida (por ejemplo, en el curro,
o en la facultad) y quieres bajar archivos de
un Fserver rpido desde casa, puedes
automatizar los downloads desde el Fserver
hacia la otra mquina sin moverte de casa.
Supongamos que el nick del Fserver es WrzServ,
el nick de nuestra mquina remota es FastDld,
y nuestro nick en casita es PyC. Vamos a verlo
paso a paso:
paso 1: ponemos el archivo que queremos
en la cola de download del Fserver
Se sale del tema del artculo explicar el
funcionamiento de un Fserver, as que espero
que ya conozcis el clsico mecanismo de:
trigger -> bsqueda del archivo mediante dir
y cd -> get.
2.4.1. A ver quin es ms listo
Si nos paseamos a menudo por redes con
encriptacin de IPs, como el IRC-Hispano, o
Netshock, nos podremos encontrar con algn
listillo que intente utilizar con nosotros la tcnica
que expliqu antes para conseguir tu IP. Me
refiero a conseguir por cualquier mtodo
(tpicamente ingeniera social) establecer una
conexin DCC contigo.
En el momento en que el listillo consiga que
le enves un archivo o le hagas un DCC Chat,
estar convencido de que ya tiene tu IP. Claro
que... lo que no sabe es que nosotros somos
an ms listos que l. ;-)
Cuando sospechemos que alguien quiere
conseguir nuestra IP intentando convencernos
para establecer cualquier tipo de conexin
DCC, podemos simular que hemos cado en la
trampa, envindole nosotros un DCC pero,
por supuesto, esta peticin de DCC no
llevar nuestra IP, si no cualquier otra.
La eleccin de la IP la dejo a vuestra
imaginacin, pero puede ser bastante divertido
ver cmo el listillo comienza su ataque contra
una IP de a guardia civil, o contra su propia
IP.
2.4.2. FXP en DCC
Bueno, l o l l amo FXP por l l amarl o de
alguna forma. Espero que sepis lo que
es el FXP (File eXchange Protocol), pero os
resumo contndoos que consiste en utilizar
un cliente (tpicamente de FTP, aunque en
este caso ser de DCC) para realizar
una transferencia de archivos entre 2
servidores.
El FXP es el mecanismo utilizado por los couriers
de los grupos de warez para distribuir las
releases a travs de los distintos servidores,
sin necesidad de que ellos tengan conexiones
de alta velocidad en su casita.
!
Para ms i nformaci n sobre FXP psat e por
www.hackxcrack.com y descrgate GRATIS el nmero
uno de esta revista en formato PDF ;)
paso 2: nos llega el DCC send del Fserver
Cuando llega nuestro turno en la cola (queue)
del Fserver, nos llegar su peticin de DCC
Send. NO la aceptaremos. En lugar de eso,
copiaremos la peticin tal cual nos llega (os
recuerdo que para ver la peticin completa no
nos sirve mIRC, tal y como expliqu en el
apartado 2.1).
La peticin podra ser algo as:
: W r z S e r v ! W r z @ 8 2 - 1 5 - 3 1 -
37.uc.nombres.ttd.es PRIVMSG PyC :DCC
SEND edlin.iso 1376722725 4510
681574400
paso 3: enviamos el DCC send a nuestra
mquina remota
Esa peticin que hemos copiado la reenviamos
a FastDld, con slo cambiar el nick de destino:
/quote privmsg FastDld :DCC SEND
edlin.iso 1376722725 4510 681574400
paso 4: el autoaccept de FastDld chupa
el archivo :)
Para que nuestra mquina remota pueda chupar
los archivos que le FXPeamos tiene que tener
autoaccept para ese tipo de archivos.
Mira que somos rebuscados, eh?... pero y lo
friki que resulta chupar archivos de esta forma
tan complicada? :-)
Una segunda utilidad que se me ocurre para
el FXP en DCC es el engaar simultneamente
a 2 listillos-busca-IPs, pero me parece a m que
eso mejor os lo cuento con DCC Chat, que es
an ms divertido... ;-)
2.4.3. Puenteando un DCC Chat
Este truquillo no tiene mucha utilidad, excepto
el poder rerte un rato o fardar de las chorradas
que sabes hacer, pero a mi personalmente me
encanta. :-)
Supongamos que hay 2 listillos que quieren
conseguir nuestra IP, intentando establecer un
DCC con nosotros. Para no variar, se llamarn
Zer0Cul y Ac1dBrn. Ambos estarn deseando
que les lancemos una peticin de DCC, o bien
que aceptemos una peticin suya.
En el momento en que, por ejemplo, Zer0Cul
nos tantee lanzndonos una peticin de DCC
chat estar la cosa hecha. Recibiremos algo
como esto:
: Z e r 0 C u l ! H 4 x 0 r @8 2 - 1 5 - 3 1 -
37.uc.nombres.ttd.es PRIVMSG PyC :DCC
CHAT chat 1376722725 4510
As que de inmediato modificamos
ligeramente esa peticin, para lanzar
esto:
/quote privmsg Ac1dBrn :DCC CHAT chat
1376722725 4510
Es decir, mandamos exactamente la misma
peticin a Ac1dBrn.
Desde el punto de vista de Ac1dBrn, TU sers
el que le estar lanzando la peticin de DCC
Chat, cuando en realidad esa era la peticin
que te l anz a ti
Ze r 0Cul . En e l
momento en que
Ac1dBrn la acepte,
desde el punto de vista
de Zer0Cul TU sers el
que lo habr aceptado.
A par t i r de ese
momento comenzarn
un dilogo de besugos,
creyendo cada uno de
el l os que el otro
interlocutor eres t. 0:)
Aqu os copio un par de capturas de pantalla
de un DCC chat puenteado entre 2 colaboradores
voluntarios, para que veis que desde el punto
de vista de ambos es con PyC con quien creen
estar hablando.
Esto es lo que ve shoot_me en el DCC Chat con Smeagol_
Esto es lo que ve Smeagol_ en el DCC Chat con shoot_me
Os dejo como ejercicio que apliquis esta misma
idea a DCC Send en lugar de a DCC Chat, tal
y como os expliqu en el apartado anterior
sobre FXP.
2.4.4. Escaneo annimo de puertos a
travs de un Fserver
No me cabe duda de que vais a flipar con lo
increblemente retorcida que es mi mente, ya
que hay miles de formas ms sencillas de hacer
un escaneo de puertos que la que voy a plantear
aqu, pero os recuerdo que mi fin no es ensear
a nadie a ejecutar un programa con un botn
muy grande que ponga DESTRUIR MAQUINA
REMOTA, si no el hurgar en las tripas de los
protocolos hasta que nuestra ansia de
conocimiento se sacie al conocer hasta los ms
rebuscados trucos.
Aqu os explicar como hacer un escaneo de
puertos annimo, utilizando un Fserver como
bouncer. Los resultados son bastante psimos,
os lo advierto. xD
El sistema de escaneo de puertos ms tpico
es el de lanzar intentos de conexin a cada
puerto, y ver cual es la respuesta. No puedo
entrar aqu en el tema de los flags de la cabecera
TCP por falta de espacio pero, para los que
sepis algo del tema, me refiero al envo de
paquetes con el flag SYN. Cada vez que se
intenta establecer una conexin TCP/IP, lo
primero que hace el cliente es enviar al servidor
un paquete con el flag SYN. Esto, por supuesto,
tambin ocurre al intentar establecer una
conexin de DCC.
Planteamos una nueva situacin. Tenemos un
Fserver, cuyo nick es WrzServ, y una mquina
que queremos escanear, cuya IP es 82.15.31.37,
y nosotros mismos somos el usuario PyC, para
no variar. :-)
La condicin necesaria para que esto funcione
es que el Fserve autoacepte algn tipo de
archivo, como ocurre muchas veces. Yo slo
realic experimentos con un Fserve que utilizaba
Ircap 6.999. Propongo como ejercicio
que intentis conseguir esto mismo con otros
scripts, para lo cual tendris que hacer una
labor de investigacin para analizar las
respuestas que os pueda dar el script, tanto
ante un puerto abierto, como ante un puerto
cerrado. Suponemos en el ejemplo que WrzServ
utiliza Ircap 6.999, para que veis las respuestas
que da este script ante un escaneo.
1: envo de la peticin spoofeada
Tenemos que construir una peticin de DCC
Send (ya que DCC Chat es improbable que
sea autoaceptado) en la que la IP sea la de la
mquina que queremos escanear (82.15.31.37),
y el puerto pues... el que queremos escanear.
:-)
Vamos a ver si en esa IP hay un servidor de
SMTP corriendo (puerto 25), as que construimos
el siguiente paquete:
/quote privmsg WrzServ :DCC SEND
uber.lco 1376722725 25 6922
Por supuesto, el primer nmero es la codificacin
de la IP que queremos escanear, el segundo
es el puerto (25 = SMTP), y el tercero un
tamao de archivo que nos inventamos, al igual
que el nombre del archivo.
2: respuesta del script ante un puerto
abierto
Si hay un servidor SMTP en la mquina que
estamos escaneando, la respuesta de WrzServ
ser algo como esto:
-WrzServ- Recibido caca.pis ( 89 bytes ).
Tus crditos en mi Fserve son
de 300000 ( + 0 )
Como vemos, el Fserver nos dice que ha recibido
89 bytes, lo cual significa, no slo que el puerto
le ha respondido cuando ha lanzado la
conexin, si no que adems le ha enviado un
mensaje de bienvenida de 89 bytes.
En el caso de que no haya mensaje de
bienvenida, nos responder con ( 0 bytes ).
La respuesta suele tardar bastante en llegar,
os aviso.
3: respuesta del script ante un puerto
cerrado
En este caso, la respuesta puede ser algo como
esto:
-WrzServ- Recibido caca.pis ( bytes ). Tus
crditos en mi Fserve son
de 300000 ( + 0 )
Como vemos, en este caso no ha recibido nada,
ya que no ha podido conectar con el puerto.
La diferencia con el caso de que el puerto est
abierto pero sin mensaje de bienvenida, es que
en ese caso nos pondra ( 0 bytes ), en lugar
de poner simplemente ( bytes ).
Por supuesto, la mquina que est siendo
escaneada no conocer en ningn momento
vuestra IP, ya que ser WrzServ el que se est
conectando a sus puertos.
2.5. Desvariando de todas las formas
posibles
Si usamos nuestra retorcida imaginacin, se
nos pueden ocurrir mil virgueras ms, la
mayor a si n l a ms m ni ma uti l i dad.
Por ejemplo, si lanzamos esta peticin a un
usuario cualquiera, por ejemplo a Zer0Cul:
/quote privmsg Zer0Cul:DCC CHAT chat
3586965548 23
Cuando acepte la peticin, su cliente de IRC
se conectar, sin que l lo sepa, a un servidor
en el que unos frikis han puesto la peli de star
wars en ascii. Todos los fotogramas de la peli
le irn llegando a travs del DCC Chat.
Realmente intil, verdad? :)
Otra idea estpida consiste en lanzar una
peticin de DCC Chat donde la ip est spoofeada
para que sea la de alguna mquina que tenga
un servidor de echo (puerto 7) corriendo.
Algunos cablemodems, por ejemplo, tienen
servicio de eco. Cuando acepten el DCC Chat,
todo lo que escriban en la sesin de chat les
ser devuelto como si estuviesen hablando con
un loro.
Otra cosa que podis hacer es conectaros a
cualquier tipo de servidor utilizando DCC Chat.
Por ejemplo, servidores de FTP, POP3, SMTP,
WEB, etc, etc. Podis escribir comandos y recibir
las respuestas como si se tratase de Telnet. Y
luego dicen de emacs, pero se puede hacer
todo sin salir de tu cliente de IRC, as que, como
sigamos as, mIRC terminar siendo el sistema
operativo del futuro. xD
Autor: PyC (LCo)
Ilustraciones: MariAn (LCo)
Agradecimientos: Scherzo (LCo), uhm, CabRa,
CHICOPOP, shoot_me, kaiszz, Smeagol_, ...
QUIERES COLABORAR CON PC PASO A PASO?
PC PASO A PASO busca personas que posean conocimientos de
informtica y deseen publicar sus trabajos.
SABEMOS que muchas personas (quizs tu eres una de ellas) han creado
textos y cursos para consumo propio o de unos pocos.
SABEMOS que muchas personas tienen inquietudes periodsticas pero
nunca se han atrevido a presentar sus trabajos a una editorial.
SABEMOS que hay verdaderas obras de arte creadas por personas
como tu o yo y que nunca vern la luz.
PC PASO A PASO desea contactar contigo!
NOSOTROS PODEMOS PUBLICAR TU OBRA!!!
SI DESEAS MS I NFORMACI N, env anos un mai l a
empleo@editotrans.com y te responderemos concretando nuestra oferta.
Tambin necesitamos urgentemente alguien que se ocupe de la
publicidad y de la web de esta editorial, para ms informacin
envanos un mail a empleo@editotrans.com
0. INDICE:
1. DOCUMENTACION
1.1. Un lugar donde vivir
1.2. Como siempre, empezamos con
los RFCs
1.3. Arquitectura del IRC
1.3.1. Redes
1.3.2. Servidores
1.3.3. Canales
Tipos de usuarios de un
canal
1.4. Seguridad en IRC
2. PROTOCOLO IRC
2.1. Comandos de conexin
2.1.1. Conectando con el servidor
2.1.2. Identificndonos
2.1.2.1. Comando NICK
2.1.2.2. Comando USER
2.1.2.3. Comando OPER
2.1.2.4. El IDENT
2.1.3. Comando MODE (modos de
usuario)
2.1.4. Comando QUIT, y /quote
2.2. Comandos de canales
2.2.1. Comando JOIN
2.2.2. Comando PART
canal)
usuario por canal)
2.2.5. Comando TOPIC
2.2.6. Comando LIST
2.2.7. Comando INVITE
2.2.8. Comando KICK
2.3. Comando PRIVMSG
2. 3. 1. Mensaj es pri vados
2.3.2.Escribiendo en el canal
2.3.3. Escribiendo en un canal en
el que no estamos
2.3.4. El protocolo CTCP
2.3.4.1. CTCP PING
ATENCION!! Sobre el ping timeout
2.3.4.2. CTCP VERSION
2.3.4.3. CTCP TIME
2.3.5. El protocolo DCC
2.4. Comandos de consulta al servidor
2.4.1. Comando MOTD
2.4.2. Comando LUSERS
2. 4. 3. Comando VERSION
2.4.4. Comando STATS
2.4.5. Comando LINKS
2.4.6. Comando TIME
2.4.7. Comando TRACE
2.4.8. Comando ADMIN
2.4.9. Comando INFO
2.5. Comandos de consulta sobre los
usuarios
2.5.1. Comando WHO
2.5.1.1. Listado de usuarios
2.5.1.2. Listado de usuarios en
canales
2.5.1.3. Bsqueda de usuarios
por IP
2.5.2. Comando WHOIS
2.5.3. Comando WHOWAS
3. PARA TERMINAR
RAW3: IRC
(Internet relay chat)
1. DOCUMENTACIN
1. 1. Un lugar donde vivir
Un mes ms, tenis con vosotros la serie RAW,
pero esta vez para presentaros algo ms que
un protocolo. Y es que el IRC es ms que eso,
ya que es tambin un lugar donde vivir.
Realmente, hay una diferencia cualitativa entre
pasar tus ratos en Internet visitando pginas
Web y bajando algn que otro gigabyte, y
entre tener adems una residencia fija en la
red, donde se sabe que se te podr encontrar
siempre que ests en persona en la red (es
decir, que no est slo tu PC conectado mientras
t te tomas unas cervezas).
Por supuesto, t no eres el nico habitante de
esa residencia, si no que la compartes con
millones de usuarios de todo el mundo que
han escogido alguna red de IRC como su hogar
en la red.
Y por qu IRC, y no cualquiera de los otros
famosos sistemas de mensajera, como
Messenger, ICQ, ...? Pues hay muchos motivos,
pero yo creo que los ms importantes son
sobre todo dos:
- En primer lugar, por la libertad, ya que
IRC no es un sistema propietario, como lo
puede ser Messenger (Microsoft), ICQ
(Mirabillis), y muchos otros. Al ser IRC un
estndar libre, tienes cientos de redes en todo
el mundo para escoger la que ms te guste.
Hay redes al gusto de cada uno. Por ejemplo,
si te gusta la anarqua (en el sentido de que
no hay prcticamente bots de servicio) puedes
escoger EfNet, en cambio, si te gusta ser
controlado, puedes escoger el IRC Hispano.
- En segundo lugar, porque desde 1988
(cuando Jarkko Oi kari nen puso en
funcionamiento el primer servidor de IRC), las
redes de IRC han ido creciendo y convirtindose
en un complejo universo autosuficiente. Y digo
autosuficiente porque puedes conseguir
cualquier cosa utilizando tan slo el IRC. Podra
hablaros de los miles de canales de warez, y
de otras muchas cosas, pero ese no es el
objetivo de este artculo, en el cual no voy a
hablaros sobre el mundillo del IRC, si no sobre
el protocolo que hace que la cosa funcione.
1.2. Como siempre, empezamos
con los RFCs
Aunque muchos de vosotros pasis del tema,
ya que para saciar la curiosidad de la mayora
bastar con leer el artculo (que para eso est),
aun as es mi deber dar las referencias para
los que queris profundizar ms en el tema.
Consi derando l a gran cant i dad de
documentacin que circula sobre IRC, me veo
en la necesidad de insistir en que aqu slo voy
a hablar de IRC como protocolo. As que este
no es otro ms de los miles de artculos clnicos
en los que se explican las mismas barbaridades
de siempre (takeovers, nukes, etc, etc). As
que cambiemos el chip, e imaginemos que
somos ingenieros de la IETF (Internet
Engineering Task Force), y no simples usuarios
curiosos. ;-)
Con respecto a los RFCs, hay bsicamente 4
que abarcan todos los aspectos del protocolo
IRC, aunque en este artculo hablaremos un
poco tambin de un quinto documento: el de
IDENT.
El RFC que empieza explicando los conceptos
bsicos de la arquitectura del IRC es el RFC
notes/rfc2810.txt). Si conocis ya bien el
funcionamiento del IRC os podis saltar este
RFC, aunque nunca est de ms mirarlo por si
acaso os enteris de algo nuevo.
Hay otro RFC, que es el que profundiza en el
tema de la administracin de canales. Se
explican todos los tipos de canales, as como
sus modos. Este es el RFC 2811 (ftp://ftp.rfc-
El tercer RFC es el ms interesante, y es sobre
el que ms hablaremos a lo largo del artculo.
En l se explica el protocolo utilizado entre un
cliente y un servidor de IRC, y es el RFC
notes/rfc2812.txt).
SERIE RAW - IRC - SERIE RAW - IRC - SERIE RAW - IRC - SERIE RAW - IRC - SERIE RAW - IRC
Por ltimo, en el RFC 2813 (ftp://ftp.rfc-
editor.org/in-notes/rfc2813.txt) se entra en
detalle en el protocolo utilizado para la
comunicacin de dos o ms servidores de
IRC. Si hemos ledo el primer RFC ya sabremos
que la arquitectura de IRC es distribuida, pero
tranquilos, que ahora mismo os lo explico. :-)
1.3. Arquitectura del IRC
Esto ser un breve resumen, ya que escapara
de la intencin de este artculo el hacer una
descripcin detallada de las cuestiones que
estn ms all de la mera descripcin de un
protocolo.
Podramos estructurar, simplificando mucho, la
arquitectura del IRC en 3 capas:
- redes
- servidores
- canales
1.3.1. Redes
Existe una gran variedad de redes de IRC
totalmente independientes. Cada red sera
como un mundo aparte. Por ejemplo, el canal
#hackxcrack puede existir tanto en EfNet como
en el IRC-Hispano, pero nada tendrn que ver
entre s ambos canales, ya que en cada uno
habr una gente diferente, y unas normas
diferentes.
Nombro aqu unas cuantas redes con algn
comentario personal (basado nicamente
en mi experiencia) sobre sus caractersticas:
- EfNet: la primera red que se mantiene
desde el comienzo del IRC hasta nuestros das.
Tcnicamente, funciona bastante bien (pocos
splits, poco lag, etc) y, al ser una red tan
antigua, tiene ya muchos canales firmemente
consolidados en los que se pueden encontrar
gran cantidad de recursos (informacin,
software, etc). Su principal inconveniente podra
ser quiz la anarqua, ya que no existen bots
de servicio para registro de nicks y canales,
pero eso es segn se mire, ya que muchos lo
pueden considerar una ventaja. Es quiz la red
con mayor nmero de usuarios (en el momento
en que escribo esto hay casi 124000 usuarios
conectados)
- Undernet: Otra red clsica. Hace aos
se mova mucho warez por ah, pero las cosas
ya no estn como antes. An as sigue siendo
una red con bastante vida.
- Dalnet: Bastante parecida a Undernet.
Tambin se mova mucho warez, y cuenta
tambin con bastantes usuarios.
- IRC-Hispano: Es una red espaola,
a diferencia de las otras. La mayora de los
usuarios son espaoles, y no se ven apenas
sudamericanos. Esta red, sobre todo en los
ltimos aos, ha sufrido gran cantidad de
polmicas por usuarios descontentos por la
pol ti ca de sus admi ni stradores. Yo,
personalmente, hace ms de un ao que jur
no volver a pisarla, pero no voy a entrar aqu
en polmicas. ;-)
- Red latina: Otra red de habla hispana
pero, al contrario que la anterior, sta est
poblada sobre todo por sudamericanos, y
apenas se ven espaoles. Es una red bastante
insegura, aunque explicar el por qu se saldra
del objetivo de este artculo. 0:)
1.3.2. Servidores
Cada red de IRC est formada a su vez por un
cierto nmero de servidores. Todos los
servidores forman una red nica (o as debera
ser) cuya finalidad es hacer que la naturaleza
distribuida del servicio de IRC sea transparente
al usuario. Es decir, independientemente del
servidor al que te conectes, tendrs los mismos
servicios y tendrs comunicacin con las mismas
personas y los mismos canales, siempre y
cuando los servidores pertenezcan a la misma
red. Esto en la prctica no es tan perfecto como
lo pinto aqu, ya que hay muchos problemas
como los splits, o las diferencias en los detalles
de configuracin entre servidores.
La arquitectura distribuida de las redes de IRC
permite tener un mayor nmero de usuarios,
aunque el sistema es poco eficiente, y cada
Dalnet: irc.dal.net
irc.eu.dal.net
Undernet: eu.undernet.org
us.undernet.org
1.3.3. Canales
Dentro de cada red, habr un cierto nmero
de canales de todo tipo. Hay canales temticos
(distintos estilos o grupos de msica, distintos
hobbies, etc), as como canales de colectivos
de toda ndole (desde grupos de warez, hasta
simples grupos de amigos). Cualquiera puede
crear un canal con tan slo
escribir un comando, por
lo que el nmero de
canal es es real mente
grande. Por ejempl o,
mientras escribo esto, en
EfNet estn funcionando
en este instante 44345
canales.
dicho, la arquitectura
distribuida de una red de
IRC es transparente al
usuari o, por l o que
c u a l q u i e r u s u a r i o
c o n e c t a d o a u n a
determinada red debera
ver los mismos canales que
cualquier otro usuario que
est conectado a otro
servidor de la misma red.
Slo hay una salvedad a
esto, y es que existe la
posibilidad de crear canales
locales para cada servidor, y son los canales
que, en lugar de comenzar por # comienzan
por &.
Por ejemplo, si estoy en el servidor irc.isdnet.fr
de EfNet y creo el canal #hackxcrack,
cualquier usuario de EfNet podr entrar en ese
canal, est en el servidor que est. En cambio,
si creo el canal &hackxcrack, slo podrn
entrar en l los usuarios de EfNet que adems
estn conectados a travs del servidor
vez que se conecta un nuevo usuario aumenta
la carga de todos los servidores (y no slo del
servidor al que se ha conectado), ya que todos
los servidores tienen que mantener unas tablas
de datos comunes, as como una comunicacin
constante de todo tipo de eventos, para
garantizar la transparencia de la arquitectura
de la red de cara al usuario.
Por poner un ejemplo, en el instante en que
escribo esto, hay 4081 usuarios conectados
al servidor de EfNet al que estoy yo conectado,
mientras que en total, en todo EfNet, hay casi
124000 usuarios.
Mapa de servidores del IRC-Hispano. En http://wjr Mapa de servidores del IRC-Hispano. En http://wjr.or .org/?tar g/?target=ircmaps& get=ircmaps&
state=expand tenis el mapa de servidores de EfNet. state=expand tenis el mapa de servidores de EfNet.
A modo de ejemplo, estos son algunos
servidores de algunas redes. Se pueden
encontrar listas completas en la Web de cada
red, o bien en la ventana de conexin de
cualquier cliente de IRC:
Efnet: irc.isdnet.fr
irc.homelien.no
efnet.demon.co.uk
irc.isdnet.fr.
Tipos de usuarios de un canal :
Para comprender muchas de las cosas que
explicar a lo largo del artculo, hay que conocer
los 3 tipos bsicos de usuarios en cualquier
canal:
- operadores (@) : son los usuarios
con privilegios para administrar la configuracin
del canal. En la lista de usuarios del canal, su
nombre aparecer precedido por una arroba
@. A lo largo del artculo veremos en qu
consisten exactamente los privilegios de un
operador. Es importante que no confundamos
un operador de canal con un operador de la
red o del servidor (a veces llamados IRCops).
- voz (+) : su nombre aparece
precedido por una cruz +. En los canales
moderados (ya veremos ms adelante lo que
significa esto), son los nicos que pueden
hablar en el canal sin ser operadores. En canales
no moderados, se utiliza muchas veces como
signo de distincin, aunque no les da ningn
privilegio sobre la administracin del canal.
- usuarios llanos : todos los que no
tengan ni @ ni +. :-)
1.4. Seguridad en IRC
Os creis que os voy a contar aqu lo que
podis encontrar en cualquiera de los millones
de tutoriales sobre hacking en IRC? Mi objetivo
es aportar algo nuevo, as que si queris conocer
los tpicos truquitos de toda la vida, recurrid al
omnisciente Google. :-)
En este artculo me voy a centrar slo en el
protocolo IRC.
Lo que s que puedo aportar con respecto a
seguridad, y que no encontraris en cualquiera
de esos tutoriales clnicos, es la seguridad en
el protocolo DCC (utilizado para conexiones
punto a punto dentro de IRC, por ejemplo para
chats privados, o para envo de archivos), pero
el DCC es un protocolo en si mismo, y merece
un artculo entero para el solito, as que
paciencia, y esperad al prximo mes para
conocer los entresijos del DCC. ;-)
2. PROTOCOLO IRC
Vamos ya al grano.
Podramos dividir el IRC como protocolo en 3
capas de abstraccin:
- script
- aplicacin cliente
- protocolo raw
La capa script sera aquella en la que se realizan
las acciones mediante mens e iconos. Cuando
se pulsa uno de estos iconos o mens, lo que
hace nuestro script en realidad es ejecutar una
serie de comandos de las capas inferiores que
veremos ahora mismo.
La capa aplicacin cliente es quiz la ms
conocida por parte de los asiduos al IRC. Son
aquellos comandos que escribimos directamente
desde el cliente de IRC, utilizando como prefijo
la famosa barra /.
Al contrario de los que algunos piensan,
estos comandos no son los que enva a pelo
nuestro cliente de IRC al servidor. Al igual que
los mens y los iconos, siguen siendo
simplificaciones para hacer ms fcil el manejo
al usuario.
En la capa de protocolo raw es en la que se
envan a pelo los comandos que entiende el
servidor, y sta es en la que se va a centrar el
artculo. ste es el protocolo que tendris que
utilizar si conectis por Telnet a un servidor
de IRC, ya que es el nico que entiende el
servidor. Algunos comandos difieren muy poco
entre la capa raw y la anterior (en muchos
casos, la nica diferencia es que en la capa
raw el comando es el mismo pero sin la barra
/ delante), pero otros son bastante ms
complejos (por ejemplo, los comandos de DCC,
que explicar en el prximo artculo).
Nos olvidamos de las dems capas, y nos
centramos a partir de ahora tan slo en la capa
raw.
2.1. Comandos de conexin
2.1.1. Conectando con el servidor
Tenis ya vuestro cliente de Telnet calentando
motores? Espero que as sea, porque entramos
ya di r e c t a me nt e c on e l t e ma .
El puerto estndar para los servidores de IRC
es el 6667, aunque dependiendo de cada
servidor, el servicio podr encontrarse en otro
puerto. Por eso es necesario tener siempre a
mano l os detal l es de cada servi dor.
A lo largo del artculo vamos a utilizar el servidor
irc.isdnet.fr de EfNet (EfNet es una red libre,
por lo que al utilizarlo como ejemplo no entro
en polmicas de partidismos; Adems, en EfNet
se encuentra el canal #hackxcrack en el que
podris encontrarme normalmente), as que
esto es lo que tendrais que escribir para lanzar
la aplicacin de Telnet:
telnet irc.isdnet.fr 6667
2.1.2. Identificndonos
Una vez conectados, tenemos que ser rpidos,
ya que el servidor tiene un timeout, as que
tendremos que tener preparados los comandos
de identificacin para lanzarlos rpidamente.
Son 2 los comandos a ejecutar para completar
la entrada en el servidor:
2.1.2.1. Comando NICK
El primer paso es muy sencillo, simplemente
tenemos que indicar nuestro nickname. Si, por
ejemplo, queremos que nuestro nick sea PyC,
slo tenemos que escribir:
NICK PyC
Si nos dice que el nick ya est en uso, podemos
volver a ejecutar el comando NICK tantas
veces como queramos, hasta que encontremos
un nick libre.
Despus de haber completado el proceso de
identificacin (con este comando y el que
explico a continuacin), podremos utilizar el
comando NICK cada vez que queramos cambiar
nuestro nickname.
2.1.2.2 Comando USER
El segundo paso consiste en dar el resto de
datos para identificarnos, es decir: el nombre
de usuario, nuestro nombre real, y los modos
de usuario.
Si sois ya usuarios de IRC, supongo que miles
de veces habris hecho un WHOIS a alguien,
y la primera lnea que os habr respondido el
servi dor ser al go pareci do a esto:
Como vemos aqu, lo primero que nos muestra
el whois es el nick (PyC), lo segundo el nombre
de usuario (Pic2), lo tercero la IP, o un DNS
as oc i ado a es a I P ( 218- 13- 21-
72.uc.nombres.ttd.es), y por ltimo el nombre
real del usuario (PyC PoC). Tanto en el campo
de nombre de usuario, como en el de nombre
real en principio podemos poner lo que
queramos, por lo que no le demos ms vueltas.
El nico detalle que hemos de saber es que en
el campo de nombre real es el nico en el que
se pueden separar palabras por espacios.
Lo nico importante a la hora de identificarnos
sera el campo de modos, pero en realidad en
muchos servidores no est implementado el
cambio de modos durante la identificacin (por
ejemplo, en el que estamos utilizando,
irc.isdnet.fr, no est implementado), por lo que
normalmente hay que cambiar los modos
despus de habernos identificado.
El campo de modos en la identificacin permite
poner automticamente los modos de usuario
+w y +i, mediante una mscara de bits (bit
2 para +w, y bit 3 para +i). Por tanto, estos
son los valores que habra que poner en este
campo segn los modos que queramos activar:
Aunque insisto en que no es mi objetivo explicar
en este artculo el funcionamiento del IRC a
nivel de usuario, os recuerdo que:
- el modo +i es el modo de usuario
invisible, que permite que tu nick no aparezca
en la lista de usuarios de un canal cuando se
hace un /who de ese canal. Por lo dems, el
usuario es perfectamente visible mediante
/whois, o para los usuarios que comparten
algn canal con l, por lo que desde luego esta
invisibilidad no es comparable a la del anillo
nico. ;-)
- el modo +w sirve para recibir los
mensajes wallops, que son los mensajes para
administracin de la red que se envan a los
operadores y a los dems interesados. En
muchas redes este modo no tiene ningn efecto.
Como en nuestro ejemplo el servidor no soporta
el cambio de modos en la identificacin, nosotros
pondremos un 0. Vamos a ver entonces cmo
quedara el comando USER para el usuario
PyC:
USER Pic2 0 * : PyC PoC
Veamos campo por campo:
En primer lugar, tenemos el nombre de
usuario: Pic2.
En segundo lugar, la mscara de modos: 0.
En tercer lugar, un campo que no se utiliza,
por lo que podemos poner cualquier cosa: *.
Por ltimo, e incluyendo espacios si queremos,
separado del resto de campos por dos puntos
(:), tenemos el nombre real: PyC PoC.
De dnde salen entonces el resto de campos
del whois? Es decir: el nickname, y la IP, o
DNS. Pues el nickname lo especificamos
precisamente en el primer comando (comando
NICK), y la IP la obtiene directamente el
servidor de la conexin que tenemos establecida
(cualquier conexin TCP/IP es una conexin
punto a punto que requiere de forma
imprescindible que los dos interlocutores
conozcan la direccin IP del otro).
2. 1. 2. 3. Y s i f us emos
operadores?
Si fusemos operadores (IRCops, o como los
quieras llamar) de la red, tendramos que utilizar
un comando adicional para identificarnos como
operadores. Para eso se utiliza el comando
OPER, con la siguiente sintaxis:
OPER nombre password
El primer campo es el nombre del operador, y
el segundo su password de operador.
2.1.2.4 El IDENT
Seguramente habris odo hablar ms de una
vez acerca del famoso IDENT, pero es probable
que no tengis ms que una idea vaga de lo
que es. Probablemente lo habris visto en la
configuracin de vuestro cliente de IRC, y por
eso seguramente habis pensado que forma
parte del protocolo IRC, pero no es as.
El protocolo IDENT es un protocolo totalmente
independiente y, de hecho, no slo se usa en
relacin con IRC. Este protocolo est asignado
al puerto 113 de TCP. En el caso concreto
que nos ocupa no podemos estudiarlo por
Telnet, ya que nosotros seremos los
servidores de ident, y no los clientes.
Algunos servidores de IRC no permiten entrar
a ningn usuario que no tenga un servidor de
ident. Durante un tiempo, el servidor que
utilizamos para el ejemplo restringa sus
conexiones de esta forma, as que espero que
para cuando salga a la luz el artculo no
tengamos este problema. Este problema, al
menos en los casos en que yo lo he visto, suele
ser siempre cuestin de un servidor concreto,
y no de toda la red, por lo que si un servidor
no nos permite entrar sin tener servidor identd
activo, podemos buscar otros servidores de la
misma red hasta encontrar uno que s que nos
lo permita.
El protocolo IDENT viene especificado en el
RFC 1413 (ftp://ftp.rfc-edi tor.org/i n-
notes/rfc1413.txt).
Como resumen, ste protocolo se utiliza para
verificar la identidad del usuario de una
conexin TCP/IP especfica, que viene
identificada por un par de puertos (el puerto
del cliente, y el puerto del servidor).
2.1.3. Ms sobre los modos de
usuar i o (comando MODE)
Tanto si nuestro servidor no permita cambiar
los modos de usuario directamente en la
identificacin, como si queremos fijar otros
modos de usuario aparte del +w y el +i,
podemos utilizar en cualquier momento el
comando MODE.
Este es un resumen de los modos de usuario
que merecen mencin:
- modo +i: ya habl de l en el punto
anterior. :P
- modo +w: dem. :P
- modos +o y +O: indica que el usuario
es un operador de la red, o un operador local,
respectivamente. Si no te has identificado
previamente con OPER, olvdate de este modo.
;-)
- modo +s: este modo, si est
implementado en el servidor, puede ser bastante
interesante. En el servidor del ejemplo
(irc.isdnet.fr), este modo no est implementado.
Podemos probarlo, por ejemplo, en el IRC-
Hispano. Este modo sirve para recibir mensajes
del servidor, referentes a g-lines, kills, etc. Y
qu utilidad puede tener esto? Pues se puede
extraer informacin til si miramos con
detenimiento los mensajes. Permanezcamos
un rato conectados logeando los mensajes del
servidor y veremos, por ejemplo, algo como
esto:
[16:13] -luna.irc-hispano.org- *** Notice
-- sol.irc-hispano.org adding GLINE for
*@usuari o69. l co. es, expi ri ng at
1049296487 (Wed Apr 2 17:14:47 2003):
Proxy abierto o Sub7 server, desinfectese
El servidor nos acaba de decir que en la direccin
usuario69.lco.es est funcionando, o bien un
servidor sub7, o bien un Proxy. Basta con que
ahora hagamos un escaneo de los puertos de
esa IP para encontrar su vulnerabilidad (en
caso de que sea un sub7) o su servicio
disponible (en caso de que sea un Proxy).
Son muy variopintos estos mensajes, pero nos
pueden dar en muchos casos informacin til.
Otra uti l i dad ms rebuscada de esto,
concretamente en el IRC-Hispano, es conseguir
la IP de un usuario mediante un poco de
ingeniera social. Lo cuento slo como ancdota,
ya que tiene poco inters, pero al menos es
curioso. Fue uno de mis muchos experimentos
chorras. El IRC-Hispano utiliza un sistema de
direcciones virtuales que oculta la IP de los
usuarios, por lo que hay que recurrir a diversas
tretas (que no voy a detallar porque se sale
del tema) para conseguir estas IPs. Como
sabris los residentes en el IRC-Hispano, existe
un bot de servicio llamado _antispam que se
encarga de que los nicos que se lucren en el
IRC-Hispano sean sus administradores,
intentando evitar que nadie publique URLs de
pginas Web con supuestos fines publicitarios,
a no ser que paguen previamente. El que
mencione una de estas URLs en un canal en el
que resida _antispam, ser g-lineado
(expulsado de la red) automticamente. As
que lo que hice en esta ocasin, fue conseguir
mediante un mnimo de esfuerzo de ingeniera
social (algo en plan: alguien sabe una Web
donde haya tal o cual?) que el usuario en
cuestin escribiese una de las URLs malditas.
Inmediatamente despus de escribirla, fue g-
lineado por el bot _antispam. Inmediatamente
mir los mensajes del servidor (que poda ver
gracias al modo +s), y vi algo parecido a esto:
[16:58] -luna.irc-hispano.org- *** Notice
-- sol.irc-hispano.org adding GLINE for
*@61-136-23-69.dialup.uni2.es, expiring
at 1048696764 (Wed Mar 26 17:39:24
2003): Publicidad no autorizada. Si desea
contratar servicios publicitarios, consulte
http://www.irc-hispano.org/servicios/
Ese g-line corresponda con el usuario que
acababa de ser expulsado por _antispam, por
l o que ya ten a su IP: 61.136.23.69.
- modo +x: Claro que, si somos unos
maestros de la ingeniera social, podemos
conseguir que el usuario del IRC-Hispano cuya
IP queremos conocer escriba en su cliente de
IRC: /mode usuario -x. Donde usuario es su
nick. Con el modo x inhabilitamos la direccin
virtual de ese usuario, por lo que cuando le
hagamos un whois veremos directamente su
IP, y no una direccin virtual.
Como hemos visto al hablar de este ltimo
modo, un usuario slo puede cambiar sus
propios modos (es de cajn, no?). La forma
de hacer esto mediante el protocolo RAW es
prcticamente igual que desde la aplicacin
cliente. Por ejemplo, para activar el modo +s,
siendo el usuario PyC, haremos:
MODE PyC +s
2.1.4. Comando QUIT (y el /quote)
Ya que estoy siguiendo ms o menos el orden
en el que se explican los comandos en el RFC
(al menos los que considero importantes),
seguir con el comando QUIT. No creis que
es demasiado pronto para cerrar la conexin,
porque quiz os convenga saber que para
probar el resto de comandos podis cerrar ya
vuestra aplicacin de Telnet. Y es que cualquier
cliente de IRC proporciona un mecanismo para
enviar mensajes raw al servidor, y es el comando
/quote. Despus de un /quote, todo lo que
se escriba ser enviado tal cual al servidor, por
lo que deber seguir el protocolo raw de IRC
(que es el protocolo que explico en este artculo).
Empezamos probando el comando QUIT desde
nuestro cliente de Telnet:
QUIT :Hasta pronto!
Con esto cerramos la conexin con el servidor
de IRC, enviando como mensaje de despedida
Hasta pronto!. Este mensaje lo leern los
usuarios de todos los canales en los que ests
cuando cierres.
Si queremos enviar esto mismo desde nuestra
aplicacin cliente de IRC (mIRC, kvirc,
xchat, o el que sea), slo tendremos que
escribir:
/quote QUIT :Hasta pronto!
Y esto ser igual para todos los comandos
explicados en este artculo, incluidos los ya
explicados, excepto el comando USER.
2.2. Comandos de canal es
2.2.1. Ent r ando en canal es
(comando JOIN)
Si estamos acostumbrados a manejar
aplicaciones cliente de IRC, veremos que de
momento hay pocas diferencias entre los tpicos
comandos con la barra / y el protocolo raw de
IRC, y eso sigue siendo igual para el comando
para entrar en un canal:
JOIN #hackxcrack
Es el comando raw para entrar en el canal
#hackxcrack.
Este canal existe en EfNet (que es precisamente
donde estamos haciendo las pruebas), y es
probable que me encontris ah, as que podis
pasaros para vuestras pruebas. ;-)
Como particularidades del comando JOIN,
puedo decir 4 cosas:
En primer lugar, algunos canales necesitan un
password para entrar. Supongamos que el
password del canal #hackxcrack es
pcpasoapaso. En ese caso el comando para
entrar en el canal ser:
JOIN #hackxcrack pcpasoapaso
La segunda particularidad es que puedes entrar
en varios canales utilizando slo un comando
JOIN, separando los canales por comas. Por
ejemplo:
JOIN #hackxcrack,#spanishwarez
Tercera curiosidad, si escribimos:
JOIN 0
Saldremos simultneamente de todos los
canales en los que previamente hayamos hecho
un JOIN.
Por ltimo, si hacis JOIN a un canal que no
ha sido creado por nadie previamente,
automticamente ese canal ser creado y t
sers operador del canal (la famosa @). En el
momento en que abandone el canal el ltimo
usuario, el canal desaparecer (es decir,
simplemente ser borrado de las tablas de
datos que mantienen en tiempo real los
servidores).
2.2.2. Sal i endo de canal es
(comando PART)
Una vez ms, el comando nos ser ya familiar:
PART #hackxcrack
Sirve para salir del canal #hackxcrack. Si
queremos incluir un mensaje de despedida,
podemos hacer:
PART #hackxcrack :me piro!
En el comando PART tambin podemos poner
varios canales, separados por comas.
2.2.3. Modos de canal (comando
MODE de nuevo)
El comando MODE no slo sirve para cambiar
los modos de usuario, sino tambin los modos
de canal. En el RFC 2811 tenis detallados
todos los modos de canal, as que slo os
resumo los ms importantes:
- modo +i (invite only) : slo pueden
entrar en el canal los usuarios que son invitados
explcitamente, mediante el comando INVITE,
o bien aquellos que estn en la lista de
excepcin de invite del canal (estn
permanentemente invitados).
- modo +m (moderated) : slo
pueden hablar en el canal los usuarios que
son operadores (@), y los que tienen voz
(+).
- modo +n (no outside messages) :
slo pueden hablar en el canal los usuarios que
previamente han entrado en el mismo. Aunque
esto os suene raro, si un canal est en modo
n (es decir, no est en modo +n) cualquiera
puede hablar sin necesidad de estar dentro del
canal. Ya veremos ms adelante cmo se hace
esto.
- modo +s (secret) : el canal no
aparecer en la lista de canales de un usuario
cuando se haga whois a este usuario.
- modo +t (topic) : el topic del canal
slo puede ser cambiado por los operadores
(@).
- modo +k (key) : slo se puede entrar
al canal si se conoce el password.
- modo +l (limit) : limita el nmero
mximo de usuarios que pueden entrar en el
canal.
Todos estos modos slo pueden ser cambiados
por los operadores (@) del canal.
Como ej empl o, para poner el canal
#hackxcrack en modo secreto (suponiendo
que seamos operadores del canal) haremos:
MODE #hackxcrack +s
Si luego nos arrepentimos, y queremos quitar
este modo, podemos hacer:
MODE #hackxcrack s
Para limitar el nmero de usuarios a 22:
MODE #hackxcrack +l 22
A partir de este momento, cuando intente entrar
(con JOIN) alguien en el canal, habiendo ya
22 personas, no podr hacerlo hasta que alguien
salga del canal.
Como ltimo ejemplo, para poner el password
pcpasoapaso en el canal #hackxcrack,
haremos:
MODE #hackxcrack +k pcpasoapaso
A partir de este momento, para entrar en el
canal habr que hacerlo con el comando:
JOIN #hackxcrack pcpasoapaso
Para lo cual, por supuesto, habr que conocer
previamente el password pcpasoapaso. ;-)
Tambin se pueden poner simultneamente
varios modos, por ejemplo:
MODE #hackxcrack +ntk pcpasoapaso
Activara simultneamente los modos +n, +t,
y +k con password pcpasoapaso.
2.2.4. Modos de usuario para un
canal (comando MODE una vez
ms)
No termina aqu la utilidad del comando MODE.
Pero no pensis que ste es el comando ms
polifactico, ya que el comando PRIVMSG,
que veremos ms adelante, le supera con
creces. :-)
Los modos de usuario para un canal son aquellos
que aplican unas normas o unos privilegios
para un determinado usuario slo dentro de
un determinado canal. Todos ellos pueden ser
fijados slo por un operador del canal.
Estos modos vienen tambin especificados en
el RFC 2811, as que resumo aqu los ms
importantes:
- modo +o (operator) : convierte a
un usuario en operador del canal (la famosa
@).
- modo +v (voice) : da voz a un
usuari o en un canal (el famoso +).
- modo +b (ban) : sirve para crear
mscaras que denieguen el acceso al canal
a un usuario, o bien a un grupo de usuarios,
segn cmo se forme la mscara. Esto lo
explicar ms adelante.
- modo +e (exception) : sirve para
permitir acceso a un usuario concreto que
est dentro de las mscaras de denegacin.
Ya lo veremos luego, que suena un poco lioso.
:-)
- modo +I (invitation mask) :
permite crear mscaras para que determinados
usuarios puedan entrar en un canal en modo
invite only (+i) sin necesidad de que nadie
les invite explcitamente.
El ejemplo ms sencillo es el de los modos +o
y +v. Por ejemplo:
MODE #hackxcrack +o PyC
Da @ al usuario PyC.
El tema de las mscaras (los otros 3 modos)
es ya ms complejo. Vamos a ir viendo distintos
tipos de mscaras mediante ejemplos con los
distintos modos.
En primer lugar, imaginemos que queremos
que en el canal #espaa slo entre gente desde
una IP espaola. Para ello podemos hacer:
M O D E # e s p a a + i
MODE #espaa +I *!*@*.es
El primer comando pondr el canal en modo
invite only, por lo que slo podrn entrar los
usuarios que sean invitados explcitamente, o
bien los que estn en la lista de excepcin de
invitaciones. Esta lista es la que se administra
con el modo +I, y eso es precisamente lo que
hacemos con el segundo comando, en el que
especificamos que todos aquellos usuarios, se
llamen como se llamen, que vengan de un
dominio .es, puedan entrar al canal sin
necesidad de ser invitados explcitamente.
Otra forma de hacer esto mismo, sera la
siguiente:
MODE #hackxcrack +b *!*@*
MODE #hackxcrack +e *!*@*. es
Con el primer comando, denegamos el acceso
a todos los usuarios. Con el segundo,
hacemos una excepcin a esa lista de
denegaciones de acceso, permitiendo que s
que puedan entrar los que vengan desde un
dominio .es.
Ahora vamos a ver cmo denegar el acceso al
usuario cuyo nickname sea PyC:
MODE #hackxcrack +b PyC! *@*
Si PyC tiene 2 dedos de frente, bastar con
que se cambie el nick para poder entrar (con
el comando NICK).
A veces hay canales en los que, por el motivo
que sea, no quieren que los usuarios utilicen
determinados scripts. Los scripts suelen poner
por defecto un determinado nombre de
usuario a la hora de identificarse, por lo que
es fcil identificarlos siempre y cuando el usuario
no haya modificado este dato a posteriori.
Supongamos, por ejemplo, que queremos
banear (denegar el acceso) a todos los
usuarios que utilicen el script Ircap 7.1. Si
vemos el whois de un usuario de Ircap 7.1,
ser parecido a ste:
PyC is ~ircap71@201.Red-22-15-
1 5 . p o o l e s . r i ma - t d e . n e t *
http://www.ircap.net !
Como vemos, el campo nombre de usuario
es ~ircap71, que es el que pone por defecto
este script. Por tanto, podemos hacer:
MODE #hackxcrack +b *!*ircap71@*
Para denegar el acceso a todos los usuarios
que tengan ircap71 en el nombre de usuario.
Por ltimo, podemos banear una IP especfica
de la siguiente forma:
MODE #hackxcrack +b *!*@201.Red-22-
15-15.pooles.rima-tde.net
Est claro, no? ;-)
2.2.5. El Topic del canal (comando
TOPIC)
El topic es, por as decirlo, un texto de
presentacin de un canal. Cuando entras
a un canal, lo primero que recibes es el texto
del topic.
Las utilidades del topic son muchas: dar una
serie de normas bsicas para los usuarios del
canal (estos topics suelen permanecer fijos),
dar alguna URL interesante de actualidad
(estos topics suelen cambiar de un da para
otro), o simplemente escribir la chorrada de
turno (he llegado a ver conversaciones enteras
entre 2 o ms operadores cambiando el topic
en lugar de escribiendo en el canal).
La primera utilidad del comando TOPIC es
simplemente ver el texto actual del topic:
TOPIC #hackxcrack
Nos mostrar el topic actual del canal
#hackxcrack.
Para modificar el topic, simplemente aadiremos
un campo ms:
TOPIC #hackxcrack :Bienvenidos al canal
de PC Paso a Paso.
El topic slo puede ser modificado por los
operadores del canal, a no ser que el canal
est en modo t (es decir, que no tenga activo
el modo +t).
2.2.6. Buscando canales (comando
LIST)
Aqu la cosa se pone fea. :-(
Habis usado alguna vez la funcin LIST
CHANNELS de mIRC para buscar canales que
contengan una determinada cadena de texto?
Men en mIRC para buscar la cadena "mp3" en la Men en mIRC para buscar la cadena "mp3" en la
lista de canales de EfNet. lista de canales de EfNet.
Lo que hace esta funcin de mIRC en realidad
es pedir al servidor la lista de todos los canales,
y luego el propio mIRC hace la bsqueda de
la cadena de texto dentro de la lista que le ha
proporcionado el servidor. Por tanto, no hay
forma de que podis hacer una bsqueda
selectiva lanzando comandos raw desde
Telnet. :-(
Para obtener la lista completa de canales,
con sus topics, y el nmero de usuarios, basta
con que ejecutis:
LIST
2.2.7. Comando INVITE
Por seguir con el orden del RFC, tenemos un
comando muy simple, que es para invitar a
un usuario a un canal, normalmente porque
el canal se encuentra en modo invite only
(+i):
INVITE PyC #hackxcrack
Con esto invitamos al usuario PyC al canal
#hackxcrack.
2.2.8. El comando prohi bi do
(comando KICK)
Normalmente, si eres una persona madura e
inteligente, no necesitars utilizar este comando
salvo en situaciones muy concretas. Este
comando permite a los operadores expulsar
a un usuario de un canal. Por ejemplo:
KICK #hackxcrack PyC :nos estas
floodeando
Expulsara al usuario PyC del canal #hackxcrack,
exponiendo el motivo: nos estas floodeando.
Si queremos expulsar permanentemente
a ese usuario del canal, tendremos que
banearle primero, es decir, aplicar una
mscara para denegar su acceso al canal:
MODE #hackxcrack +b PyC!*@*
KICK #hackxcrack PyC :vete y no vuelvas
Claro que, ya he dicho que este ban es poco
efectivo, ya que basta con que el usuario se
cambie de nick para poder entrar. Segn cada
caso ser ms efectivo un tipo de ban u otro.
Por ejemplo, para usuarios con IP dinmica
habra que banear un subdominio, siempre
y cuando no haya ms usuarios legtimos en
ese subdominio (en ese caso tendramos que
utilizar adems una mascara de excepcin con
el modo +e para los usuarios legtimos). Otra
solucin para la IP dinmica, es banear segn
el campo nombre de usuario, pero ese
campo es fcilmente modificable, por lo que
si el to es un poco listo podra volver a entrar
sin problemas.
En el caso de que el usuario tenga IP fija, no
hay ms misterio, baneas directamente la IP
y se acab (a no ser que utilice un bouncer,
pero eso ya es otra historia).
2.3. Al fin vamos a hablar (el
verstil PRIVMSG)
Tanto rollo y todava no sabemos como decir
hola en un canal! Aqu es cuando vemos al
fin una diferencia importante entre los comandos
famosos de la barra /, y el protocolo raw.
Pensad en todas las cosas de las que todava
no he hablado: escribir en un canal, escribir en
una query (mensajes privados entre 2 usuarios),
lanzar comandos CTCP, lanzar comandos DCC...
Pues todas ellas se hacen con un nico
comando! Y ste comando es el mgico
PRIVMSG. Vamos a ver todo esto con detalle.
2.3.1. Mensajes privados (queries)
Para hablar en privado con otro usuario, basta
con que hagamos:
PRIVMSG PyC :hola!
El usuario PyC recibir un mensaje privado
diciendo hola!. Quiz os preguntaris: cmo
que un mensaje privado? y que hay del query
de toda la vida?
Y es que supongo que muchos de vosotros
tendris la equivocada idea de que una query
es una especie de conexin establecida entre
2 usuarios, pero eso no es as. Esa es la ilusin
que os da vuestro cliente de IRC al abrir una
ventana especfica para la query, pero en
realidad las queries no son ms que sucesiones
de mensajes entre 2 usuarios, sin ningn tipo
de establ eci mi ento de conexi n.
2.3.2. Escribiendo en el canal
Para escribir a todos los usuarios de un canal,
el formato es el mismo:
PRIVMSG #hackxcrack :hola a todos!
Con esto escribimos en el canal #hackxcrack
la frase hola a todos!.
Ahora que la cosa es un poco diferente a lo
que estis acostumbrados a hacer con el cliente
de IRC, es buen momento para probar el
comando /quote para hacer esto mismo,
desde vuestra aplicacin cliente de IRC:
/quote privmsg #hackxcrack :hola a
todos!
2.3.3. Escribiendo en un canal en
el que no estamos
Escribir en un canal en el que no estemos (no
hayamos hecho previamente un JOIN) es igual
de sencillo, salvo que tiene un prerequisito
importante, y es que el canal tiene que estar
en modo n, es decir, que no est en modo
+n.
Si tenemos la suerte de encontrar un canal en
modo n podemos hacer una chorrada para
pasar el rato. En muchos clientes de IRC, la
letra i mayuscula se ve prcticamente igual
que la letra ele minscula. Si, por ejemplo,
tenemos en el canal #lameretes un usuario
cuyo nick sea zer0c00l (nick de lamer de
primera), podemos ponernos nosotros un nick
bastante parecido, que sera zer0c00I. Este
nick, cambiando la ele por una i mayscula,
se ver bastante parecido en un cliente de
IRC, por lo que ser dificil notar la diferencia
a simple vista, a no ser que estn los 2 nicks
uno al lado del otro. Una vez puesto ese nick,
sin entrar en el canal #lameretes, escribiremos:
PRIVMSG #lameretes :pero mira que soy
lamer
La gente del canal #lameretes, a no ser que
sean un poco avispados, creer que es zer0c00l
quien est diciendo eso, ya que no vern a
ningn otro usuario con un nick similar en el
canal. Por otra parte, zer0c00l probablemente
se volver loco creyendo que le han hackeado,
posedo, o algo as. Por supuesto, esto es una
tremenda gilipollez, y cualquiera con 2 dedos
de frente lo descubrira (sobre todo porque
cualquiera con 2 dedos de frente normalmente
tendra el canal en modo +n), pero siempre
est bien conocer estas chorradas, no? :-)
2.3.4. El protocolo CTCP
El comando PRIVMSG es tan verstil que
encapsula l solito todo un protocolo, que es
el CTCP, o Client To Client Protocol.
No voy a entrar en muchos detalles sobre el
protocolo CTCP, as que slo hablar de los
comandos ms bsicos.
2.3.4.1. CTCP PING
El comando ms tpico de CTCP es el PING.
Su utilidad es doble: en primer lugar, saber si
un usuario aparentemente conectado realmente
lo est, ya que muchas veces cuando un usuario
pierde la conexin con el servidor, durante un
tiempo su nick sigue apareciendo como si
siguiese conectado (os suena el famoso ping
timeout?), y en segundo lugar mide el lag
que tienes con respecto a un usuario.
Qu es el lag? Es simplemente el retardo
que hay entre 2 usuarios, es decir, el tiempo
que transcurre entre que uno escribe algo y el
otro lo lee. El lag vara segn la carga del
servidor o incluso segn el ancho de banda
disponible de los usuarios. La peor situacin es
cuando hay varios usuarios hablando, cada uno
con un lag diferente pero muy alto, por lo que
se forman conversaciones sin sentido en el que
cada uno da una respuesta que llega a los
dems en un momento diferente.
Yo personalmente utilizo el PING de vez en
cuando para medir mi propio lag. Lo que hago
es lanzarme un PING a mi mismo. En el mejor
de los casos debera haber un lag de 0 segundos,
pero muchas veces este lag puede ser de varios
segundos, y con eso ya sabes que, como
mnimo, todo lo que leas o escribas tendr un
retraso de tantos segundos.
Para cualquier comando CTCP tenemos que
utilizar el ascii 1, que aqu representaremos
como: . Como espero que ya sepis, podeis
poner escribir cualquier ascii del cual conozcis
su valor numrico pulsando la tecla Alt y, sin
soltarla, escribiendo su valor en el teclado
numrico. Por tanto, para escribir el ascii 1,
pulsaremos la Alt+1. Si la aplicacin que ests
utilizando no te permite escribir este ascii,
tendrs que escribirlo en alguna otra aplicacin
y copiar el ascii desde ah mediante el clsico
copy/paste.
Volviendo al tema, en qu consiste el ping?
Pues simplemente es un mensaje corto que
contiene tan slo un nmero aleatorio. En
cuanto el receptor lo reciba, tiene que enviar
una respuesta que contenga exactamente el
mismo nmero. Nuestra aplicacin cronometrar
el tiempo transcurrido desde que se envi el
nmero, hasta que ste lleg de vuelta. Para
enviar un ping al usuario PyC esto es lo que
tenemos que ejecutar:
PRIVMSG PyC :PING 1048765767
Para comprender la respuesta que nos
devuelven al PING hay que hablar de un nuevo
comando, que es el NOTICE.
Un NOTICE tiene exactamente la misma
funcin que un PRIVMSG, pero con una
salvedad, y es que los NOTICE son mensajes
que no deben tener respuesta. Es decir, cada
vez que una aplicacin de IRC recibe un
NOTICE de cualquier tipo, simplemente lo
leer e interpretar como deba, pero nunca
dando ningn tipo de respuesta. Por tanto, la
utilidad del NOTICE es el enviar mensajes en
los que haya riesgo de entrar en bucles infinitos
de respuestas.
En nuestro caso, el usuario al que hemos hecho
el PING nos responder con el mismo mensaje,
pero con la salvedad de que lo har con
NOTICE en lugar de con PRIVMSG. Si nos
respondiese con PRIVMSG, nuestro cliente
de IRC interpretara que es a l a quien estn
lanzando un PING, por lo que tendra que
responder al mismo, y as se formara un bucle
infinito de pings. Por tanto, la respuesta de
PyC a nuestro PING, suponiendo que nuestro
nick es fulanin, sera algo como esto:
P y C ! ~ P i c @ 8 0 - 2 5 - 3 2 -
27.uc.nombres.ttd.es NOTICE Fulanin
:PING 1048765767
Como vemos, responde con el mismo nmero,
para que podamos confirmar que esta respuesta
se corresponde con la peticin que habamos
lanzado.
ATENCION!! Sobre el ping timeout:
Antes de continuar, hago aqu un inciso muy
importante, aprovechando que he mencionado
antes el ping timeout. Los que sepais bien
en qu consi ste este ti po de ca da,
probablemente habris pensado: este to no
tiene ni idea, el ping timeout no tiene nada
que ver con l os pi ngs de ct cp.
El motivo por el que he mencionado el ping
timeout es porque mediante ctcp ping puedes
detectar si alguien est cado, pero en realidad
con lo que tiene que ver esta cada no es con
los pings de ctcp, si no con los pings del
servidor.
Cuando superas un cierto tiempo de inactividad,
el servidor ha de asegurarse de que sigues ah,
para lo cual te lanza un ping bastante parecido
a los de CTCP.
Si no respondes a este ping, el servidor cerrar
la conexin, asumiendo que se ha quedado
colgada. En esto consiste precisamente el ping
timeout.
Cuando conectemos por telnet al servidor de
IRC, si no hacemos nada durante un tiempo,
nos aparecer un mensaje de PING de servidor,
preguntndonos si seguimos ah. Este mensaje
puede contener un nmero, como en los CTCP
PING, o bien cualquier otro texto que tenemos
que enviar de vuelta. Por ejemplo, en el caso
del servidor que estamos utilizando de ejemplo,
ste ser el PING que nos l anzar:
PING :irc.isdnet.fr
En cuanto veamos esto, tenemos que responder
l o antes posi bl e con este comando:
PONG :irc.isdnet.fr
Algunos servidores lanzan el primer PING nada
ms identificarnos, por lo que hemos de estar
atentos al mensaje de bienvenida a la hora
de conectar con un servidor, para ver si ste
incluye un PING al que tenemos que responder
antes de nada.
2.3.4.2. CTCP VERSION
Este mensaje CTCP nos puede dar informacin
bastante til, pero hemos de saber siempre
que la respuesta puede haber sido manipulada
por el usuario, por lo que podra estar dndonos
informacin falsa.
El objetivo de este mensaje es preguntar a un
usuario qu software est utilizando como
aplicacin cliente de IRC.
El formato de la consulta es muy sencillo:
PRIVMSG PyC :VERSION
Ante esto, la aplicacin cliente del usuario PyC
nos responder de manera automtica con
una respuesta que identifica el software y el
nmero de versin, as como si tiene algn
script funcionando encima, etc.
Respuestas tpicas son las siguientes:
mIRC: mIRC v6.01 Khaled Mardam-Bey
Xchat para windows : xchat 2.0.0 Windows
5.0 [i686/449MHz]
mIRC con IRCap 7.1 : mIRC v6.03 Khaled
Mardam-Bey
I Rcap 7. 31
http://www.ircap.com
Kvirc 3 : KVIrc 3.0.0-beta2 "T-Rex" :
2003.01.04-12554 : build Sat Jan 4 20:53:34
UTC 2003 : i686-cefikloprstAGT
Como vemos, podemos extraer informacin
til sobre el sistema operativo del usuario, as
como sobre el software que utiliza (que podra
tener bugs conocidos, en caso de que
quisisemos hacer experimentos de seguridad).
He de insistir en que estos mensajes de
respuesta al VERSION pueden ser modificados
por el usuario para que ponga cualquier cosa.
2.3.4.3. CTCP TIME
Por ltimo, vamos a ver otro CTCP tpico, que
sirve para saber qu hora tiene el PC de un
usuario. Este comando es til para conocer el
pas en el que se encuentra el usuario (por la
diferencia horaria), as como para sincronizar
alguna cita. Aunque suene a coa, yo uso el
TIME a veces para sincronizarme con algn
amigo para quedar a alguna hora.
El formato del mensaje es muy simple:
PRIVMSG PyC :TIME
La respuesta a este comando ser un NOTICE
con ste formato:
P y C ! ~ P i c @ 2 1 5 - 2 0 5 - 1 9 -
7.uc.nombres.ttd.es NOTICE fulanin :
TIME Fri Mar 28 13:29:16 2003
2.3.5. El protocolo DCC
Tambin el DCC funciona mediante el comando
PRIVMSG! Os gustara saber cmo se pueden
interceptar envos de archivos, o chats
privados, por DCC? Os gustara saber
cmo spoofear vuestra IP en un DCC?
Esto, y ms, es lo que explicar en el prximo
artculo. ;-)
2.4. Comandos de consulta al
servidor
Vamos a ver ahora un grupo de comandos que
se utilizan para pedir informacin variada al
servidor.
2.4.1. Mensaje del da (comando
MOTD)
Cuando entramos en un server, nos da un
mensaje de bienvenida, tambin conocido como
MOTD (Message Of The Day), que nos da
informacin til sobre el servidor. Podemos
pedir al servidor en cualquier momento su
MOTD, o incluso el de cualquier otro servidor
de la misma red. Algunos son curiosos, como
por ejemplo:
MOTD efnet.vuurwerk.nl
A ver a qu os recuerda ese dibujito ascii. ;-)
2.4.2. Carga del servidor (comando
LUSERS)
Al principio del artculo os di algunas cifras
concretas sobre los usuarios que haba
conectados en EfNet en ese instante, as como
sobre el nmero de canales, y el nmero de
usuarios en un servidor concreto. Todas esas
ci f ras podemos ver l as ej ecut ando:
LUSERS
2.4.3. Versin del software en el
servidor (comando VERSION)
No slo podemos ver el software que utilizan
los clientes, si no tambin el software del
servidor, as como otra informacin til,
mediante el comando:
VERSION
Por ejemplo, en el servidor irc.isdnet.fr, sta
ser la respuesta:
2. 8/hybr i d- 6. 3. 1( 20020418_1) .
i rc. i sdnet. fr AGHi KMpYZ TS5owc
-
WAL L CHOPS PRE F I X=( o v ) @+
CHANTYPES=#& MAXCHANNELS=20
M A X B A N S = 2 5 N I C K L E N = 9
T OP I C L E N=1 2 0 KI C KL E N=9 0
N E T W O R K = E F n e t
CHANMODES=b,k,l ,i mnpst KNOCK
MODES=4 are supported by this server
De aqu extraemos informacin interesante
sobre la configuracin del servidor. Por
ej empl o, nos di ce que sl o soporta
canales de tipo # (globales) y & (locales)
(existen tambin los canales ! y +, pero
no he considerado que merezca la pena
hablar de ellos), el nmero mximo de
canales por usuario es 20, el nmero
mximo de entradas en la lista de bans
(denegacin de acceso a un canal) es
de 25, la longitud mxima de un nickname
es de 9 caracteres, la longitud mxima
de un topic es de 120 caracteres, etc.
2.4.4. Estadsticas del servidor
(comando STATS)
Muchos servidores desactivan alguna de estas
opciones, al no querer que los usuarios puedan
extraer demasiada informacin que podra ser
utilizada para algn tipo de ataque. Son varias
las opciones, pero mostrar slo las que
funcionan en el servidor que estamos utilizando
de ejemplo.
En primer lugar, si hacemos:
STATS u
Nos muestra el uptime del servidor, es decir,
cunto tiempo lleva funcionando desde la ltima
vez que se reinici.
En segundo lugar, est la estadstica de uso
de comandos, pero antes de que lo probis
os tengo que advertir. Si ejecutais este comando
en este servidor os har un k-line temporal,
es decir, os expulsar de toda la red durante
24 horas. Eso s, os lo har despus de daros
el resultado, lo cual veo bastante absurdo. Si
no quieren que utilices ese comando, no es
ms razonable que no lo implementen, en lugar
de ejecutarlo para despus expulsarte? Para
evitaros el k-line os pasteo aqu el resultado
que me dio a mi la ltima vez que ejecut este
comando. El comando a ejecutar sera:
STATS m
Y sta la respuesta del servidor:
ADMIN 161 1715
AWAY 1324744 41605335
CAPAB 8 160
CLOSE 6 20
CONNECT 491 9057
DIE 14 138
DLINE 5 119
ERROR 5425 156096
GLINE 1031 100586
HASH 4 8
HELP 124 442
HTM 54 7
INFO 356 4588
INVITE 624304 11705238
ISON 48403584 2260375326
JOIN 12335190 135226756
KICK 2169543 91710944
KILL 26745 2459300
KLINE 1210 73957
KNOCK 858 8501
LINKS 652 3195
LIST 75991 305704
LOCOPS 15 353
LTRACE 1 12
LUSERS 298179 7191563
LWALLOPS 0 0
MODE 72304763 1431760954
MOTD 467 3691
NAMES 127934 1381606
NICK 72403821 2147611586
NOTICE 36420416 2708147443
OPER 387 5729
OPERWALL 14733 536306
PART 11601855 106863938
PASS 1041568 7289166
PING 40404679 442423522
PONG 24647891 346314785
PRIVMSG 238041898 1376495144
QUIT 19063494 472024380
REHASH 15 89
RESTART 2 14
SERVER 4472 154251
SET 9 127
SJOI N 58209061 2226248553
SQUIT 4073 114713
STATS 819 7103
SVINFO 7 93
TESTLINE 6 94
TIME 86997 759067
TOPIC 1140668 80984008
TRACE 10218 59279
UNDLINE 0 0
UNGLINE 0 0
UNKLINE 26 757
USER 37767462 867701368
USERHOST 4102785 63264793
USERS 21238 327
VERSION 7628 55489
WALLOPS 176 8224
WHO 4503972 40190982
WHOIS 2268763 17289803
WHOWAS 6383 48645
Esos nmeros nos muestran el nmero de veces
que ha sido utilizado cada comando. La utilidad
que podais sacar de esta informacin ya
depende de vuestra imaginacin. Por ejemplo,
el uso ms obvio es conocer todos los comandos
que tiene implementados el servidor. Los
comandos que no conozcais los podis buscar
en el RFC 2812 y el RFC 2813, aunque
algunos ni siquiera estarn contemplados en
los RFC. Adems, muchos de estos comandos
slo los pueden ejecutar los operadores de la
red. Por si tenis curiosidad, os pasteo a
continuacin el k-line que me hizo el servidor
inmediatamente despus de ejecutar el
comando:
You are banned from this server-
Temporary K-line 1440 min. - stop stating
(2003/03/14 18.37)
-
[ 1 8 : 3 5 ] C l o s i n g L i n k :
PyC[PyC@213.206.14.9] (Connection
closed)
2.4.5. Compr obando l a r ed
(comando LINKS)
Con el comando LINKS podemos ver todos los
servidores a los que est conectado el nuestro
(o cualquier otro de la red), lo cual nos sirve
para detectar posibles splits (desconexin de
algunos servidores a la red, lo que causa la
aparicin de dos o ms redes fantasma).
S i m p l e m e n t e e j e c u t a m o s :
LINKS
Y nos dar la lista de servidores. Mediante este
comando podemos estudiar adems la topologa
de la red.
2.4.6. Poniendo el reloj en hora
(comando TIME)
Alguna vez habis utilizado el teletexto, o la
radio para saber la hora y aseguraros de que
vuestro reloj no se ha quedado sin pilas? Pues
se acab el utilizar medios anticuados, a partir
de ahora vais a poner en hora los relojes con
vuestro servidor de IRC :P
TIME
Os dar la fecha y hora que tiene el servidor.
2.4.7. Traceo de servi dores
(comando TRACE)
Con este comando podis ver la ruta que hay
entre vuestro servidor y cualquier otro de la
misma red. Si, por ejemplo, ejecutamos:
TRACE efnet.demo.co.uk
Nos mostrar la ruta que hay que atravesar
para comunicar tu servidor con este otro por
el camino ms corto.
Nos puede servir tambin, por ejemplo, para
buscar servidores de un determinado pas. Por
ejemplo, si hacemos:
TRACE *.es
Podremos comprobar que no hay ningn
servidor espaol de EfNet. :-(
2.4.8. Informaci n sobre l os
admi ni stradores (comando
ADMIN)
Si queremos, por ejemplo, saber cmo contactar
con l os admi ni stradores del servi dor
irc.homelien.no, slo tenemos que ejecutar:
ADMIN irc.homelien.no
Y nos dar la informacin de contacto.
2.4.9. Un poco de hi st or i a
(comando INFO)
Si queremos saber algo de la historia de IRC,
o del servidor, podemos ejecutar:
INFO
Para que nos cuenten lo que les de la gana.
:-P
2.5. Comandos de consulta sobre
los usuarios
Este ltimo grupo de comandos son de uso
cotidiano, no como los ltimos que hemos visto.
Son fundamentales, as que estad bien atentos.
;-)
2.5.1. Comando WHO
Este comando tiene muchas utilidades. Vamos
a ver las ms importantes, pero hay que tener
en cuenta que los usuarios en modo invisible
(modo de usuario +i) no aparecen en los listados
generados por una consul t a WHO.
2.5.1.1. Listado de usuarios
En primer lugar, podemos utilizar WHO para
listar todos los usuarios de un determinado
dominio:
WHO *.es
Nos mostrar todos los usuarios conectados a
la red que vengan de un dominio .es, siempre
y cuando no estn en modo invisible.
2.5.1.2. Listado de usuarios en
canales
Para ver los usuarios (no invisibles) que hay
en el canal #hackxcrack, haremos:
WHO #hackxcrack
2.5.1.3. Bsqueda de usuarios por
IP
Este punto si que es realmente interesante. Si
conocemos la IP de alguien, podemos saber si
est conectado a nuestra red de IRC, y tambin
con qu nickname.
Supongamos, por ejemplo, que la IP es:
217.125.24.17 (al igual que todas las IPs
utilizadas a lo largo del artculo, esta IP ha sido
escogida de forma totalmente aleatoria). En
primer lugar, tenemos que conocer el DNS
asignado a esa IP, para lo cual, desde nuestra
aplicacin cliente de IRC (no desde telnet!)
podemos ej ec ut ar l o s i gui ent e:
/dns 217.125.24.17
Nos responder algo como esto:
[17:04] *** Looking up 217.125.24.17
-
[17:04] *** Resolved 217.125.24.17 to
217-125-24-17. uc. nombres. ttd. es
Ya sabemos cual es el DNS asociado a esa IP.
Si ahora hacemos la siguiente consulta:
WHO 217-125-24-17.uc.nombres.ttd.es*
Nos devolver el (o los) nickname de esa IP,
si es que ese usuario est conectado a la misma
red de IRC que nosotros. Si el usuario no est
conectado, simplemente nos dir algo como
esto:
217-125-24-17.uc.nombres.ttd.es* End
of /WHO list.
2.5.2. Comando WHOIS
Este comando es uno de los que ms utilizo
constntemente. Nos da mucha informacin
ti l sobre un usuari o. Si hacemos:
WHOIS PyC
Nos puede devolver una respuesta como sta:
PyC i s ~Pi c2@138. Red- 25- 12-
191.pooles.rima-tde.net * PyC PoC
PyC on #LCo @#spani shwarez
@#hackxcrack +#espaa
PyC using efnet.demon.co.uk <pils> how
do you think i got oline?
PyC End of /WHOIS list.
La primera lnea del whois nos indica su
nombre de usuario (~Pic2), su IP o DNS
(138.Red-25-12-191.pooles.rima-tde.net), y su
nombre real (PyC PoC).
Despus de eso, nos muestra la lista de
canales en los que est el usuario, siempre
y cuando el canal no sea secreto (modo +s)
o privado (modo +p). Adems, nos dice el
tipo de usuario que es en cada canal. En este
ejemplo concreto, el usuario PyC est como
usuario llano en el canal #LCo, como usuario
con voz en el canal #espaa, y como
operador en los canales #spanishwarez y
#hackxcrack.
Por ltimo, nos dice el servidor a travs del
cual est conectado el usuario. En este caso el
servidor sera efnet.demon.co.uk. La frase que
pone despues es un pequeo quote que aade
el servidor, as que no tiene el ms mnimo
inters.
Si el usuario estuviese en el mismo servidor
que nosotros, nos habra dado una informacin
adicional, como sta:
PyC has been idle 2secs, signed on Fri
Mar 28 16:56:59
Esta informacin nos dice el idle, es decir, el
tiempo que lleva este usuario sin escribir nada,
y la fecha y hora en la que conect con el
servidor.
Si queremos saber esto mismo y no estamos
en el mismo servidor que este usuario, bastar
con que hagamos la consulta poniendo su nick
2 veces:
WHOIS PyC PyC
Intuitivo, eh? ;-)
2.5.3. Comando WHOWAS
Este comando nos dice cundo estuvo conectado
un determinado nick. Por ejemplo, para saber
cundo estuvo conectado el usuario PyC:
WHOWAS PyC
Nos responder algo como esto:
PyC was PyC@203.47.23.8 * PoC
PyC using efnet.demon.co.uk Fri Mar 28
17:33:03 2003
End of WHOWAS
3. PARA TERMINAR
Buff... ha sido una tarea ms pesada de lo que
esperaba al principio, pero ya estn resumidas
las bases del protocolo IRC. :-)
En este artculo he seguido el RFC de forma
ms estricta que en los anteriores. Si habis
seguido los 3 artculos publicados hasta ahora,
habris comprobado que el estilo de redaccin
ha cambiado en los 3, y es debido a que estoy
experimentando para ver vuestra reaccin ante
las distintas formas de escribir, para ver cual
os gusta ms. :-)
En primer lugar, he de aclarar que no he incluido
la mayora de las respuestas del servidor a
cada comando, ya que si no el artculo se
extendera hasta el infinito. He considerado
que la mayora de las respuestas son
suficientemente intuitivas. Si lo queris ver
desde otro punto de vista, os dejo la
interpretacin de las respuestas como ejercicio.
:-P
Se me ocurren algunas curiosidades que contar
para terminar.
En primer lugar, os resumo la lista de tareas
que puede realizar el operador de un
canal (los de la famosa @):
- INVITE invitar a un usuario a un
canal en modo invite only (modo +i).
- KICK expulsar a un usuario del
canal.
- MODE cambiar los modos del canal,
y los modos de otros usuarios en el canal.
- TOPIC cambiar el topic del canal si
el canal est en modo +t. Si no, cualquiera
puede hacerlo, y no solo un operador.
- PRIVMSG Por supuesto, un
operador siempre puede hablar en el canal,
aunque ste se encuentre en modo moderado
(modo +m).
Otra cosa que he de mencionar, es que no he
hablado de la mitad del protocolo IRC, que es
el que se utiliza entre los distintos servidores
de una red, y no entre un cliente y un servidor.
He dado por hecho que, si sois administradores
de una red de IRC, tendris mejores fuentes
de consulta que esta revista y, en caso contrario,
no os interesar lo ms mnimo conocer este
protocolo. De todas formas, lo tenis
completamente detallado en el RFC 2813.
Por ltimo, una pequea curiosidad, y es que
el IRC no es case-sensitive, es decir, que no
distingue entre maysculas y minsculas, y
esto produce algunas situaciones curiosas. Por
ejemplo, por raro que parezca, en IRC se
considera que los caracteres { } | ^ son las
minsculas de los caracteres [ ] \ ~
respectivamente. As que, por ejemplo, el nick
^{Zer0C00|}^ es equi val ente al ni ck
~[zer0c00\]~. Si no sois asiduos a las redes
de IRC, os parecern nicks muy raros, pero os
aseguro que mucha gente utiliza nicks con ese
tipo de smbolos. :-)
Autor: PyC (LCo)
Agradecimientos: Scherzo (LCo),
PoLLo, polhux, skitter, Tuxed,
NetLander, _Stealth_, KaR]V[aN,
y los que se me olviden.
PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL
HAY MUCHOS MAS EN
http://pclog.buscalogos.com/
PERSONALIZA TU MOVIL
PC P
PC P
ASO
ASO
A
A
P
P
ASO
ASO
Este nmero 9 de PC PASO A PASO (Los Cuadernos de Hack x Crack) contiene gran cantidad de palabras y conceptos
que seguro ha pillado desprevenido a ms de uno. Si eres un lector habitual ya sabes que solemos explicar precisamente
todos esos conceptos a lo largo de nuestros artculos, pero en este caso (y nos referimos en especial al artculo del NMAP)
hemos preferido dar una visin general a partir de la cual profundizaremos en prximos nmeros.
Si es la primera vez que nos lees y no posees un cierto nivel en esto de la informtica, seguro que te has quedado fuera
de lugar y sin saber muy bien qu tipo de revista has comprado, por ejemplo, hablamos de establecer conexiones por
TELNET sin ms explicaciones y nos quedamos tan anchos. Bien, esto no es as, en los nmeros anteriores hemos
explicado hasta el hartazgo desde cmo se abre una Ventana DOS (Ventana de Comandos) hasta cmo se establece una
conexin por Telnet y mil cosas ms de nivel bsico. Ests leyendo un nmero que utiliza los conocimientos ya adquiridos
en anteriores entregas, por ejemplo el curso de Visual Basic ya est por la entrega 3, igual que la SERIE RAW.
Si quieres ver nuestra lnea editorial tienes en nuestra Web el nmero 1 de Hack x Crack a tu disposicin en formato
PDF, descrgalo y lelo tranquilamente, es completamente gratis y podrs ver que hemos empezado DESDE CERO!!!
Posdata para los miembros del foro: Si algn miembro del foro cree que esta nota la hemos puesto para rellenar, solo
tiene que mirar la revista para darse cuenta de que hemos empezado a reducir el tamao de letra porque hemos tenido
verdaderos problemas de espacio, no digamos ya los concursos de Linux y logos (que son miniaturas en comparacin
con anteriores nmeros). Esta nota es muy importante porque tenemos miedo de estar tomando una lnea demasiado
tcnica y todos sabemos que eso es peligroso, por ello necesitbamos advertir a los nuevos lectores que si no comprenden
este nmero de PC PASO A PASO es precisamente porque son nuevos lectores y no han seguido la revista desde su
inicio.
Parece mentira pero en tan solo 9 nmeros nos hemos introducido de lleno en un mundo para muchos desconocido e
intentamos en cada nuevo nmero editado llegar un poco ms lejos. Ahora sera el momento ideal para decirte que si
te falta algn nmero de la revista puedes pedirlo desde nuestra Web e intentar venderte la moto, pero no es ninguna
moto, es algo que debers hacer si eres un nuevo lector y quieres seguir avanzando. Para nosotros la venta de nmeros
atrasados es ms una cruz que un beneficio, te lo aseguro, pero es un servicio que estamos dando porque es
IMPRESCINDIBLE para los nuevos lectores. Bueno, que me quedo sin espacio, un fuerte abrazo a toda la pea del foro
;)
MU Y I MP ORTA N T E : C OMU N I C A D O E D I TOR I A L !
1. INTRODUCCION
Me he resistido bastante a escribir este artculo
ya que, al margen de mi mana particular hacia
Microsoft, en general quera centrar la serie
RAW en estndares pblicos, y no en protocolos
propietarios de una compaa, como es el caso
del protocolo que utiliza MSN. Pero desde el
principio supe que tarde o temprano tendra
que escribir sobre este tema, ya que es sin
duda uno de los que ms pueden interesar a
los lectores en general.
Yo, personalmente, no soy usuario de MSN,
pero como hay que conocer siempre al
enemigo, considero igualmente interesante
conocer el protocolo que utiliza.
Como ya he comentado, este protocolo no es
un estndar pblico, si no que es propietario
de Microsoft. Por tanto, no existe ningn RFC
que detalle su funcionamiento. An as, hay
informacin bastante completa que podis
encontrar fcilmente a travs de Google y, por
supuesto, siempre nos queda la ingeniera
inversa. ;-)
Antes de empezar, he de decir que existen
gran cantidad de protocolos diferentes, ya que
con cada nueva versin de MSN el protocolo
se ha ido complicando. Por tanto, no puedo
garantizar que lo que explique aqu tenga que
funcionar necesariamente, y menos an que
lo que explique aqu sea TODO el protocolo.
Por tanto, tomad este artculo ms como un
primer acercamiento a este protocolo, que como
una especi fi caci n tcni ca detal l ada.
Si queris informacin completa y al da sobre
este protocolo, tenis una fuente muy buena
e n : h t t p : / / www. h y p o t h e t i c . o r g /
docs/msn/index.php.
2. ARQUITECTURA DE MSN
El protocolo de MSN, como cualquier otro de
los explicados hasta ahora en la serie RAW,
funciona a base de comandos que son enviados
desde un cliente hacia un servidor a travs de
una conexin TCP. El puerto utilizado en este
caso es el 1863. Una diferencia notable entre
este protocolo y otros, como el FTP, o el HTTP,
es que el servidor no slo enva al cliente
respuestas a los comandos que ste solicita, si
no que adems puede enviar mensajes propios
al cliente en cualquier momento. Esto es lgico
si pensamos por ejemplo que los usuarios de
tu lista de contactos pueden conectarse y
desconectarse en cualquier momento, y el
servidor ha de avisarte cuando esto ocurra,
aunque t no l o est s sol i ci t ando
constantemente.
En este sentido, y en otros tantos, hay muchos
conceptos comunes entre IRC y MSN, aunque
en realidad ambos protocolos distan mucho,
tanto en su gramtica, como en su arquitectura,
y en cuestiones de diseo.
La cuestin ms importante de la arquitectura
de MSN es la organizacin de los servidores,
RAW 9
MSN (Microsoft Messenger)
- Descubriremos el Protocolo MSN (MESSENGER)
- Estudiaremos los Servidores que intervienen en un Inicio de Sesin en MSN.
- Nos conectaremos por TELNET y nos autentificaremos por MD5
- Chat y FTP en MSN
ya que puede parecer un poco confusa al
principio.
Una sesin de MSN no es tan simple como en
la mayora de los protocolos, en los cuales
simplemente se establece una conexin TCP
entre nuestro cliente y un servidor y ale, a tirar
comandos. En el caso de MSN, hay 3 tipos de
servidores diferentes con los que podemos
establecer conexiones a lo largo de una nica
sesin.
La sesin comienza cuando establecemos una
conexin con el puerto 1863 de un servidor
nico, que es el llamado Dispatch, cuya url
es messenger.hotmail.com.
Una vez conectados con el servidor Dispatch,
le pedimos que nos diga con qu servidor
podemos conectarnos para llevar a cabo el
resto de la sesin. Por tanto, el servidor
Dispatch slo sirve para repartir los recursos
(servidores) disponibles entre todos los usuarios.
El servidor Dispatch nos dar la direccin del
servidor que debemos utilizar, el cual se llama
dentro de esta arquitectura Notification
Server.
A continuacin, cerramos la conexin con el
servidor Dispatch, para realizar una nueva
conexin con el servidor Notification cuya IP
nos acaba de faci l i tar el Dispatch.
El resto de la sesin se llevar a cabo en el
servidor Notification, que ser el que reciba
nuestros comandos, y nos enve las respuestas,
as como los mensajes asncronos que deba
enviarnos (como los avisos de que un usuario
de tu lista se ha conectado o desconectado).
El tercer tipo de servidor, llamado SwitchBoard,
slo entrar en juego si establecemos un Chat,
para lo cual debemos hacer una solicitud al
servidor Notification, el cual nos proporcionar
la direccin de un servidor SwitchBoard que
podremos utilizar exclusivamente para esa
sesin de Chat. El resto de comandos seguirn
gesti onndose a travs del servi dor
Notification, y podremos solicitar nuevas
sesiones de Chat, lo que dar lugar a una
conexin con un nuevo servidor SwitchBoard
(Vease IMAGEN A en la pgina siguiente)
En la ilustracin podemos ver una sesin de
ejemplo, en la que PyC tiene establecida una
sesin de chat con el usuario Scherzo, y otra
con la usuaria Adhara (a que est bien la
chica? ;-).
3. FORMATO DE LOS COMANDOS
Antes de empezar a mostrar los comandos,
tenemos que conocer unos cuantos aspectos
Serie Raw - MSN - Serie Raw - MSN - Serie Raw - MSN - Serie Raw - MSN - Serie Raw - MSN
comunes a todos ellos.
Todos los comandos empiezan por un cdigo
identificador de 3 caracteres. Este cdigo indica
el tipo de comando y, aunque hay muchos
comandos diferentes, se puede hablar de 3
tipos especialmente importantes:
Mensajes: Su cdigo identificador es
MSG, y son los que se usan para transmitir
mensajes de texto, como por ejemplo cuando
ests hablando en un chat.
Errores: Su cdigo es un nmero de
3 cifras, que codifica el tipo concreto de error.
Son enviados siempre del servidor al cliente.
A lo largo del artculo iremos viendo algunos
de los errores ms importantes.
Resto de comandos: Cualquier otra
combinacin de 3 letras reconocida por el
protocolo. Si probamos alguna combinacin
que no corresponda con ningn comando, el
servidor nos responder con un error 200
(Syntax Error).
Despus del identificador de tipo de comando,
siempre vendrn uno o ms parmetros,
separados por espacios. Por tanto, si
queremos incluir espacios dentro de un
parmetro, tendremos que codificarlo
mediante urlencode. Tenis una
especificacin completa de este sistema
de codificacin en el RFC 1738, pero
en realidad muchas veces basta con
saber simplemente que el espacio se
codifica con el ya conocido %20
(puedes repasar los nmeros 1, 2 y 3
de PC PASO A PASO / Los Cuadernos
de Hack x Crack donde se explic
extensamente eso del %20).
El nico sistema de codificacin que se
usa no es urlencode, que se utiliza slo
para los parmetros, pues tambin se
usa el sistema UTF-8, pero en este
caso para el cuerpo de los mensajes de
texto (MSG). Tenis la especificacin
completa de UTF-8 en el RFC 2279. Igual que
os resuma antes el urlencode, con respecto a
UTF-8 basta decir que mientras no usis
caracteres raros (es decir, prcticamente
cualquier cosa que no sean letras sin tildes, y
nmeros) no tenis que hacer nada, ya que
este sistema slo sirve para codificar caracteres
que se salgan del estndar ascii de 127
caracteres.
Por ltimo, slo queda hablar de un parmetro
fundamental, que se encuentra como primer
parmetro en todos los comandos, incluidos
IMAGEN A
RFC?... !
RFC? %20? urlencode? UTF-8? Argggg de qu
estamos hablando?
En los nmeros anteriores se ha explicado extensamente
todo lo relativo a los RFCs y sus traducciones al espaol.
Si eres un nuevo lector debe sonarte a chino, no desesperes,
en www.hackxcrack.com puedes pedir los nmeros
atrasados.
los errores (de hecho, en los errores, es el
nico parmetro), y exceptuando nicamente
los mensajes (MSG). Este parmetro lo
encontrbamos tambin precisamente en mi
ltimo artculo, que trataba sobre el protocolo
DNS, y tiene el mismo significado en este caso.
Se trata del Transaction ID, o identificador
de transaccin (TRID). Es un nmero nico
que identifica una determinada transaccin,
e s d e c i r, u n a c o mb i n a c i n d e
solicitud+respuesta. Cada vez que el cliente
enve un comando al servidor, lo har con un
TRID diferente, y el servidor deber responder
a ese comando con el mismo TRID. Ms que
una medida de seguridad se trata de una
medida de gestin, ya que permite distinguir
qu respuesta corresponde a qu comando
cuando hemos solicitado varios comandos al
servidor y estamos esperando varias respuestas.
Digo que no es muy prctico como medida de
seguridad porque los clientes de MSN suelen
utilizar TRIDs secuenciales, es decir, empiezan
por el TRID 0 y a cada nuevo comando van
usando el prximo TRID. El TRID es un nmero
de 32 bits, por lo que tendramos que enviar
ms de 4 mil millones de comandos en una
sola sesin para que hubiera problemas
potenciales con el TRID.
Igual que el TRID sirve para saber qu respuesta
corresponde a qu comando, por supuesto,
tambin sirve para saber qu error corresponde
a qu comando.
El servidor tambin puede utilizar nuevos TRIDs
cuando enve al cliente mensajes asncronos
(por ejemplo, cuando un usuario de la lista de
contactos se conecte y tenga que notificrselo
al cliente).
4. COMENZANDO LA SESIN
Una vez calentados los motores de nuestra
aplicacin de Telnet:
telnet messenger.hotmail.com 1863
Con eso realizamos el primer paso para
comenzar una sesin, que es conectar con el
servidor Dispatch.
En realidad, no os aconsejo que probis este
protocolo mediante Telnet, ya que los comandos
son muy largos y muy pesados de escribir, y
adems el servidor os puede desconectar
fcilmente si no recibe lo esperado en el
momento esperado (ante lo cual posiblemente
os responder con un error 715). Por tanto,
en mi opinin la verdadera utilidad de este
artculo est en conocer el protocolo bien para
programar vuestras propias aplicaciones que
exploten algn aspecto concreto del protocolo,
o bien para alguna ocasin en la que necesitis
saber lo que est ocurriendo en vuestra sesin
de MSN mediante un sniffer.
Una vez conectados, vamos a lanzar ya nuestro
primer comando, el comando VER, que sirve
para especificar la versin del protocolo a utilizar.
Este es el comando:
VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0
Como ya dijimos, los 3 primeros caracteres
identifican el tipo de comando, en este caso el
comando VER (Version), y el primer parmetro
es siempre el TRID que, en este caso, al ser el
primer comando que enviamos, es el 0. El resto
de parmetros son especficos del comando
Uffff... !
Ufff si no sabes utilizar TELNET nunca has ledo esta
revista, te aconsejamos que revises los nmeros anteriores.
TELNET te permite conectarte a un servidor remoto
DIRECTAMENTE y "hablar" con l (enviarle comandos),
en PC PASO A PASO hemos explicado muchas veces su
funcionamiento y es una de nuestras herramientas de trabajo
ms "bsicas" :)
VER, ya que el nico parmetro obligatorio en
la mayora de los comandos es el TRID.
Por supuesto, antes de hacer nada ms, lo
primero es identificarnos. Para ello empezamos
consultando el sistema de autenticacin que
debemos utilizar:
INF 1
A este comando nos responder el servidor
con el tipo de desafo que se utilizar para la
autenticacin. Actualmente slo se usa el
sistema MD5, que lo tenis definido en el RFC
1321. Pero tranquilos, que an no hemos de
autenticarnos. Esto se har posteriormente,
en el servidor Notification.
De momento, lo nico que nos interesa es que
el Dispatch nos diga con qu servidor
Notification debemos conectar para el resto
de la sesin.
Suponiendo que nuestra cuenta en hotmail sea
pyc@hotmail.com, el siguiente paso ser
identificarnos mediante este comando:
USR 2 MD5 I pyc@hotmail.com
Despus del TRID, como segundo parmetro,
repetimos el sistema de autenticacin que nos
indic el servidor que debamos utilizar (aunque
an no lo vamos a utilizar). El tercer parmetro,
la I, indica que este comando Inicia el proceso
de autenticacin, ya que este proceso se realiza
en varios pasos, y ste ser el primero. El
ltimo parmetro, por supuesto, es nuestra
cuenta en Hotmail, que es lo que nos identifica.
A este comando el servidor nos debera
responder con algo como esto:
Lo que nos interesa de todo esto es el tercer
parmetro: 207.46.106.120:1863. sta es la
IP y el puerto que hemos de utilizar para
conectar con el Noti f i cati on Server.
Ya podemos cerrar la conexin con el Dispatch,
y abrir una nueva con el Notification:
telnet 207.46.106.120 1863
Con esto conectamos con el servidor Notification.
Una vez aqu, tenemos que repetir los pasos
anteriores, para luego continuar:
INF 4
INF 4 MD5
USR 5 MD5 I pyc@hotmail.com
Esta vez, el servidor ya no nos responder con
un XFR, si no que nos solicitar que continuemos
el proceso de autenticacin. Para ello, nos
enviar la cadena aleatoria para el desafo MD5:
USR 5 MD5 S 1443856346.37654
Como vemos, esta vez no se trata de una I, si
no de una S, ya que no es el primer paso de
la autenticacin. Se sale del tema de este
artculo explicar en detalle la autenticacin MD5,
as que os recomiendo que simplemente utilicis
una aplicacin que haga el trabajo por vosotros.
Tenis una en http://www.fourmilab.ch/md5/
A partir de la cadena aleatoria que nos ha
proporcionado el servidor, construimos el
md5sum (mediante una aplicacin como la que
he mencionado) de la cadena resultante de
concatenar el nmero aleatorio con nuestra
password. Si, por ejemplo, nuestra password
es: LCo, tendremos que hacer el md5sum de
esta cadena: 1443856346. 37654LCo
Para el caso concreto de la aplicacin que os
he mencionado, ejecutaramos desde una
ventana MS-DOS o desde una shell de Linux/Unix
lo siguiente:
md5 -d1443856346.37654LCo l
XFR 2 NS 207.46.106.120:1863 0 207.46.104.20:1863
A lo cual la aplicacin nos dara la siguiente
cadena md5sum:
776e48f7a65f1ae6f3420d3520d55d9e
OYE!!!... !
- OYE!!! Que yo pico con el ratn sobre el md5.exe y me
sale una ventana negra que no funciona Cmo se hace
el md5sum de la cadena "144385646.37654LCo"?
Vale, vamos a explicarlo paso a paso para aquellos que
nunca nos han ledo y posiblemente esta sea una de las
ltimas veces que lo haremos.
1.- Vamos a la WEB que hemos mencionado anteriormente
http://www.fourmilab.ch/md5/ y bajamos un poco hasta
encontrar el enlace para descargar el programa (puedes
verlo en la imagen de color rojo). Pulsamos sobre l y
guardamos el archivo donde queramos (nosotros lo dejamos
en C:\)
2.- Descomprimimos el archivo en la carpeta c:\md5
3.- Iniciamos una Ventana de Comandos, algo explicado
una y mil veces, por ejemplo, en Windows XP Vamos al
Menu Inicio --> Ejecutar y en la ventanita que nos saldr
escribimos cmd.exe y aceptamos (otra forma de hacerlo,
vamos al Menu Inicio --> Programas --> Accesorios -->
Smbolo del Sistema). Ahora tendremos una preciosa
ventanita negra como la de la imagen.
4.- Ahora ejecutamos el programa md5.exe (que si has
seguido nuestros pasos estar en C:\md5\) con la cadena
que queremos "descifrar" y las opciones pertinentes. Pues
venga, escribimos la siguiente instruccin:
c: \ md5\ md5. exe - d1443856346. 37654LCo - l
despus pulsaremos enter y obtendremos la cadena
m d 5 s u m q u e e s t a b a m o s b u s c a n d o
(776e48f7a65f1ae6f3420d3520d55d9e). Puedes verlo en
la pantalla.
Para los que estn muy despistados:
- c:\md5\ --> es la ruta, es decir, donde hemos
descomprimido el programa que nos hemos bajado.
- md5.exe --> es el programa que queremos ejecutar
- -d1443856346.37654LCo -l --> es la cadena que
deseamos "traducir" con las opciones -d al principio y -l
al final (si quieres saber ms sobre las opciones de este
programa lee la documentacin del mismo, que nos
quedamos sin espacio en la revista).
- f i n a l me n t e o b t e n e mo s e l r e s u l t a d o :
776e48f7a65f1ae6f3420d3520d55d9e
Muchos pensarn que a estas alturas esta explicacin tan
detallada es totalmente innecesaria, pues en Hack x Crack
estamos totalmente de acuerdo, pero despus nos llegan
mails preguntando cosas tan sencillas como estas y nos
volvemos locos. En la semana del 15 al 21 de Diciembre
inauguramos "nueva WEB" y esperamos poder poner en
Ya podemos enviar nuestra respuesta al desafo
del servidor mediante Telnet:
Si todo ha ido bien, el servidor nos responder
con algo como esto:
USR 6 OK pyc@hotmail.com PyC 1
Donde PyC es nuestro nick en MSN, y el 1
indica que nuestra cuenta ha sido verificada.
Teniendo en cuenta que los passwords se
codifican con MD5, y que se utiliza cada vez
una cadena aleatoria diferente, mejor ser que
os vayis olvidando de robar cuentas de MSN
con un sniffer. ;-)
El siguiente paso ser indicarle al servidor que
nuestro usuario ha cambiado de estado, ya
que pasa de estar en estado desconectado a
estar online, para lo cual ejecutamos el
comando:
CHG 7 NLN
Que indica que nuestro nuevo estado es NLN
(Online). El servidor difundir este cambio de
estado a los usuarios que te tengan en su lista
de contactos.
En lugar de conectar directamente como NLN,
podramos conectar como invisibles con el
estado HDN (Hidden):
CHG 7 HDN
En este caso, el servidor no difundira nada, y
para el resto de usuarios aparentemente
seguiras desconectado.
En cualquier momento, podremos volver a
cambiar nuestro estado mediante el comando
CHG, siendo estos los estados ms importantes:
NLN (oNLiNe : conectado)
FLN (oFfLiNe : desconectado)
HDN (HiDdeN : conectado, pero aparece como
desconectado para el resto de usuarios)
IDL (IDLe : el usuario lleva inactivo cierto
tiempo)
AWY (AWaY : ausente)
BSY (BuSY : ocupado, no molestar)
A lo largo de la sesin no slo podemos cambiar
nuestro estado, si no tambin nuestro nick.
Para ello utilizaremos el comando REA:
REA 8 pyc@hotmail.com PyC%20LCo
Con esto hemos cambiando nuestro nick a PyC
LCo, por supuesto, codificado con urlencode
(%20 en lugar del espacio). El problema es que
Microsoft impone una censura sobre los nicks,
pero hay formas de saltarse esto. ;-)
Si codificamos todo el nick, y no slo los espacios
y caracteres especiales, podr pasar los filtros
de Microsoft. :-D
En este momento, podemos enviar un comando
para identificar el software que estamos
utilizando, y su versin, as como el sistema
operativo, pero este comando no es obligatorio.
Si queremos hacerlo:
Con esto indicamos que nuestro sistema
operativo es Windows 98 en un procesador
Intel 386, y que nuestro cliente es la versin
4.5 build 127 de Microsoft Messenger.
El servidor nos responder con el nmero de
versin actual, y la URL desde la que podemos
bajarla:
USR 6 MD5 S 776e48f7a65f1ae6f3420d3520d55d9e
CVR 8 4.5.0127 4.5.0127 1.0.0863
http://download.microsoft.com/download/msnmessenger/ins
tall/4.5/win98me/en-us/ mmssetup.exe http://messenger.mic
rosoft.com
CVR 8 0x0409 win 4.10 i386 MSMSGS 4.5.0127 MSMSGS
ella este tipo de explicaciones tan bsicas en lugar de
publicarlas en la revista. Venga, os dejamos con el resto
del artculo :)
En cualquier momento podemos desconectar
con el comando OUT:
OUT
5. UNA VEZ CONECTADOS...
Por nuestra parte, ya est todo hecho para
comenzar la sesin (aunque no ha sido fcil).
Ahora es tarea del servidor (que trabaje un
poco) enviarnos toda la informacin que
necesitamos cada vez que conectamos.
En primer lugar, nos enviar dos mensajes de
Hotmail, dndonos informacin sobre nuestra
cuenta, y sobre los mensajes que tenemos en
nuestra bandeja de entrada. Estos dos mensajes
comenzarn con:
MSG Hotmail Hotmail ...
Pero lo nico que puede parecernos interesante
de todo esto es el campo Inbox-Unread, que
contiene el nmero de mensajes sin leer que
tenemos en l a bandej a de entrada.
En cualquier momento a lo largo de nuestra
sesin, nos pueden llegar nuevos mensajes de
Hotmail para indicarnos que hemos recibido
un email.
Lo que s que es ms interesante, es la
notificacin del estado de cada usuario de
nuestra lista de contactos. Para ello, el
servidor utilizar un nuevo TRID en el cual nos
enviar, lnea por lnea, el estado de cada
usuario. Por ejemplo:
ILN 9 NLN Scherzo@hotmail.com Scherzo
ILN 9 AWY Adhara@hotmail.com Adhara
ILN 9 BSY skitter@hotmail.com skitter
El servidor nos indica aqu que el usuario
Scherzo se encuentra conectado (NLN),
que el usuario Adhara est ausente (AWY),
y que el usuario skitter est ocupado (BSY).
Los usuarios que estn desconectados no
aparecern en esta lista.
En cualquier momento, el estado de un usuario
puede cambiar, y en este caso el servidor no
utilizar el comando ILN, si no bien el comando
NLN o el FLN. El NLN se usar cuando el
nuevo estado no sea desconectado (oNLiNe,
AWaY, o BuSY). El FLN se usar cuando el
nuevo estado sea desconectado. Por ejemplo:
NLN AWY Scherzo@hotmail.com Scherzo
Nos indica que el usuario Scherzo ha cambiado
s u e s t a do a oc upado ( AWY) .
Mientras que:
FLN Scherzo@hotmail.com Scherzo
Nos indica que el usuario Scherzo se ha
desconectado.
6. LISTAS DE CONTACTOS
Aunque en un principio pueda parecer que
existe una nica lista de contactos, en realidad
hay que tener en cuenta varias listas.
En primer lugar, la mas obvia, es la lista de
usuarios que hemos ido aadiendo para conocer
su estado y comunicarnos con ellos. Pero
tambin es importante la lista contraria, que
es la de aquellos usuarios que te han aadido
a ti a su lista. Con estos usuarios tambin
puedes establ ecer una comuni caci n.
Adems de estas dos listas, hay dos listas
especiales, la de Allow y la de Block, que sirven
para indicar qu nivel de privacidad deseamos
tener frente a qu usuarios.
Por ltimo, hay que recordar tambin que la
lista de contactos que hemos aadido nosotros
no es nica, ya que podemos agruparla en
distintas listas. Por ejemplo, una lista para tus
amigotes, otra para los compaeros de
clase/trabajo, otra para la familia, etc.
Por tanto, podemos manejar un nmero
indeterminado de listas, aunque las ms
importantes son las 4 primeras que nombr:
FL (Forward List) : Tu propia lista de
contactos, incluidos los de todos los grupos.
RL (Reverse List) : La lista de los usuarios
que te tienen en su propia FL.
AL (Allow List) : Lista de usuarios para los
que deseas ser visible.
BL (Block List) : Lista de usuarios para los
que no deseas ser visible.
Por su puesto, las listas AL y BL son
mutuamente excluyentes.
Cada lista tiene un nmero de versin que
se incrementa cada vez que se hace una
modificacin sobre esa lista (se aaden o se
eliminan usuarios). El nmero de versin de
cada lista es mantenido por el servidor.
Si queremos que el servidor nos d una de
nuestras listas, la solicitamos con el comando
LST. Por ejemplo, para solicitar nuestra lista
FL:
LST trid FL
Donde trid es el identificador de transaccin
que corresponda utilizar en ese momento. A
esto nos responder el servidor con algo
parecido a esto:
Vamos a analizar esta respuesta:
En primer lugar, podemos deducir fcilmente
que el servidor nos enva una lnea de respuesta
por cada usuario que tengamos en esa lista (en
este caso, la lista FL).
El primer parmetro, despus del TRID, es el
nmero de versin de la lista FL. A continuacin
tenemos un nmero que indica la posicin
dentro de la lista, y despus otro que indica el
nmero total de elementos en la lista. A
continuacin, el email y el nick. Y por ltimo,
un nmero que indica el grupo en el que
tenemos a ese usuario. Por ejemplo, en este
caso podramos tener un grupo, el grupo 0,
para los miembros de LCo, otro grupo, el 1,
para los compaeros de la facultad, y otro
grupo, el 2, para los Pollos.
Podemos ver que en nuestra FL hay un usuario,
Pollo Dios, que no nos fue enviado por el
servidor en un comando ILN cuando nos
conectamos. Esto se debe a que este usuario
no estaba conectado en el momento de
conectarnos nosotros (o bien estaba invisible).
Podemos gestionar estos grupos mediante
comandos. Por ejemplo, con el comando:
ADG trid Familia 0
Aadimos el grupo familia a nuestra FL. El
servidor nos responder con la nueva versin
de la lista FL, y con el cdigo que corresponde
a ese grupo:
ADG trid 101 Familia 3
Es decir, la lista FL est ahora en su versin 101,
y al grupo Familia le corresponde el cdigo 3.
Podemos bor r ar un gr upo c on:
RMG trid 3
Con esto borraramos el recin creado grupo
3, es decir, el grupo Familia.
LST trid 100 1 4 Scherzo@hotmail.com Scherzo 0
LST trid 100 2 4 Adhara@hotmail.com Adhara 0
LST trid 100 3 4 skitter@hotmail.com skitter 1
LST trid 100 4 4 pollodios@hotmail.com Pollo%20Dios 2
Con respecto a la gestin de usuarios dentro
de una lista, disponemos de los comandos
ADD y REM para aadi r y borrar
respectivamente. As:
ADD trid FL soulnet@hotmail.com Soulnet 0
Con esto aadimos al usuario Soulnet al
grupo LCo (grupo 0).
Para borrar al usuario recin aadido:
REM trid FL soulnet@hotmail.com
Si, en lugar de aadir a la lista FL, aadimos
a las listas AL o BL, los efectos son diferentes.
Si aadimos un usuario a nuestra lista AL:
ADD trif AL soulnet@hotmail.com Soulnet
Indicamos al servidor que permitimos que ese
usuario pueda conocer nuestro estado. En este
caso, no hay que indicar un cdigo de grupo,
ya que no hay grupos dentro de la lista AL,
slo en la lista FL.
Si, en cambio, queremos bloquear a un usuario,
tendremos que aadirlo a nuestra lista BL. En
caso de que estuviese previamente aadido a
nuestra lista AL, tendremos que eliminarlo
primero, ya que si no el servidor nos devolver
un error 219:
REM trid AL soulnet@hotmail.com
ADD trid+1 BL soulnet@hotmail.com
Soulnet
Podemos obligar a que un usuario reciba nuestra
confirmacin si quiere aadirnos a su FL (es
decir, si quiere aadirse a nuestra RL), mediante
el comando:
GTC trid N
Si en lugar de N el parmetro fuese A,
indicaramos lo contrario: que cualquier usuario
podra aadirnos a su lista sin pedirnos permiso.
En el momento en que un usuario nos aada
a su lista, el servidor nos avisar de que se ha
aadido ese usuario a nuestra RL, con un
mensaje como este:
ADD 0 RL 120 soulnet@hotmail.com
Soulnet
Con esto nos indica que el usuario Soulnet nos
ha aadido a su FL y, por tanto, se ha aadido
a la versin 120 de nuestra RL. Cuando ocurra
esto, decidiremos qu hacer con este usuario,
aadindolo en nuestra AL si queremos que
sea nuestro amiguito, o en la BL si no queremos
saber nada de l (o, ms bien, que l no sepa
nada de nosotros).
Por supuesto, el servidor tambin nos avisar
de las bajas en nuestra RL, con un mensaje
como este:
REM 0 RL 121 soulnet@hotmail.com
Que nos indica que el usuario Soulnet nos ha
borrado de su lista FL.
7. CHAT
Como ya dijimos, para las sesiones de chat se
uti l i za un tercer servi dor, que es el
SwitchBoard. Si queremos iniciar una sesin
de chat, lo primero ser solicitar la direccin
de un SwitchBoard que est disponible. Para
el l o uti l i zamos el si gui ente comando:
XFR trid SB
La respuesta del servidor:
XFR trid SB 64.4.12.193:1863 CKI
12398789312.541378664.23146
No slo nos indica la IP y puerto del servidor
SwitchBoard, si no que tambin nos da una
cadena aleatoria que necesitaremos para la
autenticacin en el servidor.
A continuacin, por supuesto, lanzamos el
nuevo Telnet, sin cerrar el anterior, ya que
seguiremos necesitando la conexin con el
Notification Server para todos los dems eventos
de la sesin
telnet 64.4.12.193 1863
Dentro del SwitchBoard comenzamos
identificndonos:
Como veis, repetimos la cadena que nos dio
el Notification Server. Una vez conectados e
identificados, podemos invitar a otros usuarios
a que se unan al Chat:
CAL 2 Scherzo@hotmail.com
Con esto, invitamos al usuario Scherzo a que
se una a nuestra sesin de chat en el
SwitchBoard. El servidor nos responder:
CAL 2 RINGING 2893765
Indicndonos el identificador de sesin que
dar a ese usuario.
El servidor avisar a Scherzo con un mensaje
como este:
RNG 2893765 64.4.12.193:1863 CKI
34482642.436429847 pyc@hotmail.com PyC
Que le indica quin le ha solicitado que se una
al chat (PyC), en qu servidor (64.4.12.193
en el puerto 1863), la cadena de identificacin
(34482642.436429847), as como el
i denti fi cador de sesi n (2893765).
Si ahora l quiere unirse al chat, deber empezar
por conectar con el Swi tchBoard:
telnet 64.4.12.193 1863
Para, a continuacin, identificarse para comenzar
la sesin:
Como vemos, repetimos los dos nmeros que
nos fueron dados en el comando RNG.
Si la identificacin es satisfactoria, el servidor
nos dar la lista de usuarios conectados al chat:
IRO 1 1 3 pyc@hotmail.com PyC
IRO 1 2 3 Adhara@hotmail.com Adhara
IRO 1 3 3 soulnet@hotmail.com Soulnet
ANS 1 OK
Como vemos, el formato es similar al de la
respuesta al comando LST.
Si Scherzo acept nuestra invitacin, y realiz
todo el proceso descrito anteriormente,
reci bi remos un mensaj e como este:
JOI Scherzo@hotmail.com Scherzo
Indicndonos que Scherzo se ha unido a nuestro
chat.
La conversacin en el chat, desde el punto de
vista del protocolo RAW, no es trivial, ya que
se utiliza el estndar MIME, del cual ya he
hablado en otros artculos de la serie (sobre
todo en el que trataba sobre el protocolo HTTP).
Por tanto, cada texto enviado al chat ha de ir
acompaado de una cabecera MIME aunque,
por suerte, bastante sencilla en comparacin
con cmo puede llegar a complicarse una
cabecera MIME.
Adems, el protocolo MSN permite especificar
el nivel de confirmacin que deseamos que nos
de el servidor por cada mensaje enviado:
U : El servidor no enva ningn tipo de
confirmacin. Nosotros vamos escribiendo, y
no sabemos si los interlocutores estn leyendo
lo que escribimos.
USR 1 pyc@hotmail.com 12398789312.541378664.23146
ANS 1 Scherzo@hotmail.com 34482642.436429847 2893765
N : Por cada mensaje que escribimos, el servidor nos
enviar una lnea con un comando NAK trid si el mensaje
no lleg a su destino.
A : Por cada mensaje que escribimos, el servidor no slo
nos responder si el mensaje no lleg (NAK trid), si no que
tambin nos confirmar en caso de que llegase correctamente
(ACK trid)
Asumiendo que no deseamos ningn tipo de confirmacin
(U), ste sera un mensaje de ejemplo:
El ltimo parmetro del comando (149) indica el tamao
en bytes del mensaj e, i ncl ui da l a cabecera.
Como vemos, indicamos que utilizamos codificacin UTF-
8, que ya dijimos que es la que se utiliza para los mensajes
de texto.
La lnea X-MMS-IM-Format indica varios parmetros sobre
el tipo de letra utilizado. Para una escritura normal podis
copiar directamente esa lnea.
Nuestros interlocutores en el chat recibirn un mensaje del
servidor como este:
MSG pyc@hotmail.com PyC 149
MIME-Version: 1.0
Content-Type: text/pl ai n; charset=UTF-8
X-MMS-IM-Format: FN=Arial; EF=; CO=0; CS=0;
PF=22
Hola!! :-DDD
Podemos, adems, enviar un mensaje especial que
simplemente indica al resto de interlocutores que nos
encontramos en ese momento escribiendo un mensaje (desde
luego, si lo hacemos por telnet, no tiene mucho sentido).
El mensaje sera similar a este:
MSG U 90
MIME-Version: 1.0
Content-Type: text/x-msmsgscontrol
Typi ngUs er : pyc @hot mai l . c om
Lo curioso de este tipo de mensaje es que
podemos escribir cualquier cosa en el campo
TypingUser, por lo que podramos engaar al
resto de usuarios, hacindoles creer que es
otro usuari o el que est escri bi endo.
Por ltimo, para finalizar la sesin de chat (es
decir, cerrar la conexin con el SwitchBoard)
podemos usar el mismo comando que cierra la
conexi n con el Noti fi cati on Server:
OUT
Ante lo cual, el resto de interlocutores recibirn
un mensaje como este:
BYE pyc@hotmail.com
Indicndoles que el usuario PyC ha abandonado
el chat.
8. ENVIANDO ARCHIVOS
El equivalente al DCC en el protocolo MSN
(MSNFTP) dista mucho en realidad del mismo,
no slo porque la sintaxis es diferente, si no
tambin porque aqu hay una mayor seguridad,
al haber un dilogo entre ambas partes de la
transferencia que permite asegurarse hasta
cierto punto de que ests enviando el archivo
al usuario que deseas, y no a otro cualquiera
que se ha colado en la conexin, como veamos
en el caso de los protocolos DCC y FTP en
anteriores artculos. Antes de que tiris cohetes
en favor de Microsoft, tened en cuenta que los
protocolos DCC y FTP existen desde la era de
los dinosaurios, y el protocolo MSNFTP slo
MSG trid U 149
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-MMS-IM-Format: FN=Arial; EF=; CO=000000; CS=0; PF=22
Hola!! :-DDD
desde el ao 98, as que ya sera delito, a esas
alturas, no haber diseado un protocolo
medianamente seguro.
En lo que s que se parecen DCC y MSNFTP es
en que la conexin se realiza punto a punto
entre ambos usuarios, actuando, normalmente,
el usuario transmisor como servidor, y el
receptor como cliente.
Vamos a ver detenidamente los pasos que se
siguen desde que el usuario PyC desea enviar
un archivo al usuario Scherzo, hasta que ste
lo recibe.
8.1. PyC enva a Scherzo una
invitacin para recibir un archivo.
Para ello, enva al servidor un mensaje como
este:
MSG trid U 273
MIME-Version: 1.0
Content-Type: text/x-msmsgsinvite; char
set=UTF-8
Application-Name: File Transfer
Application-GUID: {5D3E02AB-6190-11d
3-BBBB-00C04F795683}
Invitation-Command: INVITE
Invitation-Cookie: 22692
Application-File: LCo.jpg
Application-FileSize: 57565
Este mensaje indica que queremos enviar un
archivo llamado LCo.jpg, de tamao 57565
Bytes.
El parmetro ms raro que podemos ver aqu
es el llamado Application-GUID. ste
numerajo hexadecimal identifica unvocamente
un tipo de aplicacin, en este caso, la aplicacin
de transferencia de ficheros. Si utilizamos
valores diferentes para el Application-GUID
podemos construir invitaciones para servicios
muy diferentes.
Por ejemplo, con:
Application-GUID: {02D3C01F-BF30-482
5-A83A-DE7AF41648AA}
Se tratara de una invitacin para un chat por
voz.
No bastara con modificar el Application-
GUID, ya que el chat por voz, y cualquier otro
tipo de invitacin, tiene diferentes campos en
la cabecera, as que lo pongo slo como ejemplo.
En el caso que nos ocupa, que es el de la
transferencia de ficheros, podramos incluir un
campo opcional, que sera:
Connectivity: N
Este campo indica que no tenemos posibilidad
de abrir conexiones entrantes (probablemente
porque estamos detrs de un firewall), as que
invitamos al receptor del archivo a que sea l
el que abra el puerto para la transferencia. En
el resto del ejemplo, asumiremos que es PyC
(el que ha hecho la invitacin) el que abre el
puerto, tal y como veremos ms adelante.
8.2. Scherzo acepta la invitacin de PyC
En el caso de que Scherzo desee recibir el
archivo, enviar un mensaje con el formato
siguiente:
MIME-Version: 1.0
set=UTF-8
Invitation-Command: ACCEPT
Launch-Application: FALSE
Request-Data: IP-Address:
Como vemos, en este mensaje Scherzo acepta
la invitacin de PyC, y adems le solicita los
datos necesarios para la conexin: la IP y el
puerto al que debe conectarse. En el caso de
que fuese Scherzo el que tuviese que actuar
como servidor (si PyC hubiese enviado el
parmetro Connectiviy: N) este mensaje sera
totalmente diferente, pero no entraremos en
detalles, ya que slo hablamos del caso ms
general.
Si, en cambio, Scherzo no aceptase la invitacin,
podr a rechazarl a con este mensaje:
MIME-Version: 1.0
set=UTF-8
Invitation-Command: CANCEL
Cancel-Code: REJECT
8.3. PyC facilita a Scherzo los datos
necesarios para la conexin
A continuacin, PyC tiene que dar a Scherzo
los datos que necesita para establecer la
conexin. Para ello, enva un mensaje como
ste:
MSG trid N 239
MIME-Version: 1.0
set=UTF-8
Invitation-Command: ACCEPT
IP-Address: 217.20.11.135
Port: 6891
AuthCookie: 73856
Launch-Application: FALSE
Request-Data: IP-Address
Es fcil interpretar el significado de los
parmetros. La IP y el puerto se encuentran
en los parmetros IP-Address, y Port,
respectivamente. El nico parmetro que
requiere una explicacin es el AuthCookie.
Este parmetro servir para que luego el cliente
se identifique a la hora de establecer la conexin.
Esto es precisamente lo que diferencia el
protocolo MSNFTP de otros protocolos de
transferencia de archivos, como DCC, o FTP,
en los cuales cualquiera puede conectarse a un
puerto en escucha del servidor, y suplantar as
la personalidad del cliente legtimo. Aqu no
basta slo con conectarse el primero, si no que
adems hay que demostrar que fue a nosotros
a quien se hizo la invitacin para la transferencia.
Pero todo esto lo veremos ahora, en los
siguientes pasos.
8.4. Scherzo se conecta a PyC
Ahora que el cliente de Scherzo conoce la IP y
puerto que ha abierto PyC para la transferencia,
ya puede establecer una nueva conexin TCP.
En este caso:
telnet 217.20.11.135 6891
Por supuesto, si PyC est detrs de un firewall,
tendr que abrir el trfico entrante para ese
puerto. MSNFTP suele usar el puerto 6891 y
los sucesivos (6892, 6893, ...), as que tendra
que abrir estos puertos en el NAT del firewall
en caso de encontrarse en una red privada,
como es por ejemplo el caso de un usuario de
ADSL con Router.
A partir de ahora, el resto de pasos se llevan
a cabo dentro de esta nueva conexin
establecida.
8.5. Scherzo se identifica, y
comi enza l a transf erenci a
En el caso de DCC o FTP, llegados a este punto
comenzara automticamente el flujo de datos
nada ms establecerse la conexin entre el
cliente y el servidor. En cambio, aqu son
necesarias unas gestiones previas para
identificar al cliente.
El primer paso es simple:
VER MSNFTP
A lo cual nos responder con el mismo mensaje
el servidor, indicando as que ambos estn de
acuerdo con el protocolo a utilizar: MSNFTP.
A continuacin, viene el paso crucial, que es
la identificacin del cliente:
USR Scherzo@hotmail.com 73856
Como vemos, indica su nombre de usuario
(Scherzo@hotmail.com), as como la
AuthCookie que le dio el servidor antes de
establecer la conexin y que, tericamente,
solo conocen ambas partes. Por supuesto, si
con un sniffer has capturado el AuthCookie
de otro usuario, podras colarte t en su lugar,
y conseguir as un Hijacking como los que
expliqu en los protocolos DCC y FTP.
Si la autenticacin ha sido correcta, el servidor
nos responder con el tamao del archivo
en Bytes:
FIL 57565
Despus de esto, ya slo falta que el cliente
inicie la transferencia con el comando:
TFR
8.6. PyC transfiere el archivo a
Scherzo
Como a los muchachos de Microsoft les gusta
complicar las cosas, la transferencia del archivo
no consiste en un simple flujo de datos, como
ocurre en el caso de DCC o FTP.
El propio protocolo TCP/IP ya se encarga de
empaquetar los datos y fragmentarlos, por lo
que estos protocolos delegan por completo en
los niveles inferiores (nivel de transporte: TCP,
y nivel de red: IP) para estas tareas. En cambio,
MSNFTP implementa su propio sistema de
empaquetamiento de los datos en bloques,
que es relativamente complejo.
Cada bloque tiene una pequea cabecera de 3
Bytes, que especifica el tamao del bloque (por
defecto de 2045 Bytes), de la siguiente
manera:
El primer byte de la cabecera, es siempre 0,
excepto en el ltimo bloque, que es 1.
El segundo byte y el tercer byte especifican
la longitud del bloque segn la frmula:
(tercer byte) * 256 + (segundo byte)
Por tanto, el ltimo bloque, que finalizara la
transferencia, constara nicamente de los 3
bytes de cabecera, con el siguiente valor:
Primer byte = 1
Segundo byte = 0
Tercer byte = 0
Cuando Scherzo haya recibido todo el archivo,
cerrar l a sesi n con el comando:
BYE 16777989
Ese nmero es un cdigo que indica que la
operacin termin con xito. Existen otros
cdigos, como por ejemplo:
2147942405 : Disco del receptor lleno. No
se puede conti nuar l a transferenci a.
2164261682 : El receptor ha cancelado la
transferencia.
En lugar de utilizar estos cdigos para cancelar
la transferencia, se puede utilizar directamente
el comando:
CCL
Que tiene el mismo efecto, en cualquier
momento durante la sesin de transferencia.
Tanto con un BYE como con un CCL se cierra
la conexin, con lo que nuestra atencin volvera
a las otras conexiones que tendremos (con un
Notification Server, y con uno o varios
SwitchBoards), y volvera a repetirse toda la
historia que ya os he contado, por lo que
aqutermina mi trabajo por el momento. ;-)
Autor: PyC (LCo)
EL GANADOR DEL
SORTEO DE UN SUSE
LINUX 9.0 DEL MES DE
Noviembre ES:
Jesus Valbuena Maeso
VIZCAYA
SEGUIR LLAMANDO, EL PROXIMO
PODRIA SER PARA TI (PAG 27)
SUSCRIBETE A
PC PASO A PASO
SUSCRIPCIN POR:
1 AO
11 NUMEROS
45 EUROS (10% DE DESCUENTO)
+
SORTEO DE UNA CONSOLA XBOX
+
SORTEO 2 JUEGOS PC (A ELEGIR)
=
Cont r a Reembol so
Cont r a Reembol so
Solo tienes que enviarnos un mail a preferente@hackxcrack.com
indicando:
- Nombre
- Apellidos
- Direccin Completa
- Poblacin
- Provincia
- Cgigo Postal
- Mail de Contacto y/o Telfono Contacto
Es imprescindible que nos facilites un mail o telfono de contacto.
- Tipo de Subscripcin: CONTRAREEMBOLSO
- Nmero de Revista:
Este ser el nmero a partir del cual quieres subscribirte. Si deseas
(por ejemplo) subscribirte a partir del nmero 5 (incluido), debes poner
un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos)
APRECIACIONES:
* Junto con el primer nmero recibirs el abono de 45 euros, precio
de la subscripcin por 11 nmeros (un ao) y una carta donde se te
indicar tu nmero de Cliente Preferente y justificante/factura de la
subscripcin.
* Puedes hacernos llegar estos datos POR MAIL,tal como te hemos
i ndi cado; r el l enando el f or mul ar i o de nuest r a WEB
(www.hackxcrack.com) o envindonos una carta a la siguiente direccin:
CALLE PERE MARTELL N20, 2-1
CP 43001 TARRAGONA
ESPAA
* Cualquier consulta referente a las subscripciones puedes enviarla
por mail a preferente@hackxcrack.com
Giro Post
Giro Post
al
al
Envanos un GIRO POSTAL por valor de 45 EUROS a:
CALLE PERE MARTELL20, 2 1.
CP 43001 TARRAGONA
ESPAA
IMPORTANTE: En el TEXTO DEL GIRO escribe un mail de contacto
o un nmero de Telfono.
Y enviarnos un mail a preferente@hackxcrack.com indicando:
- Nombre
- Apellidos
- Direccin Completa
- Poblacin
- Provincia
- Cgigo Postal
- Mail de Contacto y/o Telfono Contacto
Es imprescindible que nos facilites un mail o telfono de contacto.
- Tipo de Subscripcin: GIRO POSTAL
- Nmero de Revista:
Este ser el nmero a partir del cual quieres subscribirte. Si deseas
(por ejemplo) subscribirte a partir del nmero 5 (incluido), debes poner
un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos)
APRECIACIONES:
* Junto con el primer nmero recibirs una carta donde se te indicar
tu nmero de Cliente Preferente y justificante/factura de la subscripcin.
* Puedes hacernos llegar estos datos POR MAIL,tal como te hemos
indicado; o envindonos una carta a la siguiente direccin:
CALLE PERE MARTELL N20, 2-1
CP 43001 TARRAGONA
ESPAA
* Cualquier consulta referente a las subscripciones puedes enviarla
por mail a preferente@hackxcrack.com
1. INTRODUCCIN
Sin duda, escribir este artculo me va a traer
muchos recuerdos, ya que haca varios aos
que no conectaba con un servidor de Usenet
y, en cambio, cuando todava iba en paales
por la red, las news ocupaban ms de la
mitad de mi tiempo ciberntico (Usenet, news
si estos trminos no te son familiares, sigue
leyendo y descubrirs un nuevo mundo; si ya
l os conoces, profundi zaremos en su
funcionamiento).
Creo que puedo asegurar que Usenet fue uno
de los motivos por los cuales me enamor
irremediablemente de Internet cuando, all
por el ao 95, me encontr repentinamente
abrumado por una cantidad de informacin
con la cual antes ni siquiera haba soado. Por
aquel entonces, mi contacto con LA RED era
a travs de un terminal en modo consola (texto)
servido por una mquina VMS (si sientes
curiosidad por este trmino, www.google.com).
El navegar por la WWW mediante un navegador
en modo texto (Lynx) haca que la Web no
fuese precisamente lo que se me presentaba
como ms atractivo de Internet.
Pero el hecho de que no pudiese ver las pginas
con un interfaz grfico no era el nico motivo.
Tan slo unos pocos meses despus instal un
prodigio de la tecnologa, un mdem 14400,
en el flamante Pentium 90 nuevo de mi hermano.
Conect por primera vez a la red con un interfaz
grfico, el poderoso Windows 3.1, gracias al
prodigioso (y ahora prehistrico) Trumpet
Winsock, y pude ver al fin una pgina Web tal
y como fue concebida, en un navegador grfico
como era Netscape (Explorer ni siquiera exista,
pero seguro que tampoco lo habra usado
aunque hubiese existido :-P).
Sinceramente, por aquel entonces la Web me
pareci poco ms que curiosa, al igual que
cualquier cosa nueva que me pudiera haber
encontrado, pero no me pareci realmente
interesante. Al menos, no al lado de la ingente
cantidad de informacin que circulaba por
Usenet, terreno que iba conociendo ya bastante
bien.
Cuntas horas pasara por aquel entonces
rebuscando entre los miles de grupos,
suscribindome y desuscribindome y, sobre
todo, fascinndome ante la enorme diversidad
de culturas y personalidades con las que poda
contactar un pobre chaval como yo para el que,
hasta ese momento, su contacto ms directo
con otra cultura haban sido los comics de
Marvel?
Raw 10
nntp (usenet)
- PROTOCOLO NNTP (EL GRAN OLVIDADO)
- NEWS / USENET: UNA RED DE FOROS
- TOPOLOGIA DE USENET
- JERARQUIA DE NEWSGROUPS
- SERVIDORES ESCLAVOS
- LA SOCIEDAD DE USENET: TROLLS / FLAMEWARS / SPAM-BOTS /
CROSSPOSTING ... ...
Quiz hoy da las news estn desfasadas desde
el punto de vista tecnolgico, pero no es fcil
hacer desaparecer una sociedad formada
durante aos por cientos de miles, o millones
de personas y, en cuestiones como sta, donde
lo realmente importante es la informacin, la
tecnologa queda en un segundo plano.
Probablemente, Usenet ser conocido para
muchos de vosotros, pero estoy tambin seguro
de que ms de uno no habris odo hablar
jams de lo que sigue siendo hoy da una de
las comunidades ms importantes de Internet,
y todo esto os estar sonando a chino.
Para todos esos que an no sabis de qu
hablo, empezar por una pequea introduccin
para contaros qu es todo esto, porque hoy
da sigue siendo una importante fuente de
informacin que, por su carcter propio, no
puede ser reemplazado por los nuevos sistemas
(al menos de momento).
2. QU ES USENET?
Si estas leyendo esto, quiz es tu da de suerte,
porque si en lugar de habrmelo preguntado
a m, hubieses buscado respuesta a esta
pregunta en los FAQs y diversos artculos acerca
de Usenet te habras encontrado con multitud
de respuestas evasivas y complicadsimas
reflexiones filosficas y metafsicas acerca de
lo que es, no es, deja de ser, y sigue siendo
Usenet. Personalmente, no entiendo bien a
qu se deben estas comeduras de cabeza
porque, si bien Usenet es complejo en sus
detalles, la idea general es bien sencilla. Esto
es lo que es Usenet: una red de foros.
Supongo que todos sabis lo que es un foro:
un punto de encuentro para gente interesada
en un tema comn, en el cual esta gente puede
escribir artculos, preguntas, o cualquier otra
cuestin que deseen compartir o comunicar al
resto de personas del foro (claro ejemplo es
el foro de esta revista: www.hackxcrack.com).
Usenet es bsicamente una comunidad de foros
en la cual existen decenas de miles de foros
diferentes, cada uno con su temtica particular
y sus usuarios particulares, y donde se pueden
crear nuevos foros segn vaya surgiendo la
necesi dad por parte de l os usuari os.
Quiz algunos conozcis Usenet por otros
nombres ms comunes, ya que vulgarmente
se le suele llamar las news o los newsgroups.
Posiblemente ms de uno os habris topado
con estos trminos pero los habris ignorado
al no saber de qu iban. Por ejemplo, al contratar
vuestra conexin a Internet, posiblemente
vuestro ISP os dio la direccin de su servidor
de news, o al configurar vuestro cliente de
correo (Outlook, Netscape, ...) os habris
encontrado con opciones para conectar con un
servidor de news, o incluso en el propio Google
habris visto el apartado GRUPOS entre los 5
apartados principales: La web, Imgenes,
Grupos, Directorio, y News (en este caso, News
no tiene nada que ver con el tema, pero si
Grupos).
RAW 10 - USENET - RAW 10 - USENET - RAW 10 - USENET - RAW 10 - USENET - RAW 10
Hay un dicho popular que reza: si no sale en la tele-,
no existe, pues hoy en da podramos decir lo mismo pero
relacionado con Internet: si no sale en GOOGLE, no
existe.
Hay muchas utilidades del buscador GOOGLE que muchas
personas desconocen. Una es la de poder buscar imgenes
(botn imgenes) y otra es la de poder buscar en USENET
(botn grupos). Dedcale 3 minutos a cada opcin y ya no
podrs vivir sin ellas.
Hay un dicho poular... !
No es casualidad que la mayora de clientes
de correo incorporen tambin funciones para
conectar con Usenet, ya que muchos de los
conceptos que manejaremos sern muy
parecidos a los de una mailing-list, o lista de
correo, y el formato de los mensajes en Usenet
es bastante similar al del correo electrnico.
2.1. Jerarqua de los newsgroups
Antes de seguir por el camino que he empezado
a tomar, voy a avisaros de que hay gente
bastante quisquillosa a la cual no le gusta que
se hable de foros cuando se habla de Usenet,
as que a partir de ahora usaremos el trmino
grupo para referirnos a un foro concreto de
Usenet.
Quiz os preguntis de qu forma se pueden
administrar tantsimos grupos (he hablado
antes de decenas de miles). Realmente es muy
difcil mantener el orden en tal cantidad de
informacin, ya que son miles de artculos
nuevos los que aparecen cada da publicados
en los distintos grupos de Usenet, y en la
prctica, no slo es difcil, si no que de hecho
no se ha conseguido.
Si buscis en Usenet un sistema fiable de
comunicacin, estis totalmente equivocados
y ya os podis ir buscando otra cosa. Ms
adelante os hablar de los problemas que puede
haber con los artculos de un grupo, pero de
momento vamos a tratar de los problemas que
hay con la propia existencia de los grupos.
Para organizar la ingente cantidad de
informacin, en Usenet existe una ordenacin
jerrquica. En los comienzos de Usenet (a
principios de los aos 80, aunque hasta el ao
86 no se impuso el protocolo NNTP sobre el
UUCP, utilizado anteriormente) se crearon 8
grupos principales de los cuales colgaran todos
los dems mediante una estructura en rbol
como la que siguen los directorios (carpetas)
de un disco duro. Estos 8 grupos principales
eran los siguientes:
comp.* - (computers) todo lo relacionado con
ordenadores, informtica, etc.
humanities.* - como bien dice el nombre:
humanidades.
news.* - todo lo relacionado con la propia
Usenet.
rec.* - (recreation) ocio.
sci.* - (scientific) ciencia.
soc.* - sociedad.
talk.* - grupos para charla.
misc.* - cualquier tema que no encajase en
alguna de las otras categoras.
Cada una de estas categoras principales fue
amplindose con multitud de subcategoras,
pero tambin se fueron creando con el tiempo
nuevas categoras principales, habiendo cientos
de ellas actualmente. La ms importante de
todas las categoras nuevas fue quiz la categora
alt.*, que englobaba todos los grupos
ALTernativos no creados dentro de las categoras
principales (y de la cual actualmente cuelgan
ms de 20 mil grupos), aunque tambin cabe
destacar la categora biz.*, dedicada a negocios,
y otras categoras que abarcan varios miles de
grupos, como free.* o microsoft.*. Adems,
se crearon diversas categoras nacionales: es.*
(Espaa), fr.* (Francia), etc.
Si entramos en el apartado GRUPOS de
www.google.com veremos un directorio
bastante extenso de los grupos de Usenet que
existen en la actualidad. En la pgina principal
slo se muestran las categoras principales,
pero puedes expandir la lista completa de
grupos para hacerte una idea de la cantidad
de grupos que existen.
Fig 1.- Jerarqua de grupos de Usenet.
En esta ilustracin distingo las categoras de
los grupos recuadrando a estos ltimos. Como
vemos en el ejemplo, de la categora es.*
cuelgan muchos grupos, como por ejemplo el
grupo es.test (grupo espaol para realizar
pruebas), pero tambin muchas subcategoras,
c omo por ej empl o l a c at egor a
es.humanidades.*. A su vez, de la categora
es.humanidades.* cuelgan, por ejemplo, los
gr upos es. humani dades. ar t e y
es.humanidades.literatura.
Entre los muchos grupos y las muchas
categoras que cuelgan de la categora principal
rec.*, encontramos como ejemplo curioso el
del grupo rec.humor que, adems de ser un
grupo, existe tambin una subcategora
(rec.humor.*) con el mismo nombre, de la
cual cuel gan por ejempl o l os grupos
rec.humor.funny y rec.humor.d (vete t a
saber qu ser este ltimo, porque el nombre
no es muy expl ci to que di gamos...).
Para acceder a Usenet basta con conectarse a
uno de los miles de servidores existentes
mediante el software adecuado (clientes de
correo con funciones para lectura de news, o
bien clientes especficos), que lo que hace
internamente es comunicarse con el servidor
de news, a travs del puerto TCP 119, mediante
el protocolo NNTP, que es precisamente el que
detallar en este artculo. Una vez conectados
a la red, solicitaremos al servidor una lista de
los grupos disponibles, y navegaremos por la
jerarqua para suscribirnos a aquellos que
nos interesen.
Desde el momento en que nos suscribimos a
un grupo, ya podremos consultar los artculos
especficos publicados en ese grupo y, si el
grupo est configurado para permitirlo, tambin
enviar nuestros propios artculos para que los
puedan ver el resto de usuarios suscritos a ese
grupo.
Fig 2.- Listado de grupos del servidor
news.mad.ttd.net, utilizando como
software Netscape Messenger, en la cual
nos acabamos de suscribir al grupo
talk.bizarre, para hablar de cosas
extraas...
Hay un dicho poular... !
Imagen B
Ahora aparecer una ventana donde nos preguntar el
nombre, podemos escribir lo que queramos, tu nombre real
(por ejemplo PEDRO) o un NICK (por ejemplo BIGBOY).
Nosotros pondremos MAXLINE.
Pulsaremos el botn siguiente y nos pedir una Cuenta de
Correo electrnico, podemos poner lo que queramos, por
ejemplo una que no exista, noexisto@losiento.com (es una
buena practica para evitar el correo basura). Pulsaremos el
botn siguiente y nos aparecer la tercera y ltima ventana
del asistente, donde se nos pide el Servidor de Noticias.
Imagen C
Esta es la ventana ms importante y deberemos poner el
Servidor de News que nos ofrece nuestro ISP (nuestro
Proveedor de Internet, por ejemplo Telefnica); si no
dispones de ese dato, llama a tu ISP y exige que te lo
proporcionen.
Configurando nuestro software para leer las NEWS y
buscando un Servidor de Noticias gratuito.
Como no podemos negar la realidad, seguro que la mayora
de lectores utilizan WINDOWS XP como sistema operativo.
Todo usuario del Sistema Operativo Windows tiene instalado
el programa Outlook Express (es parte del sistema operativo)
que sirve para enviar y recibir mails (gestor de correo
electrnico); pero muchos no saben que ese mismo programa
se utiliza tambin para acceder a USENET y leer las
news (gestor de grupos de noticias).
Antes de seguir, un apunte importante: Si alguien tiene
instalado el OFFICE y utiliza como gestor de correo
electrnico el Microsoft Outlook (incluido en el OFFICE),
que se olvide de acceder a las news. El Microsoft Outlook
no tiene gestor de news!!!
Por lo tanto debemos iniciar el Outlook Express (Menu
Inicio --> Todos los Programas --> Outlook Express) y una
vez abierto el programa crearemos una cuenta de noticias.
Para crearla iremos al Menu Herramientas --> Cuentas
Imagen A
Aparecer una ventana y del grupo de botones que hay a
la derecha pulsaremos sobre AGREGAR NOTICIAS.
2.2. Topologa de la red Usenet.
Pero el fondo de la cuestin es ahora: Cmo
se administra toda esta cantidad de grupos?
Cmo se consigue que en todos los servidores
de Usenet existan los mismos grupos con los
mismos artculos? Pues la respuesta es bien
sencilla: NO se consigue. :-)
En el artculo sobre DNS vimos cmo se
administraba este sistema, tambin jerrquico,
centralizando cada subdominio en una serie
de servidores dedicados a ello. En cambio, en
Usenet no hay ningn tipo de centralizacin,
as que todos los servidores pueden tener a
todos los grupos.
En la prctica, no hay ningn servidor que
tenga todos los grupos, ya que cada servidor
est configurado de una forma diferente, segn
los intereses de cada administrador (intereses
de una compaa, si es por ejemplo un servidor
perteneciente a un ISP, o bien intereses
personales, si es por ejemplo un servidor
perteneciente a un usuario particular como t
o como yo que ha deci di do ofrecer
altruistamente su propio PC como servidor para
toda la comunidad de Usenet).
Segn esta configuracin, cada servidor incluir
en su lista unos grupos u otros. Por ejemplo,
puede haber servidores censurados que no
incluyan en su lista ningn grupo relacionado
con sexo o violencia, o puede haber servidores
espaol es que sl o i ncl uyan grupos
internacionales o espaoles, pero no grupos
franceses, japoneses, o de otros pases, etc.,
etc.
El problema es que este tipo de filtrado de
grupos puede ser propagado a otros servidores
en contra de sus deseos. Por ejemplo, veamos
la siguiente ilustracin:
Fig 3.- Topologa simplificada de la red
Usenet.
En el ejemplo vemos una red simplificada que
consta tan slo de 6 servidores, aunque en
Aunque es recomendable utilizar el Servidor de News de
tu ISP, quizs te interese probar con servidores Gratuitos
(o Libres, segn se mire). Hoy en da es difcil encontrar
un Servidor de Noticias Gratuito y que permita a
cualquiera conectarse a ellos, nosotros utilizaremos el
Servidor de News dp-news.maxwell.syr.edu (que figura
en la imagen anterior y en la fecha de publicacin de esta
revista funciona perfectamente, aunque no te deja). Puedes
pr oba r c on c ua l qui e r ot r o de l a l i s t a
http://www.newzbot.com.
Una vez introducido pulsaremos el botn siguiente y en la
siguiente ventana pulsaremos el botn finalizar. Nos
encontraremos entonces frente a la ventana de la Imagen
B, donde pulsaremos sobre el botn CERRAR. Despus
nos preguntar si queremos descargar los Grupos de Noticias
a lo que responderemos que si. Si todo ha ido bien, se
descargarn los grupos de noticias y podrs suscribirte a
los que quieras.
Aqu te dejamos para que experimentes tu mismo o corremos
el riesgo de que en el foro nos machaquen a crticas por
explicar cosas tan sencillas. Si tienes dudas sobre el
funcionamiento del Outlook Express pregunta en el foro
de la revista (www.hackxcrack.com).
realidad Usenet consta de miles de servidores.
Como ejemplo, podis encontrar listas de
servidores en http://www.newzbot.com/.
En nuestra red ficticia existen dos tipos de
servidores: los servidores malignos, y los
servidores catlicos. Los servidores malignos
(sealados con un pequeo diablillo en la
ilustracin) no tienen ningn tipo de censura,
mientras que los servidores catlicos
(sealados con unos rombos en la ilustracin)
aborrecen los contenidos pornogrficos.
Supongamos que el administrador (Admin)
del servidor A, que es uno de los servidores
malignos, decide crear un grupo nuevo,
llamado alt.sex.aliens, para los usuarios que
desean tratar el apasionante tema de las
relaciones sexuales con seres de otros planetas
(aunque parezca mentira, este grupo existe
en realidad).
En un primer instante, el administrador crear
el grupo en la lista del servidor A.
A continuacin, en el instante 2, el nuevo grupo
se propagar a todos los servidores conectados
al servidor A, es decir: los servidores B, C, y
D.
El servidor B, uno de los malignos, incluye
el nuevo grupo en su lista, ya que no tiene
ningn filtro programado para no incluir ese
tipo de grupos. En cambio, tanto el servidor C
como el D pertenecen a los servidores
catlicos, y tienen programado un filtro que
impide la creacin de ningn grupo que
contenga palabras como sex.
En el tercer instante, el servidor B, el nico
que incluy el nuevo grupo en su lista, intentar
propagarlo hacia todos los servidores
conectados a l. Por supuesto, no intentar
propagarlo hacia el servidor A, a pesar de que
est conectado a l, ya que sabe que el servidor
A ya conoce el grupo, pues fue l mismo el
que le comunic que el grupo haba sido creado
(el cmo sabe exactamente el servidor B que
el servidor A ya conoce ese grupo es algo que
explicar ms adelante). A los que si que
intentar propagar el nuevo grupo es a los
servidores C y F.
El servidor C pasar del tema, porque ya conoca
la existencia del nuevo grupo gracias al servidor
A. En cambio, el servidor F no tena noticia de
la creacin del nuevo grupo, pero tampoco lo
incluir en su lista, ya que es uno de los
servidores catlicos, y su filtro encontrar la
temida palabra sex en el nombre del grupo.
Por tanto, los servidores C, D, y F han recibido
la noticia de que ha sido creado el grupo
alt.sex.aliens, pero ninguno de ellos lo ha
aadido a sus listas y, por los mismos motivos,
tampoco contribuirn a la propagacin de ese
nuevo grupo.
El pobrecito servidor E, que ha tenido la mala
suerte de estar conectado slo a servidores
catlicos (C, D, y F) jams se enterar de que
el nuevo grupo fue creado y, aunque a l le
habra interesado aadirlo a su lista, no podr
hacerlo.
As, cuando el pervertido de PyC se conecte a
su servidor E para contactar con alguna guapa
aliengena, encontrar sus intenciones frustradas
al no existir ningn grupo adecuado para el
tema.
Quiz ahora empezaremos a comprender por
qu cuando se buscan definiciones de Usenet
se encuentran multitud de respuestas vagas, y
de cuestiones casi metafsicas. Si este nuevo
grupo existe slo en unos servidores y no en
todos, se considera que ese grupo pertenece
a Usenet? Dnde estn los lmites? Usenet
abarca todos los grupos que existen en todos
los servidores, slo aquellos que estn en todos,
slo aquellos que existen en la mayora...?
Pero ste no es el nico problema, ya que lo
mismo que ocurre con la creacin de grupos
ocurre tambin incluso con los artculos que
se publican dentro de cada grupo. Cada servidor
puede tener sus propias reglas de filtrado para
censurar los contenidos que desee, o para
evitar el spam, o para evitar la saturacin del
servidor (prohibiendo el envo de archivos
binarios, que ocupan mucho ms que el texto),
o por cualquier otro motivo.
Al final, lo que resulta de todo esto es que
Usenet no es un concepto absoluto, si no
relativo, y es diferente segn el servidor que
usemos como punto de referenci a.
Pero an podemos rizar ms el rizo, e incluso
decir que la nica diferencia entre un servidor
y otro no es el nmero de grupos y de artculos
que hay en cada uno, si no incluso el orden
en que aparecen los artculos! Muchas veces
nos encontraremos con paradojas, como
respuestas a artculos que llegan antes que el
propio artculo original, o incluso respuestas a
artculos inexistentes. Todo esto se debe al
mecanismo de distribucin de los artculos,
que no es ni mucho menos pti mo.
Adems, para colmo, los artculos tienen una
caducidad dependiendo de los caprichos de
cada servidor. Por ejemplo, en un servidor
espaol podran seguir la poltica de mantener
los artculos de los grupos franceses slo durante
un da, y los espaoles conservarlos por una
semana. En cambio, en otro servidor que fuese
francs, la poltica podra ser justo la contraria.
Siguiendo con los aspectos de la arquitectura,
es importante tambin hablar de los servidores
esclavos. Un servidor NNTP esclavo no realiza
todas las funciones que realiza un servidor
normal, si no que acta slo como intermediario
entre la red Usenet y algn grupo concreto de
usuarios, por ejemplo los usuarios de una LAN
(red de rea local), o los clientes de un
determinado ISP.
Fig 4.- Esquema de conexin de un
servidor NNTP esclavo con la red Usenet.
El servidor esclavo poseer una amplia cache
para minimizar el nmero de accesos a la red
Usenet, por lo que el uso de servidores esclavos
para los distintos ISPs, LANs, o cualquier otra
comunidad, puede aligerar bastante la carga
de la red. Por este motivo, el RFC del protocolo
NNTP recomienda que se de cierta prioridad a
los servidores esclavos frente a los usuarios
normales. Ya veremos ms adelante algo ms
acerca de esto.
2.3. La sociedad de Usenet
Antes de entrar de lleno con el tema principal
del artculo (el protocolo NNTP), os comentar
algunos aspectos curiosos sobre este mundillo.
En cualquier FAQ sobre el tema tendris
explicaciones y divagaciones ms detalladas
sobre cualquier aspecto particular del mundo
como curiosidad que una traduccin al ingls
sera la palabra thread, que seguro que conocis
todos aquellos que utilicis habitualmente
cualquier tipo de foro, pues un thread es
precisamente eso: un hilo de conversacin.:-)
Por tanto, os aconsejo que evitis en la medida
de lo posible enviar un mismo mensaje a varios
grupos, ya que podis causar problemas y, sin
duda, mol estar al resto de usuari os.
En lo que respecta al spam, si el servidor limita
este tipo de mensajes dirigidos a varios grupos
simultneamente, los bots pueden saltarse esto
sencillamente por fuerza bruta, es decir, enviando
el mismo mensaje a cada grupo por separado.
En este caso, es bastante ms complicado
evitarlo, y la principal arma son ahora los filtros
que analicen los mensajes tratando de encontrar
algo sospechoso (remitentes indeseados,
palabras clave como enlarge your penis, o
cualquier otro tipo de filtrado inteligente).
Ya que he hablado de las conversaciones
cruzadas difciles de seguir a las que se llega
debido al crossposting, tambin hablar de
otras conversaciones indeseables, que son las
famosas flamewars. Si tratis de documentaros
acerca de Usenet por vuestra cuenta,
probablemente daris con trminos como
flamewar, o troll. Por cmo se utilizan estos
trminos en la documentacin que se suele
encontrar, quiz podis pensar que se trata de
trminos tcnicos probablemente relacionados
con alguna compleja tcnica utilizada por
hackers avanzados. Nada ms lejos de la
realidad, ya que una flamewar no es ms que
un hilo de conversacin molesto y que no lleva
a ninguna parte, ya que consiste simplemente
en un intercambio de insultos, o en un dilogo
de besugos. Se habla tanto acerca de las
flamewars por el simple hecho de que son
bast ant e f r ecuent es y engor r onan
consi derabl emente l os hi l os real mente
interesantes de los grupos.
de Usenet, as que slo os introducir un poco
el tema. Bsicamente lo que har ser advertiros
de algunas cuestiones que irritan bastante a
los usuarios honrados de Usenet, para evitaros
problemas si pensis incorporaros a esta
interesante comunidad.
En primer lugar, coment algo antes acerca
del spam. Como ya sabemos, el spam es esa
odiosa publicidad que no solicitamos pero que
nos llega una y otra vez impidindonos centrar
nuestra atencin en lo que realmente nos
interesa. Usenet no se libra del spam, ni mucho
menos, ya que existen bots que lo que hacen
simplemente es conectarse a los servidores
NNTP para enviar automticamente una serie
de mensajes a varios grupos.
La solucin ms sencilla para estos bots
spameadores sera enviar un nico mensaje,
e indicarle al servidor que publicase ese mismo
mensaje en tropecientos grupos que l
especificase. El problema que tienen los bots
con esto es que, en general, los servidores
NNTP no se lo pondrn tan fcil.
En efecto, se puede indicar a un servidor que
un mismo artculo sea publicado en ms de un
grupo simultneamente, pero en general los
servidores NNTP limitarn mucho esta
caracterstica, o incluso directamente la
inhabilitarn.
Al limitar la publicacin en mltiples grupos,
no slo estn combatiendo el spam, si no que
tambin estn evitando otro problema comn
en Usenet, que es el conoci do como
crossposting (publicacin cruzada). Cuando
un usuario empieza un tema de discusin
enviando un mismo artculo a varios canales,
y la gente se pica y empieza a publicar
respuestas al tema se puede montar un buen
jaleo, pues habr multitud de mensajes cruzados
entre varios grupos simultneamente, a los
cuales ser muy difcil seguirles el hilo. Ahora
que menciono la palabra hilo, os comento
Para aclarar el otro trmino, un troll es
simplemente lo que en cristiano podemos llamar
un tocanarices, es decir, un to que no tiene
nada mejor que hacer que pasar su tiempo
insultando a los usuarios de un grupo, o
planteando cuestiones irrelevantes slo por el
gusto de crear polmica. En este punto, no
todo el mundo est de acuerdo con la
terminologa, ya que algunos llaman troll a la
persona, mientras que otros llaman a la persona
troller, y troll a los mensajes indeseados que
stos publican en algn grupo. Si encontris
en un grupo un mensaje del tipo sois todos
unos lamers, sin duda habis dado con un
troll.
Por ltimo, antes de que os pongis a hacer
vuestras propias pruebas, os comento algunos
puntos ms. En primer lugar, si queris probar
la creacin de nuevos grupos, mejor que
desistis en el intento. Crear un grupo no es
sencillo, y adems necesitis el apoyo de otros
usuarios, por lo que os aconsejo que primero
os hagis bien con el funcionamiento de la red,
y luego os planteis de nuevo si realmente os
interesa crear un grupo nuevo (con la cantidad
de grupos que existen actualmente, parece
realmente difcil no encontrar al menos uno
que encaje en el tema que deseis tratar).
Con respecto a las pruebas que queris hacer
para publicar artculos, no lo hagis en cualquier
grupo! Existen grupos especficos para pruebas,
como por ejemplo: alt.test, misc.test, o
alt.binaries.test (este ltimo para pruebas
con archivos binarios).
Ya que hablo de los archivos binarios, es decir,
aquellos que no son texto puro (imgenes,
sonidos, programas, etc), os comento que el
tema tiene bastante miga. No se pueden enviar
archivos binarios a cualquier grupo, si no slo
a aquellos especficamente creados para ello
(generalmente, se encuentran en la categora
al t. bi nari es. *). Muchos servi dores
directamente no incluirn ninguno de estos
grupos, ya que aumentan considerablemente
la cantidad de recursos necesarios (espacio de
disco, y ancho de banda, principalmente).
Usenet es principalmente una red de intercambio
de artculos, entendidos estos como texto puro
y duro. Por supuesto, siempre podis utilizar
URLs para llevar al resto de usuarios a cualquier
otro tipo de contenidos (pginas web, ftp, etc).
Con respecto tambin al envo de artculos,
algunos grupos estn moderados, es decir,
cualquier artculo que se desee enviar pasar
previamente por un proceso de seleccin para
juzgar (bien por una persona, o bien por un
script) si conviene su publicacin.
3. USENET EN PROFUNDIDAD
Vamos a ver ahora en detalle cmo funciona
exactamente l a red Usenet. Empezar
comentando el sistema de distribucin de
artculos entre los servidores, para luego pasar
a detallar el protocolo NNTP y, por ltimo, hablar
acerca del formato de l os art cul os.
3. 1. Jugando a l os cromos
El sistema de distribucin de artculos y grupos
de Usenet es bastante parecido al juego de los
cromos al que todos hemos jugado de pequeos.
Primero uno mostraba sus cromos al otro, el
cual iba diciendo sile o nole, y luego el otro
haca lo mismo con los suyos.
Vamos a ver la interaccin entre dos servidores
NNTP, uno de l os cual es ser el que
ori gi nal mente querr cambi ar cromos
(receptor), y el otro el que los ofrece (emisor).
Estos son l os pasos que se segui rn
normalmente:
a) El receptor pregunta al emisor si ha incluido
en su lista grupos nuevos.
b) El emisor responde, dando la lista de
grupos nuevos.
c) El receptor, segn sus propios criterios,
decidir si incluir o no los grupos en su propia
lista.
d) El receptor pregunta al emisor si existen
nuevos artculos en los grupos que comparten.
e) El emisor responde con una lista de
artculos nuevos
f) El receptor solicitar al emisor aquellos
artculos que no tenga de la lista que le facilit
en el paso anterior.
g) El emisor transmite cada artculo solicitado
por el receptor. Los pasos f y g se repiten para
cada artculo que pueda interesar al receptor.
h) El receptor le facilita al emisor la lista de
artculos nuevos que tiene l, por si alguno le
interesa al emisor.
i) El emisor solicita al receptor aquellos
artculos que no tenga de la lista que le facilit
el receptor en el paso anterior.
j) El receptor transmite cada artculo solicitado
por el emisor. Los pasos i y j se repiten para
cada artculo que pueda interesar al emisor.
Fig 5.- Esquema del sistema de
distribucin de grupos y artculos entre
dos servidores NNTP.
Este es el sistema que aconseja utilizar el RFC
977, que trata sobre el protocolo NNTP.
En la prctica, es ms eficiente propagar los
nuevos grupos y artculos segn se van creando,
en lugar de esperar a que el resto de servidores
nos lo pidan, ya que todo funciona ms rpido
mientras los contenidos estn en la cache del
servidor, y no arrinconados en su disco duro.
Esto se har mediante unos mensajes de control
especiales que veremos ms adelante.
Hay que destacar el hecho de que no existen
comandos especficos de autenticacin ni de
identificacin de ningn tipo para que un servidor
distinga cuando se conecta un usuario de cuando
se conecta otro servidor, excepto para el caso
de servidores esclavos (tal y como veremos
ms adelante). Por tanto, la condicin de usuario
o de servidor se deduce implcitamente segn
los comandos que se ejecuten a lo largo de la
sesin (un usuario suele utilizar los comandos
para leer y publicar artculos, mientras que un
servidor suele utilizar los comandos de
distribucin de artculos).
Por otra parte, cualquier servidor NNTP debera
conocer las IPs de los dems servidores NNTP
que se puedan conectar a l, para as no dar
privilegios de servidor a un simple usuario que
pudiera tener malas intenciones.
3.2. El protocolo NNTP
Al fin nos centramos ya en el propio protocolo
RAW que, tal y como os acabo de comentar,
se encuentra especificado en el RFC 977
(ftp://ftp.rfc-editor.org/in-notes/rfc977.txt).
Ir mostrando una sesin de ejemplo paso a
paso, tal y como he hecho otras veces.
3.2.1. Conectando con el servidor.
Tenis ya preparados esos Telnets? Pues
vamos all!
telnet news.mad.ttd.net 119
Si sois chicos listos, habris deducido que el puerto
asignado al servicio NNTP es el 119. ;-)
Recuerda que en color verde tenemos las
ordenes de conexin (ejecucin del programa
Telnet y conexin a un Servidor Remoto), en
color rojo tenemos las respuestas del servidor
y en azul los comandos que nosotros le
enviamos al Servidor Remoto una vez nos
hemos conectado medi ante Tel net).
Al igual que en otros muchos protocolos, todas
las respuestas del servidor comienzan
siempre por un cdigo numrico de respuesta
de 3 dgitos.
Existen 5 tipos bsicos de respuestas:
- 1xx Las respuestas cuyo cdigo empieza
por 1 son de carcter informativo.
- 2xx Las que empiezan por 2 indican que
el comando se ha realizado con xito.
- 3xx Las que empiezan por 3 indican que el
comando es correcto y que podemos continuar
el proceso.
comando es correcto, pero que no se puede
ejecutar por algn motivo.
comando es incorrecto, no est implementado,
o que hay algn problema en el servidor.
Dentro de cada uno de los 5 tipos bsicos de
respuestas, existe a su vez otra clasificacin,
en funcin del segundo dgito:
- x0x Se refiere a cuestiones acerca de la
propia conexin o de la configuracin en
general.
- x1x Se refiere a cuestiones sobre los
grupos.
- x2x Se refiere a cuestiones acerca de los
artculos.
- x3x Se refi ere al mecani smo de
distribucin de art cul os y grupos.
- x4x Se refiere a la publicacin de artculos.
- x8x Se refiere a cualquier funcin propia
de un software especfico, que no forme parte
del estndar.
- x9x Reservado para funciones de
depuracin.
As, por ejemplo, una respuesta del tipo 11x
nos informar acerca del estado de nuestra
conexin, una respuesta del tipo 24x nos
indicar que la publicacin de un artculo ha
tenido xito, y una respuesta del tipo 58x nos
indicar que el software que corre en el servidor
no tiene implementado el comando no estndar
que se ha solicitado.
Todo esto lo cuento ahora porque, nada ms
conectar, el servidor nos enviar un cdigo de
respuesta que tpicamente (si todo va bien)
ser uno de estos dos:
-200 Servidor preparado.
IMPORTANTE: Servidores de News que no funcionan.
Usaremos este servidor (news.mad.ttd.net) para el ejemplo.
Si no te funcionase correctamente utiliza el servidor gratuito
mencionado al principio de este artculo (dp-
news.maxwell.syr.edu) y, por si acaso, tienes listas
de servidores en http://www.newzbot.com (srvete tu
mismo ;).
IMPORTANTE:
IMPORTANTE:
!
No sabes qu es TELNET? Malo, malo eso significa
que no has seguido nuestra revista :)
Hemos liberado muchos artculos en nuestra Web
(www.hackxcrack.com), si quieres empezar a trabajar con
Telnet nada mejor que descargarte el Artculo RAW 1 /
POP 3 del nmero 7 de PC PASO A PASO y pegarle un
vistazo.
Que lo disfrutes!!!
No sabes que ...
IMPORTANTE:
!
- 201 Servidor preparado, pero que sepas
que no puedes publicar artculos a travs de
este servidor.
En general, para nuestras pruebas nos servir
cualquiera de los dos tipos, pero cuando
lleguemos al punto de experimentar con las
funciones de publicacin de artculos (por
supuesto, si son pruebas, tendremos que
hacerlas en algn grupo destinado a ello, como
por ejemplo alt.test), necesitaremos un
servidor que nos responda con cdigo 200 al
conectar.
3.2.2. Ayuda, por favor!
Antes de hacer nada podemos pedir ayuda al
servidor, para que nos informe de los comandos
que tiene implementados, as como de su
formato:
HELP
El servidor normalmente nos responder con
una lista de comandos con sus parmetros, y
posiblemente referencias a informacin
complementaria o a alguna direccin para avisar
de posibles problemas.
Como vemos, el cdigo de respuesta ante el
comando HELP es 100, ya que se trata de
una respuesta informativa, y adems es
i nf or maci n general acer ca de l a
configuracin.
3.2.3. Listado de grupos
Lo primero que nos interesar ser ver la lista
de grupos que tiene el servidor. Para ello
ejecutamos el comando:
LIST
A lo cual el servidor nos responder con
tropecientas lneas, cada una de las cuales
tendr el formato:
grupo ltimo primero publicar
Donde grupo es el nombre del grupo al que
se refiere esa lnea, ltimo es el nmero
asignado dentro de ese grupo al ltimo artculo
publicado, primero es el nmero asignado al
primer artculo publicado (y que, por supuesto,
an no ha caducado y se conserva en la base
de datos del servidor), y publicar indica si en
ese grupo est permitido publicar artculos (y),
o si es de slo lectura (n).
Si ltimo es menor que primero (lo cual sera
absurdo) significa que no hay ningn artculo
en ese grupo.
3.2.4. Un poco de sadomaso
Si sois de los que os va la sumisin, podris
materializar vuestras fantasas a travs del
protocolo NNTP, ya que con el comando:
SLAVE
Informis al servidor NNTP de que quien se
conecta no es un usuario normal, ni otro servidor
NNTP normal, si no un servidor NNTP
esclavo.
Ya expliqu anteriormente en qu consiste un
servidor esclavo as que, como podis imaginar,
puede tener sus ventajas el identificarse como
esclavo, ya que el servidor podra darte prioridad.
Por supuesto, no es muy honrado hacerse pasar
por servidor esclavo slo por conseguir un poco
de prioridad, aunque eso lo dejo a la conciencia
de cada uno.
Si el servidor acepta la conexin de servidores
esclavos, responder con algo como esto:
202 slave status noted
No he hecho pruebas suficientes como para
hacer una estadstica, pero sospecho que
muchos servidores pasarn del tema, por lo
que no s hasta que punto puede ser til este
comando.
3.2.5. Hay grupos nuevos?
Tal y como hemos visto, el primer paso para
la distribucin de grupos y artculos entre los
servidores consiste en preguntar a otro servidor
si ha incluido recientemente grupos nuevos en
su lista.
Por supuesto, eso de recientemente es un
trmino muy subjetivo, y a las mquinas no
les va mucho eso de la subjetividad. Por tanto,
al preguntar a un servidor si tiene grupos
nuevos tenemos que indicarle tambin cmo
de nuevos han de ser para que nos interesen
(es decir, para que nos parezcan recientes).
Normalmente, indicaremos como parmetro el
momento (fecha y hora) en que hicimos la
ltima consulta del mismo tipo.
ste es un ejemplo del comando que pregunta
por los nuevos grupos:
NEWGROUPS 040110 133005
El primer parmetro es la fecha, en el
formato YYMMDD, es decir, los dos primeros
dgitos identifican el ao (os suena el famoso
problema del ao 2000 por representar aos
con slo 2 cifras?...), los dos siguientes el mes,
y los dos ltimos el da del mes.
En el ejemplo, la fecha especificada es el 10
de Enero del ao 2004.
El segundo parmetro es la hora, en el
formato HHMMSS, es decir, los dos primeros
dgitos identifican la hora (en formato 24h),
los dos siguientes el minuto, y los dos ltimos
los segundos. En el ejemplo, la hora
especificada es la una y media del medioda,
en el segundo 5 (13:3005).
El problema al usar este formato es que el
servidor podra estar en una franja horaria
distinta a la nuestra (por ejemplo, si conectamos
desde Espaa con un servidor de USA). Si
queremos garantizar que la referencia horaria
es la misma, podemos aadir el parmetro
GMT, que indica que la fecha y hora dadas son
con respecto al meridiano 0:
NEWGROUPS 040110 133005 GMT
Ante este comando, el servidor siempre nos
responder con un cdigo 231, tanto si hay
grupos nuevos como si no.
En general, en NNTP se suele indicar el final
de cualquier texto mediante una lnea que
contenga nicamente un punto. Por tanto, si
reci bi mos una respuesta como esta:
231 New newsgroups follow.
.
Significa que en el servidor no se ha creado
ningn grupo nuevo desde la fecha y hora
especificados.
Si recordamos lo que cont acerca de los cdigos
de respuesta, comprobamos que tiene sentido
que se asigne el cdigo 231 a esta respuesta,
ya que las respuestas 2xx corresponden a
comandos ejecutados con xito, y las
respuestas x3x se refieren a cuestiones acerca
del mecanismo de distribucin de artculos y
grupos entre servidores y, por supuesto, el
comando NEWGROUPS es uno de los utilizados
en la distribucin de grupos.
3.2.6. Hay artculos nuevos?
Como vimos, una vez que ve qu grupos nuevos
ha creado el servidor, cualquier servidor que
quiera continuar la distribucin a travs de otro
servidor solicitar a continuacin la lista de
artculos nuevos para aquellos grupos que le
interesen.
El formato del comando que permite esto es
parecido al del comando NEWGROUPS:
NEWNEWS alt.sex.aliens 040110 133005 GMT
Con esto solicitamos al servidor la lista de
artculos nuevos en el grupo alt.sex.aliens
publicados desde las 13:3005 GMT del 10 de
Enero del 2004.
Esto sera poco eficiente si tenemos que solicitar
de una en una las listas para todos los canales,
por lo que podemos utilizar como comodn el
asterisco (*):
NEWNEWS alt.sex.* 040110 133005 GMT
Este comando nos dar la lista de artculos
nuevos para todos los grupos que pertenezcan
a la categora alt.sex.*.
El servidor responder al comando
NEWNEWS con el cdigo 230, devolviendo
una lnea por cada mensaje nuevo. En cada
lnea habr una cadena extraa metida dentro
de los caracteres < >.
Esta cadena es lo que se llama Message-ID
(identificador de mensaje), e identifica
unvocamente un mensaje dentro de toda la
red Usenet.
Ms adelante veremos para qu nos pueden
servir los Message-ID.
3.2.7. Sile sile, nole nole...
Si queremos ensear nuestros cromos al
servidor, es decir, decirle qu mensajes tenemos
nosotros que potencialmente puedan interesar
al servidor porque no los tenga (en teora esto
ocurrira slo si nosotros fusemos otro servidor
NNTP) , ut i l i zar emos el comando:
IHAVE<132509143@u13. hackxcrack. com>
Ese parmetro tan raro que pasamos al
comando IHAVE es preci samente un
Message-ID.
Es i mposi bl e saber l o que representa
exactamente un Message-ID construido por
otro servidor, ya que cada uno utilizar su propia
heurstica para identificar unvocamente sus
propios mensajes. Por ejemplo, puede crear
una cadena que combine la fecha y hora de
creacin del mensaje, junto con un identificador
del usuario que lo escribi.
La heurstica de identificacin propia de cada
servidor ir siempre antes de la @, ya que
despus de esta vendr siempre el propio
nombre de la mquina dentro de su dominio.
Tras un comando IHAVE, el servidor juzgar
si le interesa o no ese mensaje.
Si le interesa, responder con un cdigo 335,
tras lo cual tendremos que enviar el cuerpo del
mensaje (segn el formato que veremos en el
punto 3.3), terminando con una lnea que
contenga un nico punto.
No lo he probado, pero se me ocurre que el
comando IHAVE podra servir para sabotear
los artculos publicados por otros usuarios. Si
conocemos el Message-ID del artculo que
queremos sabotear, y sabemos que el artculo
an no ha llegado a todos los servidores,
podramos conectarnos a los servidores que
an no tienen el artculo, decirles que tenemos
un artculo con ese Message-ID, enviar un
artculo falso y as, cuando llegue el autntico
artculo, el servidor creer que ya lo tiene y,
por tanto, lo rechazar.
Probablemente, esto ser difcil de conseguir,
ya que un servidor NNTP bien configurado
debera conocer bien las IPs de los servidores
NNTP conectados a l, y slo permitir la
ejecucin de estos comandos a los que sabe
con certeza que son servidores.
3.2.8. Solicitando un artculo nuevo
Cuando nos interese algn artculo de la lista
que nos proporcion el servidor, lo solicitaremos
con el comando:
ARTICLE <27358342@n1.news.lco.es>
Donde el parmetro es el Message-ID
correspondiente a ese artculo.
Con esto terminamos los comandos que
describen la interaccin tpica entre dos
servidores NNTP para la distribucin de grupos
y artculos. A continuacin veremos otros
comandos (o variaciones de los ya vistos), que
son los que suele utilizar un usuario normal al
conectar con un servidor NNTP.
3.2.9. Seleccionando un grupo
Lo ms habitual es que un usuario trabaje en
cada momento con un nico grupo. Por ejemplo,
lo tpico ser visualizar seguidos todos los
mensajes nuevos de un mismo grupo que nos
interesen, luego quiz publicar un artculo en
ese mismo grupo, etc. Para indicar al servidor
el grupo con el que vas a trabajar:
GROUP alt.sex.aliens
A lo cual el servidor nos responder con un
cdigo 411 si el grupo no existe, o bien con
algo como esto:
211 20 3 21 alt.sex.aliens
Donde el cdigo 211 nos indica que el comando
ha sido ejecutado con xito, y a partir de ahora
nuestro grupo de trabajo ser alt.sex.aliens
(indicado como ltimo parmetro). Adems,
nos da como primer parmetro el nmero
total de artculos en ese grupo (20), el
nmero correspondiente al primer artculo
que hay en el servidor para ese grupo (3), y
el nmero del ltimo artculo (21).
3.2.10. Cmo ver un artculo?
Si no somos un servidor, si no un usuario normal,
probablemente no habremos utilizado el
comando NEWNEWS, por l o que no
conoceremos el Message-ID correspondiente a
cada mensaje del grupo que estamos leyendo.
Por tanto, no podramos utilizar el comando
ARTICLE en la forma que lo hemos visto.
Por suerte, el comando ARTICLE permite que
se le pase como parmetro, en lugar de un
Message-ID, el nmero asignado a ese artculo
dentro del grupo. Por ejemplo, para ver el
mensaje 3 del grupo que acabamos de
sel ecci onar con el comando GROUP
(alt.sex.aliens), haremos:
ARTICLE 3
El servidor podr darnos cualquiera de estas
respuestas:
- 220 Nos da el Message-ID del artculo
para futuras referencias y, a continuacin, nos
transmite el mensaje completo.
- 221 - Nos da el Message-ID pero, a
continuacin, slo nos transmite la cabecera
del mensaje. El cuerpo del mensaje podremos
solicitarlo a continuacin, tal y como explicar
ms tarde.
- 222 Nos da el Message-ID pero, a
continuacin, slo nos transmite el cuerpo del
mensaje sin cabecera. La cabecera podremos
solicitarla a continuacin, tal y como explicar
ms tarde.
- 223 Slo nos da el Message-ID. Si, a
continuacin, queremos que nos transmita el
mensaje completo, podremos utilizar el comando
ARTICLE <message-id> o, si slo nos
interesa una de las dos partes del mensaje
(cabecera o cuerpo) podremos utilizar los
comandos que expl i car ms tarde.
- 412 Indica que no hay ningn grupo
seleccionado, debido a que no utilizamos
previamente un comando GROUP, por lo que
el servidor no sabe a qu artculo nos estamos
refiriendo.
- 423 Nos dice que no existe artculo
asignado al nmero especificado como
parmetro (3) en el grupo seleccionado.
- 430 Nos dice que no existe ese artculo.
3.2.11. Cmo ver la cabecera de
un artculo?
El comando HEAD tiene exactamente el mismo
formato que el comando ARTICLE, pero slo
nos muestra la cabecera de un mensaje, y no
e l me n s a j e c o mp l e t o . A s :
HEAD <Message-ID>
Nos mostrar la cabecera de un determinado
mensaje. Mientras que:
GROUP alt.sex.aliens
HEAD 3
Nos mostrar la cabecera del tercer mensaje
del grupo alt.sex.aliens.
3.2.12. Cmo ver el cuerpo de un
mensaje?
Lo mismo ocurre con el comando BODY que,
en lugar de la cabecera, nos muestra slo el
cuerpo del artculo. Ya veremos en el punto
3.3 el formato de los artculos en detalle.
3.2.13. El puntero de artculo
Todo este sistema para recorrer los artculos
en realidad no es muy prctico en muchas
ocasiones.
Por ejemplo, cuando hace varios das que no
visitamos Usenet y conectamos con nuestro
cliente de news para descargar todos los
artculos que hayan sido publicados en nuestro
grupo favorito esos das, lo que sin duda har
internamente nuestro cliente es solicitar al
servidor las cabeceras de todos los artculos
secuencialmente. Al tener las cabeceras (con
el comando HEAD), podr mostrarnos de un
vistazo algunos datos bsicos, como el asunto
o el remitente del mensaje. Una vez que
tenemos la lista de cabeceras simplificadas ya
podemos escoger aquellos artculos que
queremos ir leyendo.
Para facilitar esta lectura secuencial de artculos,
existen una serie de comandos (y variaciones
de los que hemos visto hasta ahora) que
permiten moverse por los artculos de forma
relativa, y no absoluta. Es decir, podemos fijar
un puntero que seale a un artculo en concreto,
y a partir de ah ir dicindole tan slo al servidor:
rlame el siguiente!
Fig 6.- Recorriendo una lista de artculos
mediante el puntero.
Vamos a ver cmo se consigue todo esto en
los siguientes puntos.
3.2.14. Fijando la posicin inicial
del puntero
Lo primero que habr que hacer para recorrer
una lista de artculos mediante un puntero ser
fijar el puntero en su posicin inicial.
Hay varias formas de hacer esto. Por ejemplo,
cuando utilizamos el comando ARTICLE, no
slo estamos visualizando un artculo, si no
que adems estamos inicializando el puntero
para que apunte a ese artculo. El comando
cuya nica funcin es fijar el puntero es:
STAT 3
Donde el parmetro es el nmero de artculo
dentro del grupo. Por tanto, antes de un
STAT siempre tendremos que haber ejecutado
un GROUP, tanto para seleccionar el grupo,
como para saber cul es el primer artculo del
grupo.
Fig 7.- Estado del puntero
tras ejecutar STAT 3.
Ojo! Que hay que tener dos
cosas en cuenta. En primer
lugar, que el comando STAT
slo modifica el puntero de
art cul o si se usa como
parmetro el nmero de artculo
dentro del grupo, tal y como
hemos hecho aqu, pero no si
se utiliza como parmetro un Message-ID (tal
y como dice en el RFC, no sirve para nada
usar STAT con Message-ID, aunque no debera
dar ningn error). En segundo lugar, hay que
tener siempre en mente que los comandos
ARTICLE, HEAD, y BODY tambin modifican
el puntero de artculo, siempre que sean usados
con nmeros de artculo en lugar de con
Message-ID. Por tanto, si queremos tener
controlado el puntero de artculo, tendremos
que tener mucho ojo a la hora de usar estos
comandos.
Ahora que tenemos el puntero fijado en el
artculo 3, cmo podemos ver el artculo sin
modificar el puntero y sin tener que usar un
Message-ID (en cuyo caso todo esto no tendra
ningn sentido)? Pues utilizando la ltima
variante de los verstiles comandos ARTICLE,
HEAD, y BODY:
ARTICLE
Escribiendo ARTICLE a secas visualizamos el
artculo que est en estos momentos sealado
por el puntero.
HEAD
Con esto visualizaramos slo la cabecera del
artculo que est en estos momentos sealado
por el puntero. Os dejo como gran ejercicio
mental que deduzcis que har un comando
BODY si no le pasas ningn parmetro. ;-)
3.2.15. Siguiente!
Pos ale, ya hemos visto el primer artculo, y
queremos ver el siguiente de la lista:
NEXT
As de sencillo. Con esto hemos fijado el puntero
en la siguiente posicin dentro de la lista de
artculos del grupo en el que estamos trabajando.
Si estbamos ya en el ltimo artculo y no existe
un siguiente, el servidor nos responder con
un error 421. Si no, nos responder con un
cdigo 223, indicndonos adems el Message-
ID del artculo al que apunta ahora el puntero.
despus de ejecutar un
NEXT.
3.2.16. Vuelta atrs
Tambin tenemos la
posibilidad de avanzar hacia
atrs en lugar de hacia alante:
LAST
En este caso la respuesta de error ser el cdigo
422 en caso de que estuvisemos ya en el
primer artculo y no hubiese uno previo.
despus de ejecutar un
LAST.
3.2.17. Publicando un
artculo
Para el final hemos dejado la
que es sin duda una de las
funciones ms importantes,
que es la publicacin de
nuestros propios artculos.
Hay que tener en cuenta antes de nada que
puede haber varios motivos por los cuales no
nos est permi ti do publ i car art cul os.
En primer lugar, al conectar con el servidor
ste nos tuvo que saludar con un cdigo 200,
porque si lo hizo con un cdigo 201 ya sabemos
que podremos hacer cualquier cosa excepto
publ i car nuestros propi os art cul os.
En segundo lugar, al ver la lista de grupos
(comando LIST) el ltimo parmetro que nos
mostraba el servidor para cada grupo nos
indicaba precisamente si tenemos permiso para
publ i car en ese grupo (y) o no (n).
En tercer lugar, el servidor podra rechazar
nuestros artculos por otros motivos justo
en el momento en que nos disponemos
a publicarlo.
La nica forma de comprobar esto es
preci samente i ntentando publ i carl o:
POST
Con esto indicamos al servidor que queremos
publicar un artculo en el grupo con el que
estamos trabajando (el cual indicamos
previamente con un comando GROUP), aunque
en la cabecera del artculo ser donde
indiquemos finalmente sobre qu grupo o
grupos queremos que se publique el artculo,
como veremos ms adelante.
Si al servidor le mola, nos responder con un
cdigo 340, invitndonos a que enviemos a
continuacin el artculo (recordemos que los
cdigos 3xx nos informan de que un comando
ha sido ejecutado con xito, y el servidor espera
por tanto a que se complete un proceso con el
prximo paso).
Si al servidor no le mola que publiquemos
artculos en ese grupo, nos responder en
cambio con un cdigo 440, y ya no habr ms
que hacer.
Por tanto, despus del POST, si recibimos un
cdigo 340 simplemente tenemos que enviar
el artculo completo, con cabecera y cuerpo,
siguiendo el formato que explicar ahora
mismito. :-)
3.2.18. Adis!
El ltimo comando que falta por contar es el:
QUIT
Para los que no tengis demasiada imaginacin
os explico que es el comando que sirve para
terminar la sesin y cerrar la conexin con el
servidor. :-P
3.3. Formato de los artculos
Como hemos ido viendo a lo largo del texto,
un artculo se compone bsicamente de dos
partes: cabecera y cuerpo. No es sta la
nica coincidencia con los mensajes de correo
electrnico (tal y como vimos en los artculos
sobre POP3 y, sobre todo, sobre SMTP), si no
que adems las cabeceras guardan tambin
muchas similitudes.
La especificacin completa del formato de los
artculos de Usenet se encuentra en el RFC
1036 (aunque el RFC 977 se refiere
constantemente al RFC 850, en realidad el
RFC 1036 ha sustituido a este).
3.3.1. Cabecera del artculo
Las lneas de cabecera dan una serie de datos
imprescindibles, o no, acerca del artculo.
Existen una serie de lneas de cabecera que
son obligatorias en todos los artculos, y
son: From, Date, Newsgroups, Subject,
Message-ID, y Path.
Como cabeceras opcionales tenemos:
Followup-To, Expires, Reply-To, Sender,
References, Control, Distribution,
Keywords, Summary, Approved, Lines,
Xref, y Organization.
Explicar a continuacin cada una de las lneas
de cabecera obligatorias, y algunas de las
opcionales.
3.3.1.1. From:
Especifica una direccin de correo electrnico
que es (supuestamente) la del remitente.
Permite incluir tambin el nombre completo
del remitente. Podemos usar uno de estos 3
formatos admitidos:
From: PyC@LCo.es
From: PyC@LCo.es (Pepito Lopez)
From: Pepito Lopez <PyC@LCo.es>
El primer formato especifica slo la direccin
de correo, mientras que los otros dos especifican
adems el nombre completo.
Si tenis imaginacin y habis seguido el resto
de la serie RAW, probablemente se os habr
ocurrido probar a poner una direccin de correo
falsa en el From. ;-)
3.3.1.2. Date:
Al igual que en el caso del correo electrnico,
las cabeceras de NNTP siguen el estndar
MIME, as que hay que utilizar un formato de
fechas admitido por este estndar. Si, por
ejemplo, queremos especificar el 21 de
Noviembre del ao 2003, a las 13:3005 segn
el meridiano 0 (GMT):
Date: Fri, 21 Nov 03 13:30:05 GMT
3.3.1.3. Newsgroups:
Indica el grupo de destino en el que queremos
publicar el mensaje:
Newsgroups: alt.sex.aliens
Si queremos iniciar un crossposting, enviando
el mensaje a varios grupos, podemos separarlos
por comas:
Newsgroups:
alt.sex.aliens,alt.sex.ganimedes,alt.sex.
kripton
3.3.1.4. Subject:
Al igual que en un mensaje de correo electrnico,
es un texto que especifica el asunto del mensaje.
En caso de que sea respuesta a otro mensaje
debera empezar con el prefijo Re:, aunque
no es obligatorio. Lo que si que ser obligatorio
en este caso es incluir la lnea de cabecera
opcional References, tal y como veremos ms
adelante.
3.3.1.5. Message-ID:
Ya hemos visto antes en qu consista un
Message-ID. Siempre hemos de encuadrarlos
entre los caracteres < y >.
3.3.1.6. Path:
Esta lnea es bastante interesante, ya que ayuda
mucho a mejorar el rendimiento en la
distribucin de artculos. Cada vez que un
artculo pasa por un servidor, ste aade su
nombre en esta lnea. As, cuando un servidor
A solicite la lista de artculos nuevos a un
servidor B, y ste vea que en el Path de
un artculo se encuentra el nombre del
servidor A, el servidor B sabr entonces
que A conoce ya ese artculo, por lo que se
ahorrar incluir ese artculo en la lista que
facilitar al servidor A.
En el Path cada servidor va aadiendo su
nombre, separndolo de los dems con un
signo !:
Path:
news.hackxcrack.com!n133.Lco.es!@ns
s.mad.ttd.es
Si el servidor news.hackxcrack.com solicitase
artculos nuevos a otro servidor, ste no incluira
en su lista de artculos nuevos aquellos que
tuviesen un Path como este, en el que se
encuentra ya el servidor news.hackxcrack.com.
Un servidor malicioso podra sabotear la
distribucin de artculos hacia un servidor si
incluyese en el Path de los artculos que recibe
la direccin del servidor al que quiere sabotear,
aparte de la suya propia.
3.3.1.7. Followup-To:
Para comentar algunas de las cabeceras
opcionales (el artculo sera demasiado extenso
si comentase todas), empezar por esta, ya
que es interesante por su relacin con algunos
aspectos que hemos visto a lo largo del artculo.
En concreto, puede ser til para evitar el
crossposting.
Si tenemos, por ejemplo, un artculo que incluye
e s t a s dos l ne a s de c a be c e r a :
Newsgroups:
alt.sex.aliens,alt.sex.ganimedes,alt.sex.kripton
Followup-To: alt.sex.aliens
Este artculo se habr publicado en los grupos
alt.sex.aliens, alt.sex.ganimedes, y
alt.sex.kripton pero, en cambio, las respuestas
a ese artculo sern publicadas slo en el grupo
especificado en la lnea Followup-To, es decir,
en alt.sex.aliens.
Esta es la forma correcta de publicar un artculo
cuando es realmente necesario hacerlo en varios
grupos, ya que no se generar un crossposting,
pues todas las respuestas quedarn en un nico
grupo.
Por supuesto, en los artculos construidos de
este modo es conveniente indicar en el texto
del mensaje que aquellas personas que quieran
seguir el hilo de este artculo debern hacerlo
en el grupo alt.sex.aliens, ya que la mayora
de la gente no suele ojear las cabeceras antes
de responder a un artculo. ;-)
3.3.1.8. References:
Cuando el artculo sea respuesta a otro artculo,
deber estar presente esta lnea, que contendr
como parmetro el Message-ID del artculo
original del cual es respuesta.
3.3.1.9. Control:
Esta lnea de cabecera se usa para una serie
de artculos especiales que contienen
comandos de control para los servidores NNTP.
Los mensajes de control permiten varias
funciones, como cancelar la distribucin de un
artculo previamente publicado, avisar a otro
servidor de la creacin o destruccin de un
grupo, etc.
Como ya dije cuando habl del mecanismo de
distribucin de grupos y artculos, es ms
eficiente avisar de la creacin de grupos nuevos
segn van apareciendo, en lugar de esperar a
que nos pregunten por ellos. La forma de
conseguirlo es mediante los comandos de
control.
La especificacin detallada de estos comandos
de control la podis encontrar en el RFC 1036,
ya que el espacio para el artculo se me est
acabando ya. :-(
3. 3. 2. Cuerpo del art cul o
Por ltimo, acerca el cuerpo del artculo slo
he de mencionar un par de cosas.
En primer lugar, como en NNTP para indicar
el fin de un texto se utiliza una lnea con un
nico punto, si queremos, por algn extrao
motivo, que nuestro texto incluya una lnea
con un punto, tendremos que poner dos
puntos en lugar de uno. Es decir, un texto
como este:
.. .

---
Ser interpretado como:
. .

---
(Se supone que es una cara). Ya que siempre
que hay dos puntos al comienzo de una lnea
se contraen en uno solo, para distinguirlo del
punto simple que finalizara el cuerpo del
mensaje.
Como ltimo comentario, si queremos incluir
archi vos bi nari os t endremos que
documentarnos ms, ya que hay que codificarlos
mediante uuencode siguiendo el estndar
MIME, y todo esto se sale con mucho de lo
que puede abarcar el artculo. :-(
4. RESUMIENDO
Creo que es necesario hacer una sesin
completa de ejemplo, porque ahora mismo
debis de tener miles de ideas flotando en la
cabeza, pero nada concreto.
As que aqu os pongo una sesin completa de
ejemplo, y os voy comentando cada paso (los
comentarios irn en color negro). El servidor
al que nos conectaremos ser nsnmrro2-
lo.nuria.telefonica-data.net
Os dejo ya con esto, y espero veros el prximo
mes no slo con un artculo, si no con dos! :-
O Tenis curiosidad? Pues esperad al prximo
mes, para ver de qu estoy hablando. ;-)
telnet nsnmrro2-lo.nuria.telefonica-
data.net 119 (Nos conectamos al servidor)
200 nsnmrro2-lo.nuria.telefonica-data.net
InterNetNews NNRP server INN 2.3.2
ready (posting ok). El servidor nos saluda
con cdigo 200, por lo que podemos utilizar
este servi dor para publ i car art cul os.
GROUP alt.sex.aliens Seleccionamos este
grupo para trabajar con l
211 77 14766 14847 alt.sex.aliens El
servidor nos informa de que el grupo
seleccionado ser a partir de ahora nuestro
grupo de trabajo. En el servidor hay 77 mensajes
almacenados en ese grupo, que van desde el
nmero 14766 hasta el nmero 14847,
HEAD 14840 Queremos ver la cabecera del
artculo 14840 del grupo alt.sex.aliens.
221 14840
<607b02db.0401071042.3f62ccf4@pos
ting.google.com> head La primera lnea de
la respuesta al comando HEAD nos dice que
nos va a mostrar lo que pedimos (cdigo 211),
que el nmero del artculo que va a mostrar es
el 14840, y nos dice adems el Message-ID de
ese artculo.
Path: nsnmrro2-lo.nuria.telefonica-
data.net!nsnmrro1-lo.nuria.telefonica-
data.ne
t!in.100proofnews.com!in.100proofnew
s . c o m! h e r me s . v i s i . c o m! n e ws -
out.visi.com!petb
e.visi.com!newsfeed2.dallas1.level3.ne
t!news.level3.com!postnews1.google.c
om!not
-for-mail En esta lnea vemos los servidores
por los que ha circulado este artculo (al menos
hasta donde sabe ste servidor), para evitar
que sea distribuido una y otra vez a los mismos
servidores.
From: gaxa7a5@yahoo.com (gaxa7a5)
Aqu tenemos el remitente del artculo.
Newsgroups:
alt.sex.algore.lick.the.wet.toad,vegas.p
ersonals.fsm,alt.sex.algore.
little.wooden.boy,alt.sex.aliens,alt.sex.
alt.syntax.tactical Como vemos, este artculo
fue enviado a varios grupos, y no slo a ste.
Esto ya va dando que pensar bastante... A ver
si va a tratarse de spam...
Subject: HOW I GOT A 9 INCHES PENIS...
READ MY STORY! / 01.07.2004 10:48
/ Creo que por el asunto del mensaje queda
ya patente que se trata de spam, a no ser
que... y si contactando con algn alien ha
conseguido este hombre aumentar su virilidad
y quiere compartir su experiencia con el resto
de la comunidad?
Date: 7 Jan 2004 10:42:34 0800 Fecha
de publicacin segn el formato MIME.
Organization: http://groups.google.com
Lnea de cabecera opcional que normalmente
da informacin acerca de la organizacin a la
que pertenece el remitente. En este caso, ha
sido Google quien ha aadido la lnea, indicando
que el artculo fue enviado a travs de Google.
Lines: 17 Otra lnea opcional, que indica el
nmero de lneas que hay en el cuerpo del
artculo.
Message-ID:
<607b02db.0401071042.3f62ccf4@pos
ting.google.com> Esto ya no es opcional, ya
que es el identificador de mensaje de este
artculo. Vemos de nuevo que el artculo ha
sido enviado a travs de Google.
NNTP-Posting-Host: 209.115.59.183 Otra
lnea opcional que nos da la IP desde la que se
public el artculo. :-O
Content-Type: text/plain; charset=ISO-
8859-1 Horror! Ya estamos otra vez con el
MIME. Acaso no lo sospechbais? Como ya os
dije, los artculos de Usenet siguen el estndar
MIME, por lo que las lneas de cabecera
opcionales incluyen muchas de las lneas del
estndar MIME. Os recuerdo que esta lnea
informa acerca del formato del texto que se
encuentra en el cuerpo del art cul o.
Content-Transfer-Encoding: 8bit Cuando
se trate de texto puro, a veces lo podremos
encontrar codi fi cado en sl o 7 bi ts.
X-Trace: posting.google.com 1073500955
17623 127.0.0.1 (7 Jan 2004 18:42:35
GMT) Lnea opcional que permite seguir el
rastro a la publicacin del artculo. En este caso
la cosa queda bastante clara con las lneas
anteriores.
X - C o mp l a i n t s - T o : g r o u p s -
abuse@google.com Mira tu por donde, que
esta lnea nos puede ser til, ya que nos informa
de dnde debemos acudir en caso de que
detectemos que el remitente ha abusado de
los servicios ofrecidos por Google. Como en
este caso se trata de spam, si tuvisemos mala
leche podramos notificarlo en esta direccin
aunque, sinceramente, dudo que sirviese para
nada. :-)
NNTP-Posting-Date: Wed, 7 Jan 2004
18:42:35 +0000 (UTC) Aqu me han pillado...
para qu servir esta lnea opcional, si la lnea
obligatoria Date ya informa de la fecha de
publicacin? :-m
Xref: nsnmrro2-lo.nuria.telefonica-data.net
alt.sex.algore.lick.the.wet.toad:380
5 v e g a s . p e r s o n a l s . f s m: 2 3 5
alt.sex.algore.little.wooden.boy:8075
alt.sex.aliens:1
4840 alt.sex.alt.syntax.tactical:13133 En
primer lugar nos da la direccin del servidor
al que estamos conectados, para luego decirnos
el estado de este artculo en la base de datos
de ste servidor. Ya sabemos que el artculo
es el 14840 del grupo alt.sex.aliens, pero esta
lnea nos dice que este artculo se encuentra
tambin en otros grupos (como ya sabemos,
gracias a la lnea Newsgroups), y nos dice el
nmero de artculo que ocupa dentro de cada
uno de esos otros grupos. Esto permitir a
nuestro cliente identificar este artculo aunque
estemos en otros grupos, para marcarlo como
ya ledo y evitarnos releer el mismo spam una
y otra vez en todos los grupos. Por ejemplo,
este artculo es el nmero 3805 del grupo
alt.sex.algore.lick.the.wet.toad.
. Esta lnea que contiene slo un punto finaliza
la transmisin de la cabecera que habamos
solicitado. Si en lugar de HEAD hubiramos
utilizado el comando ARTICLE, aqu habra una
lnea en blanco, despus el cuerpo del mensaje
y, por ltimo, una lnea como sta que slo
tuviese un punto.
NEXT Movemos el puntero al siguiente artculo,
es decir, al 14841.
223 14841
<7a196ddb.0401071956.4ce763e4@po
sting.google.com> Article retrieved;
request text separately. El servidor nos dice
que el puntero se sita ahora en el artculo
14841 del grupo en el que estamos, tal y como
habamos pedido. Nos da, adems el Message-
ID del artculo.
BODY Esta vez vamos a pedir el cuerpo del
artculo 14841.
222 14841
<7a196ddb.0401071956.4ce763e4@po
sting.google.com> body Nos da el Message-
ID del artculo, para mostrarnos su cuerpo a
continuacin.
FAT DUMPY EXWIFE FOUND TAKING
DUSTBATH ON MARS. AMAZIINGLY THE
PHOTO
ONLY SHOWED PORTIOS BUT IT WAS
VERY FIGHTENING TO SEE. El artculo
nos cuenta la apasionante historia de una gorda
haciendo cochinadas en Marte.
. La lnea con el punto termina el texto.
QUIT Con lo de la gorda en Marte ya hemos
tenido suficiente por hoy...
205 . Usease: Hasta luego!
Autor: PyC (LCo)
Ilustraciones: Adhara (LCo)
SERIE RAW:
CONOCIMIENTO EN
ESTADO PURO
1.- QU ES NETBIOS?
Por dnde empiezo? Tengo 10 pginas para
explicar qu es, cmo funciona y algn mtodo
de "penetracin" buffff, es una lastima que
esta revista no tenga ms pginas, porque hay
mucho que explicar, bueno, empecemos
Hacemos un rpido viaje en el tiempo y nos
vamos a 1984. IBM disea un sistema
"application programming interface" (API) para
conectar en red sus computadoras y lo llam
Network Basic Input/Output System (NetBIOS).
Esta API era un sencillisimo sistema para
permitir a un pc conectarse con otro para poder
intercambiar datos. Pero en aquella poca,
hacer que una mquina "hable" con otra
totalmente distinta era difcil (los ordenadores
no eran muy stndares que digamos), por lo
que en 1995, IBM "invent" un "protocolo de
transporte", es decir, unas "normas" que, si
todos los PCs cumplan, permita que unos
hablasen con otros. Este protocolo unido a la
API dio lugar a lo que se llam NetBIOS
Extended User Interface (NetBEUI). Venga, no
te duermas, que la clase de historia ya se
acaba ;)
Hasta ahora hemos visto el "mundillo" de las
Ips en los nmeros anteriores, bien, pues el
NetBEUI funciona de forma parecida pero en
lugar de utilizar Ips utiliza NOMBRES.
Imagina una habitacin en la ms absoluta
oscuridad con una mesa en el centro y 10 sillas
alrededor con una persona sentada en cada
silla, imagina que tienen que empezar a debatir
sobre algn tema importante pero los
interlocutores no se conocen y no pueden
verse ummm hay un problema, cuando
alguien hable no sers capaz de "identificarlo",
y si dos personas tienen una voz parecida, ya
ni te cuento. Como tu eres el moderador y eres
muy listo, les dices que al inicio de cada
intervencin deben pronunciar su nombre, de
esta forma todos sabemos quin est hablando
en cada momento. Muy bien, pues eso es lo
que hace esa cosa que hemos llamado NetBEUI,
establ ecer unas normas de conducta.
Imagina ahora que se aade una silla ms y
una persona entra en la sala (Inicio de sesin).
Segn el protocolo (el NetBEUI), esa persona
debe presentarse al resto de miembros diciendo
su nombre y tomar asiento, pero no todo es
tan sencillo, imagina que el nuevo "tertuliano"
se llama Juan y ya haba otra persona llamada
Juan sentada en la mesa. CONFLICTO!!!
Recuerda que la habitacin est a oscuras, si
hay dos personas con el mismo nombre no
podremos distinguirlas correctamente, por lo
tanto se le deniega el acceso (inicio de sesin)
y se le "invita" (obliga) a cambiar de nombre
o adios muy buenas.
Todo eso ocurre cuando un ordenador quiere
entrar a formar parte del resto de la "red"
(resto de tertulianos) en un sistema NetBEUI,
el PC que quiere meterse en la red debe dar
un nombre y ese nombre no puede ser repetido
en una misma red.
Este protocolo (NetBEUI) empez ser muy
utilizado por las aplicaciones de red y por
NETBIOS: ESTUDIO Y
PENETRACION DE SISTEMAS
PARTE I: TOMA DE CONTACTO E INTRUSIN
aquella reliquia llamada Windows para Grupos
(alguien la recuerda? ;)). En aquella poca el
NetBEUI competa con el IPX de Novell, otro
protocolo del que no hablaremos porque este
mes "no toca", y como siempre ocurre, se
crearon las implementaciones de NetBEUI para
IPX, es decir, que las mquinas basadas en
NetBEUI finalmente podan "relacionarse" con
las redes IPX. Y a todo esto, paralelamente,
nos encontramos con los protocolos elejidos
para Internet: TCP/IP. Pues lo mismo, en poco
tiempo salieron implementaciones del NetBEUI
para que pudiese "hablar" con redes basadas
en TCP/IP.
- Muy interesante, pero por qu me explicas
todo eso, yo lo que quiero es estudiar esos
procesos de "penetracin" que
NO!!!, lo primero es lo primero, es necesaria
una pequea "toma de contacto" antes de
lanzarte a la conquista de Internet, recuerda
que solo el conocimiento te hace libre ;P
Si gamos ah, si ahora tenemos un
problema!!! El TCP/IP funciona a base de Ips
(ya lo explicamos en anteriores nmeros) y el
NetBEUI funciona a base de nombres (si, si,
nombres tan sencillos como Carlos, PC5 o
PCPRINCIPAL), as que en 1987 (si no me falla
la memoria) el IETF (Internet Engineering Task
Force) public los RFC 1001 y 1002 (RFC son
documentos donde se detalla prcticamente
todo lo relacionado con la tecnologa de la que
se sirve Internet: protocolos, recomendaciones,
comunicaciones...). Muy bien, pues esos
documentos son en los que se basan
actualmente tanto Microsoft con su "Compartir
Impresoras y Archivos para redes Microsoft)
como Linux con su SAMBA, tanto uno como
otro son la evolucin del NetBEUI, llamada
posteriormente NETBIOS SOBRE TCP/IP y se
utilizan para montar mesas (sesiones) con
tertulianos (PCs) deseosos de compartir
informacin ;) repartidos por cualquier rincn
de Internet.
Venga, que ya acabo!!! El NETBIOS SOBRE
TCP/IP es conocido como NBT (como le gusta
a los "genios" machacarnos a los pobres
mortales con siglas y mas siglas es increible)
y se basa en tres servicios: Un servicio de
nombres y dos servivios de comunicaciones
(datagramas y sesiones). El primero, el servicio
de nombres, resuelve (implementa) la relacin
NOMBRE-IP, es decir, gestiona la relacin entre
un NOMBRE y su IP. Los otros dos se utilizan
para gestionar la transmisin de datos.
- Ya has acabado?
Bueno, porque el director me ha dicho que
debo ser breve, que si no, escribo 50
folios sobre todo esto venga, si, ya he
terminado :)
Resumen...
!
2.- El NETBIOS en nuestro
Windows.
Ahora, para ver "de cerca" eso del NETBIOS,
nos vamos a nuestras conexiones de red,
APRENDIENDO NETBIOS APRENDIENDO NETBIOS APRENDIENDO NETBIOS
Resumen/Detalles importantes: El NETBIOS es un
protocolo/servicio que te permite compartir recursos entre
ordenadores (como por ejemplo tus discos duros). Este
servicio est a la escucha en los puertos 137, 138 y 139
(esto de los puertos ya sabes como funciona de otros
nmeros)
nos metemos en las Propiedades del Protocolo
Internet TCP/IP
nos metemos en las Propiedades del Protocolo
Internet TCP/IP
podrs ver que puedes gestionar si deseas
Netbios (o no) en tu Windows XP.
El mes que viene...
!
3.- Escaneando mquinas con
NETBIOS :)
Bueno, vamos a empezar a divertirnos :)
Lo primero que necesitamos es un escaneador
de IPs que apunte a los puertos 137, 138 y
139, los puertos que utiliza NETBIOS. Como no
tenemos ni nguna v cti ma en mente,
escanearemos Internet buscando mquinas con
esos puertos abiertos mediante el software IP-
TOOLS (lo encontrars en http://www.ks-soft.net
o en nuestra Web www.hackxcrack.com). Una
vez descargado, lo instalamos, ejecutamos y
nos encontraremos con esto:
El mes que viene explicaremos la forma de configurar el
sistema para dejar proteger un poco yu sistema de los
ataques por NETBIOS y lo explicaremos para cada sistema
Windows. Las imgenes ateriores son de Windows XP.
Nos vamos al Menu Tools --> NB Scanner (si,
si, eso que vimos en la clase de historia ;)
Ahora introducimos un rango de Ips. Arriba,
donde pone From Addr, pondremos la IP inicial
del rango que queremos escanear y en To Addr
la IP final. Un da de estos explicaremos algunas
"cositas interesantes" sobre la seleccin de
rangos para escanear, pero por ahora nos
conformaremos con introducir un rango al azar,
por ejemplo del 194.85.173.0 al 194.85.173.255
y pulsaremos START (el hombrecito verde).
Veremos como el programa empieza a trabajar
y no tardar mucho en encontrar una IP-
VCTIMA, en este caso la 194.85.173.100 :)
Fjate bien en la cantidad de informacin que
nos da el programa de la IP 194.85.173.100:
- Host: aud131a.karelia.ru --> El nombre del
dominio, que nada tiene que ver con el nombre
de NETBIOS. En el nmero 1 de PC PASO A
PASO (Los cuadernos de Hack x Crack)
encontrars qu es eso de los nombres de
dominio, lo tienes GRATIS para descargar en
www.hackxcrack.com.
- Status: OS NT WORKSTATION 5 (el sistema
operativo de la vctima)
- Resource: los elementos "compartidos"
- Type: tipo de elemento (si es una impresora,
un disco duro )
- Etc.
4.-Estudiando a la vctima:
Una vez encontrada una posible vctima, vamos
a i ntentar presentarnos y para eso
necesitaremos el LANGUARD NETWORK
SCANNER, programa que encontrars en
nuest ra Web (www. hackxcrack. com)
Pues venga, lo descargamos, ejecutamos y nos
encontraremos frente a esto
Puedes utilizar...
!
Puedes utilizar cualquier scanner, simplemente tienes que
configurarlo para buscar los puertos 137, 138 y 139 abiertos.
Nosotros hemos utilizado el IP-TOOLS porque es una
herramienta muy interesante que creemos deberas probar
je, je es una especie de todo en uno ;)
Para introducir la IP-VICTIMA nos vamos al
Menu File --> New Scan, seleccionamos Scan
One Computer y la introducimos.
Pul samos FINISH y vol veremos a l a
ventana pri nci pal del programa, pues
venga, empi eza l a fi esta, pul sa el
botn de PLAY (est arriba a la
i zqui erda). Obtendremos un montn
de datos, sera realmente interesante
expl i car cada uno de el l os pero no
hay ms espacio, quizs en el prximo
nmero, me i nteresa ms que una
vez dentro practi ques l os comandos
que te detal l amos al fi nal de este
artculo ;)
Ahora, arriba a la izquierda, pon el mouse
sobre la ip, pulsa con el botn derecho del
Mouse y en el Menu contextual selecciona
Gather Information, esto nos ofrecer ms
informacin de la "victima", por ejemplo el
usuario, discos duros compartidos, etc.
Pgina 42
Ahora, si la vctima fuese un Windows
9X en lugar de un Windows 2000 y
pusi esemos el mouse sobre l a IP y
abriesemos el menu contaxtual (botn
derecho del mouse), un poco ms
debajo de la opcin Gather Information
estar a "i l umi nada" l a opci n Crack
Password, con l o que obtendr amos
directamente el password de la vctima,
as de fcil. :)
Como esto en un Wi ndows 2000,
pues no podemos hacer eso, por
lo que tendramos que utilizar un diccionario
de claves (est en el mismo menu) o
utilizar una tcnica de "null connect"
que no explicaremos hoy. Despus del
uno va el dos, y estamos en el
primer artculo de NETBIOS, antes
de enfrentarte a un Wi ndows 2000
tendrs que "trastear" un poco con
mqui nas Wi ndows 9X y con l os
comandos que hay al fi nal de este
artculo :)
5.- Entrando en la vctima:
Si est uvi esemos ant e un Wi ndows
9X ya tendramos la clave y procederamos
a l a entrada al si stema y eso es l o
que vamos a expl i car ahora, pero
antes te "rel ato" cmo averi gua el
LANGUARD NETWORK SCANNER
la tan apreciada clave.
Sobre cmo...
!
- Entrando a lo lamer y sin aprender nada:
Una vez crackeado el pasword con el
LANGUARD, simplemente haz un doble click
sobre la IP y tendrs a tu disposicin las
unidades disponibles, as de simple :)
- Entrando y aprendiendo, como debe ser:
* Abrimos una Ventana de Comandos
* Introducimos el comando net use
x:\\xxx.xxx.xxx.xxx\c$ /user:yyyyyy (y pulsamos
enter)
Sobre cmo el LANGUARD NETWORK SCANNER
averigua la clave en un Windows9X: Pues es muy sencillo,
de verdad, je, je Imagina que tienes un hermano pequeo
(como de 10 aos) un poco tonto, le dices que piense en
una palabra y le aseguras que TU averiguars esa palabra.
Tu hermano se rie de ti y piensa en una palabra, por ejemplo
ABCK
Tu, que eres muy listo, en lugar de empezar a soltar posibles
palabras (diccionario de claves) le preguntas a tu hermano
si la primera letra es una A, a lo que responde que si (ya
tenemos la primera letra). Le preguntas si la segunda letra
es una A y te dice que no, le preguntas si la segunda letra
es una B y te dice que si (ya tenemos AB). Ahora haces lo
mismo para la tercera (sigues el abecedario) y cuando le
preguntas si es una C te dice que si (ya tenemos ABC). De
nuevo le preguntas por la cuarta letra recorriendo el
abecedario y cuando llegues a la K te responder
afirmativamente. Se acab, ya tienes la palabra (clave):
ABCK. Tu hermano, sorprendidisimo te mirar y adorar
por el resto de tus das, je, je :)
Hemos dicho que tu hermano tena que ser un poco tonto
para no darse cuenta de que le ests sacando la palabra de
una forma tan tonta, pues en este caso, tu hermano pequeo
es Microsoft con su Windows 9X ;), as es como el
LANGUARD averigua la clave de la vctima: preguntando
letra a letra.
ASUSTADO?!!! Piensas ahora en las horas que has
pasado INDEFENSO conectado con tu Windows 9X?
Bueno, dale las gracias a Bill Gates ;p. A ver si en el
prximo nmero te enseamos cmo configurar tu equipo
para defenderte de esto, que este mes no hay espacio.
!
* Ahora nos preguntaran el password,
pues nada, lo introducimos.
* Finalmente, te vas a MI PC y te
encontrars con un nuevo "disco duro"
(recurso) l l amado vi cti ma1 ;p
* Se acab, entra en esa nueva unidad
y utilizala como si fuese parte
de tu PC ;)
6.- IDEAS/ADVERTENCIAS/NO
SEAS MALO:
Puedes imaginarte la de cosas malas
que puedes hacer, por ejemplo subir
unos cuantos programitas y un win.ini
modificado que haga referencia a unos
cuantos programas para que sean
ejecutados al en cada inicio del sistema
y ya seguiremos otro da con esto, que
estamos preparando un artculo al
respecto :)
DESCARGA EL NUMERO
UNO DE HACK X CRACK
(PC PASO A PASO) GRATIS
EN NUESTRA WEB
WWW.HACKXCRACK.COM
Explicacin de la linea use x:\\xxx.xxx.xxx.xxx\c$
/user:yyyyyy
- net use: Te ensea informacin sobre las conexiones o te
conecta/desconecta de un recurso compartido.
- x: es el nombre que le asignaremos en nuestro equipo al
recurso que intentas acceder. Imagina que intentas acceder
al un recurso compartipo de la vctima llamado disco4,
pues en tu equipo aparecer un nuevo "recurso" llamado
x (puedes poner el nombre que quieras)
- xxx.xxx.xxx.xxx: la IP de la vctima
- c$: sera la/el unidad/recurso compartida/o por la vctima.
- /user:yyyyyy --> El usuario
Un ejemplo de intrusin una vez crackeado el password
sera:
Net use victima1:\\xxx.xxx.xxx.xxx\c$ /user:manolito
Explicacin...

Serie Raw NXC Protocolos y Servicios TCP-UDP

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Serie Raw NXC Protocolos y Servicios TCP-UDP

Hochgeladen von

Copyright:

Verfügbare Formate

Pgina 16 PC PASO A PASO N 11

Das könnte Ihnen auch gefallen