Mostrando entradas con la etiqueta seguridad informatica. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad informatica. Mostrar todas las entradas

viernes, 23 de febrero de 2018

SQL Injection para dummies (Tercera y última parte)

Buenas de nuevo.

En este tercer y último post sobre SQL Injection (por ahora) vamos a sacarle todo el jugo al asunto, y a la base de datos.

Una vez hemos hecho el reconocimiento sobre el sistema objetivo, vamos a intentar obtener los datos de más campos de la base de datos, no solamente los nombres y apellidos como obtuvimos con el “ ‘ or ‘1’=’1 “.

lunes, 19 de febrero de 2018

SQL Injection para dummies (Segunda parte)

Hola de nuevo.

Aquí tenemos la segunda entrada sobre SQL Injection. En la anterior nos quedamos en descubrir un parámetro vulnerable y el por qué de que esto sea así. Ahora vamos a pasar a jugar con la vulnerabilidad y a hacer cosas más vistosas.
Sabiendo la estructura exacta de la consulta SQL podríamos llevar a cabo ataques mucho más precisos, pero rara vez vamos a tener acceso al código a la hora de realizar un pentest. Por tanto, vamos a ir dando palos de ciego y viendo qué nos encontramos a medida que avanzamos con el ataque.

viernes, 16 de febrero de 2018

SQL Injection para dummies (Primera parte)

Buenas a todos, este es mi primer post en el blog tras el inicio de los C43S4RS. No sabía muy bien de qué hablaros puesto que mis compañeros del grupo tienen muy buenas ideas y proyectos para plasmar aquí, y por supuesto no quería pisarles ninguna, así que al final me he decidido a escribir sobre SQL Injection.

lunes, 28 de marzo de 2016

Cómo usar Metasploit en Armitage desde 0 a modo colaborativo

Hoy vamos a explicar el potencial de Armitage, una interfaz gráfica sobre el conocido framework  de explotación Metasploit, la cual nos va a ayudar en nuestras auditorías, llegando al punto de poder colaborar al mismo tiempo con varios compañeros en nuestro Pentesting. Antes de nada comentar que vamos a usar una máquina atacante con una distribución Kali Linux 2.0 y otra máquina vulnerable Windows como víctima.

Configuración Inicial
Antes de nada vamos a configurar la máquina del atacante. Dado que Armitage trabaja sobre Metasploit y este a su vez trabaja con una base de datos Postgresql, lo primero que debemos hacer es levantar el servicio de la base de datos.



Ahora arrancamos Armitage, donde lo primero que nos pedirá es conectarse al servidor de Metasploit RPC, en caso de que no esté levantado nos preguntará si lo queremos levantar. Acto seguido pedirá los datos de conexión, donde introducimos los datos por defecto que podemos ver en la siguiente imagen.
Configuración por defecto
Primeros pasos
Una vez tenemos Armitage funcionando lo primero que se haría ahora sería escanear la red. Armitage incorpora una función para poder escanearla con Nmap. Para ello nos vamos a la pestaña Hosts Nmap Scan y aquí elegiríamos el tipo de escaneo, en nuestro caso Intense Scan.


 Introducimos la dirección IP de la red y el CIDR (el nº de unos de la máscara).


Una vez finalice el escaneo podemos apreciar como salen los hosts de nuestra red.


Encontrado vulnerabilidades
Una vez tenemos el esquema de la red y los equipos que podemos encontrar, nos iremos uno por uno a escanear los posibles fallos de seguridad. Para ello le damos clic derecho sobre nuestro objetivo y seleccionamos Scan.


Una vez hecho esto, tendríamos que irnos a la pestaña Attacks Find attacks.


Con esa funcionalidad conseguimos que se busquen los diferentes exploits que pueden afectar a los diferentes vectores de ataques encontrados en el escaneo. Vemos en la siguiente imagen como se van consultando al servicio de Metasploit.

