miércoles, 31 de diciembre de 2008

Aire Fresco en Information Gathering (Actualización)

Acabo de actualizar el post "Aire Fresco en Information Gathering" que si recordais, una de las herramientas que comentaba no la había podido encontrar.

La web en cuestión se encuentra en el enlace www.usernamecheck.com, pero recomiendo a los lectores que lean el post original para ver una explicación de que se puede hacer con esta web.

miércoles, 24 de diciembre de 2008

Fichero "backdoor" en Netifera

Hace pocos días que tuve conocimiento de un software llamado Netifera, aún en estado beta, que proporciona un framework para desarrollo de herramientas de seguridad y para la integración con otras herramientas. Sin duda un software al que hay que llevarle un seguimiento muy de cerca.

Del software en cuestión ya hablaré otro día cuando lo tenga probado y pueda valorar con conocimiento de causa, pero de momento me gustaría escribir de algo, cuando menos curioso, que sucede en la instalación.

Tras descargar y descomprimir el paquete para Linux que previamente me he descargado de la web, hago un listado de directorios del paquete y me encuentro con esto:

about_files
about.html
backdoor <----
backdoor_install.sh <----

configuration
features
jre
libcairo-swt.so
netifera
plugins


¿¿¿"backdoor" y "backdoor_install.sh"???? Además miro la documentación y en ella dicen concretamente que debo ejecutar ese fichero como root, lo cual me deja un poco confuso. Si bien es cierto que sería de tontos si quisieran colocar un backdoor en un software dejarlo tan a la vista y con ese nombre, el paranóico que llevo dentro no se pudo resistir a pegarle un vistazo al script:

#! /bin/sh

