auditar-api

Revisando nuestros servicios: auditar API (parte 1)

Poder ofrecer la información de valor que genera tu empresa de una forma eficiente y segura es tan importante que puede ser el punto de inflexión entre convertirla en un Unicornio o llevarla directamente a la ruina.

En el mundo de hoy, contar con una buena API que permita a terceros consumir tu información te va a permitir extender tu negocio más allá de lo que puedes ofrecer de forma individual. Es habitual conceder acceso a una parte pública de la información, pero otra parte sensible suele estar vinculada a algún contrato, cuota o condiciones particulares.

Una API abierta a terceros te permitirá abrir tu información y servicios a todo tipo de clientes, gestionando hasta dónde quieres que puedan llegar. Sólo tienes que ponerte a desarrollar en tu proceso de integración continua, darle caña a las pruebas unitarias, los test de integración, la documentación y todo lo que tu metodología dicte. Por fin tienes una API de calidad dispuesta a echar humo con miles de clientes y…

…entonces llego yo y te pregunto… ¿has tenido en cuenta la seguridad en el ciclo de vida de tu API?

Tu respuesta tiene una alta probabilidad de ser «ehhh…. no!». Lo normal es que sea así y que se hayan cometido errores de desarrollo que impliquen vulnerabilidades en nuestra API que puedan impactar en nuestro producto.

¿Como incorporo la seguridad a mi API?

api_security

Si no has empezado a desarrollarla, entonces te recomiendo que tengas en cuenta algún modelo como «Microsoft Security Development Lifecycle» (echando un vistazo aquí, aquí o aquí, aunque hablaremos de esto en breve) y lo hagas bien desde el principio.

Si ya tienes tu API funcionando, en la próxima entrada realizaremos una pequeña prueba que te puede ayudar a evaluar su seguridad.

En cualquier caso, deberías tener en cuenta siempre estos checks básicos:

1) Fase de Autenticación:

  • Habilita tu API únicamente con SSL, todos los accesos debería ser https. Prohibe http o dale un uso meramente informativo.
  • Nunca envíes usuarios, contraseñas, tokens… en la url.

2) Fase de Autorización:

  • Pon especial atención en el escalado de privilegios tanto en horizontal como en vertical.
  • Acentúa los controles en las peticiones que actualicen o eliminen información.
  • Utiliza roles para administrar permisos de tus usuarios.
  • Protege al máximo las funcionalidades destinadas a usuarios administrativos.

3) Gestión de sesión:

  • Habilita un tiempo máximo de sesión (timeout).
  • Asegúrate de tener medidas para invalidar tokens si es necesario.

4) Validación de entradas:

  • Los ataques web habituales pueden afectar a tu API, así que pon atención en los conocidos ataques de injección, xss…

5) Codificación de salidas:

  • Revisa bien la estructura de tu salida json, xml,…
  • Inserta cabeceras de seguridad acordes al uso que se le va a dar a tu API.

Empieza por echar un vistazo a estas recomendaciones. En la próxima entrada seguiremos viendo detalles para tener tu API lo más segura posible. ¿Te lo vas a perder?

voluntechies

Voluntechies, tecnología al servicio de los niños

Hace unas semanas mi antiguo profesor, Chema Alonso, publicó en su blog una entrada sobre Voluntechies, una iniciativa muy interesante que utiliza la realidad virtual para tratar de aportar a niños enfermos un poco de distracción y diversión de cara a su lucha diaria.

La verdad es que el post me tocó la fibra sensible por varios motivos, el primero por una introducción de Chema sobre sus dos hijas en las que me sentí muy identificado. Los que tenemos esos pequeños seres por casa sabemos de su increíble capacidad para asombrarse, pasarlo bien y ser felices durante todo el día. Mis pitufas de 3 y 1 año hacen que viva cansado, sin fuerzas, tomando café como un condenado para sobrevivir a las noches de tos, mocos y despertares varios. Convierten mis tardes en juegos de alfombra (o en visionados recurrentes de películas de princesas) y los fines de semana en interminables sesiones de parque rodeados por padres que no miran por la seguridad y educación de sus hijos (o de aquellos a los que sus hijos no respetan).

