lunes, 31 de octubre de 2011

Recuperando cookies de Internet Explorer con Flub0.4

Compartir este artículo:
 

Buenas a todos, en el post de hoy me gustaría mostraros una posible manera para recuperar las cookies almacenadas por Internet Explorer en una máquina infectada con la última versión pública de Flu, la b0.4, y que podéis descargar desde aquí.

En nuestro blog ya hemos hablado otras veces del tema de la suplantación de cookies como en los artículos Hijacking en TuentiHijacking en Twitter o en Cookie Monster: automatizando el hijacking, por lo que omitiremos el paso de suplantar la cookie, y nos limitaremos a recuperarla.

En primer lugar accederemos a la consola CMD remota de la máquina de la que queramos recuperar las cookies de Internet Explorer:

 

 

Deberíamos saber la carpeta en la que se almacenan las cookies de IE para poder recuperarlas. Tal información la podéis obtener navegando por la máquina, o consultando la siguiente clave del registro: "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\LowRegistry\IEShims\NormalizedPaths". Por ejemplo para el caso de Windows 7 sería la siguiente:

 

 

Desde la consola mostraremos el contenido de dicha carpeta, para ver todas las cookies que hay almacenadas en ficheros de texto plano. Como la máquina infectada es un Windows 7 podemos valernos de powershell:

 

 

Ahora recuperaremos las que nos interesen con el comando "getfile":

 

 

Si vamos finalmente a nuestro servidor Web, en la carpeta "descargas" que contiene el panel de control de Flu, tendremos una copia del fichero, y podremos ver la cookie solicitada:

 

Espero que os haya gustado el post, de vez en cuanto os iremos contando trucos como este para explotar todas las funcionalidades de la nueva versión de Flu.

 

Saludos!

domingo, 30 de octubre de 2011

Informe Flu - 43

Compartir este artículo:

Disfrutad del resumen:

Lunes 24 de OctubreMartes 25 de OctubreMiércoles 26 de OctubreJueves 27 de OctubreViernes 28 de OctubreSábado 29 de Octubre

sábado, 29 de octubre de 2011

Vuestras opiniones

Compartir este artículo:

Buenas a todos, hoy aprovecharemos el post para daros los datos que se han ido recogiendo en el portal de las últimas encuestas que hemos ido realizando a lo largos de los meses pasados.

En la última encuesta os preguntábamos sobre vuestras distribuciones de seguridad favoritas. La distro favorita fue Backtrack con 118 votaciones, seguida de Blackbuntu con 34, Ophcrack con 30, GnackTrack con 16, Kon-Boot con 12 y BackBox con 8.

Por otro lado os hicimos una encuesta durante el verano en la que debíais valorar cual era la rama de la informática a la que veíais más futuro. La rama más votada fue el Desarrollo móvil con 42 votos seguido del Desarrollo web y empatado con las Auditorias de seguridad con 16, Consultoría en general con 10, Formación a empresas con 4 y finalmente con un voto "A los curiosos Community Manager".

Finalmente, antes del verano os hicimos la pregunta ¿Qué rama de la informática llama tu atención?, y distéis los siguientes resultados: Auditoría de seguridad  fue la más votada con 86 votos y seguida algo alejada de la Consultoría de sistemas con 39 votos, Desarrollo de aplicaciones con 35 votos, Docente con 20 votos, Soporte técnico con 13 votos y Equipo de pruebas con 13 votos también.

Ahora estamos realizando una encuesta sobre los retos hacking que publicamos todos los meses, y a la que podéis acceder desde el menú derecho de nuestro portal.

Gracias por dejarnos vuestras opiniones!

¿Cuáles son vuestras opiniones?

saludos!

viernes, 28 de octubre de 2011

MSA-11-0036: Messaging refresh vulnerability

Compartir este artículo:

Bonito nombre le pusieron al ataque de denegación de servicio que publiqué el pasado 10 de Septiembre en el blog. Reportado al foro de Moodle y revisado en el Tracker, la severidad del ataque era calificada como “Serious”, pues las repercusiones que podía provocar como comenté anteriormente, eran la caída del servidor, debido a la inundación de peticiones y posibles daños como el crasheo de la BD.

Las versiones vulnerables eran todas las conocidas hasta la fecha, anteriores a la 1.9.14. A pesar de que Moodle está desarrollando su versión 2.x, la anterior sigue puliéndose con actualizaciones continuas, siendo esta la más utilizada.

