(*) El envenenamiento DNS no es algo nuevo, ya en el 2002/2003 había quien hablaba sobre eso en algún que otro ezine aunque no recuerdo el grupo, aunque el URL estuvo como topic en el canal #hackers y/o #networking del IRC Hispano.

Entonces, ¿Como puedo confiar que estoy escribiendo en la web de Hackindex y no en otra web?. Cualquiera con los conocimientos suficientes podría hacer una réplica de hackindex para capturar contraseñas. ¿Sintomas?, “ohh, vaya, la cookie ha caducado, tendré que iniciar sesión de nuevo”.

Una forma de evitarlo, podría ser con un certificado digital y el url pasaría a ser de tipo “https://“.

Pero, imaginense la siguiente situación: ¿Qué pasaría si nos creyéramos más listos que el hambre y dijéramos “Vamos a crear nuestra propia entidad certificadora“?. Respuesta: Que todo aquel que entrara en nuestra web recibiría de propina un mensaje del navegador “Certificado no conocido” y dándole la opción de “Confiar sólo para esta sesión”, “Confiar para siempre” y “no confiar” si se trata de Mozilla.

Ahora bien, si puede ser posible hacer un envenenamiento DNS, ¿por qué no podría ser posible hacer un envenenamiento DNS del servidor que aloja el emisor de certificados digitales?. Si hacemos click en “confiar para siempre” y suponiendo que se tratara del autentico hackindex ya tendríamos la llave pública de hackindex cacheada en mi navegador (*2) y en el momento en el que alguien usurpara hackindex mi navegador “cantaría” el error. Pero todos aquellos que entraran por primera vez, serían engañados.

(*2) Suposición. Tengo que comprobar si efectivamente es así. Si alguien lo sabe con certeza por favor que diga algo.

Es decir, en mi opinión lo mejor sería siempre utilizar una entidad certificadora conocida y de prestigio. En caso contrario, podríamos tener una situación de tipo “pescadilla que se muerde la cola”.

Supongamos por un momento, que mi carné de identidad ha caducado y necesito renovarlo. Por lo tanto voy a la web “https://www.citapreviadnie.es/” donde puedo pedir cita para renovar el carné de identidad. En esa web me pedirán datos personales y por ese motivo utilizan una conexión cifrada, pero cual es mi sorpresa de que usan su propio emisor de certificados.