Una vez terminado nos vamos a la máquina víctima y hacemos clic derecho para ver la opción Attack, donde encontramos las posibles exploits que pueden afectarle a nuestro objetivo.


En nuestro caso es una máquina XP con una vulnerabilidad muy conocida en el puerto 445 (MS08-067) que aunque parezca sorprendente sigue existiendo en muchas máquinas a día de hoy. Aquí os dejo referencias sobre la misma:

Atacando a la víctima
Ahora que ya tenemos varias ataques posibles podemos elegir el que queramos. Nosotros seleccionaremos el exploit a lanzar en Attack → smb ms08_067_netapi. Una vez hecho esto debemos configurar las opciones del exploit como haríamos en la consola de Metasploit. 


¿Cómo sabemos que nuestro ataque ha funcionado? Podemos ver en la consola si las diferentes fases del exploit se han ejecutando correctamente y si hemos conseguido alguna sesión de meterpreter, shell... Aquellos equipos que sean comprometidos saldrán marcados como en la imagen.


Explotando el objetivo
Ahora ya tendríamos el control del equipo víctima y pasaríamos a la fase de explotación. Un consejo es crear varias sesiones de meterpreter sobre cada víctima previamente a la explotación por si alguna falla. En cuanto a la explotación en si sólo tendríamos que irnos a la sesión que queremos y elegir qué hacer. En la siguiente imagen vemos como podemos ejecutar un keylogger para ver que escribe la víctima Meterpreter1 → Explore  Log keystrokes.


Tenemos gran cantidad de posibilidades como explorar los archivos, tomar capturas de pantalla de lo que está viendo la víctima en cada momento o incluso obtener las contraseñas que hay almacenas en la RAM.

Modo colaborativo
Una funcionalidad muy interesante de Armitage es el modo colaborativo o lo que se conoce como multiplayer. Básicamente nos permite que varios usuarios compartan la información del pentest a través de la interfaz Armitage, para ello todos se conectan a la misma bbdd compartida en tiempo real, donde se almacenan los diferentes vulnerabilidades encontradas. Esto es muy útil en auditorías internas grandes ya que hace que sea mucho más fácil la coordinación entre el grupo de pentesters.

Además de ver que es lo que hace cada uno, podemos comunicarnos con los diferentes usuarios, así como ver los escaneos y máquinas vulneradas. 


¿Cómo usamos el modo multiplayer?
Básicamente en el modo multiplayer tenemos un Armitage en modo servidor y el resto en modo cliente (arquitectura Cliente-Servidor típica). Lo primero que tendremos que hacer para levantar el servidor es irnos a la carpeta de Armitage, que en Kali Linux está en /usr/share/armitage/ :


Y ahora tenemos que iniciar el archivo teamserver pasándole los parámetros de nuestra IP y la contraseña que queremos ponerle. En nuestro caso la IP es 192.168.0.107 y la contraseña wwh. En la siguiente imagen vemos el resultado de la ejecución así como los parámetros que necesitarán el resto de compañeros para conectarse al servidor.


Ahora ejecutamos Armitage desde los diferentes clientes, tanto desde nuestra máquina como desde las del resto de compañero de equipo. Se puede apreciar en la imagen anterior la IP de la máquina donde está el servicio, el puerto, usuario, contraseña y el Fingerprint del servidor. Una vez ejecutado nos pedirá los parámetros de configuración del servidor de los que hablábamos.


Si las credenciales son válidas nos saldrá lo siguiente:


El Fingerprint del servidor del equipo debe ser el mismo, sino estaríamos conectando a uno diferente. Nos pedirá acto seguido nuestro nick para poder hablar con el resto de compañeros:


En la siguiente imagen vemos en el Log de Eventos de Armitage los diferentes usuarios conectados y lo que están haciendo en cada momento. En la imagen vemos como un usuario ha lanzado un escaneo y todos los usuarios verán los resultados. Los avances que lleven a cabo todo el equipo serán compartidos por todos.