Según la descripción dada por Michael de Raadt, Manager del desarrollo de Moodle:

Topic:Message refreshing system may cause unlimited queries and DDos attack
Severity:Serious
Versions affected:< 1.9.14 (2.x not affected)
Reported by:Xavier Paz
Issue no.:MDL-29311
Solution:upgrade to 1.9.14
Changes (1.9):http://git.moodle.org/gw?p=moodle.git;a=commit;h=97f258fabb3ebfa7acc7c02cb59de92b01710f99
Description:

Users could change the wait parameter from message/refresh.php to zero to cause a denial of service attack.

¡Realmente lo más jodido es que aparezca la persona que movió mi tema al Tracker! ¿Y yo que pasa? ¡Qué copiar y pegar sabemos todos! ¡Sino que se lo digan a los desarrolladores del FIFA!

http://moodle.org/mod/forum/discuss.php?d=188318

Para la corrección manual que ha deseado publicar el equipo de desarrollo, tenemos esta alternativa similar a la que expuse.

Cerraremos de este modo el bucle infinito que conseguíamos, al modificar la URL de forma manual, gracias a la función ceil que redondeaba al número más alto entero resultante, se lograba el fallo. Así después de incorporar la actualización (0*1,2 = 0 → 0) terminaría siendo un entero positivo no vulnerable, gracias a la implementación de un simple if.

Además, aparecieron otras 6 vulnerabilidades para los que seguimos con la v1.X, lo cual se recomienda actualizar a todos aquellos que posean versiones anteriores a 1.9.14.

  • MSA-11-0031 - Fallo en las constantes de la API de formularios.
  • MSA-11-0032 - Problema de validación SSL de MNET.
  • MSA-11-0036 - Vulnerabilidad en el refresco de los mensajes.
  • MSA-11-0037 - Inyección en la edición de las secciones de curso.
  • MSA-11-0038 - Reforzada la protección contra inyecciones en base de datos.
  • MSA-11-0040 - Potencial revelado de información personal.
Saludos 4n4les! ;)

jueves, 27 de octubre de 2011

Herramientas hacking by SecurityTube

Compartir este artículo:

Security Tube es de esos sitios que merecen la pena visitar a diario. Es conocido por los videos de contenido hacking e interesantes tutoriales. Pero hay más tras esta página y nos proporciona una gran fuente de herramientas para testear la seguridad en la red.

Estas son las categorías que tenemos en la sección tools de la web:

Como se puede ver hay de todo en este bazar del hacking. Os recomiendo tiempo para estudiar las herramientas y cada uno deberá hacerse con su conjunto favorito de herramientas.

Nosotros en Flu Project os proponemos un listado de aplicaciones de auditoría de seguridad que nos gustaría ir ampliando entre todos. Podéis acceder a él desde el siguiente enlace:

http://www.flu-project.com/sobre-flu/herramientas-de-auditoria-de-seguridad

Iremos actualizando las herramientas de la página con las que nos vayáis enviando. Y recordad que el límite es tu imaginación.

Comentad cuales son vuestras favoritas, ¡anímense! ;)

miércoles, 26 de octubre de 2011

#FPR3 – Reto de Octubre: ¡Fusión!

Compartir este artículo:

Buenas a todos, hoy damos comienzo al tercer reto hacking de Flu Project, al que hemos titulado "¡Fusión!" y en el que de nuevo tenemos el placer de contar con la colaboración de @hecky, de neobits.org. El hashtag oficial de Twitter para este reto será #FPR3.

El reto, con el que hemos querido hacer un guiño a los fans de la serie Dragon Ball (como un servidor), consiste en un único documento que deberéis descargaros en vuestro equipo. El documento contiene todas las pistas necesarias para pasar el reto.

Descargar documento

Dentro de una semana publicaremos la respuesta al reto, así como el listado de la gente que haya logrado pasarlo ;)
Suerte, saludos!

martes, 25 de octubre de 2011

Análisis de comportamiento de un troyano

Compartir este artículo:

Hola!

Muy buenas a todos/as!

Hoy publicaré algo distinto y será el análisis de comportamiento de un troyano. Será algo muy básico iré avanzando conforme me vaya informando del tema.

Este artículo lo que haré será poner wireshark y ver las conexiones que establece el troyano, además de luego con process explorer y installrite ver los cambios que han habido en el sistema después de la infección con el builder.