BACKDOOR=backdoor
[ $# -ge 1 ] && BACKDOOR=$1

die() {
echo $1 1>&2
exit 1
}

[ -f ${BACKDOOR} ] || die "file not found: ${BACKDOOR}"
[ -x ${BACKDOOR} ] && [ -u ${BACKDOOR} ] && [ `stat -c '%g' ${BACKDOOR}` -eq 0 ] && echo "${BACKDOOR} already installed." && exit 0
[ `id -ru` -eq 0 ] || die "You must run that script as root."
chown 0:0 ${BACKDOOR} && chmod 4755 ${BACKDOOR} || die "Installation failed"
echo "Installation successful."


Pues bien, parece ser que el script "backdoor_install.sh" lo único que hace es darle el fichero al usuario root y luego darle permisos de SUID al binario, y lo deja con permisos 755, es decir, ¡¡cualquiera puede ejecutar el binario como root!!. Me quedo realmente alucinado, es realmente peligroso dejar un binario de root con el SUID activo y además dejar permiso de ejecución a todo el mundo, y no solo a un grupo, realmente muy peligroso.

De vuelta a la documentación de Netifera, encuentro buscando por ahí una explicación de porque existe ese fichero. La explicación que da el equipo de netifera es que necesitan ese fichero para que, cuando netifera se ejecuta con privilegios de usuario, pueda abrir los sockets necesarios para hacer sniffing de la red, y eso solo se puede hacer con privilegios de root. El motivo de llamarle de una manera tan peculiar es precisamente alertar sobre los riesgos que implica tener un binario como ese en el sistema.

Realmente, como dicen ellos, es peligroso, el binario podría sufrir alguna vulnerabilidad que permitiera ejecutar código y entonces cualquiera podría ejecutar código con privilegios de root. Como mínimo, cualquiera en el equipo va a poder hacer sniffing de toda la máquina y capturar contraseñas que se envien en claro, obtener información, quizá usarlo para hacer un MitM desde un usuario no privilegiado, en fin, peligroso peligroso.

De todas maneras, para quedarme más tranquilo, aunque se trate de algo muy rudimentario (tampoco quiero ponerme a hacerle la ingeniería inversa al binario) le pego un vistazo a las cadenas dentro del fichero para intentar hacerme una idea de lo que hace y me encuentro lo siguiente:

/lib/ld-linux.so.2
__gmon_start__
libc.so.6
_IO_stdin_used
socket
_exit
__errno_location
strtoul
sendmsg
__libc_start_main
GLIBC_2.0
PTRh
[^_]


Efectivamente parece que cuadra con las explicaciones que da el equipo de netifera, así a vista de pájaro, con lo que el paranóico que llevo dentro se queda razonablemente más tranquilo.

Las alternativas que propone netifera en su documentación son las siguientes:
  • Dejarlo como está y asumir el riesgo.
  • Ejecutar netifera como root: Todo el entorno se ejecutará como root, por lo que no será necesario activar SUID sobre el backdoor.
  • Utilizar los "sudo gráficos" que vienen en muchas distribuciones como el su-to-root con lo que tendriamos algo equivalente a lo anterior, pero mucho más cómodo.
  • Esperar a una próxima versión en la que tienen pensado autenticar de alguna manera el acceso a estos privilegios.

Realmente yo no pienso dejar ese binario con permisos para escritura para todo el mundo, yo optaría por alguna de las siguientes opciones:
  • Dejarlo sin permisos SUID y hacerme root al ejecutarlo. No me gusta 100% esta solución porque implica tener ejecutandose todo un entorno con privilegios de root cuando no es para nada necesario, y eso va completamente en contra del principio de mínimo privilegio, pero sin duda es mucho mejor que dejar el binario expuesto para su ejecución a todo el mundo.
  • Darle permisos de SUID pero quitar los permisos para todos los usuarios, dejando únicamente que ejecuten este binario root y los pertenecientes al grupo que pertenezca el fichero. Para ello he creado un grupo "netifera" en mi equipo del que soy el único miembro. De esta manera la ejecución como root ya no está disponible para todos los usuarios, sino solo para los que tienen permiso para ejecutar netifera, en este caso solo yo, reduciendo considerablemente el riesgo.
  • Crear un usuario netifera que sea el único que puede ejecutar el software y lanzar el backdoor como root, y configurar para mi usuario un sudo o su-to-root para ejecutar ese binario con esos privilegios, de esta manera no solo basta con que alguien consiguera un acceso con mi usuario, sino que debería descubrir la contraseña de sudo. Esta opción sería probablemente la más segura, pero también la más incómoda, porque quiere decir que no podrías tener acceso con el usuario netifera a tu home y cosas de estas.
De las tres, por proporcionar una seguridad aceptable mientras el equipo de netifera implementa estas medidas de autenticación y una gran flexibilidad en el uso de la herramienta, yo voy a implementar la segunda opción, tengo un grupo "netifera" al que me he añadido y he modificado los permisos del fichero backdoor para que solo los miembros de este grupo pueden ejecutar el binario como root:

# chmod 750 backdoor
# addgroup netifera
# adduser mi_usuario netifera
# chgrp netifera backdoor


Más adelante iré usando la herramienta y si detecto que me da algún problema por haber tomado esta solución ya os lo haré saber, aunque en principio no debería dar ningún problema.


martes, 16 de diciembre de 2008

Versión 3 de la Guía OWASP

Acabo de recibir la notificación de la publicación de la OWASP Testing Guide v3 (PDF), que como ya sabreis, es una guía destinada a describir el proceso de test de intrusión en aplicaciones web.

La particularidad de esta guía en contraposición a otras guías que hay por ahí de test de intrusión general o aplicaciones web, es el gran detalle con el que está escrita cada una de sus partes, muy lejos del estilo abstracto de otras guías. En la guía publicada por OWASP, todas las vulnerabilidades a testear están perfectamente explicadas, con ejemplos y con referencias a las herramientas necesarias para que sean explotadas exitosamente.

Sin duda un manual de referencia imprescindible para aquel que se dedica a la seguridad de aplicaciones web y, por supuesto, aquellos que se dedican al desarrollo de este tipo de aplicaciones.

miércoles, 10 de diciembre de 2008

TCP Flood: LetDown

Acaba de llegar a mis manos un paquete de herramientas llamadas "Complemento" de entre las cuales me ha llamado la atención la herramienta LetDown, basicamente por estar inspirada en el famoso post de Fyodor (desarrollador de nmap): "TCP Resource Exhaustion and Botched Disclosure" en el que intentaba dar su teoría sobre Sockstress y la nueva vulnerabilidad de TCP que esta herramienta explota.

Por lo que se dedujo de los posts intercambiados entre Fyodor y los descubridores de la vulnerabilidad, no parece ser que este LetDown sea idéntico que Sockstress, aunque sí que podría ser algo similar.

La sintaxis de la herramienta es sencilla:
Usage:
Usage:
letdown -d destination ip -p port [options]
Options:
-d destination ip address, target
-p destination port
-s source ip address
-x first source port (default 1025)
-y last source port (default 65535)
-i network interface
-t sleep time in microseconds (default 0)
-a max time in second for waiting responses
-f automagically set firewall rules for blocking
rst packet generated by the kernel
examples: -f iptables, -f blackhole (for freebsd)
-P payload file (see payloads directory...)

Los binarios se distribuyen en código fuente o en .deb ,por lo que resultan muy fáciles de instalar. Si no tienes una distribución basada en debian probablemente tendrás que instalar a mano (o con tu gestor de paquetes) las librerías libnet y su correspondiente paquete de headers si es que no lo tienes instalado.

De momento lo he probado para tumbar una máquina Windows y una Linux y no me ha funcionado, quiero investigar un poco un poco más a ver si es que algo no lo estoy haciendo bien.

Lo que sí que he hecho es capturar los paquetes que salen al lanzar la herramienta y efectivamente vemos esto:

11:44:11.885329 IP 192.168.1.21.1025 > 192.168.1.9.22: S 1:1(0) win 1024
11:44:11.885684 IP 192.168.1.9.22 > 192.168.1.21.1025: S 1683795610:1683795610(0) ack 2 win 5840
11:44:11.885730 IP 192.168.1.21.1025 > 192.168.1.9.22: R 2:2(0) win 0

Como podemos ver, tiene pinta de los ataques de Fyodor y Sockstress, manda un único paquete SYN, al que el host atacado responde con SYN/ACK, para que finalmente el host atacante responda haciendo un RESET de la conexión. Esto no parece tener mucho secreto, donde está la chicha es en el Payload de las conexiones.

Si consigo que funcione haré una ampliación del post y pondré que tal me ha funcionado y cual era "el truco".

¿Si a alguien se le ocurre alguna idea...?

jueves, 27 de noviembre de 2008

Aire Fresco en Information Gathering

La pasada semana tuve la suerte de poder desplazarme a Barcelona junto con unos compañeros de trabajo para poder asistir al IV OWASP Meeting Spain, en la que se trataron diversos temas sobre el nuevo framework para auditoría web w3af, el análisis de eco de aplicaciones web, la visión de Microsoft sobre la seguridad de sus propias aplicaciones e Information Gathering.

La que os vengo a comentar hoy (las otras ya las comentaré en otro momento) es la presentación que hizo




  • Google Sets: Otro gran trabajo de Google que nos facilita mucho el trabajo. Imaginad que vemos las cabeceras de un correo, o realizamos una transferencia de zona y vemos el nombre de tres máquinas: "turia", "ebro" y "jucar". Sólo tenemos que introducirlas en Google Sets y este relaciona las tres palabras y nos da uno montón de palabras más relacionadas con estas. Esto resulta muy muy útil sobretodo porque los administradores de sistemas tienden a poner nombres de una temática similar a sus sistemas, por lo que esta lista puede ser de mucha utilidad para realizar una resolución inversa de nombres y descubrir nuevos objetivos. Poniendoselo difícil a Google, intento introducir "shodan", "nidan", "sandan" (números en Japonés) y efectivamente lo reconocer y me saca una lista con otros números en Japonés.
  • Pipl: Web que le metes el nombre de una persona y te saca todas las referencias que encuentra de una persona, muy interesnte también. He probado a poner mi propio nombre y hasta sale una referencia a un compañero de carrera que me incluyó en los agredecimientos de su Proyecto Final de Carrera.
  • UserCheck: Esta es una web que cuando vi la presentación sencillamente me encantó, tiene referencia a un montón de sitios web y redes socialesa las cuales consulta para saber si un nombre de usuario concreto está dado de alta en alguno de ellos. Sin embargo, no he podido encontrar la web, si alguien sabe donde está por favor que ponga comentario.
Otro día os comentaré cosas de otras presentaciones que tampoco tuvieron ningún desperdicio.

ACTUALIZACIÓN 31/12/2008: Según leo en el blog personal de Christian Martorella, la web de UserCheck estaba en realidad en www.usernamecheck.com, desde este enlace sí que se puede ver la web que aparece en la presentación.

jueves, 20 de noviembre de 2008

¿Ataque a Ministerios.es?

Hace unas horas ha pasado por mis manos un correo electrónico de estos en cadena diciendo que la web www.ministerios.es había sufrido un defacement por parte de algún seguidor de la Huelga de Ingenieros Informáticos del 19 de Noviembre. Tras comprobar el enlace, efectivamente nos encontrabamos con la siguiente web:


Hay que ser un poco cautos, no sería la primera vez que alguien registra un dominio que parece corresponderse con una entidad o persona física (pasó hace poco con un conocidísimo político catalan que no disponía del dominio .es correspondiente a su nombre) y lo hace pasar como una web hackeada.

Vamos rapidamente a www.nic.es para obtener más detalles sobre este dominio y observamos lo siguiente:



Como podemos ver la persona registradora es una "Persona Física", al contrario de lo que sucede con otros dominios como mec.es, que está a nombre del propio Ministerio de Educación y Ciencia, por lo que en principio nos haría pensar que se trataría de uno de estos "defacements falsos".

No obstante, hay dos cosas que me resultan inquietantes, en primer lugar el dominio no se acaba de registrar, sino que lleva años ofreciendo servicio, y en segundo lugar, si buscamos la web en archive.org (ya comentaré el uso de esta herramienta en otro post) podemos ver que efectivamente ha estado ofreciendo servicios de "índice" de las webs ministeriales. Además, buscando el nombre de la persona propietaria del dominio enconrtamos en LinkedIn un consultor de SAP de la empresa HP, que en principio no parece tener nada que ver con ningún Ministerio.

Todo esto me hace plantearme varias posibilidades:
  1. Un particular lleva años ofreciendo este servicio de manera desinteresada y un intruso ha aprovechado alguna debilidad en el proveedor del hosting para hacer un defacement.
  2. Idem que el anterior pero el propietario del dominio, en apoyo de las movilizaciones del día 19 de Noviembre ha decidido simular un defacement en su web.
  3. Existe una relación no inmediata entre dicha persona y los Ministerios

¿Qué opinais?

lunes, 17 de noviembre de 2008

Buscador de CheetsSheet

Desde el blog Security by Default leo que han montado una web con una búsqueda personalizada de Google para buscar CheetsSheets de forma cómoda en un número determinado de webs.

Es interesante que contribuyamos con los enlaces que podamos conocer, así tendremos todos un buscador más potente y eficaz. Yo por mi parte ya he dejado un post con 2 o 3 sugerencias.

miércoles, 5 de noviembre de 2008

Ataques clásicos: El gusano de Morris

Hace unos pocos días, el 2 de Noviembre, se cumplieron 20 años de la aparición del primer gusano de Internet, el Gusano de Morris, llamado así por su creador, Robert Tappan Morris, por aquel entonces estudiante de 23 años que liberó en la entonces Arpanet el primer software (conocido) diseñado para auto-replicarse a través de la red.

El gusano no pretendía realizar ninguna acción especificamente maliciosa al infectar equipos, simplemente pretendía infectar el máximo número de sistemas posibles pero, debido a un bug en el código, el gusano provocó unos efectos no deseados, degradando en gran medida el funcionamiento de la red.

El Gusano de Morris explotaba para propagarse vulnerabilidades de los servicios SendMail y Finger, que permitieron que la infección afectara al 10% de los sistemas conectados a la red (unos 60.000 máquinas conectadas en total).
  • SendMail: La vulnerabilidad de SendMail explotada consistía en aprovechar un bug en la opción DEBUG, que si bien no estaba activada por defecto sí que era activada frecuentemente por muchos administradores en tiempo de compilación para facilitar la configuración del complicado SendMail. Este ataque permitía al Gusano de Morris ejecutar en la máquina atacada comandos shell que tenían como objetivo descargar un fichero de código C al que se le pasaban el nombre de Host, Usuario y Contraseña de la máquina origen del ataque para que este descargara una serie de ficheros que posteriormente ejecutaba, enmascarandolos con el nombre de "sh" para intentar que pareciaran ejecuciones de una Shell.
  • Finger: La vulnerabilidad de Finger explotada era debido a un bug que permitiría realizar un Buffer Overflow al pasarle una entrada de datos de más de 512 bytes, proporcionando un acceso Shell al gusano una vez explotado. Esta, según dicen, fue la vía más exitosa de infección del gusano.
  • Rsh/Rexec: Además de explotar las vulnerabilidades anteriormente mencionadas, el Gusano de Morris, una vez dentro de un sistema, intentaba aprovechar las relaciones de confianza del mismo (ficheros .rhosts y /etc/hosts.equiv) para acceder a nuevos sistemas. Para ello en primer lugar necesitaba acceder a las cuentas de los usuarios de la máquina, ya que a través de la explotación de vulnerabilidades anteriores obtenía privilegios de ejecución como "daemon", pero no como "root". Para obtener esas contraseñas utilizaba el campo de descripción del fichero /etc/passwd (llamado campo GECOS) para obtener su nombre y apellido, y de esta manera utilizar combinaciones con este nombre y una lista de contraseñas "habituales" para obtener acceso a las cuentas de los usuarios, y desde ahí aprovechar sus relaciones de confianza para propagare nuevamente.
Para los curiosos, el código fuente del gusano está publicado.

El que tenga algún detalle más sobre este gusano que lo ponga como comentarios, siempre resulta interesante conocer los detalles sobre estos "ataques clásicos".

domingo, 2 de noviembre de 2008

Vulnerabilidad Dan Kaminsky (II)

Después de la entrada Vulnerabilidad Dan Kaminsky (I) donde introducíamos una serie de conocimientos necesarios. Vamos ahora a explicar en qué consiste la vulnerabilidad descubierta durante este verano de 2008. Para poder entender en qué consiste el ataque de Dan Kaminsky deberemos primero entender los siguiente ataques al protocolo DNS:

El siguiente texto es una traducción y recopilación de información obtenida de diferentes fuentes, con la excepción de los gráficos que son obra de www.pentester.es para aclarar aún más si cabe los detalles de la vulnerabilidad.

DNS Forgery

Pueden leer la descripción de este ataque aquí.

Para que quede más claro lo mostraremos con unos gráficos resumidos:






Llegados a este punto por probabilidad el atacante puede adivinar uno de los QID’s generados para las consultas del DNS VICTIMA. Si adivina el QID’s podrá generar una respuesta con lo podrá suplantar la respuesta que debía llegar de OTRO DNS.

DNS RRset poisoning

Pueden leer una traducción y explicación buena aquí.

Ataque de Dan Kaminsky

El ataque está basado en una combinación de los dos anteriores ataques. Y se trata de lo siguiente:

Generamos gran cantidad de querys recursivas de nivel 3 solicitando dominos como aaaa.ejemplo.es, aaac.ejemplo.es, bbbb.ejemplo.es, etc. A la vez que le enviamos la query, enviamos la respuesta hasta que seamos más rápidos que el servidor legítimo y coincida con alguno de los QID’s generados por el servidor DNS a comprometer en sus querys al OTRO SERVIDOR.
Cuando esto pase anotará en la cache una entrada de tercer nivel del estilo ababab.ejemplo.es tiene la ip 1.2.3.4. Esta entrada para lo único que sirve es para envenenar la cache de DNS, y por si solo no vale para nada, ya que nadie va a visitar esta entrada. En ese instante tiene sentido utilizar el segundo ataque que consiste en colocar en los paquetes de respuesta en el campo adicional entradas como www.ejemplo.es, mail.ejemplo.es apuntando a direcciones no legítimas. Estos campos adicionales serán aceptados porque pertenecen al mismo dominio de la petición.

Ejemplo:

- El atacante realiza N peticiones de *.google.es al servidor DNS a comprometer.

- Al mismo tiempo envía respuestas al servidor a comprometer. Esas respuestas llevan en el campo de RR adicionales entradas como:

www.google.es 1.2.3.4
gmail.google.com etc. 1.2.3.4
Siendo estas direcciones NO legítimas.

- En el momento que el QID’s de la petición (servidor dns victima -> servidor dns legítimo) y de la respuesta (atacante -> servidor víctima) coincide se almacena en la cache; al tener los recursos adicionales cualquier petición a www.google.es, gmail.google.es, serás servida por 1.2.3.4 y no por las direcciones de legítimas de Google.

A continuación se muestra un diagrama que trata de comprender todo el ataque:




Espero sobretodo que este último gráfico ayude a entender bien el ataque y en qué consiste.






jueves, 30 de octubre de 2008

CheatsSheet: Análisis de Malware

Aquí tenemos otra Cheats Sheet sobre Análisis de Malware desarrollada por Lenny Zeltser, certificado GIAC GSE e Instructor de SANS.

La información resumida en este material forma parte del curso SEC610: Reverse-Engineering Malware, impartida por él mismo:



El documento puede ser descargado desde la propia web del autor (versión inglés) tanto en WORD como en PDF, así como de www.pentester.es (versión en castellano), igualmente tanto en WORD como en PDF.

miércoles, 22 de octubre de 2008

TCPDUMP & WIRESHARK

Cualquiera que se dedique a esto de la seguridad sabe el uso intensivo que se hace de estas dos herramientas: TcpDump y WireShark.

Para el que no lo sepa, estas dos herramientas son sniffers de red, en modo texto el primero y con interface gráfico el segundo (aunque también tiene una versión en modo texto llamada TShark, muy buena). ¿Para que necesitamos en seguridad hacer sniffing de red?, pues basicamente para análizar tráfico, o bien cuando hacemos una auditoría de seguridad de un producto que transfiere datos a través de la red y queremos valorar la seguridad de estas comunicaciones, o bien en el día a día de la detección de intrusiones, cuando el NIDS detecta un posible ataque siempre es muy útil disponer de una captura completa del paquete de red y si es posible de la conexión entera, con el fin de análizarlo y descubrir si se ha tratado de un falso positivo o de un ataque real.

El caso es que ambas herramientas tienen su propio lenguaje para limitar que tipo de tráfico queremos analizar, algo muy útil si queremos centrarnos en un tráfico concreto, pero que muchas veces nos pueden surgir dudas (sobretodo con Wireshark) de como sería la opción para capturar una serie concreta de paquetes. Por ello, os remitimos una Cheats Sheet publicada en la web PacketLife en la que tenemos una referencia rápida de estas dos grandes herramientas:



Podeis pinchar en las propias imágenes para descargar el PDF, os recomiendo tenerlo a mano, yo pienso hacerlo.

También cabe destacar que la web PacketLife dispone de una sección de Cheats Sheets muy buena, puede que os interese a más de uno pasaros y descargaros alguna.

Un gran trabajo el del autor de PacketLife.

viernes, 17 de octubre de 2008

Romper WPA/WPA2 con GPU's ? Falacias!

Se ha publicado recientemente, que la empresa ItWire, ha desarrollado una nueva tecnología que permite utilizar la GPU de la tarjeta gráfica para incrementar 100 veces la capacidad de cálculo de la CPU, permitiendo romper el cifrado de WPA/WPA2. Permitidme una sarcástica carcajada para lo que es un phising comercial en toda regla y veamos porque:


Dado que la longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32] tenemos (29+29+20+32)^8 =21.435.888.100.000.000 posibles palabras del lenguaje. Dado que los procesadores actuales mas potentes (utilizando el algoritmo de aircrack) pueden a lo sumo barrer 400 palabras por segundo (y soy muy benevolo) . Multiplicado por la capacidad de procesamiento de la gran NVIDIA nos da 400.000 palabras del lenguaje por segundo. Hechando calculos...


