lunes, 31 de enero de 2011

Entrevista a Ruben Santamarta (reversemode)

Compartir este artículo:

Hola a todos, hoy proseguimos el hilo de entrevistas de la comunidad Flu Project, con una entrevista a uno de los mejores caza-vulnerabilidades españoles que existen en la actualidad, leonés de nacimiento y ReverseMode de corazón, Rubén Santamarta.

Rubén es de esa clase de personas capaces de meter en solo 48bits TeraBytes y TeraBytes de conocimiento sobre seguridad.

Probablemente esta sea de las entrevistas más complejas con las que nos encontremos, porque Rubén es de los personajes del sector más entrevistados, y pensar preguntas innovadoras comienza a ser complicado. Por ello nuestra primera pregunta para Rubén es:

¿Cuántas entrevistas te han hecho en los últimos años?

Unas poquitinas, aunque todas son diferentes. No puedo decir lo mismo si me entrevista Chema que si me entrevistan en el periódico, aunque solo cambian las formas, soy fiel a mi discurso ;)

No te vamos a meter en problemas, así que no te preguntaremos por cuánto pueden pagar las empresas por una vulnerabilidad, ni cuanto te han ofrecido las mafias rusas por ellas, pero si nos lo quieres decir… no contará como pregunta =)

La crisis ha llegado al sector de las vulnerabilidades también, no nos libramos jeje. Las  cosas se ponen cada vez más complicadas, tanto a nivel técnico como económico.

Respecto a los rusos etc, siempre comento una cosa y es el transfondo social que se da en algunos casos, no generalizo. Lo comentaba hace tiempo Mikko Hypponen de F-Secure y yo coincido, en las repúblicas de la antigua Unión Soviética hay gente muy, muy buena. Muchos ingenieros y muy bien formados, ¿Qué ocurre? Que faltan oportunidades y si a eso le añades una cierta inmunidad  a la hora de hacer cosas malas, tienes el caldo de cultivo perfecto.

¿Cómo es la bat-cueva donde surge toda la magia? ¿Y tu PC donde trabajas? ¿Eres de esos que tienen la consola de comandos con el fondo negro y las letras verde fosforito?

Pues dos mesas, 5 ordenadores, desde MACOSX hasta Windows 7, pasando por Debian , aparatos varios, muchos papeles y bolígrafos que cada cierto tiempo hay que ordenar porque toman vida propia. Mira, la consola en negro con el verde fosforito la puse el otro día en el N900 xD

Como no queríamos que huyeses sin tratar el tema que has puesto de moda:

¿Qué puedes contarnos de los sistemas SCADA y de su seguridad?, así, rápido, en diez-veinte líneas.

Tanto como de moda no se yo xD, pero si de alguna manera he contribuido a que se hable de ellos en algunos ámbitos, pues me alegro.

De cualquier manera, creo que lo que de verdad ha sido el punto de inflexión fue la aparición de Stuxnet. A partir de ahí todo ha cobrado más peso. Que es posible atacar esos sistemas nadie lo dudaba, pero que justo cuando se estaba tomando conciencia de ello apareciera Stuxnet, ha sido una grata sorpresa, aunque no se si en Iran piensan lo mismo.

La seguridad en los sistemas SCADA debe ser parte fundamental de la seguridad del futuro, no es lo mismo infectar un ordenador de tu vecino que el de tu cuñado el operador nuclear.

¿Su seguridad? Pues hay de todo, pero ciertamente hay cosas que se podrían mejorar. Tanto en software como en hardware.

¿Has tenido a alguien como referencia para llegar hasta dónde estás ahora? ¿Qué recomendarías a los jóvenes que empiezan en el mundillo de la seguridad?

Mucha gente, pero por sus trabajos unicamente. Mi opinión es que hay que huir de las referencias personales. Hay gente muy buena tecnicamente que no valen una mierda como personas. Como hay gente que también pensará eso de mí, procuro separar lo técnico de lo personal.

Sin embargo y por fortuna, conozco  mucha gente que cumple ambas cosas, buenas personas y buenos tecnicamente hablando :)

Recomendaría que leyeran todo lo posible y que se pongan retos mucho más allá de sus conocimientos. Yo aprendo así, llegar al punto que quieres te obliga a aprender gran cantidad de cosas durante el camino.

Y finalmente. ¿A quién te gustaría que hiciésemos la próxima entrevista?

A Bernardo Quintero, una de esas personas que cumplen ambas cualidades. Si conseguís arrancarle una entrevista eso sí xD

Un saludo y gracias. ¡Suerte con el proyecto! ¡Nos vemos en la rooted!

Gracias a ti Rubén, ha sido un placer. Añadimos a Bernardo a la lista de futuros posibles entrevistados =).

Saludos a todos!

domingo, 30 de enero de 2011

Informe Flu - 4

Compartir este artículo:

Damos comienzo al resumen de la semana 4 de Flu:

Lunes 24 de EneroMartes 25 de Enero
  • Pablo publicó la segunda entrega de la cadena de posts sobre Hacking MSN.
Miércoles 26 de EneroJueves 27 de EneroViernes 28 de EneroSábado 29 de Enero
  • Pablo nos trajo el resumen de las encuestas que hemos estado realizando durante el primer mes de la comunidad con algunos resultados muy interesante.

sábado, 29 de enero de 2011

Curiosidades: Vuestros resultados

Compartir este artículo:
Hoy simplemente contaremos lo que vosotros nos habéis contado a través de las encuestas. Desde que la comunidad vió la luz allá por Diciembre del 2010 se ha estado haciendo encuestas a todos los usuarios que viajaban por este rinconcito de Internet. Hoy es día de reflexión y ver que opináis , cuales son vuestros gustos, vuestras inquietudes, vuestros gustos, en general… ¡como sois!Allá por Diciembre decidisteis un 42% que la idea del blog comunitario era muy buena, ya que permitía que cualquier persona tuviera un rincón donde transmitir su conocimiento, y eso siempre es algo positivo. También recordar que un 4% votó que le parecía mal o un 12% que no había necesidad. El 33% comunicó que era imprescindible para el desarrollo del proyecto, estos resultados marcaban que el blog comunitario era solicitado por la mayoría de vosotros. Mas tarde, se os preguntó acerca de Firesheep aquel post sobre Windows Live, el cual mostraba debilidades del sistema de cookies de Microsoft. Un 58% se pronunciaron sobre que el tema era muy interesante, frente al 6% al que no le gustó el tema, denominado hacking de botón grande.Por aquellas fechas se os preguntó acerca de que sistema operativo era el que los miembros de la comunidad usan. No hubo demasiadas sorpresas, respecto a lo que se esperaba, si nos fijamos en las cuotas de mercado oficiales si hay sorpresas y gordas. El 70% utiliza GNU/Linux(Ubuntu/Debian). El 37% utiliza Windows (XP/Vista/7) y tan sólo un 8% utiliza sistemas de Apple. Hay que recordar que en esta encuesta se podía responder hasta con 3 sistemas operativos.Tras la entrevista que radiognu nos realizó a principios de Enero, decidimos preguntar que opina la gente sobre clamAV, ya que esa misma pregunta nos la realizaron en la entrevista y las respuestas fueron: 39% bueno, 14% muy bueno, frente a un 15% que comentó que era un AV pobre. El resto de los usuarios NS/NC.Como último dato por hoy, comentaros el tema de las certificaciones LPI, grandes desconocidas para muchos, pero no para los usuarios del mundo Linux. Se preguntó sobre la opinión acerca de estas certificaciones . El 43% opinó que eran muy interesantes, frente al 5% que comentó que eran pobres. Al 33% les parecen interesantes y al 19% necesarias. Nadie dijo que fueran malas.Pues hasta aquí esta primera entrega de curiosidades y la recopilación de vuestras opiniones, seguiremos realizando encuestas para ver que comunicáis, porque vuestra opinión si importa.Fuente: Se pueden observar todos los resultados en InFLUenciados -> Encuestas.