Lo primero antes de hacer ninguna infección es guardarme con installrite un snapshot del registro y archivos del sistema para luego poder comparar los cambios, además de hacer un snapshot de la máquina virtual claro.

Una vez que me he infectado por el troyano arranco Wireshark y veo que el troyano intenta conectarse al servidor “maligno”.

Podemos ver las peticiones que haría el troyano en caso de querer conectarse al servidor desde donde enviará los datos se descargará actualizaciones etc.. Como el servidor no existe no recibe respuesta alguna, en la próxima entrega veremos como envía los datos capturados y más cosas.

Ahora con process explorer vemos el proceso que ha abierto el troyano.

Podemos ver en esta imagen varia información. No tiene asociado ningún proceso padre, debería de ser explorer.exe.

Además el command line aparece una sorpresa server.exe. A simple vista con process explorer sin mirar los detalles parecería un proceso legítimo. Sólo que yo no tenía ningún Internet Explorer abierto, además de que revisando los detalles puedo ver perfectamente la infección.

Si lo comparamos con un proceso de Internet Explorer legítimo:

Podemos ver correctamente el proceso padre, además de que la ruta en el command line es el correcto. Y, si miráramos process explorer veríamos que crea un proceso en otro hilo, y no crea desde un proceso padre varios procesos hilos. :)

Y ya con Installrite vemos que han habido cambios y a destacar entre ellos vemos que se ha añadido el archivo server.exe.

Podemos ver el server.exe en Datos de Programa Y hasta aquí un brevísimo análisis de comportamiento.Un saludo

 

lunes, 24 de octubre de 2011

Flu b0.4 detectado por 19 antivirus

Compartir este artículo:

Buenas a todos, como muchos de vosotros ya nos habéis ido contando durante las dos últimas semanas, poco a poco han ido aumentando el número de antivirus que han comenzado a detectar a la nueva versión de Flu, la nueva b0.4, como un malware de tipo troyano.

Hemos procedido a realizar una serie de pruebas con Virustotal, ya que muchos de vosotros lo habíais subido con anterioridad. En primer lugar hemos subido el ejecutabale que viene compilado por defecto, apuntando a localhost, este ejecutable no puede usarse evidentemente para infectar a nadie, porque la conexión la intentaría hacer con la IP 127.0.0.1. Aún así, 19 casas de antivirus han decidido bloquear este exe.

Para la segunda prueba, hemos generado un nuevo bot con el generador de bots, apuntando a otra IP, de esta manera cambia el hash del exe final. Tras subir este nuevo archivo a virustotal, se reducía a 13 el número de antivirus que detectaban a Flu (por lo que la detección de los otros 6 realizada con el primer exe de Flu no serviría de mucho):

Finalmente hemos abierto este nuevo exe en modo texto, y hemos modificado un byte. Tras subirlo hemos podido comprobar como solo 2 antivirus eran capaces de detectar a Flu b0.4:

Nos ha hecho mucha ilusión, como a un niño con juguete nuevo, la noticia de que los antivirus nos hayan comenzado a tener en cuenta, ya que aunque Flu Project tiene un objetivo totalmente benigno para la sociedad, contribuyendo al conocimiento de seguridad y colaborando para perseguir el cibergrooming en Internet de la mano de Anti-Depredadores, este hecho significa que las casas de antivirus se han hecho eco de nuestro proyecto, y se ponen manos a la obra para protegernos a todos los usuarios de los peligros de Internet (aunque hayan tardado 10 meses en bloquear a Flu).

Saludos!

domingo, 23 de octubre de 2011

Informe Flu - 42

Compartir este artículo:

Disfrutad del resumen:

Lunes 17 de OctubreMartes 18 de OctubreMiércoles 19 de Octubre
  • Marc nos trae esta semana un artículo en el que nos enseña lo que deberíamos hacer tras recibir un correo de SPAM Analizando correo NO deseado
Jueves 20 de OctubreViernes 21 de OctubreSábado 22 de Octubre

sábado, 22 de octubre de 2011

¿Te vas a perder la #ConectaCon 2012?

Compartir este artículo:

Buenas a todos, en el post de hoy queríamos hablaros del congreso de seguridad ConectaCon, que están preparando desde la Asociación Tecnológica EnRed  2.0 (http://www.enred20.org/).

El evento ConectaCon, es un congreso de seguridad informática para Jaén, cuyo objetivo es a través de ponencias y talleres concienciar a las empresas de  la importancia de utilizar medidas de seguridad cuando se pretende tener presencia en Internet y dar un enfoque técnico sobre la materia a los alumnos de las diversas titulaciones relacionadas con la informática pertenecientes a la Universidad de Jaén.

El lugar de celebración del evento será las instalaciones de la Universidad de Jaén, durante los días 20,21 y 22 de Marzo de 2012.

Contarán con la presencia de personajes muy conocidos del sector que darán una serie de ponencias y talleres sobre seguridad en Android, Metadatos, Web Hacking, LOPD, Auditoría de Seguridad y un largo etcétera.

Aprovechamos para hacer un llamamiento a posibles patrocinadores que quieran colaborar en el evento.

Descargar Dossier

Saludos!

viernes, 21 de octubre de 2011

El sistema de ficheros procfs o “/proc”… Ese gran desconocido

Compartir este artículo:

La mayoría de los Unix y Linux, cuentan con un útil pero, en ocasiones, desconocido directorio, el cuál nos ofrece un amigable interfáz con los procesos que corren en el sistema.

Esta capa de abstracción, se denomina “procfs” y podemos tener acceso a ella como si de un sistema de ficheros se tratase en /proc.

La estructura de /proc, es muy simple. Si hacemos un listado del contenido de este directorio, veremos algo similar a esto:

La estructura de /proc, es muy simple. Si hacemos un listado del contenido de este directorio, veremos algo similar a esto:

En esta captura, podemos ver, por un lado directorios asociados a los procesos identificados por un número (el PID, o Process ID) y por otro, algunos directorios y ficheros que hacen referencia a diferentes carácterísticas de equipo. Si nos metemos en cualquier directorio de proceso, tendremos acceso a información acerca de su linea de comando, memoria, PPID. En resumen, estos ficheros y directorios que encontraremos aqui, recogen diferente información acerca del funcionamiento del programa. Esta información, en su mayoría, se almacena en formato ascii y es accesible mediante el uso del comando cat.

Por ejemplo, si queremos conocer con qué linea de comando se ha lanzado el proceso 34223, únicamente deberemos ejecutar:

$ cat /proc/34223/cmdlinesshd: usuario1@pts/0Además, dentro de profs, podemos encontrar muchísima información sobre la configuración del hardware de nuestro equipo:

  • Tipo y características de la/s CPU/s: $ cat /proc/cpuinfo
  • Modulos de cifrado activos: $ cat /proc/crypto
  • Claves almacenadas/cacheadas por el kernel: $ cat /proc/keys
  • Versión del kernel y compilador: $ cat /proc/version

También resulta muy interesante subdirectorio /proc/sys. Desde el mismo, es posible ver y modificar, algunos parámetros de la configuración del equipo, y si vamos a /proc/sys/net, podemos hacer lo propio con la red. Por ejemplo, para ver o modificar el estado del IPForwarding entre los interfaces, tan solo debemos ejecutar:

$ cat /proc/sys/net/ipv4/ip_forward

Para activarlo deberemos escribir (como root)

# echo 1 > /proc/sys/net/ipv4/ip_forward

Y simplemente, para desactivarlo:

# echo 0 > /proc/sys/net/ipv4/ip_forward

Otros parámetros que podemos fijar u observar desde este directorio son:

/proc/sys/net/ipv4/…

  • icmp_ratelimit e icmp_ratemask: Permiten controlar el rátio de generación de paquetes ICMP, por red.
  • icmp_echo_ignore_all: Activado, desactiva el envío de respuestas a ping por parte del sistema.
  • icmp_echo_ignore_broadcasts: Activado, ignora cualquier respuesta a ping que tenga como origen una dirección de broadcast (muy util en determinadas redes)
  • ip_conntrack_max: Fija el número de conexiones que el sistema puede tener en su tabla de conexiones. Por defecto, está fijado a 65536. En caso de que nuestro servidor tenga muchas conexiones concurrentes, se puede elevar o pensar en jugar con otros valores como el tiempo de conexión o el uso de balanceo de carga. Un numero elevado de conexiones, se diagnostica facilmente cuando empezamos a recibir en nuestro syslog mensajes del tipo “ip_conntrack: table full, dropping packet”. El número de conexiones concurrentes actual, podemos verlo en /proc/net/ip_conntrack.
  • ip_default_ttl: Fija el TTL de los paquetes IP
  • ip_local_port_range: Limita (o amplia) el rango de puertos usados como puertos de origen en las conexiones locales.
  • tcp_rfc1337: Activado, permite cortar conexiones en un tiempo menor del
  • tcp_syncookies: Activado, aumenta la seguridad frente a spoofing ciego, ya que activa en el kernel la utilización de un número de secuencia basado en la dirección de IP de origen, IP destino, número de puerto y el tiempo que hace que el paquete fué enviado.

Si no queremos hacer uso de este sistema, también podemos acceder o fijar estos valores mediante el comando “sysctl”. Con él, es posible acceder a todo lo que hemos visto en el apartado anterior, así como guardar la configuración en el fichero /etc/sysctl.conf.

Si quereis profundizar sobre este útil sistema de ficheros virtual, podeis visitar el correspondiente artículo en la Wikipedia (inglés):

Saludos,

 

jueves, 20 de octubre de 2011

Esteganografia en el Histograma de una Imagen

Compartir este artículo:

Hola, la entrada de hoy sera muy pequeña ya que solo les mostrare una técnica y una herramienta online.

Ya hemos hablado de Esteganografia en el espectrograma hoy hablaremos sobre Esteganografia en histogramas,asi es otra palabra rimbombante técnica rara y exquisita. Pero empecemos desde el principio osea de como la conocí.

Hay muchísimas personas que admiro de España pero al principal personaje que admiro sin duda alguna es a “Dani kachakil” ¿Que quien es kachakil? Miembro de int3pids, persona sumamente inteligente y con el don de la enseñanza. Todo esto viene a que como soy muy admirador de kachakil es obvio que leo su pagina kachakil.com donde tiene en PDF varios resolucionarios de Varios retos.

Para esta entrada me quiero referir específicamente al solucionarío del “Hackcontest de Miguel Gesteiro” donde se da a la luz lo que hoy mostrare. En esta publicación se muestra Una imagen con un grado de Esteganografía y precisamente en el histograma, lo pueden ver en la siguiente imagen.

El histograma de Una imagen es la relacion que existe de grises en una imagen. Aqui claramente se ve que el histograma fue alterado y nos da un codigo de barras. Despues de sorprenderme por tan rara y “sensual tecnica” seguí leyendo hasta encontrarme con algunos otros ejemplos de esta tecnica.

Al “parecer” la gente de “Ironic Sans” tuvo esta magnifica idea (Idea: The Histogram as the image). Y lo que se hizo es que se creo un histograma de la ciudad de nueva york y nos dio como resultado una imagen gradiente:

La idea se fue perfeccionando y Josh Millard de (JoshMillard.com) Incluso logro el histograma se pareciera bastante a la imagen original:

En esta entrada “Retro-histo: making an image fit your histogram!” Josh pone varios ejemplos asi como un repositorio de imagenes e histogramas.

Al final la gente de “Ironic Sans” en esta otra entrada (I wrote it, you made it: Histoface)  nos presenta un trabajo de “Steward Smith”, una aplicacion web que nos permite escribir mensajes de hasta 8 caracteres en el histograma y regresandonos una imagen gradiente de gris.

Con ustedes “HistoFace” Aqui pueden ver algunos ejemplos.

Esta imagen   Tiene este histograma

Pero como ya saben que yo soy fan de lo CLI y para ver el histograma no me agrada mucho la idea de estar abriendo gimp (o cualquier editor grafico) que es un programa pesado y me ocupara muchos recursos para esta simple tarea. Mejor les enseñare como verlo en un rapido comando con imagemagick

1
convert imagen histogram:imagensalida.png

El comando de arriba agarra una imagen y le decimos que nos interesa el histograma (histogram:) y seguido de los dos puntos es la salida. En este caso podemos darle una imagen de salida al histograma.

Pero no es practico tener una imagen sacar el histograma y tener que abrir otra imagen con el visor de imagenes. Asi que usaremos un truco en la salida.

1
convert heckyhisto.png histogram:x:-

Aqui leemos el histograma de heckyhisto.png y la salida la mandamos a “x:-” Este truco lo que hace es que nos la muestre de imediato osea no le damos salida a otra imagen, sino que la mostrara de inmediato con un simple visor de Imagemagick =)