Lo increíble es que me encanta, adoro a esas pequeñas personitas que se saltan todos mis protocolos de seguridad y me hacen salir de la rutina y el ajetreo laboral.

El segundo motivo, por mi experiencia personal trabajando con niños. Allá por 2.007 tuve la gran suerte de poder formar parte del grupo de investigación del departamento de Lenguajes y Sistemas Informáticos de la Universidad de Granada, en el proyecto Sc@ut.

Sc@ut era un comunicador basado en pda (si, en aquel momento no existían los smartphones…) que permitía una comunicación básica a personas con autismo o daños cerebrales. Su uso era muy sencillo y se podían configurar acciones mediante un editor de plantillas. Con un poco de entrenamiento, se comenzaron a obtener resultados muy buenos. Fruto de aquello obtuvimos varios premios, siendo el más importante la Imagine Cup de Microsoft, un concurso de desarrollo de software que nos terminó llevando a Korea para participar en las finales mundiales.

Os dejo un enlace a un video de TVE2 en el que se comenta el concurso y en el que me podéis ver simulando ser una persona con autismo:

¿Por qué os cuento esto? Sencillo, Sc@ut era un ejemplo de tecnología que ayudaba a personas con un problema y les permitía mejorar su calidad de vida. ¿No es maravilloso que lo que hacemos los que nos dedicamos a esto de la informática pueda ser de utilidad más allá del mundo laboral? Yo tengo dos pequeñas por las que daría la vida, pero hay veces en las que no está en tu mano poder encontrar soluciones. Si la tecnología puede hacer que su complicado día a día sea mejor, entonces hay que celebrarlo y difundirlo.

Es por eso que recojo el guante lanzado por Chema para hacer llegar la labor de Voluntechies un poco más lejos y animo a los muchos o pocos lectores de este blog a echarle un vistazo a su web y a asistir a alguno de sus talleres.

Os aseguro que no hay nada más gratificante que trabajar en algo que ayuda a los demás. ¿Os animáis a probarlo?

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 3)

Ha pasado un poco de tiempo desde que empezamos con esta serie de entradas dedicadas a la auditoría de código, pero vamos de nuevo con el último post de la serie.

En la primera parte, hicimos una introducción a la tarea y vimos cómo se trata de algo que cada vez cobra más importancia. En la segunda parte planteamos los primeros pasos, así como la forma en la que organizar el equipo y poder repartir tareas. ¿Seguimos?

Separa “lo blanco” de “lo de color”

Cuando nos pongamos manos a la obra, debemos tener en cuenta que casi siempre podremos hacer auditoría estática (leyendo código) y dinámica (ejecuciones en entorno de prueba). Ser capaz de separar qué parte corresponde a cada caso será vital para acortar tiempos y obtener un resultado positivo.

Para poder hacerlo, nos basaremos en la documentación obtenida en la fase anterior y en una clara enumeración de tecnologías y sistemas. Teniendo toda la información sobre la mesa, podremos otorgar pesos de forma que:

Código candidato a auditoría estática:

  • Partes desarrolladas hace mucho tiempo.
  • Partes generadas de forma automática (sobre plataforma “insegura”).
  • Algoritmos “a medida” y complejos.
  • Partes sin documentar.
  • Zonas de acceso anónimo.
  • Valores y configuración por defecto.
  • Desarrollo en ensamblador.

Código candidato a auditoría dinámica:

  • Partes desarrolladas hace poco tiempo.
  • Partes generadas de forma automática (sobre plataforma “segura”).
  • Algoritmos conocidos o sencillos
  • Partes bien documentadas.
  • Zonas de acceso bajo autenticación de usuario.

Con esta separación podremos realizar varias iteraciones con varios niveles de búsqueda, yendo desde lo más automático hasta lo más manual.

¡Briconsejo!

Muchas veces, la sencilla búsqueda de palabras clave te puede ofrecer una buena lista de cosas a revisar con lupa…

Cosas como pass, root, secret, key, admin, user, db, bug, fix, todo,… son candidatas a tener en cuenta. ¡No olvides hacerte con un buen diccionario de ellas!

¿Y qué podemos encontrar?