Se tardaría 1699,318881596 años es barrer todas la posibles cadenas, eso suponiendo que has acertado don el ESSID (ya que la cadena de cifrado depende de él) y que la PSK es de SOLO DE 8 CARACTERES! como bien sabes la longitud de la cadena en WPA puede ser mayor de 60 caracteres.


Así que este producto esta bien, sí , pero esta muy muy lejos de lo que anuncian, y es mas un phising comercial que otra cosa. He visto varios de estos como gente que vende colecciones de DVD's con tablas precomputadas que te aseeguran que rompen todos las claves WPA, falacias. El verdadero problema de seguridad de WPA son los usuarios y solo será vulnerable cuando rompan el cifrado(RC4/AES).

Por si os gusta el tema de aparatillos hardware que permiten incrementar la potencia de calculo, picocomputing contruye mediante ASICs y FPGAs dipositivos que pueden llegar a barrer 1000 palabras por segundo.

lunes, 13 de octubre de 2008

¿Estoy enfermo doctor?

Tal y como escribe Lorna Hutcheson en su post en el ISC de SANS, muchas veces el problema a la hora de comenzar un proceso de Incident Handling es que los afectados ni siquiera se dan cuenta de que han sufrido un incidente de seguridad.

Según el SANS Institute, el proceso de Incident Handling tiene unas etapas definidas, de las cuales las dos primeras (Preparación y Detección) son de especial importancia en el día día de las empresas, ya que en caso de no cumplirse dificulta mucho el análisis forense posterior, y por lo tanto aumenta las posibilidades de que el mismo incidente o similar pueda volver a ocurrir.