Excelente truco no? =D

Bueno sin mas ya pueden crear sus propios histogramas personalizados. Por mi parte creo es una técnica super interesante que investigare mas a fondo.

P.D. Por cierto no se como Miguel Gesteiro habra creado su histograma, si alguien le saca la sopa que nos avise ^.^

Saludos ;)

Atte. hecky

hecky@neobits.org

Sigueme en twitter: http://twitter.com/hecky

miércoles, 19 de octubre de 2011

Analizando correo NO deseado

Compartir este artículo:

Hola!

Muy buenas a todos/as!

Supongo que todo el mundo que tiene una cuenta de correo alguna vez habrá recibido correo SPAM. Este correo muchas veces es filtrado ppor los filtros de correo, pero en otras ocasiones aparecen en nuestra bandeja de entrada y estos correos pueden llegar a contener virus, o publicidad engañosa.

Dispongo de muchos correos de esos, por lo tanto iré analizando que hacen esas páginas además de analizar algún programa, que te haga descargar la URL maliciosa del correo.

Primero tenemos esta URL.

URL maliciosa

Lo primero que haremos será pasar la URL por un analizador, en este caso usaremos Virus Total, podemos ver el reporte aquí

Reporte Virus Total

Abrimos la URL y miramos que aparece

Si miramos el código fuente podemos ver que cuando accedemos nos redirige a otra web:

You are here because one of your friends have invited you <br>to try our free trial. <br>Hurry up! Limited quantity available!<br>We try to be helpful for you.<br>Page loading, please wait….<meta http-equiv=”refresh” content=”4; url=http://gromekha.ru/trial2/”>

Podemos ver al dominio que seremos redirigido.

En este caso, el análisis del dominio es catalogado sólamente por 1 como Phising Site

Reporte  Virus Total

Si miramos en Robtex, también es catalogado en una blacklist

Si miramos el código fuente de la web que ha sido catalogada en una Blacklist, además de considerarse un sitio de Pishing, podemos ver que hasta tienen cuenta de Google Analytics!!!!!!

var _gaq = _gaq || [];_gaq.push(['_setAccount', 'UA-19276994-1']);_gaq.push(['_setDomainName', 'none']);_gaq.push(['_setAllowLinker', true]);_gaq.push(['_trackPageview']);

Podemos hacer una búsqueda de esos ID de Google Analytics

Resultados

¿Significa que todas las webs en la que aparece este código de Analytics será un posible Phising?

Quien sabe..

 

martes, 18 de octubre de 2011

IPSec: protegiendo el nivel de red (parte II)

Compartir este artículo:

En el anterior artículo sobre IPSec hicimos una presentación del conjunto de protocolos sobre los que se basa IPSec para securizar el nivel de red. Hoy vamos a ponernos en la parte práctica para configurar IPSec de manera genérica. Cuando queramos securizar un protocolo, ya sea de red o de transporte.

PoC

Vamos a configurar, explicando en detalle, IPSec entre 2 máquinas como pueden ser un XP y un Windows 7. También IPSec se integra en el directorio activo ayudado por las políticas. Esto se verá en la tercera parte de la serie sobre IPSec. Recordad que IPSec va a nivel de máquina en las políticas de seguridad, y no a nivel de usuario.

En la siguiente imagen podéis observar en que parte se encuentran las directivas de seguridad de IP, conocido como IPSec.

En la anterior imagen se pueden observar las 3 directivas de seguridad de IP que vienen por defecto, cliente, servidor y servidor seguro. Son interesantes para aprovecharnos de la funcionalidad programada que ya traen por defecto. Pero si nos interesa configurar desde 0, podemos crear una nueva directiva con botón derecho y crear directiva de seguridad IP. Es importante recalcar que solo se pueda aplicar una directiva de seguridad de IP en un equipo. Es algo normal, ya que una directiva está compuesta por reglas, y es aquí dónde entra el jugo de IPSec, podemos configurar distintas reglas para distintos protocolos.

Vamos a suponer el caso de que creamos una directiva de seguridad de IP, el aspecto que presenta la ventana de reglas es la siguiente:

En el ejemplo se puede observar una regla dinámica, que viene por defecto y no se puede borrar, es para compatibilidad con sistemas anteriores. Podemos visualizar 2 reglas, que han sido creadas, una con el nombre web y otra con el nombre ICMP. Es recomendable que los nombres de las reglas sean significativos para que cuando otro administrador "trastee" por aquí sepa exactamente de un simple vistazo lo que realizará la regla.