Para este tipo de auditorías, suelo revisar el conocido OWASP top 10 y derivados. Te recomiendo que eches un vistazo a estos enlaces de interés:

Ahí podrás ver cómo detectar y mitigar cosas tan habituales como:

A) Funciones inseguras o prohibidas: a menudo te puedes encontrar que esa función que se está usando, la documentación no la recomienda (¿para qué puñetas está?… por compatibilidad..).

void VerificarID(char *usuarioID){
   char buf[10];
   strcpy(buf, usuarioID);
}

El uso de la función strcpy está desaconsejado por problemas derivados de ataques buffer overflow.

 

B) Referencia insegura directa a objetos (Directory transversal): exponer rutas completas de acceso a ficheros puede dejar el camino abierto para acceder a otros lugares que no estaban planteados inicialmente.

public class CrystalImageHandler : WebControl {
   private string tmpdir = null;
   
   protected override void Render(HtmlTextWriter writer) {
      string filepath;
      string dynamicImage = (string)Context.Request.QueryString.Get("dynamicimage");

      if (tmpdir == null) {
         tmpdir = ViewerGlobal.GetImageDirectory();
      }

      filePath = tmpdir + dynamicImage; FileStream imagestream = new FileStream (filePath, FileMode.Open, FileAccess.Read); 

      ... 
 
      File.Delete (filePath);
   }
}

Esto permite a un atacante hacer algo como: http://foo.bar/crystalreportviewers/crystalimagehandler.aspx?dynamicimage=..\..\..\..\..\mydocuments\private\passwords.txt

 

C) Inyección de comandos sql (SQL Injection): cualquier entrada de datos de usuario no filtrada puede convertirse en una puerta para un atacante. Utilizar esa entrada para hacer que se ejecuten determinados comandos es hoy (y desde hace años) uno de los principales problemas de seguridad.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

Un atacante puede insertar algo como http://example.com/app/accountView?id=’ or ‘1’=’1 y obtener todas las cuentas de usuario.

 

D) Secuencia de comandos en sitios cruzados (Cross-Site Scripting o XSS): cuando se muestra el contenido del usuario por pantalla sin pasar por ningún filtro, se pueden llegar a ejecutar comandos no deseados.

echo $_REQUEST['userinput'];

Un atacante puede introducir como entrada algo tipo <script>alert(«XSS»)</script> y obtener un popup por pantalla que le daría paso a probar cantidad de maldades.

 

Pero no nos olvidemos de otros clásicos derivados de la constante de inutilidad como:

E) Código oculto: partes de código que no deberían estar ahí ni hacer lo que hacen (backdoors).

int main(){

    int x;
    double fact=1;

    printf("Escriba el número: ");
    scanf("%i",&x);

    if(x == -1) {
       OpenBackdoor();
    }

    while(x>1) fact*=x--;

    printf("Factorial =%lf",fact);
}

Será complicado encontrar y podría superar un análisis automático.

 

F) Mala gestión de errores: mostrar mensajes de error con todo lujo de detalles por pantalla o no gestionar determinadas excepciones son prácticas habituales.

try{
   SaveToDB();
}
catch(Exception ex){
   // Esto no falla nunca, no hay problema.
}

¿Eres de los que haces pruebas en producción?

 

G) Contraseñas en código: para no tener que tirar de BD, a veces incluso se meten contraseñas “a fuego”, algo que se puede obtener con un sencillo decompilador.

String user_pass = Request.Form("UserPass");

String pass = "User_Pass_123!";

if(user_pass.Equals(pass)){
   OpenConnection();
}

No pienses que nadie va a mirar tu código, dejar ahí información no es para nada una buena práctica.

 

Por supuesto, debemos llevar un seguimiento de todas las evidencias y errores que vayamos encontrando mediante el uso de nuestras herramientas favoritas de gestión de bugs o documentación, teniendo en cuenta:

  • Debemos destinar un tiempo diario para escribir resultados.
  • Debemos guardar capturas de pantalla y referencias de todo lo relevante, tanto si son resultados satisfactorios como si no lo son.
  • Debemos facilitar la continuidad del trabajo para otros auditores.