Por ello, y partiendo de la base que no se ha realizado una fase de preparación muy adecuada (IDS, capturas de tráfico de red, logs almacenados remotamente en las máquinas, etc), este artículo de SANS nos da 10 indicadores/síntomas de que podemos estar sufriendo una intrusión. Evidentemente esto no es la panacea, pero si no hemos realizado una fase de preparación pueden resultar útiles para saber cuando debemos acudir a un especialista en seguridad.

Este es el decálogo, mis comentarios van en cursiva:
  1. Tu servidor de logging no registra nada o no has recibido alertas en las últimas 12 horas <- Generalmente hay actividad, si no recibes nada no quiere decir que tus sistemas se han vuelto más perfectos por si solos o que los atacantes han reconocido tu superioridad y han dejado de atacarte, probablemente ya los tienes en casa y simplemente están impidiendo que te lleguen las alertas
  2. Los discos de tu servidores FTP o de tus usuarios de repente se han llenado o quizá los logs han crecido a un tamaño no habitual
  3. Los productos de la competencia se parecen a los tuyos, con pequeños cambios <- o están ofreciendo servicios similares a los tuyos por precios ligeramente inferiores a tus mismos clientes, cuando el precio de tus servicios no es algo público
  4. Tus compradores empiezan a recibir Spam en la cuenta que solo usaban para tus servicios <- cuidado con las contraseñas de clientes, la mayoría de personas utilizan las mismas contraseñas para clientes/proveedores que para la propia empresa, así que si sufres una intrusión puede que gran parte de tus clientes se puedan ver afectados
  5. Los usuarios reportan cosas como ventanas cerrandose por si mismo, página de inicio del navegador cambiada, etc -> En general, cualquier comportamiento anómalo puede ser señal de una intrusión o virus
  6. Alguien necesita ayuda para conectarse a la Wifi de la compañía y la compañía no tiene ninguna Wifi <- casi todas las empresas tienen hoy en día Wifi, pero es una técnica habitual abrir un Rogue AP para intentar hacer un MitM a los usuarios
  7. Te das cuenta de que el software da errores o se cuelga de repente (software de pagos, navegadores, etc) <- en ocasiones es lo normal, pero si empieza a dar errores de forma más seguida hay que confirmar si se trata de algún parche reciente del fabricante que ha producido inestabilidad (esto es bastante habitual) o si puede haber otras razones (binario cambiado, librerías cambiadas, etc)
  8. Te notifican los usuarios que su contraseña no funciona <- una cantidad de usuarios bloqueados o que se han olvidado la contraseña es normal, pero si este número aumenta mucho puede que nos estemos viendo afectados por un ataque de fuerza bruta que está bloqueando a los usuarios de los que intentan obtener contraseña. Quizá en el momento que nos damos cuenta ya ha obtenido una clave y está dentro de nuestros sistemas
  9. Los sistemas funcionan de forma inusualmente lenta <- medirlo con medios objetivos, recordad que para los usuarios los sistemas SIEMPRE funcionan de manera inusualmente lenta. Si por contra el administrador verifica la lentitud es conveniente verificar el sistema y las comunicaciones, y si aún así no encontramos el motivo no es conveniente dejarlo pasar, quizá no veamos el proceso que provoca la carga porque está oculto mediante algún tipo de rootkit o similar
  10. Los visitantes a tu web corporativa notifican que son redirigidos a otra o que simplemente no tiene el mismo aspecto de siempre <- esta es evidente, demasiado evidente, un defacement de la web puede ser un objetivo en si mismo, en cuyo caso no tienen que haber llegado al resto de sistemas o puede ser una medida de distracción para centrar los esfuerzos de los técnicos y que no nos demos cuenta de que otras actividades anómalas están teniendo lugar en nuestra red