Flu Project Team

viernes, 28 de enero de 2011

Transferencias de Zona (I de II)

Compartir este artículo:

=========================================================Transferencias de Zona (I de II)Transferencias de Zona (II de II)=========================================================

Buenas a todos, en la cadena de posts que hoy damos comienzo vamos a hablar sobre el DNS (Sistema de nombres de dominio) y su posibilidad para dividir el espacio de nombres DNS en varias zonas, para delegar la administración. Tras explicar el concepto, hablaremos sobre las transferencias de zona y su seguridad.Como una imagen vale más que mil palabras, para comenzar os hemos dibujado un diagrama muy ilustrativo sobre cómo funcionan las zonas, en él os mostramos nuestro dominio flu-project.com, con su nombre de dominio “flu-project” dentro de la zona principal. Por otro lado tenemos tres subdominios “blog”, “www” y “ftp” (hipotéticos), estos subdominios pueden configurarse dentro de la zona principal, o en otra separada, como por ejemplo el caso del subdominio “ftp”, que estaría administrado por la zona “prueba”.Para que una zona nueva delegada de la principal, por ejemplo la zona prueba, funcione, es necesario configurar algunos recursos, para que tenga información sobre la delegación a los otros servidores de DNS autorizados. Es de extrema importancia que las zonas estén disponibles desde varios servidores de DNS por temas de disponibilidad.Para que otros servidores además del principal puedan alojar zonas, se crearon las transferencias de zona, que se encargan de hacer la replicación de todas ellas y de sincronizarlas.Ahora bien, ¿cuándo se realizan estas transferencias de zona? Tenemos cuatro posibilidades:
  1. La primera de ellas es que se instale o inicie un nuevo servidor DNS y se configure en una zona existente.
  2. La segunda, cuando finaliza el plazo de actualización de una zona.
  3. La tercera, cuando se produce algún cambio en una zona, y es necesario actualizar para replicar los cambios.
  4. Y la última, cuando manualmente se solicita una transferencia de zona.
Bien, una vez entendido bien el concepto de zona, vamos a llevarlo a la práctica. Vamos a abrir una consola de comandos de Windows y ejecutaremos el programa “nslookup”, para Linux también existe. Nslookup es una aplicación de línea de comandos que permite probar y solucionar problemas en los servidores DNS. Nosotros lo utilizaremos para activar una transferencia de zona de manera manual.Vamos a iniciar Nslookup en modo interactivo, para ello basta con abrir un CMD y escribir el comando “nslookup”:Ahora vamos utilizar la instrucción SET TYPE para consultar datos de tipo DNS (NS), para ver otros tipos de consultas podéis utilizar la ayuda poniendo una interrogación ?:Ahora buscaremos los servidores de DNS de alguna organización:Ya sabemos los servidores DNS de ese dominio, ahora procederemos a ponernos como uno de ellos:Ahora ya nos queda tan solo para realizar la transferencia de zona ejecutar el comando LS contra el dominio que queramos:Y disfrutar de todo el listado de máquinas que contienen las zonas:Ese listado que veis en la imagen, que bien podría ser una captura de la película Matrix =), lo he redirigido a un fichero y he contado más de 20000 máquinas, como veis es una transferencia de zona completa de una organización, que reporté hace un par de años y ahí sigue para disfrute del personal... La transferencia de zona la hemos realizado desde fuera de la red interna debido a una mala configuración por parte de la organización. Esto no debería ocurrir, por motivos de seguridad obvios, y es que cualquiera desde su casa puede hacerse con todas las IP y dominios internos de una organización.Para que estuviese bien configurado, nos debería haber respondido al comando LS con algo como lo siguiente:El próximo día os enseñaremos a realizar la configuración correctamente para evitar que sucedan estas cosillas.Saludos!

jueves, 27 de enero de 2011

Las viñetas de Flu Project - 1

Compartir este artículo:

Buenas a todos, hoy vamos a dar comienzo a otra nueva sección en el blog de Flu Project, la categoría viñetas. En ella publicaremos cada cierto tiempo un pequeño comic sobre alguna historieta de humor g33k =)

Podéis enviarnos todo tipo de viñetas y comic graciosos sobre seguridad y tecnologías de la información que gustosamente publicaremos con vuestro nick en el blog del portal.

Para comenzar os dejamos el siguiente mini comic que hemos dibujado Pablo y yo sobre los jóvenes h4x0rs:

miércoles, 26 de enero de 2011

Seguridad: comprometiendo un switch (Parte II de II)

Compartir este artículo:

========================================================= Seguridad: comprometiendo un switch (Parte I de II) Seguridad: comprometiendo un switch (Parte II de II)=========================================================

En el articulo anterior pudimos ver cómo comprometer la seguridad de un switch y como me pareció un tema interesante decidí crear esta segunda parte en la que os explicare como securizar un switch de manera que podamos protegerlo contra una serie de ataques, trabajaremos con una sintaxis de IOS que es el sistema operativo de Cisco, que es lo que a fin de cuentas es más normal encontrarse dentro de una red más o menos importante, pero lo importante es entender el concepto y la diferentes medidas.La mayoría de los switch poseen unos puertos que funcionan con un ancho de banda superior al resto de puertos y suelen ser tipo Ethernet Giga, en estos puertos lo correcto es conectar host que necesiten más ancho de banda que un equipo final normal, estos puertos suelen estar destinados a servidores, por lo que no solo seria necesaria asignar una MAC a ese puerto. Estos puertos también pueden estar destinados a ser puertos troncales, un puerto troncal cumple la finalidad de unir dos switchs, por lo que en estos puertos habría que actuar con cuidado y calculando bien antes de definir un numero máximo de direcciones MAC.Pasemos al código, una vez dentro del switch pasamos a modo configuración:
  • sw(config)# interface interfaz slot/port -> seleccionamos la interfaz y el puerto
  • sw(config)# switchport mode access -> automaticamente cuando conectemos un host funciona
  • sw(config)# switch port-security -> activamos la seguridad