Bueno pues esto ha sido todo, espero que os haya gustado la herramienta. Para el que no me conozca me llamo Rafa Sojo, soy estudiante de "Sistemas Microinformáticos y Redes" y me encanta la seguridad. Os dejo mi twitter por si queréis contactar conmigo.

Un saludo.

martes, 13 de octubre de 2015

Hackeando el 2FA en Android

Muchos de nosotros hacemos uso del doble factor de autenticación (2FA: two step verification) y recomendamos su uso, ya que es una capa de seguridad más añadida a nuestras contraseñas en cuentas de correo, blogs y otros servicios en Internet. Si es complicado hacerse con nuestras credenciales, más aún poder obtener el código de verificación 2FA. Pero ¿qué pasaría si pudiésemos obtener ambas cosas al mismo tiempo?

En el siguiendo artículo vamos a ver como podemos obtener las credenciales de cuentas de correo electrónico así como los códigos de verificación almacenadas en un terminal Android. Antes de comenzar es muy importante recordar uno de los principios de la Seguridad en Android (vistos en el artículo Metodología de Seguridad en Android) donde para cada aplicación instalada en Android se crea un usuario, de tal forma que una aplicación no puede acceder a la carpeta de otra aplicación. Además dentro de la memoria del terminal tenemos una parte de memoria interna (sólo accede el sistema) y otra de memoria externa o de usuario (sin contar con el almacenamiento SD).

Todo esto está muy bien, pero esta seguridad se rompe en el momento en que rooteamos el teléfono o una aplicación maliciosa ejecuta un exploit el cual utiliza una vulnerabilidad del sistema para hacer una elevación de privilegios y hacerse root, de tal forma que una aplicación con permisos root tendrá permiso para campar a sus anchas y acceder a los ficheros que quiera en la memoria interna. 

Nosotros nos vamos a centrar en dos aplicaciones que podemos encontrar en muchos terminales Android, un gestor de correo y el gestor de 2FA. Las aplicaciones en concreto son:
  • Correo (com.android.email)
  • Google Authenticator (com.google.android.apss.authenticator2)
Una de las grandes vulnerabilidades de las aplicaciones Android que podemos encontrar dentro del TOP 10 Owasp Mobile Risks es el almacenamiento inseguro de datos, este tipo de vulnerabilidad es la segunda más encontrada como podemos ver en el esquema de OWASP.


Como hemos hablado anteriormente, dentro del sistema operativo Android existe una memoria interna en la cual se instalan las aplicaciones, concretamente la ruta es /data/data/ y ahí vamos a encontrar las aplicaciones de la cual queremos obtener información, tal cual como lo haría una aplicación maliciosa que consigue acceso root.

Insecure Data Storage en com.android.email

Esta aplicación de correo electrónico desarrollada por Google la podemos encontrar en muchas distribuciones de Android como parte del sistema operativo, tanto en ROMs de marcas comerciales como también en ROMs cocinadas.

Si nos traemos las todo el directorio /data/data/com.android.email/ podemos encontrarnos con que hay una base de datos SQLite muy interesante dentro del directorio databases: EmailProvider.db


Concretamente dentro de la tabla HostAuth podemos encontrar los correos configurados en el terminal junto con la contraseña en plano, algo increible pero cierto. Si abrimos este fichero con algún programa para visualizar SQLites encontramos lo siguiente:


Aquí no acaba la cosa, el sistema también almacena en texto plano las contraseñas de los correos en texto plano en el siguiente fichero /data/system/users/0/accounts.db 


Bueno ya tenemos los correos electrónicos y las contraseñas, si ahora intentamos acceder a alguno de estos correos nos solicita el 2FA. ¿Cómo hacemos para conseguir el código de verificación teniendo acceso al terminal como root?