Evidentemente lo mejor es montar detectores de intrusos basados en red y en host, análisis (automático si es posible) de logs y generación de alertas en caso de producirse anomalías, etc, pero al menos con este decálogo de SANS tenéis la opción de salir airosos de un incidente y, quizá para la próxima vez, implantar medidas de Preparación y Detección para que si vuelve a ocurrir seamos capaces de detectarlo tempranamente y de disponer de la máxima cantidad de información posible

Finalizo el post con una gran frase que me dijo un profesor cuando estudiaba en la universidad: "Todo administrador de sistemas sufre alguna vez alguna intrusión en su vida, no importa lo experto que sea, pero sabe enfrentarse a ella y hacer una correcta gestión del incidente. El administrador que os diga que NUNCA ha sufrido una intrusión en sus sistemas es que sencillamente nunca se dio cuenta de ello".

Una gran frase, sin duda, y un buen decálogo, gracias SANS.

viernes, 3 de octubre de 2008

Resucita el Ping de la Muerte

Todos recordamos aún el ataque DoS que fue conocido hace años como el Ping de la Muerte, que consistía en aprovechar un error en practicamente todas las implementaciones de las pilas TCP/IP de todos los fabricantes de sistemas operativos y electrónica de red (Unix/Linux, Windows, impresoras, routers, firewalls) para mandar un ICMP de tamaño superior al máximo permitido por el protocolo, pero fragmentado, de tal manera que al ser reensamblado superaba el tamaño máximo permitido y producía una denegación de servicio en la máquina que realizaba el "desfragmentado".

Pues bien, esta vulnerabilidad que fue corregida por los fabricantes a lo largo de 1997 parece que ha vuelto a resucitar, no porque se haya encontrado una vulnerabilidad idéntica, sino por el descubrimiento de una técnica similar que recuerda mucho a este ataque debido a lo difundido que está el fallo y a no necesitar requisitos grandes de ancho de banda ni disponer de un botnet ni nada parecido para realizar el ataque.

La vulnerabilidad fue descubierta por los desarrolladores del conocido escaneador de puertos Unicornscan que, según sus propias palabras, mientras realizaban unas pruebas con la herramienta se dieron cuenta que en determinadas circustancias el sistema escaneado respondía a algunos paquetes continuamente hasta que el sistemas dejaba de funcionar y era necesario realizar un reinicio para que recuperara su correcto funcionamiento.

Por lo que se ha podido saber de la vulnerabilidad entre los datos publicados y un "intercambio de posts" entre Fyodor (desarrollador de nmap) y Robert Lee (uno de los descubridores de la vulnerabilidad) parace ser que se trataría de una especie de "SYN de la Muerte", debido a que parece tener algo que ver con la manera en que almacena las conexiones activas una pila TCP/IP cuando recibe un SYN. Además, por una frase que leo en alguno de estos artículos, la herramienta sockstress desarrollada como prueba de concepto (aunque no ha sido publicada) permitiría entre sus parámetros definir IP de origen y de destino, lo que me lleva a pensar si estos parámetros estarán destinados a realizar Spoofing de IP (con lo cual ya sabemos que el DoS está basado únicamente en el paquete SYN) o si por el contrario el ataque es del tipo Echo-Chargen y consiste en hacer que el sistema se reenvie paquetes hasta que se colapse por si mismo.

En cualquier caso, los fabricantes ya están trabajando para lanzar los parches de seguridad adecuados, que serán publicados el día 17 de Octubre, justo antes de que los descubridores de la vulnerabilidad den los detalles técnicos en la T2 Security Conference de Finlandia.

Estemos todos atentos a la publicación de los parches y apliquemelos cuanto antes, antes de que empiecen a aparecer herramientas DoS "on the wild", recordad que esta vez no hace falta disponer de una botnet, un atacante solo necesita lanzar unas pocas conexiones para detener el servicio de nuestras máquinas.

miércoles, 1 de octubre de 2008

Vulnerabilidad Dan Kaminsky (I)

Como es de suponer muchos de vosotros habréis leído por infinidad de sitios sobre la vulnerabilidad de DNS que ha provocado un revuelo considerable.

En esta entrada voy a "intentar" explicarla con un poco detalle para quien tenga curiosidad de cómo se producido y por qué.
Los requisitos para no perderse demasiado es saber cual es básicamente el funcionamiento del protocolo DNS. Para esto aconsejo los siguientes enlaces que lo explican y dan una visión general:

Wikipedia
Video tutorial

Una vez ya tenemos claro el mecanismo del protocolo DNS de manera genera y para que sirve, empezaremos en esta primera entrada explicando aquellas partes del protocolo implicadas en la vulnerabilidad para que después sea más fácil comprenderla:

Descripción del protocolo DNS

Lo primero que debemos saber y refrescar es cual es la estructura de un mensaje del protocolo rfc1035: Lo primero de todo es saber que un mensaje DNS se estructura 5 secciones:


  1. Header
  2. Question
  3. Answer
  4. Authority
  5. Additional

A continuación se explicarán brevemente las secciones relevantes para entender la vulnerabilidad, no siendo el objetivo de esta entrada explicar todo acerca del protocolo, pero sí lo suficiente. Por lo que se explicarán Header, question y Additional Records.

1. Header

ID: Identificador de 16 bits que genera el que realiza la petición, este identificador se copia en la respuesta y puede ser utilizado por el que realiza la query para como que es la respuesta a su petición; pudiendo descartar respuestas de un tercero.

QR: Especifica si es una pregunta ó una respuesta.

Opcode: Indica el tipo de query.

AA: Si este bit está activo indica que el servidor de nombres que contesta es una autoridad del nombre de dominio.

TC: Mensaje truncado en la transmisión. RD: Si está activo le indicamos al servidor que continue la pregunta recursivamente. RA: En un respuesta nos indica si está activo si el servidor permite recursión. Z: no se usa. RCODE: Indica el tipo de respuesta. QDCOUNT: número de entradas en la sección de la pregunta. ANCOUNT: número de entradas en la sección dedicada a la respuesta. NSCOUNT: número de entradas en la sección dedicada a la AA. ARCOUNT: número de registros en la sección adicional.

2. Question


QNAME: nombre de dominio

QTYPE: tipo de query.