Llegados a este punto pasaremos a analizar los comandos y las opciones más comunes que podemos configurar ahora.
  • sw(config)# switch port-security aging
  • El comando aging define cuanto tiempo se aplica la acción definida cuando se produce una violación de las reglas, pasado ese tiempo acaba la restricción. Hablaremos de eso más adelante. Por defecto el comando da un tiempo de 45 segundos que podemos modificar añadiendo los minutos y segundos de la acción después del comando aging, por ejemplo si ponemos:
  • sw(config)# switch port-security aging 0 0 -> La acción se ejecuta siempre y de forma infinita
ó
  • sw(config)# switch port-security aging 5 30 -> La acción duraria 5 minutos y 30 segundos
  • sw(config)# switch port-security maximum n -> El comando maximun nos dice el número de direcciones máximas que aprenderá el puerto (n)
  • sw(config)# switch port-security mac-addres MMMM.AAAA.CCCC
El comando mac-addres nos dice las direcciones MAC de los host que tendrán permitido el acceso a ese puerto, este comando tiene sentido si existe un número máximo de direcciones definido previamente, esta sería la opción ideal para un puerto Giga que solo necesitamos conectar un servidor. También nos puede ser útil si vamos a conectar una serie de equipos finitos o dentro de un rango normal que sepamos que si se supera es porque algo raro esta pasando (como un ataque de ARP-Flood), para estos casos nos puede interesar el comando:
  • sw(config)# switch port-security mac-addres sticky
Con este comando las direcciones se irán almacenando en la tabla CAM (MAC) del switch de forma automatica y cuando llegue al limite ya tendria definidas las direcciones MAC posibles que se conectarían desde ese puerto.
  • sw(config)# switch port-security violation {shutdown/protect/restrict}
Este comando sirve para especificar que acción se llevara acabo en caso de que alguna de nuestras reglas definidas anteriormente sea saltada, nos encontramos con tres opciones:
  • shutdown: Es la opción por defecto y lo que hace es tirar el puerto que ha sufrido la violación.
  • protect: Evita la entrada a la red a la MAC no permitida.
  • restrict: Evita la entrada a la red a la MAC no permitida y además manda una alerta al servidor de eventos por lo que nos da más control sobre lo que pasa en la red.
Cabría añadir que si queremos configurar un switch entero seria más sencillo y rápido usando rangos de configuración de interfaces:
  • sw(config)# interface interfaz slot/port – ultimoPuerto