Como mi navegador no conoce esa entidad certificadora, aparece la ventana afirmando tal hecho. Si examino el certificado digital, observo que el emisor se llama “DIRECCION GENERAL DE LA POLICIA” que efectivamente está listado por el ministerio de industria (http://www.mityc.es/DGDSI/Servicios/FirmaElectronica/Prestadores/) como un prestador valido de servicios de certificación. Pero realmente … ¿puedo fiarme?

La posibilidad de disponer de una extensa base de datos con la que comerciar es algo muy goloso para diversas mafias y la posibilidad de que sin darme cuenta esté entregando mis datos personales a una mafia está siempre latente.

En esta URL (http://www.mozilla.org/projects/security/certs/included/) hay una lista de certificados que por defecto vienen incluidos en Mozilla. Mi opinión es que los navegadores que se distribuyan en España, sea Mozilla, Explorer, Konqueror, etc, también deberían incluir por defecto los certificados listados por el ministerio de industria de esta forma se evitaría la situación de la pescadilla.

Saludos.

Aviso: Esta entrada tiene un error de concepto, ver el primer comentario.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

La información incluída en este documento es expuesta en base a un interés educativo. HackIndex no se hace responsable del uso de dicha información.

El siguiente documento es propiedad de HackIndex y de su autor, pudiendo ser distribuído de forma totalmente libre y sobre cualquier tipo de soporte siempre y cuando se respete el formato original, se cite a A.H.E. como fuente, se incluya un enlace actualizado al documento o a la web del grupo: http://www.hackindex.org ; y se incluya este disclaimer en su totalidad y sin modificación alguna.

Queda extrictamente prohibida su distribución con fines lucrativos, cuando se altere su contenido sin consentimiento o cuando se incumpla cualquier otra condicion citada anteriormente en el presente disclaimer.
#####################################

CURSO PRACTICO DE HACKING–2a entrega

Queridos compañeros (exploradores y novatos con ganas de aprender):

Como os  prometi aqui teneis el  segundo capitulo del  CPH, que espero
que  pueda serviros  a abrir  la  brecha del  estudio autodidacta  con
algunos  consejillos y  notas.  Antes de  comenzar  con este  capitulo
quiero recalcar que el objetivo de este “seminario” de hacking intenta
ilustrar los modos de conseguir introducirnos en una maquina unix cuya
seguridad ha sido comprometida,  generalmente por una mala gestion del
administrador,  que muchas  veces pasa  olimpicamente del  sistema que
debe cuidar  como Cancerbero.  En ningun caso  he querido  arrastrar a
nadie  al empleo de  este conocimiento  para oscuros  propositos, sino
para impulsar  a los estudiantes novatos  a llevar los  sistemas a sus
ultimas  posibilidades  y  no  como  meros  usuarios  finales.Asi  que
=A1abstenerse los lamers!

En este sentido, ha salido este  mes en la revista @rroba un excelente
articulo de  Carlos Sanchez Almeida  titulado “Hackers de  plastico” y
aunque corto  merece la pena que lo  leais. Al igual que  a finales de
los setenta se  acuñaba el termino “punkies de  plastico” para señalar
que debajo de la mascarada de tachuelas y cuero, aquellos punkies eran
tan burgueses como sus papis, los hackers de plastico son aquellos que
se  han erigido  como arquetipo  de la  revolucion moderna:  el hacker
televisivo, cruce de Neo y el  padre Apeles. Pero ya sabeis: con lo de
hacker  ocurre  lo   mismo  que  con  quienes  se   dicen  rosacruz  o
sufi…Ciertamente no lo son. Un  hacker de verdad “jamas se colocaria
un piercing para aparentar: lo  unico que agujerean es el sistema”. El
hacking es un camino duro y dificil, “que implica muchas renuncias. La
primera y  la mas  importante es la  que diferencia  verdaderamente al
hacker del lamer: la renuncia al ego…”

Y  ahora vamos  con nuestro  asunto. Antes  de entrar  de lleno  en el
capitulo 2 quiero aclarar algo  a los estudiantes del primer capitulo:
Las  utilidades whois, traceroute,  host, ping  y nslookup  las debeis
tener  en cualquier  sistema linux  que  monteis. Las  podeis usar  en
consola  o en un  xterm. Algunas  como traceroute  hay que  usarlas en
ciertas distros linux como root, pero en otras no. Evidentemente antes
habreis de conectaros y si  sois novatillos el paquete kppp de KDE
se parece  muchisimo al procedimiento  de conexion telefonica  a redes
del Windoze. Una  vez conectados podeis abrir xterms  en el escritorio
KDE o pasaros  con Alt-Ctrl-Fx a una consola  (Volvereis al escritorio
con  Alt-Ctrl-F7).  Otras  utilidades   teneis  que  buscarlas  en  la
red.  Para ello  basta con  www.altavista.com y  www.alltheweb.com que
contiene un buscador FAST FTP y  WEB y una dosis minima de ingenio. De
todos modos os dire donde podeis descargar las herramientas:

-fping en www.stanford.edu/~schemers/docs/fping/fping.html
-nmap en www.insecure.org/nmap/
-netcat en www.l0pht.com/~weld/netcat/
-queso en ftp.connect.net/pub/security/trinux/netmap/

Espero que continueis en la brecha

Saludos,

LECTER

CPH. CAPITULO 2. EXTRACCION DE INFORMACION CRITICA DEL OBJETIVO

En este  capitulo nos vamos a  centrar en la  obtencion de informacion
critica  que  luego  podra  ser  explotada para  introducirnos  en  el
sistema. La informacion critica se basa siempre en algun compromiso en
la  seguridad  de  un  servicio,  un  bug  (fallo)  de  algun  comando
relacionado con los servicios, etc. Para este capitulo me he basado en
un   libro  muy   util   que  acaba   de   salir  al   mercado:Hacking
exposed;network  security secrets  and solutions,  de  Stuart McClure,
George Kutz y otro mas (ya esta en español).

1)Informacion  critica obtenida  mediante “transferencia  de  zona” de
servidores DNS  mal configurados.   Algunas veces nos  encontramos con
servidores  DNS   configurados  de   manera  insegura  y   que  pueden
permitirnos entrar  en la  llamada zona de  transferencia de  DNS, aun
siendo  usuarios  de   internet  no  autorizados.  Podemos  intentarlo
utilizando la instruccion nslookup en modo interactivo:

$>nslookup

=2E..a continuacion aparecera el servidor  DNS por defecto que sera el
de  nuestro ISP  u organizacion…pero  como queremos  consultar otro,
X.X.X.X  (uno que corresponda  a nuestro  objetivo, como  obtuvimos al
hacer whois transmeta.com) escribiremos

>server X.X.X.X

a lo que respondera aceptandolo como “default”. A continuacion hacemos

>set type=3Dany
>ls -d objetivo.net.>> fichero

Lo  que hemos hecho  es definir  el tipo  de registro  como cualquiera
(any)   con    lo   que   podemos   recuperar    los   registros   DNS
disponibles.  Luego  los  listamos  y  redirigimos  a  “fichero”  para
consultarlo mas adelante.  Si ha habido suertecilla, cosa que dudo, al
leer “fichero”, encontrariais  diversas entradas con varios registros,
p.ej:

acct22   1D IN A       192.168.230.3
         1D IN HINFO   “Gateway 2000″ “Win WKGRPS”
         1D IN MX      0 acmeadmin-smtp
         ………………………………….

El registro A indica la  direccion IP de esta cuenta, HINFO identifica
la plataforma o  el sistema operativo y MX nos  dice donde se gestiona
el correo.  Existen mas  registros, pero no  los voy a  comentar. Esta
informacion es  muy valiosa  porque nos da  de golpe  conocimiento del
sistema operativo y gestor de correo (aparte de mucho mas). Existe una
utilidad algo  dificililla de encontrar  buscando a las bravas  por la
red, que nos permite realizar transferencias de zona (cuando se puede)
y transferir  de manera  recursiva informacion de  la zona  y archivos
huespedes de cada uno de  los dominios consultados. Tal herramienta es
“axfr”         que        la        podeis         encontrar        en
ftp=2Econnectnet.com/pub/security/trinux/netmap/axfr-0.5.2.tar.gz. Una
vez instalado, hacemos como root

#>axfr objetivo.net
y saldran algunos mensajes
axfr: Using default directory /root/axfrdb
Found X.X.X.X name server for domain ‘objetivo.net’
text deleted
Received xxxx answers

Ya esta. Para consultar la base de datos basta con que hagais

#>axfrcat objetivo.net

Pero como ya he dicho, no sera tan tordo el administrador de dejar mal
configurado el servidor DNS.

2. =BFProtege algun cortafuegos nuestro objetivo?

Vamos unicamente  a comprobar si existe algun  cortafuegos que proteja
nuestro  objetivo.  La  manera   de  saltarse  el  cortafuegos  ya  la
consideraremos  en   las  tecnicas  de  ataque,   pues  ahora  estamos
extrayendo  informacion  critica  solamente.  Recordando  la  utilidad
nmap, podemos  usarla para descubrir cortafuegos.  Cuando nmap explora
un host, no solamente dice si los puertos estan abiertos, sino tambien
si estan “filtrados”. Un puerto filtrado  en nmap indica que o bien no
se  recibio ningun  paquete SYN/ACK  o RST/ACK  o bien  se  recibio un
mensaje  ICMP  de destino  inalcanzable  con  codigo 13  (Cominicacion
prohibida por  el administrador).  Otra utilidad interesante  es hping
(www.kyuzz.org/antirez). Una vez instalada, hacemos como root

#>hping objetivo.com -S -p (n=BA de puerto)

De este modo se envian paquetes  TCP SYN al puerto destino y obtenemos
informacion de los  paquetes que regresan. Si el  flag de respuesta es
SA (SYN/ACK) quiere  decir que el puerto destino  esta abierto y listo
para  recibir  conexion.  A   veces  nos  sale  como  respuesta  “ICMP
unreachable type 13 from X.X.X.X” lo  que nos indica que X.X.X.X es el
cortafuegos del objetivo.  No obstante si el resultado  de hping no da
respuesta alguna puede ser que o bien el paquete se haya perdido en la
red o  que el cortafuegos lo  detenga. Si obtenemos  una respuesta con
flag  RA (RST/ACK)  puede ser  que  el cortafuegos  haya rechazado  el
paquete o  puede que lo  haya dejado pasar  por el puerto pero  que el
host objetivo no  esta escuchando. Vamos a intentar  ilustrarlo con un
ejemplo.  Mi host  objetivo es  la pagina  web del  Centro Informatico
Cientifico de  Andalucia, www.cica.es. Voy  antes que nada a  hacer un
traceroute

$>traceroute www.cica.es
Â
 1  SEVI-X13.red.retevision.es (62.81.56.45)  134.694 ms  139.73 ms  139.866 ms
 2  SEVI-R3.red.retevision.es (62.81.56.27)  139.931 ms  120.489 ms SEVI-R1.red.retevision.es (62.81.56.28)  129.317 ms
 3  SEVI-R15.red.retevision.es (62.81.55.229)  139.938 ms  129.841 ms  119.956 ms
 4  BARC-R16.red.retevision.es (62.81.125.3)  170.034 ms  149.872 ms  149=2E948 ms
 5  ReteNAC.red.retevision.es (62.81.63.202)  139.926 ms  169.764 ms  159=2E934 ms
 6  EspaNIX.red.retevision.es (62.81.8.146)  179.967 ms  179.872 ms  169.909 ms
 7  ibernet.espanix.net (193.149.1.57)  170.042 ms  159.813 ms  149.953 ms
 8  194.179.0.113 (194.179.0.113)  179.942 ms  159.778 ms  159.919 ms
 9  A0-2-4.EB-Madrid00.red.rediris.es (130.206.224.77)  159.959 ms  199.853 ms  169.892 ms
10  A1-0-1.EB-Sevilla1.red.rediris.es (130.206.224.10)  189.936 ms  189.926 ms  179.875 ms
11  130.206.194.10 (130.206.194.10)  179.931 ms  169.96 ms  169.856 ms
12  argantonio.cica.es (150.214.5.77)  189.97 ms *  180.02 ms

 Muy  bien,   el  host  130.206.194.10  parece  ser   un  enrutador  o
cortafuegos que dirige  el trafico a argantonio.cica.es (www.cica.es).
Ahora voy a utilizar la  herramienta nmap para hacer una evaluacion de
la  topologia  de  una  subred.  Voy  a  escanear  por  el  puerto  80
silenciosamente todas las  maquinas de la subred C  a la que pertenece
www.cica.es:

#>nmap -sS -p80 www.cica.es

# Nmap (V. nmap) scan initiated 2.53 as: nmap -sS -p80 -o cica www.cica.es/24
The 1 scanned port on  (150.214.5.0) is: closed
The 1 scanned port on  (150.214.5.1) is: closed
Interesting ports on www.ceseand.cica.es (150.214.5.2):
Port       State       Service
80/tcp     open        http                   

Interesting ports on scsasnt.sas.cica.es (150.214.5.3):
Port       State       Service
80/tcp     open        http                   

Interesting ports on prometeo.cica.es (150.214.5.4):
Port       State       Service
80/tcp     open        http                   

Interesting ports on cdaea.cica.es (150.214.5.6):
Port       State       Service
80/tcp     open        http                   

Interesting ports on caf.cica.es (150.214.5.7):
Port       State       Service
80/tcp     open        http                   

Interesting ports on microbio.cica.es (150.214.5.8):
Port       State       Service
80/tcp     open        http                   

Interesting ports on www.csalud.junta-andalucia.es (150.214.5.9):
Port       State       Service
80/tcp     open        http                   

Interesting ports on thales.cica.es (150.214.5.10):
Port       State       Service
80/tcp     open        http                   

The 1 scanned port on mileto.cica.es (150.214.5.11) is: closed
Interesting ports on www.tresculturas.org (150.214.5.12):
Port       State       Service
80/tcp     open        http                   

Interesting ports on cdma.cica.es (150.214.5.13):
Port       State       Service
80/tcp     open        http                   

Host   (150.214.5.31) seems to be a subnet broadcast address (returned 1 extra pings).  Still scanning it due to positive ping response from its own IP.
The 1 scanned port on  (150.214.5.31) is: closed
Host   (150.214.5.48) seems to be a subnet broadcast address (returned 1 extra pings).  Skipping host.
The 1 scanned port on osni.cica.es (150.214.5.49) is: closed
The 1 scanned port on io.cica.es (150.214.5.50) is: closed
The 1 scanned port on iat-gw.cica.es (150.214.5.51) is: closed
Host   (150.214.5.55) seems to be a subnet broadcast address (returned 1 extra pings).  Still scanning it due to positive ping response from its own IP.
The 1 scanned port on  (150.214.5.55) is: closed
Host   (150.214.5.64) seems to be a subnet broadcast address (returned 1 extra pings).  Skipping host.
The 1 scanned port on  (150.214.5.65) is: closed
The 1 scanned port on winbdd.cica.es (150.214.5.66) is: closed
The 1 scanned port on mercurio.cica.es (150.214.5.67) is: closed
The 1 scanned port on winbdd2.cica.es (150.214.5.68) is: closed
Interesting ports on orgiva.cica.es (150.214.5.69):
Port       State       Service
80/tcp     open        http                   

The 1 scanned port on cache.cica.es (150.214.5.70) is: closed
The 1 scanned port on ntp.cica.es (150.214.5.71) is: closed
Interesting ports on patro.cica.es (150.214.5.72):
Port       State       Service
80/tcp     open        http                   

The 1 scanned port on horacio.cica.es (150.214.5.73) is: closed
Interesting ports on argantonio.cica.es (150.214.5.77):
Port       State       Service
80/tcp     open        http                   

Interesting ports on ligustino.cica.es (150.214.5.78):
Port       State       Service
80/tcp     open        http                   

Interesting ports on listas.cica.es (150.214.5.79):
Port       State       Service
80/tcp     open        http                   

The 1 scanned port on idefix.cica.es (150.214.5.85) is: closed
The 1 scanned port on lejia-s.cica.es (150.214.5.126) is: closed
Host   (150.214.5.127) seems to be a subnet broadcast address (returned 1 extra pings).  Still scanning it due to positive ping response from its own IP.
The 1 scanned port on  (150.214.5.127) is: closed
# Nmap run completed at Mon Aug  7 00:56:51 2000 — 256 IP addresses (33 hosts up) scanned in 31 seconds

Bueno, bueno…ahora si hago un traceroute a cada uno de los hosts que
han  sido  escaneados,  obtengo  que  en  todos  los  casos,  el  host
130.206.194.10 les apunta,  con lo cual podemos asegurar  que se trata
de un router/firewall frontera.
Â
Voy a escanear www.cica.es con nmap pero a todos los puertos:

# Nmap (V. nmap) scan initiated 2.53 as: nmap -vv -sS -O -P0  www.cica.es
Interesting ports on argantonio.cica.es (150.214.5.77):
(The 1508 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                   Â
22/tcp     open        ssh                   Â
23/tcp     open        telnet                Â
80/tcp     open        http                  Â
119/tcp    filtered    nntp                  Â
123/tcp    filtered    ntp                   Â
389/tcp    open        ldap                  Â
390/tcp    open        uis                   Â
443/tcp    open        https                 Â
512/tcp    open        exec                  Â
513/tcp    open        login                 Â
514/tcp    open        shell                 Â
515/tcp    open        printer               Â
3128/tcp   open        squid-http            Â
8888/tcp   open        sun-answerbook         

TCP Sequence Prediction: Class=3Drandom positive increments
                         Difficulty=3D88217 (Worthy challenge)

Sequence numbers: C71B5D1D C71EA319 C7205F3B C721CEFD C72706F0 C729B3AC
Remote OS guesses: Solaris 2.6 – 2.7, Solaris 7
OS Fingerprint:
TSeq(Class=3DRI%gcd=3D1%SI=3D15899)
T1(Resp=3DY%DF=3DY%W=3D2297%ACK=3DS++%Flags=3DAS%Ops=3DNNTNWME)
T2(Resp=3DN)
T3(Resp=3DN)
T4(Resp=3DY%DF=3DY%W=3D0%ACK=3DO%Flags=3DR%Ops=3D)
T5(Resp=3DY%DF=3DY%W=3D0%ACK=3DS++%Flags=3DAR%Ops=3D)
T6(Resp=3DY%DF=3DY%W=3D0%ACK=3DO%Flags=3DR%Ops=3D)
T7(Resp=3DY%DF=3DY%W=3D0%ACK=3DS%Flags=3DAR%Ops=3D)
PU(Resp=3DY%DF=3DY%TOS=3D0%IPLEN=3D70%RIPTL=3D148%RID=3DE%RIPCK=3DE%UCK=3DE%ULEN=3D134%DAT=3DE)
# Nmap run completed at Sun Aug  6 20:02:23 2000 — 1 IP address (1 host up) scanned in 34 seconds

Se  trata de un  Solaris 2.6-2.7  que tiene  filtrados los  puertos de
usenet (119)  y network time protocol  (123). Luego a no  ser que este
mismo  host  utilice un  filtro  de  paquetes,  sospecharemos que  son
filtrados por  las reglas  del firewall/router que  le precedia  en la
secuencia de traceroute.

Si barremos ahora los puertos del supuesto firewall:

Â
# Nmap (V. nmap) scan initiated 2.53 as: nmap -vv -sS -O -P0 -o cica 130.206.194.10
Interesting ports on  (130.206.194.10):
(The 1517 ports scanned but not shown below are in state: closed)
Port       State       Service
79/tcp     open        finger                Â
119/tcp    filtered    nntp                  Â
123/tcp    filtered    ntp                   Â
1998/tcp   open        x25-svc-port          Â
2001/tcp   open        dc                    Â
6001/tcp   open        X11:1                  

TCP Sequence Prediction: Class=3Drandom positive increments
                         Difficulty=3D38400 (Worthy challenge)

Sequence numbers: 2395ACF2 23A031DB 23AB5C89 23B4BE60 23BF584E 23C98A6A
Remote OS guesses: AS5200, Cisco 2501/5260/5300 terminal server IOS 11.3.6(T1), Cisco IOS 11.3 – 12.0(9)
OS Fingerprint:
TSeq(Class=3DRI%gcd=3D1%SI=3D9600)
T1(Resp=3DY%DF=3DN%W=3D1020%ACK=3DS++%Flags=3DAS%Ops=3DM)
T2(Resp=3DY%DF=3DN%W=3D0%ACK=3DS%Flags=3DAR%Ops=3D)
T3(Resp=3DY%DF=3DN%W=3D1020%ACK=3DS++%Flags=3DAS%Ops=3DM)
T4(Resp=3DY%DF=3DN%W=3D0%ACK=3DO%Flags=3DR%Ops=3D)
T5(Resp=3DY%DF=3DN%W=3D0%ACK=3DS++%Flags=3DAR%Ops=3D)
T6(Resp=3DY%DF=3DN%W=3D0%ACK=3DO%Flags=3DR%Ops=3D)
T7(Resp=3DY%DF=3DN%W=3D0%ACK=3DS%Flags=3DAR%Ops=3D)
PU(Resp=3DN)
# Nmap run completed at Sun Aug  6 19:40:12 2000 — 1 IP address (1 host up) scanned in 26 seconds

Vemos  que se  trata efectivamente  de  un Cisco  Terminal Router  IOS
11.3-12.0 y que filtra tambien esos dos puertos.
                                                                  Â
Si hacemos un fping a www.cica.es

#>hping www.cica.es -S -p 80
ppp0 default routing interface selected (according to /proc)
HPING www.cica.es (ppp0 150.214.5.77): S set, 40 headers + 0 data bytes
44 bytes from 150.214.5.77: flags=3DSA seq=3D0 ttl=3D243 id=3D4427 win=3D9112 rtt=3D188.4 ms
44 bytes from 150.214.5.77: flags=3DSA seq=3D1 ttl=3D243 id=3D4428 win=3D9112 rtt=3D200.2 ms
44 bytes from 150.214.5.77: flags=3DSA seq=3D2 ttl=3D243 id=3D4429 win=3D9112 rtt=3D210.2 ms
44 bytes from 150.214.5.77: flags=3DSA seq=3D3 ttl=3D243 id=3D4430 win=3D9112 rtt=3D200.2 ms
44 bytes from 150.214.5.77: flags=3DSA seq=3D4 ttl=3D243 id=3D4431 win=3D9112 rtt=3D190.2 ms
44 bytes from 150.214.5.77: flags=3DSA seq=3D5 ttl=3D243 id=3D4432 win=3D9112 rtt=3D210.1 ms

Paramos con Ctrl-C

— www.cica.es hping statistic —
6 packets tramitted, 6 packets received, 0% packet loss
round-trip min/avg/max =3D 188.4/199.9/210.2 ms
                                                      Â
y  observamos  que   el  flag=3DSA  indica  que  el   puerto  80  esta
efectivamente abierto. Pero si hacemos hping al puerto 119

#>hping www.cica.es -S -p 119
ppp0 default routing interface selected (according to /proc)
HPING www.cica.es (ppp0 150.214.5.77): S set, 40 headers + 0 data bytes

— www.cica.es hping statistic —
13 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max =3D 0.0/0.0/0.0 ms         

Efectivamente, esta vez no  tenemos ninguna respuesta y debemos pensar
que el cortafuegos/o enrutador (Cisco ultimate server) la detuvo. =BFO
tal vez  el propio  host tenia filtro  de paquetes?. Si  utilizamos de
nuevo nmap y escaneamos toda la subred en los puertos 119 y123:

#>nmap -sS -p119,123 www.cica.es/24

obtenemos en  todos los  casos que los  hosts tienen esos  dos puertos
filtrados: Mucha casualidad va a  ser que cada host utilice un sistema
de filtrado  en dichos puertos  . Lo mas  aplastante es que  el host
130.206.194.10  disponga unas  rglas  de firewall  que filtren  dichos
puertos a todos los hosts a los que apunta.

De las  cuestiones acerca de los  tipos de cortafuegos  y las tecnicas
para traspasarlos nos dedicaremos  en el capitulo destinado al ataque,
como ya dije antes.

La  exploracion de  los puertos  de un  cortafuegos es  util,  pero la
mayoria no  escuchan en puertos predeterminados.  La identificacion de
algunos  cortafuegos  puede hacerse  si  tenemos  suerte  de modo  muy
sencillo  leyendo ciertos  mensajes  de identificacion  que muchos  de
ellos presentan. Con la  utilidad netcat podemos conectarnos al puerto
21 del posible cortafuegos

#>nc -v -n 192.168.51.129 21
(UNKNOWN) [192.168.51.129] 21 (?) open
220 Secure Gateway FTP server ready

#>nc -v -n 192.168.51.129 23
(UNKNOWN) [192.168.51.129] 23 (?) open
Eagle Secure Gateway
Hostname:
3. Exportacion de archivos NFS

El Network File  System (NFS) es un sistema de  red que posibilita que
un  host  servidor proporcione  sistemas  de  archivos y  dispositivos
perifericos a  maquinas clientes. Si  el amigo administrador no  es un
lumbrera o  pasa cantidad, puede  que no haya configurado  el servidor
NFS adecuadamente…y  cualquier usuario remoto puede  tener acceso de
lectura y escritura. Si mediante una exploracion previa se observa que
el puerto 2049 (servidor nfs) de un host esta abierto, con la utilidad
showmount -e podemos conseguir la  lista de exportacion de un servidor
NFS. Si hacemos como root

#>showmount -e objetivo.net
y nos sale algo como
RPC: Port mapper failure – RPC: Unable to receive
pues nada, no ha habido suerte

pero si nos saliera

#>showmount -e objetivo2.net
export list for objetivo2.net
/pub         (everyone)
/home        (everyone)

ya  podiamos establecer una  via de  entrada con  ayuda de  los rlogin
(ya lo veremos en el hacking).

4. Listado de usuarios y grupos

Parece  mentira,  pero  algunos  administradores emplean  la  utilidad
finger  con m=EDnimas  medidas de  seguridad…y esto  permite obtener
bastante  informacion  en muchos  casos  para  ingenieria social,  que
aunque yo no  lo considero como una tecnica pura  de hacking, te puede
resolver  el  problema  .   Supongamos  que el  host  objetivo  esta
ejecutando el servicio fingerd (puerto 79). Si hacemos como root

#>finger -l @host.objetivo
[host.objetivo]
login:root                         name:root
Directory:/root                    Shell:/bin/bash
On since Sun Mar 20: 10:15(PST) on tty1. 11 minutes idle
(message off)
On since Sun Mar 20: 10:15(PST) on ttyp0 from :0.0. 3 minute 15 seconds idle
No mail
Plan:
Luke Skywalker
Linux Guru
Telnet password is Lord … (my father)

Peaso de info (pero, como las peliculas de los intocables, el parecido
con la realidad es pura coincidencia) La informacion proporcionada por
finger en principio deberia ser  inocua porque la extrae de los campos
de  /etc/passwd. Lo  mas  peligroso es  que  indica el  nombre de  los
usuarios conectados y sus  tiempos de inactividad. Moreover, cualquier
usuario  que  tenga un  archivo  .plan  o  .project en  su  directorio
particular, la presentara al  hacer finger un merodeador. Los comandos
rwho y rusers muestran los usuarios conectados al host remoto, pero no
dan  tanta informacion como  finger. Es  posible mediante  el servicio
smtp  localizar  usuarios  con  los  mandatos  vrfy  (confirmacion  de
usuarios validos)  y expn (direcciones  reales de entrega de  correo y
alias):

$>telnet 192.168.202.34 25
=2E…………………….
220 mail.bigcorp.com ESMTP Sendmail 8.8.7
vrfy root
250 root <root@bigcorp.com>
expn adm
250 adm <adm@bigcorp.com>

5. Aplicaciones RPC

Remote  Procedure  Call (RPC)tiene  que  ver  con interacciones  entre
procesos=2E  El  concepto  de  RPC  es  una  sencilla  t=E9cnica  para
desarrollar  aplicaciones donde  se requiere  la  comunicaci=F3n entre
procesadores que cooperan en un sistema distribuido.

El  mecanismo  RPC proporciona  un  servicio  para  el programador  de
apliciones  que le  permite el  uso transparente  de un  servidor para
proporcionar  alguna actividad  por  parte de  la aplicaci=F3n.   Esto
efectivamente  puede ser  utilizado para  interactuar con  un servidor
computacional o  con una Base  de Datos, y  ha sido usado  por algunos
sistemas para  proporcionar acceso a servicios  del sistema operativo.
El ultimo  uso conocido es  en sistemas basados  en micro-ordenadores,
que  da   un  mejor  resultado  que  en   los  sistemas  tradicionales
encontrados en  la mayoria de sistemas  unix.  La orden  rpcinfo es el
equivalente a finger en la enumeracion de aplicaciones RPC que estan a
la escucha en hosts remotos en los puertos 111 (rpcbind) o 32771 (Sun)
Supongamos  que nuestro  objetivo o  una  maquina de  su subred  tiene
activo el puerto 111. Si hacemos

#>rpcinfo -p objetivo.net
y obtenemos:

program   vers     proto     port
100000             2         tcp   111  rpcbind
100002             3         udp   712  rusersd
100011             2         udp   754  rquotad
100005             1         udp   635  mountd
100003             2         udp  2049  nfs
100004             2         tcp   778  ypserv

Esta informacion  (me salto lo  que ahora puede ser  superfluo) indica
que se  estan ejecutando rusersd, nfs  e ypserv que es  el servidor de
NIS.  NIS (Network  Information System)  es un  protocolo de  nivel de
aplicacion   muy    util   para   la    gestion   de   configuraciones
cliente/servidor en  sistemas unix.  Es un sistema  de bases  de datos
distribuidas que  permiten de manera  uniforme el almacenamiento  y la
recuperacion de los recursos de red. Como explica Daemond, en lugar de
gestionar  archivos   como  el  /etc/hosts,   /etc/passwd,  /etc/group
independientemente  en  cada  maquina  de  la red,  esto  permite  que
solamente haya  una base de datos  compartida (mapas) por  el resto de
las maquinas clientes en un servidor central. Esto tiene su aquel para
el hacking de sistemas usando ypcat, pero ya lo veremos.

Existen muchos  mas modos de extraer informacion,  por ejemplo leyendo
el  codigo de las  paginas web,  estableciendo posibles  relaciones de
confianza  (trusted  hosts  con  rlogin),  ingenieria  social,  quinta
columna… pero creo que no esta mal para comenzar.

Aqui termina la segunda entrega.

En  la  proxima   nos  centraremos  en  las  tecnicas   de  hacking  e
introduccion de sistemas mediante fallos de seguridad, desbordamientos
del bufer de  ciertos programas, ataques por fuerza  bruta, etc. Queda
todavia  un largo  camino y  luego hay  tecnicas  avanzadas (tunneling
firewalls, hijacking, IP spoofing…)

Tened cuidado ahi fuera .

LECTER

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.