QCLASS: clase query.

3. Additional Records (Resource Record)


NAME: Nombre de dominio al cual este RR pertenece.

TYPE: contiene el tipo de RR. Especifica el significado de los datos de RDATA.

CLASS: especifica la clase de datos del campo RDATA.

TTL: Tiempo en segundos que el RR puede ser cacheado/almacenado, después debería ser eliminado. El valor de cero indica que no almacenes.

RDLENGTH: tamaño del campo RDATA.

RDATA: Variable que describe el recurso.

Ejemplo de una petición DNS

Esto sería el contenido de una query preguntando por www.google.es:


Ilustración 1: Query DNS

Observamos como tiene el bit Recursion Desired a 1 y el campo Questions a 1.

Lo siguiente sería la contestación del servidor DNS:

Ilustración 2: Response

Lo primero que se observa es como el ID es el mismo tanto en la pregunta como en la respuesta. Vemos como la respuesta incluye 5 recursos derivados de su pregunta, 2 alias y 3 registros de tipo host (A) que indican la dirección de red. Además vemos 7 Authority nameservers y 7 RR’s adicionales.

Con esto hemos visto cuales son los registros del DNS que después nos ayudarán a entender un poco mejor el ataque de Dan Kaminsky y cómo se realiza una petición sensilla a un servidor DNS. En una entra posterior veremos ataques existentes y el nuevo descubierto por Dan Kaminsky.








sábado, 27 de septiembre de 2008

ClickJacking

Clickjacking es una técnica reciente que ha sido descrita por varios especialistas de seguridad que han podido tener acceso a los detalles de la vulnerabilidad como TERRORIFICA. Según los datos que se han facilitado, la vulnerabilidad permitiría a un atacante preparar un sitio web malicioso mediante el cual podría realizar un "secuestro de clicks", es decir, cada click que hagamos en el navegador podriamos estar clickando en otro sitio que no es el que pensamos, con el consiguiente riesgo de ejecución de malware y amenazas similares.

Los detalles de la vulnerabilidad, que afecta a practicamente todos los navegadores, iba a ser presentada en la OWASP AppSec de Nueva York pero parece ser que ha sido cancelada debido al riesgo de dar los detalles antes de que los fabricantes hayan podido desarrollar sus parches, hecho complicado puesto que según han confirmado ellos mismos no es una vulnerabilidad de fácil solución.

Por los datos que se han podido obtener, exploradores "lynx-like" no son vulnerables a este tipo de ataques. Otro de los datos que se ha publicado es que no tiene nada que ver con Javascript, por lo que usar complementos tipo NoScript no será 100% efectivo (aunque por lo que se ha podido averiguar sí que protegerá de algunos vectores de ataque).

A partir de estos datos que se han ido filtrando, varios especialistas en seguridad han "teorizado" sobre la posible vulnerabilidad, localizandola en un problema sobreponiendo un iframe transparente sobre otro que contenga otra web, de tal manera que al clickar en la web que consideramos inofensiva estamos clickando al mismo tiempo en enlaces de la web maliciosa.
Hay sitios en los que incluso han creado una pequeña prueba de concepto.

Efectivamente, la solución teorizada parece tener sentido a partir de la información que ha sido facilitada de forma pública, pero no existe ninguna seguridad de que este sea el único vector de ataque.

Por ello, realizamos las siguientes recomendaciones a seguir hasta que se conozcan más detalles sobre la vulnerabilidad:

  • No clickar en enlaces que provengan de correo, MSN, etc ,podrían llevarnos a una web maliciosa que parezca una web legítima.
  • Utilizar RUNAS (en Windows ó su en Linux) para lanzar un navegador con un usuario con mínimos privilegios en la máquina cuando queramos navegar libremente por páginas no conocidas, y NUNCA confiar en una web legítima que aparezca en este navegador.
  • Accede a las webs relevantes para tí desde los marcadores de tu navegador.
  • Esperar ansiosamente que en fabricante publique el parche que solucione la vulnerabilidad.

jueves, 25 de septiembre de 2008

Marathon Tool & Heavy Querys

Otra herramienta de las utilizadas en la DEFCON de este año es Marathon Tool, una herramienta para auditoría web basada en inyecciones de código SQL "pesado".

La inyección SQL, como todos sabemos, es una vulnerabilidad causada por una mala comprobación de los parámetros de entrada que finalmente se traducen en una solicitud SQL a base de datos diferente de la que la aplicación web está pensada para hacer.

Generalmente, si escogemos una página web aleatoriamente en todo Internet, buscamos un campo formulario y escribimos una comilla simple (') nos encontraremos algo como esto:


Encontrarnos un error de la base de datos o incluso una sentencia SQL completa como en este caso es un claro signo de que el campo formulario que hemos encontrado sufre de una vulnerabilidad de Inyección SQL.

Este es el caso más fácil, que nos muestre claramente la web algo como esto, pero no siempre esto es posible, en ocasiones está filtrada este tipo de salida, o simplemente la salida de la sentencia SQL no es utilizada para mostrar ningún contenido en la web, por lo que para detectar si la web es vulnerable o no y para intentar explotarlo tendremos que recurrir a un Blind SQL Injection, que como su propio nombre indican son "ciegas", o mejor dicho "no evidentes", puesto que obtenemos igualmente información aunque sea por otros medios.

De entre todas las técnicas de Blind SQL Injection que existen, la herramienta Marathon Tool utiliza una técnica basada en querys SQL pesadas, ¿que quiere decir esto exactamente?, pues bien, imaginaros que una aplicación SQL normal tiene una query que es ejecutada y ofrece una respuesta en un tiempo de X segundos, tiempo que podemos apreciar más o menos observando la respuesta de la página (en función también un poco de la latencia de la red, claro). ¿Que pasa si intentamos inyectar un código que en caso de funcionar correctamente realice una consulta sin ninguna intención específica de obtener información pero que sabemos que va a tener un coste para la base de datos de 1000X segundos?. Pues en el caso de que no funcione el tiempo de carga de la web será el habitual, mientras que si funciona observaremos que el tiempo de carga es muy superior al habitual.

A partir de ahí, podemos usar esta Query para ir "haciendo preguntas" a la base de datos que tengan como respuesta sí o no y comprobando mediante ese timing cual es la respuesta que nos da la base de datos, y así de esta manera ir obteniendo información de tablas, contenidos de tablas (usuarios y contraseñas) y un largo etcetera.

Sin duda alguna, menos cómodo que obtener el listado de usuarios y passwords mostrados directamente en el contenido de la web, pero igualmente factible con un poco más de trabajo.

Aquí es donde entra esta herramienta tan interesante, tras ser configurada adecuadamente permite automátizar el proceso de búsqueda de tablas y usuarios de tal manera que no tenemos que ir realizando esas preguntas que comentabamos de forma manual, sino que es la herramienta la encargada de realizar cuantas consultas sean necesarias e ir obteniendo esta información.


Una gran herramienta, sin duda.

martes, 9 de septiembre de 2008

BAFFLE: Fingerprinting de APs

Directamente de la BlackHat USA 2008 nos llega ésta herramienta de Fingerprint de puntos de acceso.

Tal y como explican los autores de la herramienta, identificar el Hardware de un punto de acceso puede ser más sencillo o (del mismo modo) más fácil de ocultar, puesto que basta con identificar/ocultar la MAC del dispositivo, que pertenecerá a un fabricante dado.

Sin embargo ésta herramienta tiene otro enfoque más parecido al de los clásicos fingerprinter para sistemas operativos. Chequeando la respuesta del dispositivo ante diversos tipos de tráfico el software es capaz de determinar el Firmware que se está ejecutando en el punto de acceso.

Aquí tenemos un demostración grabada por los propios autores de como funciona la herramienta BAFFLE:



De momento he intentado instalarlo pero me da algún problema, así que de momento tendréis que conformaros con el vídeo.

Para el que quiera trastearlo por su cuenta, el software está pensado para funcionar con una Atheros con Madwifi.

jueves, 21 de agosto de 2008

Apache Tomcat Directory Traversal Vulnerability

El US-CERT ha lanzado la alarma de una vulnerabilidad crítica en Apache Tomcat que se puede ver detallada en la web de CVE y en la página oficial de Apache-Tomcat . La vulnerabilidad permite que un atacante pueda ver información "privada/sensible" alojada en el servidor donde está instalado el software vulnerable.

Tan pronto como aparece la vulnerabilidad empiezan a aparecer las pruebas de concepto que ayudan a los script kiddies a aprovecharla para fines maliciosos. Simplemente debemos realizar una búsqueda en google y encontraremos el enlace de milw0rm, donde aparece la prueba de concepto; además de ver la facilidad de explotarla ;).