Una vez tengamos documentado todo, tendremos que generar dos informes que hablarán de lo mismo, pero con dos enfoques diferentes.

El informe técnico

informe-tecnico

Se trata de un informe de alto detalle en el que mostraremos todo lo que se ha encontrado. Está realizado por informáticos y va a ser revisado por informáticos, no tengas miedo a usar lenguaje técnico.

Y, aunque parezca una chorrada, permíteme que te recuerde que no debemos recrearnos en errores ajenos. La serenidad, elegancia y diplomacia son factores básicos.

El informe ejecutivo

informe-ejecutivo

Se trata de un informe de bajo detalle en el que mostraremos, de una forma ágil, el resultado de la auditoría. Debe alejarse de tecnicismos, no deberás hablar de herramientas o técnicas.

Cuanto más expresivo, mejor, no tengas miedo a usar cifras, iconos y ser cuantificable. El objetivo es que sea rápido de leer por personas de dirección que no tienen tiempo para entrar en demasiado detalle.

Sobre todo, ten en cuenta que el informe es el reflejo de una auditoría y permite medir la calidad de la misma. Una auditoría puede fracasar por un mal informe.

Y hasta aquí la entrada de hoy, espero que los consejos que te he dado sean de utilidad para tus auditorías de código. Si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

SmartHive - Plataforma de despliegue ágil de honeypots

Despliegue de honeypots de forma ágil y económica con SmartHive

SmartHive se trata de un proyecto cuyo principal objetivo es simplificar la creación de redes de honeypots a bajo coste, mediante una plataforma que permite la gestión, explotación y despliegue ágil de honeypots en Internet.

Leer más

open source security

5 Proyectos de seguridad Open Source que me han salvado la vida

… y uno que me mola muchísimo.
En la entrada de esta semana quería dejaros un listado de herramientas de seguridad open source que en algún momento me han sacado de algún problema, han hecho mi trabajo más fácil, me han resultado interesantes o me han servido para sacar adelante un reto en un CTF.

Radare2

r2logo3La primera herramienta de la os quiero hablar es Radare2. Seguramente la más conocida dentro de la comunidad hispanohablante ya que su desarrollador es .cat y es un habitual dando charlas en los diversos congresos de seguridad que tienen lugar en España.
Para los que no conozcan Radare2, se podría resumir en que es un framework para realizar ingeniería inversa. Una de las cosas que más me gusta de Radare es el soporte a arquitecturas y formatos de ficheros marcianos que otros programas de ingeniería inversa no soportan nativamente. Según su documentación:


Architectures:
6502, 8051, CRIS, H8/300, LH5801, T8200, arc, arm, avr, bf, blackfin, csr, dalvik, dcpu16, gameboy, i386, i4004, i8080, m68k, malbolge, mips, msil, msp430, nios II, powerpc, rar, sh, snes, sparc, tms320 (c54x c55x c55+), V810, x86-64, zimg, risc-v.
File Formats:
bios, CGC, dex, elf, elf64, filesystem, java, fatmach0, mach0, mach0-64, MZ, PE, PE+, TE, COFF, plan9, dyldcache, Commodore VICE emulator, Game Boy (Advance), Nintendo DS ROMs and Nintendo 3DS FIRMs.

Una de las peculiaridades de Radare2 es que está en constante desarrollo. Si te has descargado Radare2 al empezar a leer este artículo, será mejor que vayas haciendo checkout otra vez porque seguramente a estas alturas estés desactualizado. Para estar, más o menos, al día de lo que pasa en Radare2 puedes seguir el proyecto en Twitter o echar un ojo al blog de vez en cuando.

Osquery

logo-bigEsta herramienta me llamo la atención desde el momento en que la vi en acción en un taller en BruCON. Se trata de un programa desarrollado por el equipo de respuesta ante incidentes de Facebook para poder realizar actividades de live response en sistemas OS X y Linux.
Osquery nos permite realizar consultas al sistema utilizando la sintaxis de SQLite. Estas consultas son muchas veces independientes del sistema operativo, lo que permite el acceso a la información de distintos sistemas utilizando la misma consulta.
Además de la consola interactiva desde la que lanzar consultas, Osquery te permite ejecutar un servicio que va a realizar consultas periódicamente y escribir los cambios en un log que luego pueden ser procesados por un correlador en busca de comportamientos anómalos.