Para crear una nueva regla debemos, simplemente, pinchar sobre agregar e ir rellenando lo que el asistente nos presenta. Lo primero que preguntará el asistente es que modo vamos a utilizar, recordad del primer artículo, si modo túnel o modo transporte. La siguiente pregunta es en que tipo de red vamos a utilizar esta regla, las opciones son todas las conexiones de red, red de área local o acceso remoto. Normalmente, si utilizamos IPSec en una red local nos valdría con indicarle que la red es LAN, pero si un servidor tiene salida hacia fuera o monta IPSec en Internet, no sería la opción válida. Después se nos preguntará por el método de autenticación, recordad que teníamos 3 métodos, Kerberos, que es solo válido para entornos locales con un dominio, usar certificados, el cual requiere la instalación de un PKI, y por último, usar una clave compartida o secreto compartido, lo que significa poner una clave en el equipo, y la misma en el otro equipo. Este último método se utiliza en las pruebas de IPSec, pero no suele ser una buena solución, la seguridad depende de la "calidad" de la clave. Se puede configurar varios métodos de autenticación, en una lista dónde se indica el orden.

Tras asignar un método de autenticación, se nos pedirá que indiquemos que filtro va a usar la regla. El filtro sirve para indicar qué protocolo será el encapsulado en IPSec y cual será la dirección IP de origen y cual la de destino. Elegir la dirección origen y destino, hay que verlo desde el punto de vista de para quién es la regla, es decir, en una comunicación entre 2 equipos, estos deberán tener cada uno su directiva IPSec configurada. El origen, puede ser una dirección en concreto, un rango de direcciones (útil cuando es un servidor el que espera la petición mediante IPSec), una red en concreto o cualquier dirección IP. En la de destino, son los mismos parámetros.

En el filtro hay una pestaña que es la de protocolo, dónde se pueden elegir protocolos de nivel de red o de transporte. Realmente se puede configurar cualquier protocolo, ya que para indicar uno que no esté en la liste elegiremos la opción Otros e indicaremos el puerto de origen y destino. En origen, si fuese algo parecido como el protocolo HTTP desde el punto de vista de un cliente, sería cualquiera y el puerto destino al 80, que sería un servidor que esperase comunicación TCP por puerto 80 con IPSec.

Por último, el asistente nos pedirá que acción de filtrado queremos que se realice, es decir, cuando llegue algo que cumple con nuestra regla que estamos generando, por ejemplo, tenemos una regla para encapsular ICMP y nos llega un paquete mediante IPSec con ICMP, pues la acción de filtrado se ejecutará y realizará la acción programada. En acciones de filtrado podremos configurar el tipo de protocolo, ESP o AH, que utilizaremos en IPSec. Recordad que ESP, puede cifrar y firmar los datagramas, mientras que AH sólo firmaba dichos datagramas. ¿Firmo y cifro, o solo firmo? Eso dependerá de lo importante de la comunicación, o la información sensible que se trate en la comunicación. En este apartado hay opciones las cuales podemos marcar, como por ejemplo, Aceptar comunicación no segura pero responder siempre usando IPSec o Permitir la comunicación no segura con equipos no compatibles con IPSec. Cada uno debe elegir, en función de la importancia de la información que puede ir en el canal este tipo de opciones o de los requisitos empresariales.

En la imagen superior se puede visualizar como se puede elegir entre AH y ESP, y configurar los algoritmos de firmado y cifrado que se utilizarán. Por ejemplo para firmado disponemos de SHA1 y MD5 y en cifrado de DES y 3DES.

En la imagen superior se pueve visualizar una captura de tráfico, primero ISAKMP asociado al protocolo IKE y después el protocolo ESP, dónde el protocolo securizado va cifrado y firmado en un datagrama IPSec.

En la imagen superior se puede visualizar un datagrama IP con el protocolo AH, de firmado, para asegurar que el datagrama no ha sido manipulado en el viaje por el canal. Se puede visualizar el campo AH ICV dónde se indica la firma del datagrama.

Finalizamos la segunda entrega de IPSec dejando para la tercera entrega la integración en el directorio activo.

lunes, 17 de octubre de 2011

Buscando SQL Injections: spider para buscar URLs con parámetros por GET

Compartir este artículo:

Buenas a todos, hace unos días para llevar a cabo un proyecto necesitaba una herramienta tipo spider que me permitiese recuperar todas las URL de un sitio Web. Para esta tarea como sabéis hay numerosas aplicaciones, pero en este caso lo que necesitaba era averiguar cuales de todas esas URL contenían parámetros pasados por GET en la propia URL, para probar si esos parámetros eran vulnerables a algún tipo de inyección de código (en concreto para este caso SQL Injection).

Para esta tarea decidí desarrollar un pequeño programa en python, el cual os dejo a continuación.