Lo importante para un administrador de sistemas es ACTUALIZAR los sistemas a una versión NO vulnerable lo antes posible. En el caso de no disponer de actualización para la versión instalada se recomienda en el context.xml y server.xml revisar las opciones allowLinking y URIencondin y configurarlas de manera que no sean vulnerables.

Los deberes son probar en un entorno de laboratorio la vulnerabilidad y mostrar de una manera más práctica y menos teórica el impacto de la misma.

Un saludo.

viernes, 15 de agosto de 2008

Surf Jacking

Directamente desde la DEFCON nos llega una herramienta muy interesante que puede ser usada para robar cookies que se transmiten en claro por la red.

Actua como un sniffer de red y por supuesto se puede combinar con otras herramientas para hacer MitM si no nos encontramos en un medio compartido.

Al lanzar la herramienta, esta escucha en la red y va guardando las Cookies que encuentra para posteriormente ser utilizadas.

Levanta también un proxy HTTP en la IP 127.0.0.1 puerto 8080 mediante la cual podemos configurdad nuestro navegador para utilizarlo y empleando el comando "set cookies" elegir cual de las cookies robadas queremos usar.

Podemos ver un video de demostración realizado por los chicos de enablesecurity.com (desarrolladores de la herramienta) en el que nos enseñan como han utilizado esta herramienta para robar una sesión en Google:









Me quedan como deberes en cuanto a este post realizar la prueba con algunas webs conocidas más a ver que tal sale, otro día pondré una "tarta" para ver en cuantas de las webs que he probado ha resultado efectivo.

lunes, 11 de agosto de 2008

Pentester.es cambia de casa

Cuando montamos la web pentester.es se pensó en hacer la web desde cero, de esta manera podiamos prestar la máxima atención a la seguridad y evitar problemas que surgieran en otras plataformas más generalistas.

La idea en principio estaba muy bien, teniamos comprobaciones de los datos de entrada en todas partes, utilizabamos usuarios diferentes con diferentes privilegios dependiendo del PHP siguiendo el principio de mínimo privilegios, en fin, lo que se dice securizando minuciosamente.

El problema es que después de la jornada de trabajo y de las horas que pasamos dedicando a leer y probar temas de seguridad, el tiempo que nos quedaba para implementar toda la funcionalidad de la web era muy muy reducido, además de que tampoco es una de nuestras grandes pasiones la programación en PHP.

Por esta causa, resultaba muy incómodo publicar y administrar la web, por lo que nunca ha llegado a lanzarse debido a las pocas entradas que escribimos.

Al final, para mejorar la funcionalidad de la web, hemos optado por migrar la web a Blogger para disponer de toda la funcionalidad sin tener que implementar nada nuevo (así nos dedicamos a lo que realmente nos gusta, que es la seguridad). Quizá Blogger no esté tan minuciosamente cuidado en temas de seguridad (o sí, no lo sé) pero me parece que nos ofrece una buena seguridad (de hecho muchos de los blogs que leo habitualmente están alojados en Blogger).

Dicho esto, sin más rollos, RE-EMPEZAMOS, con nuestro nuevo hosting y nuestro nuevo enfoque (enseñar más que contar, ver margen derecho :P).

Saludos!

sábado, 1 de marzo de 2008

Cifratelo, Cifraselo

Hace algunas semanas se liberó la versión 5 del conocido software open source de cifrado TrueCrypt. Una de las mejoras más esperadas es la posibilidad de realizar un cifrado completo del disco, lo cual permite proteger, además de ficheros concretos, todos los ficheros temporales del sistema y al sistema en si mismo, lo cual aporta un nivel de seguridad muy alto especialmente cuando hablamos de dispositivos portátiles que suelen contener información confidencial.

El cifrado del disco se puede hacer en caliente, es decir, si os instalais el software y elegis esta opción el proceso de cifrado del disco va a realizarse mientras seguís utilizando vuestro equipo de la forma habitual (con algo menos de rendimiento, evidentemente).

Por el momento este cifrado solo está disponible para sistema Windows, así que de momento los usuarios de Linux tendremos que seguir utilizando otras alternativas, aunque espero poder ver pronto un sistema similar disponible para nuestros equipos.

El funcionamiento, una vez cifrado, es aproximadamente el siguiente:

- El sistema se compone de una "PreBoot Authentication" que se instala en el sector de arranque del disco (que no se encuentra cifrado), y de unos drivers de disco que se instalan en el sistema operativo (que sí se almacenan cifrados).

- Cuando arrancamos el equipo, el "PreBoot" nos solicita que introduzcamos una clave, esta clave (directa o indirectamente) será utilizada para descifrar el sistema operativo base y cargarlo en memoria.

- Una vez cargados los drivers de disco, estos realizan el descifrado de los datos de disco de forma transparente, es decir, cuando cualquier aplicación realiza una llamada a lectura o escritura en disco, el driver de disco obtiene la imegen del disco y la descifra con la clave, proporcionando la información sin cifrar a la aplicación.


Podeis ojear el manual para más información, descargar el producto y probarlo http://www.truecrypt.org aunque yo os recomiendo que antes lo probeis con alguna máquina virtual o algo, tened en cuenta que si cometeis un error el sistema estará cifrado y no podreis recuperar la información.

Sin embargo, y dado que este es un blog de seguridad, aunque este software sea una buena herramienta para mejorar la seguridad de nuestros equipos portátiles, no perdais de vista algunos riesgos que tendreis que tener en cuenta.

1) No useis contraseñas como "Patata" o "Manolo" ni en el cifrado del disco ni en el PreBoot. Tened siempre presente que un excelente sistema de cifrado puede verse comprometido solo por haber utilizado una contraseña trivial.

