AGOSTO 2009
 SNIFFERS
EN LA RED - No te creas todo lo que dicen!
Christian Vila / ISEC +
Senior Security Consultant
ISEC Information Security Inc.
www.isec-global.com
Muchas veces con el afán de solucionar problemas o de
investigar sobre ciertos temas escribimos una búsqueda en alguno de los
buscadores, abrimos las primeras páginas que aparecen y listo ya tenemos
la información que estamos buscando y encima lo aceptamos como verdad
absoluta...
Hagamos la prueba de leer lo que nos dice
Internet sobre los Sniffers de Red, escriban esta búsqueda "detección
de sniffers" seguro que encontrarán algunos sitios que explican como
con algún programita y algunos clicks del mouse se descubre como por
arte de magia si alguien nos esta "sniffeando" dentro de la red.
Inclusive algunos sitios de los cuales sospechar sería una blasfemia,
como Wikipedia, por ejemplo.
Sin embargo siempre es bueno ir las fuentes,
como en cada ocasión que se quiera investigar algún tema, dejemos de
lado los programitas mágicos y comencemos con las técnicas de los
ataques. Fíjense como un tema tan básico como es la detección de
sniffers puede engañar a más de algún experto solo por seguir la
corriente de Internet.
SNIFFING:
es un ataque definido como "PASIVO" o sea no modifica ningún paquete de
NINGÚN protocolo solo los detecta y los lee; lamentablemente son
indetectables en la red y la única forma de detectarlos es estar sentado
en la máquina que esta haciendo sniffing o por algún método de forencia
pero siempre sobre la máquina que realiza el ataque.
Existen si otras técnicas que favorecen la
captura de los paquetes realizando distintos ataques en la red local,
por ejemplo arp poison, modo promiscuo de las placas de red, ipspoofing,
etc.; pero esto es otro tema de lo que hay mucho escrito y ESTO ES LO
QUE DETECTAN LOS FAMOSOS PROGRAMITAS ANTISNIFFERS.
Van a encontrar sniffers de hhtp, sniffers
de msn, sniffers de Voip pero si realmente no se comprende bien la
técnica de los ataques, que tareas realiza, qué protocolos utiliza,
en que nivel OSI se encuentra, si no se testea en ambientes controlados;
solo me queda correr programitas, hacer un par de clicks y creer lo que
me dicen...
...por todo lo dicho los aliento a ir más
allá de lo que muestran los papers de internet, por cada ataque que
quieran investigar antes de correr cualquier herramienta testear bien
como funciona, por ejemplo les dejo una idea: ¿Que ocurriría si cambio
el switch por un hub y corro un sniffer como "wireshark"?¿Es necesario
poner mi placa en modo promiscuo, es necesario envenenar la red de
paquetes ARP?. Es increíble lo que se puede hacer con un HUB
conectándolo antes de un Access Point.
Fuente: ISec Information Security Inc
JULIO 2009
Web Aplication Vulnerabilities Parte
5 de 5
Traducción y resumen de artículo
para Security Focus:
- Five common Web application vulnerabilities
- Sumit Siddharth, Pratiksha Doshi
5ta Parte:
Enumeración de Usuarios
Enumeración de usuarios es un tipo de
ataque en el cual la secuencia de comandos de validación le dice al
atacante si el nombre de usuario proporcionado es correcto o no. La
explotación de esta vulnerabilidad permite al atacante a
experimentar con diferentes nombres de usuario y determinar los
válidos con la ayuda de estos mensajes de error.
Rating: bajo.
Productos vulnerables: Nortel Contivity
VPN client, Juniper Netscreen VPN, Cisco IOS [telnet].
Ejemplo de Mensaje de error:
Ejemplo de mensaje correcto:
Enumerar usuarios puede ayudar a un
atacante que intenta utilizar algunos nombres de usuario
triviales con contraseñas fácilmente adivinables, como prueba /
prueba, admin / admin resultados / resultados y así
sucesivamente. Estas cuentas son creadas a menudo por los
desarrolladores para realizar pruebas y muchas veces las cuentas
no son desactivadas o el desarrollador se olvida de cambiar la
contraseña.
Contramedidas:
Mostrar mensajes de error que eviten la divulgación de nombres
de un usuario válido. Asegúrese de que si existen cuentas
genéricas realizar pruebas para que sus contraseñas no sean
triviales o que estas cuentas estén totalmente eliminadas antes
de que la aplicación se ponga en producción.
Fuente: SecurityFocus
JUNIO 2009
Web
Aplication Vulnerabilities Parte 4 de 5
4ta Parte:
Cross Site Scripting - XSS
El éxito de este ataque requiere quela
víctima ejecute una url con código malicioso que a primera vista
parecería ser código legítimo. Cuando se clickea sobre una url
modificada manualmente un atacante puede hacer ejecutar código sobre
el browser de la vítima, por ejemplo algún código java malicioso
puede ser ejecutado en el contexto de un sitio web que se aprovecha
del bug XSS.
Rating: Moderado a
Crítico.
Algunos productos vulnerables:
Microsoft IIS web server, Yahoo Mail, Squirrel Mail, Google
search.
El ataque de Cross Site Scripting se
realiza a través de formularios en los cuales hay interacción
con el usuario, los siguientes son los objetivos más populares:
A continuación un ejemplo de ataque
XSS:
<form action="search.php" method="GET"
/>
Welcome!!
<p>Enter your name: <input type="text" name="name_1" /><br
/>
<input type="submit" value="Go" /></p><br>
</form>
<?php
echo "<p>Your Name <br />";
echo ($_GET[name_1]);
?>
El valor pasado por la variable 'name_1'
no está sanitizado entonces puede ser explotado para ejecutar
código arbitrario.
Otro ejemplo de explotación de este
ataque:
http://victim_site/clean.php?name_1=<script>code</script>
or
http://victim_site/clean.php?name_1=<script>alert(document.cookie);</script>
Contramedidas:
El siguiente código se recomienda
ingresar para resolver estos ataques:
<?php
$html= htmlentities($_GET['name_1'],ENT_QUOTES, 'UTF-8');
echo "<p>Your Name<br />";
echo ($html);
?>
Fuente: SecurityFocus
MAYO 2009
Web
Aplication Vulnerabilities Parte 3 de 5
3er Parte: Vulnerabilidades Format
String
Esta vulnerabilidad se
produce cuando el ingreso de entradas de usuario están sin filtrar,
generalmente son parámetros en código perl o C que realizan
funciones de formato, tales como printf ().
Un usuario
malintencionado puede utilizar el especificador de formato "%s" o "%x",
entre otros, para imprimir los datos de la pila o posiblemente otros
lugares de la memoria. Inclusive, puede escribir datos arbitrarios
en lugares arbitrarios de la memoria utilizando el especificador de
formato %n.
Las vulnerabilidades
Format String se podrían clasificar en tres categorías: denegación
de servicio, lectura y escritura.
Rating: Moderado a
Crítico.
Algunos Productos
Vulnerables:
McAfee AV, Usermin,
Webmin, various Apache modules, winRar, ettercap, entre otros.
-
Los ataques de
denegación de servicio se caracterizan por la utilización de
múltiples instancias del especificador de formato %s, este
especificador se utiliza para leer datos de la pila si se
generan múltiples peticiones hasta que el programa intente leer
datos desde una dirección ilegal se provocará que el programa se
caiga.
-
Los ataques de
lectura utilizan el especificador de formato %x, el cual es
utilizado para imprimir secciones de la memoria para las cuales
el usuario normalmente no tienen acceso.
-
Los ataques de
escritura utilizan especificadores de formato %d, %u o %x
para sobrescribir el puntero de instrucción y forzara la
ejecución de un shell (con permisos del usuario).
Este es un ejemplo del
archivo miniserv.pl (Webmin) que provoca esta vulnerabilidad:
if ($use_syslog && !$validated)
{
syslog("crit",
($nonexist ? "Non-existent" :
$expired ? "Expired" : "Invalid").
" login as $authuser from $acpthost");
}
Contramedida:
Modificar el código
fuente para que la entrada es verificada correctamente
Fuente: SecurityFocus
ABRIL 2009
Web Aplication Vulnerabilities Parte 2 de 5
2da Parte: SQL injection
La inyección de
SQL es un método muy antiguo, pero aún es popular entre los atacantes.
Esta técnica permite a un atacante obtener información crucial de un
servidor Web de la base de datos. Dependiendo de las medidas de
seguridad de la aplicación, el impacto de este ataque puede variar desde
la divulgación de información básica hasta la ejecución remota de código
y total compromiso del sistema.
Rating: Medio y Crítico
Productos Vulnerables:
PHPNuke, MyBB, Mambo CMS, ZenCart, osCommerce
MS SQL tiene la característica de llamadas de procedimiento almacenado
extendido (extended stored procedure), que permite ejecutar comandos a
nivel de sistema a través del servidor de MS SQL - como agregar un
usuario. Además, los mensajes de error mostrados por el servidor de MS
SQL revelan más información que un servidor MySQL. Mientras que MS SQL
Server no es especialmente propenso a ataques de inyección de SQL, hay
medidas de seguridad que deben aplicarse para que sea segura y no
permitir que el servidor SQL dé información crítica del sistema.
Este es un ejemplo de un código que puede ingresar un usuario y es
utilizado directamente como una query de SQL:
<form action="sql.php" method="POST" />
<p>Name: <input type="text" name="name" /><br />
<input type="submit" value="Add Comment" /></p>
</form>
<?php
$query = "SELECT * FROM users WHERE username = '{$_POST['username']}";
$result = mysql_query($query);
?>
Este script funciona normalmente cuando el campo username no contiene
ningún caracter malicioso:
$query = "SELECT * FROM users WHERE username = 'steve'";
Sin embargo una inyección de sql podría resultar de esta forma:
$query = "SELECT * FROM users WHERE username = '' or '1=1'";
Como la condición "or" es siempre verdadera, la función mysql_query va a
retornar los registros de la tabla de datos. Un ejemplo similar sería
usar "AND" y un comando de SQL que generaría un mensaje de error
específico:
Es obvio que este tipo de mensajes de error ayuda a un atacante a
obtener la información que está buscando (nombre de la tabla, de la base
de datos, usuarios, hashes de contraseñas, etc.). Mostrar mensajes de
error personalizados puede ser una buena solución para este problema,
sin embargo, existe otra técnica conocida como ataque de inyección de
SQL a ciegas (Blind SQL Injection), donde el atacante es todavía capaz
de llevar a cabo una inyección de SQL, incluso cuando la solicitud no
revela ningún mensaje de error del servidor de base de datos que
contenga información útil para el atacante.
Contramedidas:
Evite conectar a la base de datos como superusuario o como el
propietario de la base de datos. Utilice siempre usuarios personalizados
para conectar a la base de datos con el mínimo privilegio necesario para
realizar la tarea asignada.
PHP tiene dos funciones para MySQL que sanitizan los imputs del usuario:
addslashes (el más viejo) y mysql_real_escape_string (el método
recomendado). Esta función viene con PHP >= 4.3.0, por lo que debe
comprobar primero si existe esta función y que esté ejecutando la última
versión de PHP 4 o 5.
Fuente: Security Focus
| 
Hacker
Halted 2009 - Miami : La Seguridad de la Información, un tema que
preocupa a especialistas a nivel mundial.