La aplicación se ejecuta como cualquier programa en python, tendréis que pasarle un argumento con la URL del site que se auditará:

 

 

La aplicación irá recorriendo todas las páginas que vaya encontrando e irá navegando por ellas recursivamente. Cada vez que encuentra una URL con una "?", la identificará como una posible inyección para que inmediatamente podamos analizar dicha URL de manera manual:

 

 

A continuación os dejo el código fuente:

DESCARGAR CÓDIGO FUENTE

domingo, 16 de octubre de 2011

Informe Flu - 41

Compartir este artículo:

Disfrutad del resumen:

Lunes 10 de OctubreMartes 11 de OctubreMiércoles 12 de OctubreJueves 13 de OctubreViernes 14 de OctubreSábado 15 de Octubre

sábado, 15 de octubre de 2011

Jugando con los puntos de acceso gratuitos

Compartir este artículo:

Hola!

Muy buenas a todos/as!

Estamos muy acostumbrados a tener ya las redes Wireless cada vez mas a nuestro alcance, un ejemplo de esto son ya los establecimientos que disponen de redes gratuitas para que los clientes se puedan conectar, siendo esto un vector de ataque para algún cliente no satisfecho con el servicio….

Nos conectamos a la red, que esta abierta:

Podemos ver que hay diferentes redes, muchas de ellas con seguridad, tenemos una con especial potencia abierta que está cerca y que se llama igual que el establecimiento…

Una vez que nos ha dado IP:

Podríamos mirar si estamos solos en esta red, o si realmente aparte del router tenemos mas pchs conectados :D

Así que podemos lanzar nmap y ver que IP’s hay activas y además que servicios ofrecen cada una de ellas.

Lanzamos nmap

nmap -sX 1.0.0.0/24

Esto nos arroja los siguientes resultados:

Nmap scan report for 1.0.0.1Host is up (0.14s latency).Not shown: 996 closed portsPORT   STATE         SERVICE21/tcp open|filtered ftp22/tcp open|filtered ssh23/tcp open|filtered telnet80/tcp open|filtered httpMAC Address: 00:22:F7:08:73:9C (Conceptronic)Nmap scan report for 1.0.0.4Host is up (0.015s latency).All 1000 scanned ports on 1.0.0.4 are open|filteredNmap scan report for 1.0.0.5Host is up (0.11s latency).Not shown: 977 closed portsPORT      STATE         SERVICE1030/tcp  open|filtered iad11049/tcp  open|filtered td-postman1050/tcp  open|filtered java-or-OTGfileshare1065/tcp  open|filtered syscomlan1556/tcp  open|filtered veritas_pbx1935/tcp  open|filtered rtmp2718/tcp  open|filtered pn-requester23324/tcp  open|filtered active-net3814/tcp  open|filtered neto-dcs3914/tcp  open|filtered listcrt-port-24998/tcp  open|filtered maybe-veritas5000/tcp  open|filtered upnp5001/tcp  open|filtered commplex-link5100/tcp  open|filtered admd5859/tcp  open|filtered wherehoo6969/tcp  open|filtered acmsoda8021/tcp  open|filtered ftp-proxy9050/tcp  open|filtered tor-socks9103/tcp  open|filtered jetdirect16992/tcp open|filtered amt-soap-http30000/tcp open|filtered unknown40193/tcp open|filtered unknown49154/tcp open|filtered unknown

Parece que hay bastantes servicios activos. Ahora como última prueba veremos el router, si han tomado la precaución de tener las cosas con seguridad, ya que la red está abierta y da posibilidades a que intenten entrar.

Nos pide autenticación, podríamos probar los passwords mas habituales, como admin admin, admin 1234 etc..

El resultado es:

Ya tenemos acceso al router, el password estaba por defecto.

Que información podemos obtener?

En el apartado de tools podríamos cambiar el password del router

Podríamos dejar sin acceso legítimo a los dueños :P

Podemos ver que podemos habilitar servicios que necesitemos :D

Podemos incluso dejarnos para poder entrar luego con una cuenta DynDNS si fuera el caso, ya para facilitarnos las cosas.

Si hubieramos intentado entrar al router nos podíamos haber ahorrado el saber que IP’s teníamos en la red local

Y aquí tenemos toda la información del router, pero modificada claro..

Y eso es todo, recordad de asegurar vuestra red Wireless, y así poder  estar seguros antes posibles atacantes, y si la queréis dejar libres por lo menos securizad el router...