2) Mantener la seguridad de sistema operativo. Tened en cuenta que una vez arrancado el cifrado es transparente para el sistema operativo y para las aplicaciones, por lo que si estando encendido alguien explota una vulnerabilidad en él podrá acceder sin problemas a la información del disco puesto que utilizará el driver de disco cargado con la contraseña correcta que fue introducida por el usuario en el arranque.

3) Mucha precaución con el robo de portátiles encendidos (aunque esté la sesión bloqueada), podrían mantenerlo encendido hasta que aparezca alguna vulnerabilidad en el sistema operativo y luego explotarla para acceder a los datos, o bien podrían utilizar el famoso "Ataque del Frio" (http://citp.princeton.edu/memory/) para recuperar parte de la clave de cifrado del disco y averiguar mediante un ataque de fuerza bruta las partes de la clave que hayamos perdido en el proceso.

Teniendo en cuenta estas amenazas, podemos encontrarnos con una herramienta muy potente, que proporciona un buen nivel de seguridad y por si fuera poco: GPL.

miércoles, 30 de enero de 2008

Cursos y Certificaciones Profesionales


Para aquellos profesionales que estén buscando ampliar conocimientos y hayan pensado en realizar alguna certificación o curso, a continuación propongo un listado de las principales certificaciones relacionadas con el área de la seguridad informática.


ITIL. Marco de trabajo de las mejoraes prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. Ofrecido por la OGC británica (Office of Government Commerce UK).


CISSP (Certified Information Systems Security Professional ) de ISC2 , certificación de seguridad independiente. Trata de abarcar diversos dominios de seguridad TIC, desde controles de acceso a criptografía o continuidad de negocio.


CISCO CCNA Curso Técnico en redes e internet. Prepara a los candidatos a orientar su carrera profesional hacia las infraestructuras de redes y comunicaciones en Internet.


CISCO CCNP Curso de Especialista Experto en Redes e Internet. Es una titulación de alto nivel por combinar profundos conocimientos de las Redes e Internet. Preparar a los candidatos para la resolución de incidencias de red en situaciones de urgencia.


Linux Skill Certification del LPI (Linux Professional Institute), constituye un programa diseñado para certificar a los profesionales de TI en el uso del SO Linux y sus herramientas asociadas.


Brocade. Ofrece numerosas certificaciones técnicas, destacando entre otras la “Brocade Certified SAN designer” orientada al diseño de tecnología SAN.


CompTIA security+. Certificación ofrecida por la Computing Technology Industry Association que valida el conocimiento en diversas faceta de la seguridad TI: infraestructura, criptografía, seguridad operacional, etc.


HP. Diversas certificaciones en el ámbito de las TIC


IBM. Diversas certificaciones en el ámbito de las TIC


Microsoft. Diversas certificaciones en el ámbito de las TIC


Nortel. Compañía líder en comunicaciones. Certificaciones orientadas a los entornos de red y comunicaciones.


Novell. Certifiaciones en entornos Linux y Netware.


Certificaciones ORACLE orientadas a Bases de Datos, Linux, Midleware y desarrollo de aplicaciones.


CWNP ofrece varias certificaciones en entornos Wireless


SAS software expertise. Certificaciones en desarrollo software.


SNIA ofrece la certificación SNCP orientada al almacenamiento masivo en red.


SUN ofrece diversas certificaciones en los diferentes entornos TIC


Symantec. Certificaciones en protección de datos, Veritas en dos variantes especialista y profesional.


AENOR. SEGURIDAD EN TECNOLOGÍAS DE LA INFORMACIÓN E INGENIERÍA DEL SOFTWARE


Certificación CISA o CISM: cursos de preparación al examen.


Catálogo de cursos esCERT-UPC "Seguridad en sistemas de información"


SANS Institute, organización dedicada a la investigación y formación en seguridad de la información. Dispone de multitud de recursos sobre seguridad de la información (noticias, guías, certificaciones, etc.).


Nota: Para que los lectores puedan responder su opinión sobre las certificaciones, activamos desde hoy mismo el envio de comentarios.

NOTA2: Artículo de Roberto Amado


viernes, 25 de enero de 2008

Buscador de Exploits

La web ExploitSearch nos ofrece un interface de búsqueda que nos proporciona una manera cómoda para la búsqueda de exploits.
Según los desarrolladores de la web, consiguen esta búsqueda realizando peticiones especialmente seleccionada contra Google. Es una pena que dichas peticiones permanezan ocultas para nosotros, sería muy interesante saber que peticiones realiza exactamente, pero mientras tanto puede ser una manera mucho más cómoda que buscar cada vez en Google: "exploit aplicacionX main include printf" y cosas similares para intentar discriminar de todas las webs, solo aquellas en las que se encuetra el código fuente del exploit (y probar para C, para perl, etc).


Os dejo aquí empotrado el interface por si quereis hacer alguna prueba, pero si os gusta os recomendaría que lo guardarais ya en vuestro marcadores: http://exploitsearch.com










lunes, 14 de enero de 2008

Nivel de seguridad inalambrica en la ciudad de valencia

El pasado fin de semana estuve dando un paseo portátil en
mano por la ciudad de valencia obteniendo resultados aterradores. Las
capturas de datos en el escenario de pruebas ofrecieron la
posibilidad de establecer una categorización del uso de los
métodos de cifrado inalambrico por parte de la población
consultada. Permitiendo medir el nivel de seguridad de las redes
Wireless en la capital del Turia.

Se Obtenieron como resultado cuatro grandes grupos: redes
abiertas "OPN", AP's con seguridad WEP, redes que hacen uso de
WPA y puntos de acceso con WPA2. Los datos recabados reflejan el
grado de seguridad de las conexiones inalámbricas que utilizan
el estándar IEEE802.11, estimando de esta forma la exposición
de riesgo de la población que hace uso de este tipo de
tecnología.

El siguiente gráfico establece el porcentaje de uso de cada
protocolo obtenido de una muestra de

2658 puntos de acceso tomada en el escenario de pruebas, con la
siguiente distribución.

  • 538 puntos de acceso sin cifrado de datos

  • 1514 con seguridad WEP

  • 513 redes con el protocolo de seguridad WAP activado

  • 93 AP's que usan WPA2





Como se puede observar en el gráfico superior, el 20 % de
los puntos de acceso no contempla ningún tipo de cifrado de
datos o control de acceso. El 57 % utiliza seguridad WEP, mientras
que el 19 % hace uso de WPA en su punto de acceso inalámbrico.
En último lugar aparece WPA2 con un escaso 3% de uso.

Puedo casi asumir con certeza que el 99% de los puntos de acceso
con WEP son explotables de forma exitosa. Me aventuraré aun
mas a decir que el 15% de los puntos de acceso con WPA pueden ser
atacados con resultados positivos. De la misma forma el 15% de los
AP's con WPA2, lo son también (debido a que los métodos
de ataque son los mismos, diccionario y Rainbow tables). Si a ello le
sumamos el porcentaje de las redes abiertas obtenemos el siguiente
resultado.


Sí, el 80 % de las redes inalámbricas
en la ciudad de Valencia son Vulnerables


NOTA: Artículo de Roberto Amado