(Por ejemplo: sw(config)# interface Fa0 0/0 – 15)
Si aplicamos estas reglas correctamente podremos tener un switch configurado correctamente y nos ahorraríamos la mayor parte de los problemas y ataques mediante ARP.

dan1t0, Vía blog dan1t0

martes, 25 de enero de 2011

Hacking Messenger (II de II)

Compartir este artículo:

========================================================Hacking Messenger (I de II)Hacking Messenger (II de II)========================================================

El presente post es la segunda entrega de la serie Hacking Messenger. En este artículo se instalará la herramienta Simp, la cual permite cifrar los mensajes entre 2 hablantes de Messenger. La idea es muy sencilla, Simp se instalará a la espera de que el parlante 1 envíe algún mensaje al parlante 2, cuando esto suceda cifrará dicho mensaje con la clave privada del parlante 1. Cuando el mensaje viaje por la red, éste irá cifrado, al llegar al receptor, es decir, el parlante 2 éste lo descifrará con la clave pública del parlante 1. Y cuando el parlante 2 quiera enviar un mensaje al parlante 1 el proceso se realizará a la inversa.InstalaciónDurante la instalación de la aplicación se le pedirá al usuario que configure el cifrado que más le guste para el cifrado de sus mensajes. Se recomienda al usuario que escoja un cifrado fuerte para que otros posibles usuarios con malas intenciones no tengan tentaciones. El asistente para la instalación de Simp es bastante intuitivo, a pesar de venir en inglés, y fácil de manejar. Como nota aclaratoria para los que no entiendan bien el concepto de las claves públicas y privadas,la clave privada asegura que el mensaje que sale de un equipo pertenece a esa persona, a no ser que esa clave haya sido robada por lo que se debería generar un nuevo par de claves.Tras la instalaciónTras realizar la instalación de Simp, el usuario percibirá una nueva aplicación con un icono parecido al del messenger. Desde esta consola se podrá administrar las conversaciones de messenger, y cuales van cifradas y cuales no. Recordad que para poder cifrar la conversación, los 2 usuarios deben tener Simp instalado y en ejecución. En el primer contacto entre el parlante 1 y parlante 2 tras la instalación de Simp, se realizará un traspaso de claves públicas entre ambos. En la imagen se puede observar como se tiene almacenado la clave pública del otro parlante. Además en el cuadro inferior se puede observar que conversaciones están siendo ejecutadas con cifrado de mensajes y cuales no.Es interesante, este tipo de gestión y para finalizar y ver que todo funciona correctamente se ha capturado tráfico con Wireshark para ver como los mensajes de messenger ahora no son legibles como lo eran en el artículo anterior. Desde Flu Project esperamos que os haya interesado esta serie sobre lo fácil que es ver conversaciones de messenger y también lo fácil que es ponerle solución. Recordad, que el chat o messenger se creó para hablar entre amigos o como fuente de entretenimiento, y por qué no para ligoteo y mentiras, pero si lo usáis en vuestro trabajo no está de más tenerlo un poco securizado.

========================================================Hacking Messenger (I de II)Hacking Messenger (II de II)========================================================

Flu Project Team

lunes, 24 de enero de 2011

Flu Project colabora persiguiendo la pederastia con anti-depredadores.com

Compartir este artículo:
Hola a todos, en el post de hoy queríamos daros una noticia especial para la comunidad. Hace unas semanas, se pusieron en contacto con nosotros desde anti-depredadores.com, web dedicada al proyecto colaborativo y sin ánimo de lucro que apoya técnicamente a instituciones gubernamentales de cualquier país en la identificación y rastreo de Pedófilos, que ponen en riesgo la integridad y seguridad de los menores y jóvenes en Internet. El proyecto está apoyado actualmente por sec-track.org y su lider 4v4t4r.Nos propusieron realizar una versión de Flu específica para combatir la pederastia, orientada a la obtención de información de estos criminales que permita identificarlos e incriminarles por los delitos cometidos.Tras hablar con los líderes del proyecto, hemos llegado a un acuerdo de colaboración, en el que brindaremos apoyo técnico mediante el desarrollo de una versión específica del troyano Flu.Ahora y más que nunca solicitamos todo el apoyo de la comunidad en forma de ideas, desarrollo de código, etc.Por motivos de seguridad obvios, el código fuente de esta versión de Flu, que será conocida como Flu-AD, no será publicado, pero deciros, que el desarrollo del Flu normal seguirá su curso, con las liberaciones de código fuente tras cada versión, como está siendo habitual.Para llevar a cabo la coordinación del proyecto, hemos creado un subforo específico, en el que iremos hablando del desarrollo de Flu-AD, que partirá del esqueleto de Flu b0.2 (última beta estable).Las funcionalidades iniciales que planteamos para Flu-AD son las siguientes:
  • Capturar imágenes y videos desde una webcam.
  • Buscar imágenes en el equipo.
  • Capturar la pantalla.
  • Evolucionar el Keylogger para poder capturar conversaciones de msn, chat, etc. con detección de ventana.
  • Activar micrófonos y grabar escuchas.
  • Subir y bajar ficheros entre cliente y servidor.
Cualquier otra idea que se os ocurra, como habitualmente, será bienvenida.La gente que desee participar en esta rama del proyecto Flu, deberá enviar un correo electrónico a la cuenta: antidepredadores@flu-project.com, indicando de que manera puede colaborar. Los que os impliquéis en el desarrollo recibiréis un rol especial acreditativo en el portal.Esperamos que os guste la iniciativa, por nuestra parte haremos todo lo que esté en nuestras manos para colaborar en el proyecto y luchar en la causa.

¡Saludos!

Flu Project Team

domingo, 23 de enero de 2011

Informe Flu - 3

Compartir este artículo:

Esta semana se resume con los artículos publicados en el blog comunitario.

Damos comienzo al resumen de la semana 3 de Flu:

Lunes 17 de EneroMartes 18 de EneroMiércoles 19 de EneroJueves 20 de EneroViernes 21 de EneroSábado 22 de EneroSemana de redes y pruebas de concepto en Flu Project... y mañana ¡una gran noticia!

sábado, 22 de enero de 2011

Seguridad: comprometiendo un switch (Parte I de II)

Compartir este artículo:

========================================================= Seguridad: comprometiendo un switch (Parte I de II) Seguridad: comprometiendo un switch (Parte II de II)=========================================================

Cuando nos encontramos con una red no domestica, con varios host conectados a la red entre los que podemos encontrar alguna impresora, equipos finales como PC’s o teléfonos VoIP, algún servidor web o de correo; como podría ser la red de una pequeña o mediana empresa tenemos que tener como mínimo un router y un dispositivo intermediario entre el router y los equipos finales, lo más eficiente es encontrarnos con un switch.Podemos pensar que para qué poner un switch pudiendo poner un hub que es más económico y a nivel de instalación es Plug&Play, y la respuesta es bien sencilla, un hub a nivel informática de red es como un ladrón a nivel de electricidad, es decir, envía por todos los puertos la misma información vaya para el host que este conectado a ese puerto o no, por lo que es el equipo final el encargado de descartar la información que no es para él (o no). Esto nos puede parecer una razón poco poderosa a la hora de decantarnos entre un aparato o otro, pero tenemos que tener en cuenta lo que significa que un hub envía toda la información por todos lo puertos y es que si un usuario malintencionado quisiera saber todo lo que hacemos a través de la red con colocar un simple sniffer podría monitorizar todas las conexiones de la red, con lo que esto supondría para la seguridad de nuestra red, recordemos que aunque en nuestra red solo se conecten empleados tenemos que tener siempre en cuenta que el 80% de los ataques a una red siempre se producen desde dentro de esta.Hay otras dos razones de porque nunca debemos de poner un hub, una de ellas es por eficiencia, un hub reparte el ancho de banda de la red entre sus puertos haya equipos conectados a estos o no, por lo que si necesitamos conexión para seis equipos y ponemos un hub de ocho puertos, perderemos un 25% del ancho de banda. La otra razón también es por eficiencia de la red, ya que un hub al enviar toda la información a todos los puertos aumentaría la posibilidad de colisión de datos exponencialmente (red tipo bus), lo que haría que el rendimiento de nuestra red cayera en picado.Dicho todo lo anterior y ya decantados por la opción de instalar un switch tenemos que tener claro que un switch mal configurado es un agujero de seguridad tan grande como un hub, expliquemos porque. Como hemos explicado antes un switch es un dispositivo intermedio de capa 2 es decir trabaja con direcciones MAC, dirección MAC destino y dirección MAC origen y de esta forma establece la conexión entre los dos hosts (puertos del switch) correctos, por defecto el switch es un dispositivo que “aprende”, es decir nada más encenderlo enviará toda la información por todos los puertos al igual que un hub, pero irá memorizando la MAC del dispositivo que hay conectado a ese puerto de forma que creará una tabla interna en la RAM en la que asociará una dirección MAC a un puerto (o interfaz).Hasta aquí todo parece sencillo, ahora imaginemos que tenemos una red tipo árbol en la que tenemos varios switch conectados unos a otros, en este caso en la tabla descrita anteriormente nos encontraríamos con varias MAC’s asignadas al mismo puerto. En la imagen podemos ver una tabla ARP de un switch, como podemos observar tenemos direcciones de tipo estáticas y dinámicas (lo explicaremos más adelante):En la imagen podemos ver una tabla muy sencilla y con pocas direcciones. Imaginemos ahora por un momento que pasaría si la memoria que tiene destinada el switch a guardar esta información se llenara con muchas MAC’s, se produciría un desbordamiento de buffer (buffer overflow) y el switch al ver que no puede acceder a la información de su tabla procedería a comportarse como un hub, es decir empezaría a enviar toda la información por todos los puertos, esto en un switch solo se daría si se está produciendo un ataque, con lo que si no tenemos monitorizada la red, estaremos ante un ataque de robo de información que no podremos detectar facilmente si no somos muy perspicaces (como usuarios finales).Para protegernos de este tipo de ataques basta con asignar todas las direcciones MAC a un puerto determinado y configurar la tabla de forma estática, claro que en un sitio donde hay movimiento de equipos y de usuarios, es normal que tengamos que tener algunos puertos o dispositivos totalmente configurados de manera dinámica, esto no quita que podamos poner restricciones a los puertos como n MAC’s diferentes por puerto, o si se detecta que un puerto en el que sabemos que solo podría ir conectado un host empieza a enviar información de varias MAC’s en un periodo de tiempo ridículo  tirar la conexión automáticamente. De esta forma nos estaremos quitando un gran porcentaje de ataques de este tipo.Para comprobar si nuestra red está a salvo de este tipo de ataques lo mejor es probar atacándola, si tenemos un windows podemos usar WinArpAttacker, si tenemos un sistema basado en Linux podemos usar ARPTools, los dos nos ayudaran a llenar la RAM de nuestro switch (ataque ARP-Flood) y comprobar simplemente con WireShark como empezamos a recibir paquetes destinados a otros host de la red. Si queremos ocultar nuestra MAC durante la auditoría, si tenemos un LINUX bastaría con:# ifconfig eth0 down# ifconfig eth0 hw ether 00:AA:BB:CC:DD:00# ifconfig eth0 upSi tenemos un windows bastaría con usar alguna utilidad como MacShift.En otra próxima entrega entraremos más a ver como solucionar esto con diferentes métodos según nuestras necesidades.

dan1t0, Vía blog dan1t0

viernes, 21 de enero de 2011

Wardriving y geoposicionamiento de redes Wifi con móviles Symbian yGoogle Earth (Parte II de II)

Compartir este artículo:
Buenas a todos, hoy finalizaremos la cadena de post sobre wardriving en sistemas Symbian, con la transformación del reporte xml a kml y su integración con Google Earth.En primer lugar deberemos transformar el reporte xml a kml, para ello yo he elegido un script en perl llamado kisgearth, que realizará el cambio de formato de manera automática. Hay otros programas que realizan esta tarea, pero este me ha parecido bastante práctico, sencillo y eficiente. Lo podéis descargar desde el siguiente link:
Una vez descargado, necesitaréis un interprete de lenguaje Perl, como he hecho las pruebas en Windows 7, me he descargado para esta labor el software Active Perl.Tras instalar Active Perl, deberéis dejar en la ruta “C:\Perl\bin” (C:\ por defecto) el fichero xml que os ha devuelto barbelo, que encontraréis en la ruta “\barbelo” de la tarjeta de memoria de vuestro móvil y el script kisgearth que habéis descargado antes. Una vez hecho esto, abriréis un terminal y ejecutaréis el siguiente comando:

kisgearth.pl -oN barbelo.kml -n1 -- Barbelo-Jan-01-2011-19.xml

Siendo barbelo.kml el nuevo fichero que se va a crear y Barbelo-Jan-01-2011-19.xml el fichero que nos ha generado barbelo.Tras ejecutarse el script se nos habrá generado el fichero kml en la ruta “C:\Perl\bin”. Ahora simplemente, si ya tenemos Google Earth instalado en el ordenador, lo cargamos haciendo doble clic sobre el icono y deberéis ver vuestro mapa con las redes wifi que habéis encontrado y la información de las mismas:
2
Espero que os hayan gustados los posts, hasta la próxima!
Flu Project Team

jueves, 20 de enero de 2011

Wardriving y geoposicionamiento de redes Wifi con móviles Symbian yGoogle Earth (I de II)

Compartir este artículo:
Buenas a todos, en la cadena de post que hoy doy comienzo voy a hablaros de las técnicas de Wardriving sobre terminales móviles con sistemas operativos Symbian.
Para la realización de las pruebas he utilizado un terminal Nokia 5800, el software “Barbelo” y el programa Google Earth.
¿Qué es el Wardriving?
El Wardriving es una técnica que se utiliza para hacer búsquedas de redes wifi desde un vehículo en movimiento a través de un ordenador equipado con tecnología Wi-Fi, como un portátil, una PDA o un terminal móvil. Una vez registradas las redes wifi detectadas se suelen posicionar en un mapa (en caso de que el terminal usado tuviese GPS y se hubiese almacenado la posición exacta del punto de acceso), para obtener un mapa con los lugares donde están situados los terminales wifi que hemos ido escaneando.
Por Internet se ha hecho muy común el registro de estos mapas, para que cualquier usuario cuando haga un viaje sepa donde puede tener acceso gratuito a Internet mediante una red wifi. El sitio mas popular es: http://www.wigle.net/
Con respecto a la legalidad de la publicación del campo de la dirección MAC de los puntos de acceso entre el resto de datos de las wifis en internet, hay diversidad de opiniones, pero si se considera que ésta dirección es única y que con ella se puede identificar al usuario de la misma, se estaría cometiendo un acto ilegal. ¿Vosotros qué opináis?. De cualquier manera este campo se puede borrar antes de subir el fichero con las redes wifis mapeadas a Internet.
Wardriving en Symbian
Antes de comenzar a explicaros el uso de esta técnica en vuestro terminal symbian, deberéis instalar las dos siguientes herramientas en el móvil:
Capturador de redes wifi: barbelo-v0.3.sisx
Posicionador GPS: GPSd-v0.2.jar
Las herramientas Barbelo y GPSd se instalan como cualquier otro programa en symbian. Una vez instaladas deberíais ver en el menú Aplicaciones las herramientas instaladas:
Scr000004[1]
En primer lugar deberemos activar la recepción de posicionamiento por GPS, para ello abriremos la herramienta GPSd, y veremos la siguiente pantalla:
Scr000001[1] Scr000006[1]
Deberemos esperar hasta que el GPS se sitúe. En el caso de mi móvil ha tardado un minuto. Una vez situado pulsaremos sobre la opción Ocultar (Hide).
Ahora abriremos el software Barbelo.Scr000002[2]
Una vez abierto, nuestro móvil habrá comenzado a capturar redes wifi, y se nos irán mostrando en forma de lista en la pantalla. Si vamos pulsando sobre cada una de ellas podremos ir viendo las características de las mismas:
barbelo1 barbero2
Ahora para comenzar a generar nuestro log de redes wifi pulsaremos sobre el botón opciones, y seleccionaremos la opción “Start log”, de esta manera ya estaremos guardando la lista de wifis en el móvil, con su posición por GPS.
Scr000008[1]
Para parar de sniffar tráfico deberemos pulsar sobre el botón opciones, y seleccionaremos la opción “Stop log”. Una vez finalizado el proceso, se nos habrá generado automáticamente un fichero xml, en la ruta "/barbelo" de la tarjeta de memoria del móvil, con toda la información, que podrá ser parseada por cualquier programa, en nuestro caso, lo transformaremos con una herramienta al formato kml que interpreta Google Earth.
Esto es todo por hoy, el próximo día os mostraré como convertir el fichero xml al formato kml y a mostrar el mapa de las redes encontradas en Google Earth.
Hasta el próximo post, saludos!
Flu Project Team

miércoles, 19 de enero de 2011

Hacking Messenger (I de II)

Compartir este artículo:

========================================================Hacking Messenger (I de II)Hacking Messenger (II de II)========================================================

En el presente artículo se explicará lo fácil que es observar los mensajes de messenger o chat. Hoy en día cualquier equipo que se encuentre en la misma red que un equipo que está chateando (si se trabaja en modo compartido, o en modo conmutado mediante un ataque de envenenamiento ARP, que ya explicaremos en otro post) puede leer los mensajes que éste envía con sus contactos. Como solución se propone la implantación de una herramienta que haga mas segura la conversación.Herramientas necesarias para la pruebaPara analizar el tráfico se necesitará la aplicación Wireshark. Esta herramienta antes conocido como Ethereal, es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones para desarrollo de software y protocolos, y como una herramienta didáctica para educación.Para cifrar los mensajes del chat se puede utilizar, entre otras herramientas, Simp. Esta aplicación cifra los mensajes antes de salir del equipo emisor, y una vez llegan al equipo receptor, antes de ser reportado el mensaje al cliente de mensajería se descifra, por lo que el cliente de mensajería receptor recibe el mensaje en texto plano. De este modo se evitará que alguien ajeno a quien va destinado el mensaje pueda leer el contenido.Primer paso: Observando mensajesEn primer lugar, se arranca Wireshark y se encontrará la pantalla que se puede observar en la imagen. Se debe configurar la interfaz de red por la que se va a 'escuchar' el tráfico. En el ejemplo se utiliza la interfaz Wifi, denominada Microsoft por el sistema. Al pulsar sobre la interfaz que se quiere utilizar, la interfaz de red empezará a capturar paquetes y se podrá ir analizando el tráfico en la aplicación. Se puede observar en la imagen de la derecha como Wireshark captura todo el tráfico que circula por la red. Es interesante poder filtrar los paquetes que interesen en cada momento. En este momento interesa analizar los paquetes del protocolo de MSN que circulan por la red.Para amenizar la búsqueda de paquetes y el poder analizarlos se filtrará por protocolo como se puede observar en la imagen:

A continuación se muestra, filtrados los paquetes que se han ido capturando y pueden ser analizados. Es importante observar el protocolo, y diferenciar que algunos de los paquetes son de control del protocolo msnms, mientras que otros paquetes contienen los mensajes entre los usuarios.En la imagen de la izquierda se puede observar como el paquete número 8, marcado con el color amarillo, contiene un 'to' (identificado con el color verde) que es el usuario al que se envía el mensaje, también contiene un 'from' (identificado con el color rojo) que identifica al usuario que envía el mensaje. Además, en la última línea del paquete se puede observar en texto plano el siguiente mensaje 'hola, estoy siendo observado...' identificado con el color verde. En la imagen de la derecha se puede observar como el usuario que anteriormente recibe el mensaje, contesta al usuario que envío el anterior mensaje. El color verde identifica el paquete 129 que es la contestación al mensaje anterior. Se puede observar como el 'to' y el 'from' han intercambiado los papeles. Ahora el usuario hotmail es el que recibe el mensaje y el emisor es el usuario gmail. El mensaje en texto plano se puede observar al final del mensaje, identificado con el color naranja.Se ha visto como es muy fácil observar conversaciones de messenger o chat. Simplemente se necesita estar en la misma red que uno de los hablantes. En el siguiente artículo cifraremos los mensajes para que nadie pueda verlos, excepto, el receptor.

========================================================Hacking Messenger (I de II)Hacking Messenger (II de II)========================================================

Flu Project Team

martes, 18 de enero de 2011

Entrevista a Juan Luis García Rambla (Undercoder)

Compartir este artículo:

Hola a todos, hoy damos comienzo a una nueva línea de posts que haremos para la comunidad Flu con entrevistas a personajes destacados del sector de la seguridad de la información.

Hoy, tenemos el honor de comenzar con una entrevista a Juan Luis García Rambla (Undercoder).

Juan Luis es Responsable del Área de Seguridad de Informática64 y trabaja en esta compañía desde hace ya casi 11 años, ahí es nada. Analista forense experto y dominador de legalidad informática, este año acaba de recibir su sexto galardón como MVP. 3 en Windows Security, 2 en Security Consumer y el último en tecnologías Forefront. Ha escrito varios libros, dos de ellos en la temática de Seguridad de la Información: "Aplicación de medidas para la implantación de la LOPD en las empresas" y "Microsoft Forefront Threat Management Gateway TMG 2010" y ha colaborado en otros libros como son “LOPD aplicada a tecnología Microsoft versión 2”, “Análisis Forense Digital en Entornos Windows" o "SharePoint 2010: Seguridad"

Juan Luis, ¿cuál fue tu primer contacto con la informática?

Mi primer contacto tuvo lugar con un ordenador Spectrum 16K que tenía un amigo y en el que jugábamos y como no llegó la inquietud de saber cómo estaban hechos. Posteriormente tuve mi primer ordenado, el Amstrad CPC 472, variante del 464 que portaba una ROM versión 1.1. Aunque empecé jugando, pronto empecé a realizar programación en Basic y código de máquina en el mismo. Si no recuerdo mal tendría unos 13 años. Desde entonces siempre a mi alrededor en una medida u otra siempre me ha acompañado un equipo.

¿Y con la seguridad?

Esta es posterior a principios de los 90. Entro como militar profesional en una unidad militar de Guerra Electrónica y por mi trayectoria con los sistemas informáticos, participaba activamente en sistemas de detección, intrusión y decepción de comunicaciones en datos. Aunque a otro nivel las bases teóricas y tecnológicas estaban basadas en los mismos axiomas que los sistemas de ataques actuales. Ahí tuve mis primeros contactos con los sistemas de cifrado, de comunicaciones y otros sistemas relacionados con la seguridad informática.

¿Cómo es el día a día de un profesional de la seguridad?

Pues la verdad es que el mundo de la seguridad es tan amplio y hay tantos tipos de profesionales que cada cual puede tener perspectivas diferentes. Evidentemente una buena parte es de I+D, que debe ir alternándose con la realización de auditorías o la implantación de  mecanismos de defensa o bien escribir un artículo o libro. En mi caso puedo decir que cada día es diferente. Mi trabajo evidentemente no puede ser considerado como rutinario, lo mismo estoy auditando un sistema interno Microsoft, implementado un sistema de protección de red, o realizando una auditoría o implantación de LOPD. El de muchos profesionales de la seguridad también puede describirse de esta forma.

¿Qué podrías recomendar a los jóvenes que empiezan en el mundillo de la seguridad?

La seguridad está en constante evolución y requiere por lo tanto de constancia y perseverancia. Es tanto el campo que es mejor centrarse en algo más específico y empezar a crecer desde ahí. Eso sí, aprender todo lo posible dentro del margen legal :-) (a veces me sale esta vena).  También y aunque parezca contradictorio con nuestro yo técnico, el escribir decentemente acaba convirtiéndose en una necesidad. Evidentemente no todo el mundo acaba escribiendo artículos o libros, pero seguramente alguien relacionado con la seguridad acabará redactando un informe. Hay que tener en cuenta que estos no solo lo leen técnicos..