Insecure Data Storage en com.google.android.apss.authenticator2

Vamos a ver ahora un caso parecido con la aplicación de Google Authenticator ¿Alguna vez os habéis planteado restaurar vuestro Android de fábrica con su correspondiente Wipe-Data pero no os habéis atrevido porque podéis perder el 2FA? 

Además de eso podemos preguntarnos (por aquello del pensamiento lateral de los hackers) qué ocurriría si copio el directorio completo /data/data/com.google.android.apps.authenticator2 y lo monto en otro terminal, ¿debería dejarme acceder a los códigos de verificación? ¿la instalación del Google Authenticator y los códigos que se generan debería ser única? es decir,si tendría algún tipo de protección por seguridad. Pues bien, la respuesta a estas preguntas es que no tiene protección, podemos hacer lo que queramos

Paso a paso, haremos lo siguiente:

 1. Copiamos la carpeta completa del terminal con la instrucción: 

adb pull /data/data/com.google.android.apps.authenticator2  

 2. Vemos que tenemos dentro tres carpetas: app_sslcache, databases y shared_prefs.

 3. Dentro de la carpeta databases nos centramos en el fichero databases.db y en la tabla accounts obtenemos lo que buscamos, las cuentas asociadas con su código secreto.


Con estos secret keys podemos generar los códigos de verificación asociados a cada una de las cuentas de correo cuyas contraseñas ya teníamos. Pero vamos a probar a montar toda la estructura de directorios en un emulador a ver si funciona el Google Authenticator, para ello primero instalamos la aplicación y acto seguido copiamos todo el directorio completo con las tres carpetas.


Instalamos con adb install <aplicación.,apk> y copiamos todo el directorio al emulador para ver si nos permite así cambiar los códigos de un terminal a otro simplemente con Copy/Paste. En la siguiente imagen vemos como lo permite perfectamente.


Conclusión

Hemos visto como por culpa de fallos a nivel de programación donde se lleva a cabo un almacenamiento inseguro de información sensible, se ven expuestas nuestras contraseñas y los códigos secretos de verificación. Cualquiera de nuestros terminales puede ser víctima de cierta aplicación maliciosa, de una vulnerabilidad de 0day o de una vulnerabilidad no parcheada por nuestro fabricante.