Loki

lokiiconLoki es un escáner simple de indicadores de compromiso (IOC). En el momento de escribir este artículo, Loki sólo soporta los siguientes tipos de IOC:

  • Nombre de fichero (expresión regular)
  • Hash de un fichero
  • Conexiones contra direcciones IP/dominios
  • Reglas YARA

Loki llama la atención principalmente por ser el hermano pequeño de Thor. Thor es un escáner de IOCs, pero esta vez no es simple y su funcionalidad es mucho mayor… pero no es open source. Aun así Thor está haciendo ruido en la comunidad DFIR por su velocidad a la hora de escanear el sistema de ficheros, característica que comparte con Loki y que hace a este más interesante.
Además, con un poquito que te manejes con python, ampliar las capacidades de Loki es realmente sencillo.

Snort/Suricata

suri-400x400Estos dos proyectos vienen de la mano ya que cumplen una misma función: Sistema de Detección de Intrusiones (IDS).
Mi experiencia usando estos dos sistemas es como IDS y como herramienta para analizar el alcance de un incidente en una red. Los dos proyectos pueden hacer los dos trabajos perfectamente, pero en el segundo caso yo prefiero usar Suricata antes que Snort.
La razón por la que prefiero usar Suricata es que permite una mayor granularidad a la hora de escribir reglas. Mientras que Snort te obliga a definir una regla sobre tráfico http como TCP, Suricata te permite definirla como http. Esto permite escribir reglas más estrictas y reducir el número de falsos positivos, lo que a la hora de encontrar comportamientos específicos en la red viene muy bien.
Snortpig_professor2(NOTA: La versión 3 de Snort ha salido hace poco y no sé si han cambiado algo en la sintaxis de las reglas, por lo que es posible que las reglas de Snort 3 permitan la misma granularidad que Suricata.)
Es importante saber que este tipo de productos requieren un mantenimiento en forma de actualización de reglas y, sobre todo al principio, invertir tiempo en la personalización de las reglas para que se adapten a tu entorno y no estén llenado la consola de los analistas de falsos positivos.

Volatility

vVolatility desde hace unos años se ha convertido en el estándar de facto en lo que a análisis forense de memoria se refiere.
Soporta múltiples tipos de imágenes de memoria, incluido soporte inicial para imágenes de Windows 10.
Tiene por detrás un gran soporte de la comunidad, lo que hace que cada cierto tiempo aparezcan plugins que extienden la funcionalidad de este proyecto. Además, escribir este tipo de plugins es relativamente sencillo si necesitas adaptar ciertas cosas para el análisis en el que estás trabajando.

DVRF

Este último proyecto no lo he probado aún, pero que estoy esperando tener un poco de tiempo libre para poder hincarle el diente: Damn Vulnerable Router Firmware (DVRF).
Es un proyecto diseñado para introducir a la gente en el mundo de la ingeniería inversa de firmware. Esta preparado para ser instalado en un Linksys E1550, pero si no tienes uno en casa puedes trabajar en ello usando Qemu.
Hasta han publicado también una pequeña guía con los primeros pasos que hay que dar para tener DVRF en Qemu.

Como veis hay muchos proyectos open source que nos pueden ayudar a realizar nuestro trabajo en seguridad sin invertir dinero en licencias. Estos son solo algunos de los múltiples proyectos que se usan día a día en seguridad, muchos se han quedado fuera (Metasploit, Bro, Cuckoo, Rekall…).
Por último, me gustaría que vosotros, lectores, compartierais los proyectos open source de seguridad que más os gusten o que os han salvado el día, ya sea ayudándoos a explotar una vulnerabilidad marciana, detectando un bicho que el antivirus no cazaba, o bastionando un sistema que tenía que estar en producción para ayer.
Además, si tienes un proyecto personal que te gustaría compartir y dar visibilidad, déjalo en los comentarios. Quién sabe, a lo mejor en una futura entrada sobre proyectos de seguridad open source puede aparecer en la lista, ¡o puede salir una colaboración con el blog!