¿A quién te gustaría que hiciésemos la próxima entrevista?

Pues en el día a día conozco gente muy interesante, pero desde hace años trabajo codo a codo en Informática 64 con Juan Garrido. Sus conocimientos y aportes, han complementado cosas que yo inicialmente no creía casi ni posible. Aunque es reconocido como un gran especialista forense, no hay que desdeñar otras múltiples facetas de su capacidad tecnológica. Sería un buen ejemplo para que lo entrevistarais.

Muchas gracias Juan Luis por dedicarnos unos minutos de tu valioso tiempo para poder charlar contigo y entrevistarte. Intentaremos secuestrar a Juanillo (Silverhack) próximamente para entrevistarle y que ya de paso nos firme su libro de Análisis Forense =)

Saludos!

lunes, 17 de enero de 2011

Nueva versión: Flu b0.2

Compartir este artículo:
Buenas a todos, hoy hemos lanzado la beta 0.2 de Flu, en la que hemos añadido muchas novedades y mejoras. Muchas de ellas propuestas por muchos de vosotros que estáis colaborando activamente en el proyecto, ¡gracias!A continuación os presento el listado de mejoras:
  • Se han reconstruido varias partes del código fuente para mejorar la estabilidad de Flu y solucionar los problemas que presentaban algunos usuarios de Windows XP a la hora de ejecutar a Flu.
  • Ahora los envíos de información desde las máquinas infectadas al servidor web se realizan cifradas con AES.
  • Se ha procedido a cifrar con AES el fichero "_debug_err_win_32.txt" que contiene las pulsaciones de teclado recogidas por el keylogger, y se ha dejado preparado para en próximas versiones de Flu traernoslo hasta el servidor web donde será descifrado.
  • Hemos añadido un manual de usuario en el que se explica el funcionamiento y configuración de Flu.
  • El código fuente se ha comentado con más profundidad para ayudaros a entender todas sus funcionalidades.
  • Se han añadido nuevos ataques preconfigurados:
    • Apagar sistema
    • Cerrar sesión
    • Detener el servicio Centro de seguridad
    • Mostrar versión de Windows
    • Mostrar listado de drivers instalados
    • Mostrar información completa del sistema
    • Mostrar direcciones MAC de los adaptadores de red
    • Mostrar configuraciones de las interfaces de red
    • Mostrar listado de conexiones de red realizadas
    • Mostrar listado de procesos en ejecución
    • Mostrar servicios del sistema
    • Mostrar mensaje de infección por pantalla
    • Crear usuario nuevoAdmin con contraseña 123456
    • Convertir usuario nuevoAdmin en administrador
  • Y la mejor de todas las novedades, ¡hemos añadido el ataque David Hasselhoff! Ahora con un simple clic podrás cambiar el fondo de escritorio de todas las máquinas infectadas por Flu por el fondo de pantalla super sexy de nuestro amigo David. ¿Quien se puede resistir =P?:
Como es habitual, podréis descargar esta nueva versión de Flu con todos los códigos fuente, vacuna, manual de usuario, etc. desde el siguiente enlace:http://www.flu-project.com/downloadflu¡Disfrutarlo! Para cualquier cosa no dudéis en contactar con nosotros en info@flu-project.com.Saludos!

Flu Project Team

domingo, 16 de enero de 2011

Informe Flu - 2

Compartir este artículo:

Esta semana se resume con los artículos publicados en el blog comunitario.

Damos comienzo al segundo resumen de la semana 2 de Flu:

Lunes 10 de Enero

Martes 11 de Enero

Miércoles 12 de Enero

Jueves 13 de Enero

Viernes 14 de Enero

Sábado 15 de Enero

¡Bendita semana!

sábado, 15 de enero de 2011

Gira Up To Secure 2011

Compartir este artículo:
La entrada de hoy es más un resumen de lo vivido durante la última semana en la gira Up To Secure 2011, lo cual tengo que agradecer al señor Chema Alonso por haberme invitado a impartir la charla de Malware en Mac OS X y la solución BitDefender.ProgramaEl evento ha pasado esta semana por las ciudades de Pamplona, Zaragoza y Barcelona, contando con un gran aforo. El programa constaba de las siguientes charlas:- Mac OS X & Malware en tu empresa.- Protege tus teléfonos móviles... Forever!- ¿Son seguras las soluciones en la nube?- La seguridad si importa: Windows Live & IE9Yo, como ponente de la charla 'Mac OS X & Malware en tu empresa', me ha resultado una semana muy dura, pero en la que se ha aprendido mucho. Muchos temas interesantes, en los que por ejemplo telefónica nos hablaba de como securizar nuestros teléfonos móviles, y como el presente de la tecnología está en los dispositivos móviles. Por otro lado, los chicos de Quest, explicaban en las distintas ciudades como 'la nube' está cada vez mas cerca. La idea de que servicios como los propios sistemas estén en la nube asusta a más de uno, pero Quest explica lo que es el Cloud Computing, y como es una buena solución. Aunque siendo realistas, eso de que nuestros datos no estén cerca de nosotros, a más de uno le inquieta.La última, quizá la mas esperada, charla impartida por Chema Alonso explicaba como la seguridad es muy escasa en clientes webmail, aunque sea Gmail. Chema explicó conceptos interesantes, a la que la gente reaccionó con concentración y curiosidad.Mi charla, la cual fue la primera en Zaragoza y Barcelona y tercera en Pamplona por cuestiones de trenes, trataba del malware en Mac OS X. Mucha gente dice que no existe el malware para Mac, que es una invención de las casas de antivirus. Se realizó una demostración en la que se pudo observar como se infectaba un Mac OS X y después una solución AV como BitDefender limpiaba el malware.A modo personalCompartir cartel con ponentes tan importantes y la oportunidad ofrecida por un amigo, fue una experiencia enriquecedora. Nunca se podrá olvidar el trato recibido por las personas de los eventos, y quiero agradecer desde aquí a los centros dónde fuimos acogidos CEIN, CREA y BCNActiva.