Recomendaciones
  • Actualizar el sistema lo máximo posible, ya que los fabricantes no suelen sacar muy a menudo actualizaciones para forzarnos así a comprar nuevos terminales. Recomiendo en este caso el uso de ROMs cocinadas que parchean los fallos de seguridad a diario
  • Hacer uso de herramientas de control de permisos para impedir a las aplicaciones tener más permisos de los necesarios, de tal forma que podemos así controlar quien accede a que recuersos. Podéis ver herramientas de control de recursos en mi artículo  Privacidad en Android del blog de Hacking Ético (http://hacking-etico.com/2014/08/12/privacidad-en-android/)
  • Hacer uso de herramientas de seguridad como antivirus, antimalware y otras herramientas que te chequean los fallos de seguridad más reciente. Os recomiendo que uséis la herramienta Android Vulnerability Test Suite (https://github.com/nowsecure/android-vts) que os permite testear si tenéis las últimas vulnerabilidades parcheadas.
  • Otras capas de seguridad recomendables serían deshabilitar el ADB (Android Debug Bridge), usar bloqueo de sesión bien con pin numérico de más de 5 dígitos o patrón y sobre todo cifra tu dispositivo por si cae en manos equivocadas. 
Formación en Seguridad Android

Si te interesa la seguridad en Android, los próximos cursos y talleres que impartiré serán los siguientes:


  • Curso Forense en Android ( 29 Enero y 5 Febrero - Modalidad Online): curso totalmente práctico donde llevaremos a cabo el proceso forense de un terminal Android para obtener el máximo número de pruebas. Tocando directorios claves del sistema operativo como de las aplicaciones más utilizadas que nos brindan gran cantidad de información. Más información aquí.
  • Taller Pentesting de Aplicaciones Android (12 Febrero Cuenca - MorterueloCon): taller de 4 horas sobre auditoría de aplicaciones móviles siguiendo la metodología OWASP. Más información aquí.
  • Curso Pentesting en Android (27 Febrero Valencia): un curso presencial muy completo de 8 horas de duración, donde veremos los diferentes puntos del Pentesting en Android para poder auditar aplicaciones, analizar malware e incluso llevar a cabo un análisis forense de un terminal. Más información aquí.



Espero que os haya gustado el artículo y que tengáis presente que la seguridad 100% no existe, sólo podemos añadir cuantas más capas de seguridad mejor.

Un handshake


"Comienza haciendo lo que es necesario, después lo que es posible y de repente estarás haciendo lo imposible"
S.F.d.A.










viernes, 20 de febrero de 2015

Haciendo un DUMP de la memoria RAM

En un análisis forense es de vital importancia conseguir una copia exacta del sistema que se vaya analizar incluyendo la memoria RAM, teniendo ésta mucha importancia debido a la volatilidad que implica el poder llegar a perder los datos si la alimentación fallase porque como ya sabemos, la memoria RAM sólo almacenará datos cuando el sistema esté encendido. Es por esto que una de las primeras acciones para la recogida de evidencias será capturar todo lo que hay en la memoria física para poder analizarlo posteriormente sin alterar ningún dato.

Para poder hacer un dump de la memoria (volcado de memoria) existen varias herramientas que nos ayudarán a conseguir el objetivo. Yo os traigo las dos herramientas que mas me han gustado a mi después de haber estado probando unas pocas. Y por supuesto, de Microsoft Windows.


  • Win32dd.exe - Win64dd.exe: Dependiendo del sistema operativo que utilices tendrás que usar una versión u otra. Esta sencilla herramienta nos hará una copia de la RAM tal cual esté en el momento. Según tengamos más o menos memoria física tardará mucho o poco, no tardará lo mismo para una RAM de 2GB que para una de 8GB. Esta herramienta funciona a través de la línea de comandos, por lo que tendremos que abrir un cmd y desde la ruta de donde tengamos el .exe escribiremos el siguiente comando: win64dd.exe /r /a /f dump.img. Vamos ahora a analizar para que sirve cada opción;
    • /r -> Crea el archivo de volcado de memoria
    • /a -> Contesta si a todas las preguntas que se hagan durante el proceso
    • /f -> Fichero destinado (Nombre del fichero)

Como podemos ver en la imagen, sale información sobre el SO que usamos, la capacidad de la memoria, la cantidad que tenemos disponible etc.. 

Ejecutando el comando de win64dd.exe

Una vez se haya realizado el dump nos saldrá un mensaje como el de la siguiente imagen en el cual nos indica el tiempo que tarda en hacerse, el tamaño del fichero o el total de paginas escritas.


DUMP hecho exitosamente

Esta es una de las dos sencillas herramientas que traigo para hacer el volcado de la memoria física que va por línea de comandos y que puedes descargar desde aquí, la siguiente herramienta es en un entorno gráfico muy fácil de utilizar también.

  • FTK Imager: La segunda herramienta también sirve para hacer una copia exacta de la memoria física del momento. Una de las ventajas que tiene esta herramienta al ser en un entorno gráfico, es que cuando conseguimos hacer la copia, podemos examinar el valor de la misma y así ver por ejemplo alguna password que haya quedado almacenada en la RAM al loguearnos en algún portal, los procesos que estaban abiertos y las conexiones activas, versión del sistema operativo y muchas más cosas. Para conseguir un volcado se haría de la siguiente manera: Al ejecutar el programa haremos click en el icono de la memoria que pone "Capture memory". 
Crear el volcado de memoria
          En la siguiente ventana que se nos abre, en destination path daremos click en browse para seleccionar el lugar de almacenamiento de dicha captura. Para finalizar haremos click en capture memory y empezará a realizar el volcado. Igual que en la anterior herramienta, dependiendo de la capacidad de nuestra memoria tardará más o menos. Una vez que tenemos la memoria capturada y quisiéramos verificar que está bien hecha la captura, deberíamos podemos verificarlo mediante el md5 o sha1 que nos da haciendo click con el botón derecho en su icono y más tarde en "Verify drive/image". Mientras tanto, vemos en la pestaña de abajo como el principio de nuestra memoria está lleno de 0, es algo normal pero si vamos bajando, vemos información que tenía almacenada la RAM cuando hicimos el dump. Os pongo dos ejemplo de una contraseña que se quedó guardada o de un simple proceso que estaba en ejecución en el momento de la captura.

Contraseña almacenada en la RAM de un campo hidden

Proceso en ejecución a la hora de realizar el dump


Esta herramienta como podemos ver nos podría servir de gran ayuda a la hora de realizar un análisis forense en la captura de evidencias, podemos ver que procesos había en ejecución incluso con las conexiones que realizarían estos mismos. FTK Imager podemos descargarla desde aquí.

Otras herramientas que también podrían servir son; NotMyFault de SysInternals, SystemDump o LiveKD



Viendo estas dos herramientas y la gran utilidad que tienen en un análisis forense para recoger evidencias he llegado a replantearme que la memoria RAM tiene mucha más información valiosa de la que yo pensaba, al ser volátil no la tenemos muy en cuenta pero nos puede servir para conseguir información muy valiosa sobre un sistema. Bueno y.. una vez conseguido el dump de la RAM ¿Qué? ¿Cómo vemos toda la información de una forma estructurada?
Para eso os traigo una gran herramienta  que incluye en su repositorio la distribución de seguridad informática Kali Linux llamada volatility que nos servirá de gran ayuda para ver que contiene nuestro volcado de memoria de una forma estructurada y con muchas opciones.



-Volatility: Para empezar, arrancaremos nuestro Kali y en un USB por ejemplo tendremos la copia del volcado que tendremos que haber hecho previamente. Empezaremos con el siguiente comando para que analice el volcado y nos dará información del SO que lleva instalado.
vol imageinfo -f /ruta/volcado.img


El siguiente comando nos ayudará para conseguir las direcciones de memoria donde están los registros del sistema. El comando que ejecutaremos eserá el siguiente. (Seleccionaremos el perfil que nos dio el resultado anterior)
vol hivelist -f /ruta/volcado.img --profile=perfil


Como ya dije anteriormente, la memoria RAM almacena cantidad de información, y una que nos puede ser muy útil es la de saber los procesos que había activos en el momento del dump para poder ver si había algun software malicioso ejecutandose.
vol pslist -f /ruta/volcado.img --profile=perfil


Y también podemos ver que procesos son hijos de que procesos pero esta vez añadiremos la opción pstree para ver en forma de árbol estos procesos.
vol pstree -f /ruta/volcado.img --profile=perfil


No nos vamos a olvidar de saber que servicios se estaban ejecutando en el momento del dump por supuesto, y para ello usaremos la opción svcscan.
vol svcscan -f /ruta/volcado.img --profile=perfil



Y por último he querido añadir también el comando ldrmodules que puede servir para buscar una dll oculta que haya en el sistema.
vol ldrmodules -f /ruta/volcado.img --profile=perfil



Esto es todo lo que os he querido mostrar en esta entrada de hoy, nos vamos sabiendo que en un análisis forense será de vital importancia hacer un volcado de la RAM siendo una de las primeras tareas que tengamos hacer debido a que es volátil. Este volcado podrá aportar a la hora de crear el informe final muchas evidencias y así conseguir el objetivo.




Un saludo!

@Joseliyo_Jstnk