seguro-interesa

¡Seguro que te interesa! – 19

En esta sección os dejamos las noticias que nos han llamado la atención y que consideramos te pueden ser de ayuda. Es por eso que es… ¡seguro que te interesan!

[05/02/2016] Mikko Hypponen publica el museo del malware en archive.org. Si llevas un tiempo en esto, date un paseo para recordar cómo eran los programas que te daban tantos dolores de cabeza.

[08/02/2016] Desde Dr. Web detectan una familia de troyanos (Loki) que afecta a dispositivos Android y permite la inyección de su código en aplicaciones legítimas para conseguir permisos de administrador.

[09/02/2016] Microsoft publica 13 boletines de seguridad resolviendo un total de 41 vulnerabilidades. Cabe destacar una vulnerabilidad crítica (CVE-2016-0038) que afecta a todas las versiones de Windows y podría permitir la ejecución remota de código si un usuario abriera un archivo de Journal específicamente creado.

[09/02/2016] Los amigos de HackPlayers nos hablan sobre una utilidad muy interesante para saber qué hace un comando antes de ejecutarlo.

[10/02/2016] Pwn2Own vuelve. Esta vez con nuevas reglas y con la inclusión de VMWare en la competición.

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.

de-charleta

De Charleta: «Disrupting Nation State Hackers» (Rob Joyce)

En esta charla el jefazo del grupo TAO (Tailored Access Operations) nos enseña como defender nuestras redes de grupos como el suyo. Son cosas que llevan diciendo desde hace bastante tiempo, pero que las diga la cabeza del grupo de la NSA que se dedica a realizar este tipo de ataques a ese nivel le da más valor todavía… y a lo mejor hacer que los jefes se paren a escuchar por una vez.

Rob Joyce es el lider del grupo TAO de la NSA. Antes de eso ha trabajado en distintos puesto de liderazgo dentro de la NSA por más de 25 años

USENIX Enigma 2016

Inglés.

seguro-interesa

¡Seguro que te interesa! – 18

En esta sección os dejamos las noticias que nos han llamado la atención y que consideramos te pueden ser de ayuda. Es por eso que es… ¡seguro que te interesan!

[01/02/2016] Una vez confirmada la entrada, os avanzamos que SecurityInside estará en RootedCON 2016, así que os lo iremos contando todo.

[01/02/2016] La universidad de Stony Brook publica un estudio sobre el riesgo al que están expuestos los usuarios que hacen uso de los servicios gratuitos de streaming como Rojadirecta.

[01/02/2016] Errores de configuración en servidores Apache (que incluyen el módulo opcional mod_status) pueden desvelar la localización de un servidor en la Deep Web.

[02/02/2016] Interesante entrada sobre envío de mails desde WP con plantilla Jupiter, de los amigos de HackPlayers.

[03/02/2016] El equipo de seguridad de Google sigue mejorando la Navegación segura (Safe Browsing) para proteger a los usuarios de ataques de ingeniería social llevados a cabo mediante anuncios.

¡Feliz fin de semana!

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