Flu Project Team

viernes, 14 de enero de 2011

Nuevo canal IRC

Compartir este artículo:

Buenas a todos, a principios de semana estrenamos en el portal un canal IRC para hablar en tiempo real entre los miembros de la comunidad y debatir temas sobre el proyecto (y sobre lo que queráis). Gracias Drknzz.

Por el momento ya nos hemos conocido varios miembros de la comunidad. Decir que hay gente de mucho nivel por el portal de todo el mundo, un verdadero placer =) y que seguro servirá para hacer de la comunidad un sitio de referencia en seguridad de la información, y de Flu un referente para aprender técnicas anti-malware.

Podéis acceder al canal desde aquí. Daos una vuelta, presentaros y ya veréis como repetís ;). Casi siempre está uno de nuestros moderadores @Drknzz. Pablo y yo estaremos siempre que podamos para hablar con vosotros, resolver dudas, proponernos ideas, ayudarnos o simplemente para charlar un rato.

Aprovecho el post también para daros algún dato interesante sobre el portal.

En la actualidad ya hemos superado los 300 usuarios registrados. El foro está teniendo mucho movimiento, y hemos superado los 320 mensajes, mucha gente está proponiendo ideas que en estos momentos si no son ellos mismos, somos Pablo y yo, se están desarrollando. Por ejemplo, una de las principales ramas de investigación que ha ido apareciendo es la de portar Flu a linux, donde ya hay varios usuarios investigando. Otra bastante interesante ha sido la de portar Flu para Android en la que estoy yo y @felmoltor. Por otro lado, y la que más afluencia está teniendo es la de Flu para Windows, en la que se están desarrollando una gran cantidad de funcionalidades nuevas. De hecho la semana que viene estaréis probando muchas de ellas en la b0.2 de Flu. No os adelanto más cosas, pasaros por el foro y por el canal IRC y disfrutarlas vosotros mismos ;)

Saludos!

jueves, 13 de enero de 2011

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (II de II)

Compartir este artículo:

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (Parte I de II)

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (Parte II de II)

Buenas a todos, en el post de hoy vamos a concluir la cadena de posts que comenzamos ayer sobre cifrado de datos con el algoritmo Rijndael (AES)

Hoy descifraremos la cadena de texto que ciframos ayer mediante una aplicación desarrollada en PHP, que emulará la manera en la que Flu desencripta los datos enviados en la botnet.

El código utilizado para el proceso de desencripción es el siguiente:

Como veis, hemos creado una función llamada decrypt a la que le pasaremos por cabera tres datos, el primero será la clave que utilizamos en el proceso de encriptación, el segundo será nuestro vector de inicialización y en tercer lugar la cadena encriptada.

La función se compone de solo dos líneas de código, la primera que creo que no hará falta explicar, en la que convertiremos el vector de inicialización a codificación UTF-8. Y la segunda que es un poco más compleja.

Nota: Como curiosidad, aunque no tiene nada que ver con el post, la función mb_convert_encoding de PHP si le pasamos como parámetros algo parecido a esto mb_convert_encoding($iv,’UTF-8',’ISO-8859-1') comprobará si la cadena iv está en formato ISO-8859-1 para codificarla a UTF-8.

Si ahora le pasamos como parámetros mb_convert_encoding($iv,’UTF-8',’ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1') comprobará 5 veces si la cadena iv está en formato ISO-8859-1. Veis por donde voy ¿no? Si tenemos en cuenta que el mecanismo para determinar el charset es muy costoso, y le pasamos un fichero con muchos parámetros separados por comas, estaríamos ante un DDoS de nuestro servidor web en toda regla. Volvamos a nuestro algoritmo =)

En primer lugar le indicaremos que se hará el descifrado con una clave de 128bits, recordar los tamaños que comentábamos en el post anterior, 128, 192 y 256 bits. En segundo lugar le pasaremos la clave tal cual. En tercer lugar le pasaremos la cadena encriptada, recordad que la habiamos convertido a base 64 en el último paso de nuestro algoritmo de cifrado por lo que habrá que restaurarla a su origen. A continuación le indicaremos el modo de cifrado por bloques, en nuestro caso CBC y finalmente le pasaremos el vector de inicialización.

Para probar si funciona nos creamos una aplicación PHP utilizando la función anterior:

Si la ejecutamos, para ello nosotros hemos montado un WAMP en Windows 7, veremos el mensaje desencriptado:

Espero que os haya gustado el post.

¡Hasta la próxima!

miércoles, 12 de enero de 2011

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (I de II)

Compartir este artículo:

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (Parte I de II)

Flu beta 0.2 y el envío de datos de la botnet cifrados con AES (Parte II de II)

Buenas a todos, la próxima versión de Flu, que será la beta 0.2 se caracterizará porque permitirá, entre otras cosas, el envío de los datos recuperados desde nuestra botnet de manera cifrada mediante el algoritmo Rijndael (AES). En esta cadena de dos posts que hoy doy comienzo voy a enseñaros a cifrar una cadena de texto, desarrollando un programa en C#. Posteriormente descifraremos la cadena desarrollando una aplicación PHP, al igual que hará Flu en su próxima versión.

Antes de nada vamos a ver un poco de historia sobre este algoritmo:

En el año 2000, hace ya 11 años, el National Institute for Standards and Technology, conocido como el NIST, anunció que el algoritmo Rijndael iba a ser el nuevo estándar.

El nombre del algoritmo proviene de sus inventores Joan Daemen y Vicent Rijmen. AES es un sistema de cifrado por bloques que puede manejar longitudes de entre 128 y 256 bits de clave y de bloque.

En 2003 fue aprobado para su uso por la NSA para cifrar información clasificada como alto secreto.

Hoy por hoy es de los algoritmos de criptografía simétrica más seguros.

Si tenéis interés en aprender el funcionamiento del algoritmo hasta el más mínimo detalle, os recomiendo sin duda esta animación Flash que ha diseñado Enrique Zabala: http://bit.ly/aTumKd

Comencemos con el algoritmo de cifrado que vamos a estudiar:

En primer lugar agregaremos la siguiente directiva using:

A continuación os presento el algoritmo de cifrado completo:

En primer lugar debemos definir una clave y un vector de inicialización (iv). Para el ejemplo hemos inventado una clave de 16 bytes (qwertyuioplkjhgf), es decir 16 x 8 = 128 bits, que es el tamaño menor de clave que admite AES. Podéis sustituir la clave por la que queráis, pero siempre respetando los tamaños. Idem con el vector de inicialización.

Si no queréis inventaros una clave o vector de incialización podéis generarlos automaticamente con el siguiente código:

Rijndael rijndael = Rijndael.Create();

byte[] clave = rijndael.Key;

byte[] iv  = rijndael.IV;

Ahora pasaremos a bytes la cadena de texto que queremos cifrar, en nuestro caso se la pasaremos en la variable cadena y creamos la variable cadenaEncriptada donde almacenaremos el resultado.

A continuación crearemos la instancia del algoritmo Rijndael:

RijndaelManaged cripto = new RijndaelManaged();

Y estableceremos el flujo en memoria para el cifrado y el flujo de cifrado:

using (MemoryStream ms = new MemoryStream(inBytes.Length))

using (CryptoStream objCryptoStream = new CryptoStream(ms, cripto.CreateEncryptor(clave, iv), CryptoStreamMode.Write))

Una vez hecho esto realizamos el cifrado enviando los datos en bytes al flujo de cifrado (objCryptoStream.Write) y recuperaremos los datos ya cifrados en la variable cadenaEncriptada:

cadenaEncriptada = ms.ToArray();

Finalmente devolvemos el resultado en Base 64.

Para mostraros el funcionamiento he desarrollado una sencilla aplicación que os podéis descargar junto con su código fuente desde aquí.

Aprovecho el post para agradecer a @nexus6 su apoyo en el desarrollo de este módulo de Flu, ¡gracias!

Mañana continuaremos con el descifrado mediante el desarrollo de una aplicación en PHP.

Saludos!