domingo, 8 de marzo de 2015

Crónicas: RootedCon 2015, día 3

El último día de la RootedCon 2015 no fue menos interesante que las dos jornadas anteriores. Una vez más, fui al hotel en transporte público, tal y como ya hice los dos días anteriores. 

La primera ponencia que tuvimos fue la que dio Miguel Tarascó, (@Tarlogic y @AcrylicWifi). Su ponencia trataba sobre la problemática de que uno se descargue los códigos fuentes o librerías y no revise si éstos contienen alguna instrucción que nos produzca algún daño o se descargue algún tipo de código sin que nos enteremos. Sobretodo el problema está códigos que tengan muchas líneas y/o dependencias (que a su vez también sean muy extensos). O, los IDEs de desarrollo que a la hora de previsualizar los componentes o, incluso, compilar código, se ejecuten y se lancen cosas que no debieran. Una lista  de elementos que podrían ejecutar líneas embebidas en el código fuente podrían ser gestores de compilación (make, Gralle, MsBuild) e IDEs (Android Studio, Visual Studio). 

La siguiente ponencia, aunque en el tweet que puse yo dije que hablarían "de casinos" (por el título de la ponencia), realmente hablaban de traders de banca. De la mano de Pablo Casais (@pcasais), pudimos ver cómo haciendo un poco de ingeniería inversa y social, se podía terminar consiguiendo crear un contrato (que en teoría sólo lo puede hacer un perfil de usuario determinado) y "ejecutarlo" para que se lleve a efecto (que, una vez más, lo debería de hacer otro usuario distinto). La teoría dice que es un control para evitar que alguien se lleve pasta o se realicen operaciones arriesgadas. Algunas notas que pude tomar es que hay motores que dependiendo del país o, incluso, del proveedor que lo va a usar, permite poner una interfaz gráfica u otra. Tenían granjas de servidores, entre otros de ficheros. También el código fuente de la aplicación o, incluso, acceso a la base de datos (cuyas credenciales pudo sacar, en parte, del código fuente y haciendo ingeniería social). Total: pudo enviar contratos sin autenticar e, incluso, cambiar el destino de la pasta. 

En el descanso tuve la oportunidad de visitar alguna de las salas donde estaban haciendo @X1RedMasSegura. En la sala donde estaban era la de los (muy) jóvenes, pude ver a . Allí sólo estaban los niños de hasta casi 9 años. Tal y como decían, y es cierto, no estaban aquellos para los que realmente era de esperar: los adolescentes, que eran los destinatarios. También vi muy contento a Longinos padre (@LonginosRecuero), como de costumbre. Además, tuvo la oportunidad de dar una charla para los yayos digitales. 

Ya después del descanso, y con unas cuantas conchas Códan en el cuerpo, David Pérez y José Picó, con su empresa Layakk (@layakk) nos hablaron de las herramientas que montaron para un trabajo que tuvieron que hacer para una empresa. Al final, script a script, fueron tirando del hilo: correlacionar los puntos de acceso de la zona con los probes de los dispositivos de la zona (sobretodo de los bares), con unos auriculares y unos pitidos según uno se acerca o se aleja de la zona determinada, unas antenas en "la meleta" de una moto para dirigirlas a la zona deseada (los puntos de acceso deseados)....

Al finalizar esta charla, y antes de pasar a la siguiente, Deloitte CyberSock (@Deloitte / @Deloitte_Spain), de la mano de Pedro (@NN2ed_s4ur0n) sortearon formaciones su academia: una completa y 4 de medio día. 

Hugo Teso (@hteso), una vez más, nos habló sobre temas de aviones. Aunque antes, en previsión de la duración de su exposición, tal y como ha sucedido otros años, la organización nos trajo unas cuantas cajas de pizzas, allí, al escenario. 


Al final, resulta que estaban vacías... Lo importante es informar sobre su exposición ¿O no? En esta ocasión, ésta iba sobre simuladores de vuelo, tanto para aviones "pequeños" como comerciales. Estos simuladores, además de tener temas de vuelo, también simulaban aerolíneas. Nos habló sobre la explotación y post-explotaciones de los sistemas, los cuales podrían correr en prácticamente cualquier arquitectura: ARM, x86, x64. Sobretodo un requisito es que los simuladores sean lo más realistas posibles. Algunos de los ejemplos que puso, además de un mapa con los aviones de los que podríamos disponer como aerolínea, eran manipulación en hexadecimal y debugueando. Algo que como ya sabréis, no es mi fuerte que digamos. Alguna de las herramientas nombradas son bastante conocidas: IDA, Radare2... La última parte fue el proyecto que está montando para que haya más personas que tengan curiosidad puedan ponerse a investigar este tipo de cosas. Y así, "el año que viene, sea otro el que pueda hacer la ponencia sobre aviones" (más o menos parafraseado). 

Eduardo Arriols (@_hykeos) nos habló de cómo se pueden bypasear o saltar las medidas de seguridad física de un edificio. Es decir: la diferencia entre la intrusión física y la lógica. Nos fue poniendo una serie de ejemplos: las puertas con alarma cuando se abren [ponerle un buen imán en el sensor), los sensores con láser o infra-rojos (enchufarle con un puntero láser en el detector), los detectores de alarma de movimiento (si son por por temperatura, ponerse encima una manta térmica de esas que se ponen en los accidentes o del Decathlon), Los antecedentes para llegar a estos ejemplos: hay que tener una estrategia bien definida, Y muchas veces no se tienen en cuenta todos los tipos distintos de seguridad: social, lógica o física. Esa estrategia estará formada por: una definición del objetivo, localización de la información, analizarla, reconocer el lugar, entrar en el entorno, planear qué se va a hacer, ensayar de alguna forma y terminar entrando al lugar. 

Después fue Chema (@chemaalonso) quien dio una charla sobre el proyecto que llevan desde ElevenPaths (@ElevenPaths) llamado path5 ó, tal y como nos adelantó, nombre provisional Tacyt. Nos puso diversos ejemplos de qué fueron descubriendo en algunas aplicaciones móviles maliciosas y sus creadores. Es un proceso en el que se descargan todas las aplicaciones gratuitas (las APKs) y después hacen un gran procesado con ellas. Lo que últimamente se hace llamar datamining

La siguiente charla la dio Raúl Siles (@raulsiles) fundador de Dinosec (@dinosec). Si el año pasado ya nos habló de forzar a actualizaciones de una versión determinada en móviles iPhone, este año le ha tocado a Android (la distribuida por Google, no las cocinadas como Cyanogen o las que ponen los fabricantes y las operadoras). Para ello ha hecho una división de los servicios de los que constan los dispositivos: GPS (Google Play Services) y GSF (Goolge Services Framework). Según se van actualizando éstas, que lo hacen de forma independiente al sistema operativo, se encargará de la actualización del mismo uno de estos dos servicios. Un comando destacable en la consola sería adb logcat con sus distintos parámetros. Total, que poco a poco pudo conseguir forzar la actualización a una versión anterior (la 4,4,3). Aunque le entendí que quiso probar a alguna versión más antigua, parece ser que no fue posible. Eso sí, en gtihub ha puesto unas cuantas herramientas, como por ejemplo, un plug-in para burp.

Antes de la siguiente ponencia, nos comunicaron que tendríamos licencias para algún producto más de Tarlogic. Y en algún momento también nos sortearon 3 jamones que según el tamaño de la caja, debían de ser muy grandecitos. 

Y, la última charla de este año fue la que nos dio Adrián Villa (@AdriVillaB), que estaba relacionada con el DRM de las distintas plataformas de video en streaming y cómo controlan si para una misma cuenta hay varios usuarios "abusando" para ver los contenidos. De las distintas plataformas que probó (Orange, Nubeox, Wuaki.TV, TotalChannel y Netlix), menos la última de todas, las demás pudo engañar al sistema, con más o menos facilidad, para poder visionar el contenido cuando en teoría debería de estar controlada esa casuística. Eso sí, nos informó que tenía las cuentas de pago. La gracia estaba en que, en general, había que conseguir "impersonalizar" al usuario de pago para poder visionar los vídeos. Después, con un ejemplo como una plataforma web, se podrían mostrar a cualquiera sin ningún problema. Recordemos que simplemente era una prueba de concepto y nada más. 

Y ahí ya terminó la RootedCon 2015:


El año que viene, seguro que viene con más contenido tan interesante como este año y los anteriores. ¡¡Allí os espero!! Y... ¿Cuál será el próximo evento en el que nos veamos?




sábado, 7 de marzo de 2015

Crónicas: RootedCon 2015, día 2

Hoy viernes, de nuevo a la RootedCon 2015. Podemos destacar que hoy nos han hecho unas cuantas PoCs más que ayer.

Antes de la primera ponencia, Román nos ha hablado de la asocicación ANSI (Asociación Nacional para la Seguridad de la Información), para intentar hace un poco de lobby y que se hagan leyes coherentes relacionadas con la seguridad informática.

La primera ponencia la ha hecho Alfonso Muñoz (@mindcrypt), en el que nos ha contado su investigación sobre esteganografía aplicada al market de Google y a las aplicaciones publicadas. Además de hacer pruebas de enviar imágenes con esteganografía (.jpg y .png), también se ha descargado una buena muestra de éstas, y las ha analizado para saber si se escondían cosas, como código maligno, texto, etc... Nos ha hablado de diversas técnicas muy conocidas, como el famoso bit menos significativo. De hecho, parece ser que en el caso de los .jpg, aparecen problemas bastante conocidos en este blog, como cuando me cambiaron las imágenes del reto que monté. Nos ha comentado que estadisticamente, las aplicaciones con más permisos... son la que tienen menos probabilidad de ser (o contener) código malicioso. O las que tienen una descripción muy pobre también tienen más papeletas de serlo. De hecho, otra forma de ocultar este tipo de código se encuentra en la carpeta de resources de estas aplicaciones. Incluso se ha encontrado con que hay aplicaciones que se descargan bases de datos... que contenían recetas de hachís escritas en turco.

La siguiente charla la ha dado Carmen Torrano (@ctorranog), que nos ha contado su estudio para la tesis que está haciendo sobre WAFs (Web Application Firewalls). Estas aplicaciones tratan de comprobar que toda la información que recibe una aplicación web es inocua o, en caso contrario, muestra al usuario algún mensaje de error. Los motores de estas aplicaciones pueden trabajar de distintas formas: con métodos estadísticos (o ¿estohastico?), que es el que hay que enseñarle previamente para que sepa qué tiene que filtrar y qué no. Otra posibilidad es trabajar con "machine learning". Este método tiene una fase de pre-carga: que nos lo ha llamado "feature learning" y "feature selection". Para, más adelante, el momento de procesamiento. Al final, lo que propone es hacer una mezcla de ambos métodos, en los que ha obtenido, con los datos con los que ha trabajado, mejores resultados.

Tras el desayuno, hemos tenido a Abel Valero (@sanguinawer) nos ha hablado de cómo, después de perder unos vídeos de WebEx que tenía cacheados en su disco duro, pudo recuperarlos poco a poco, tirando de software de recuperación de datos y, más adelante, ir haciendo un poco de reversing de las cabeceras de inicio y fin de fichero. ¿Cómo lo hizo? A partir de unos ficheros que tenían estructura de .wav y con Radare2, entre otras herramientas. Al final, a partir de un poco de código, consiguió añadir los datos necesarios de cabecera para poder reproducir los ficheros correctamente.

Julián Vilas (@julianvilas), nos ha hablado de las distintas vulnerabilidades que se le encontraron a Struts, tanto la primera versión (que no sabía que se había discontinuado en el 2013) como la versión 2. Entre otros problemas, se ha hablado del CVE-2014-0114. Y de los distintos parches que se le fueron añadiendo a lo largo de los años para parchear cosas que el anterior parche tendría que haber parch... solucionado. Una de las cosas que no ha comentado ha sido la posibilidad de llamar a métodos muy empleados en la reflexión, tales como el getClass y sus submetodos, permitiendo setear datos, como, por ejemplo, URIs erroneas.

Ricardo Rodriguez (@RicardoJRdez) y José Vila (@cgvwzq) nos han hablado de la posibilidad de crearse una pasarela con dos móviles de la forma que uno de ellos lea una tarjeta de crédito NFC, le envíe información a otro móvil, y ese otro móvil, con un software determinado y cerca de una datáfono que lea NFC, realizar el pago con cargo a esa tarjeta. Incluso ponían el ejemplo de poder hacer la lectura y enviar un mensaje a otro móvil de forma remota para que éste pudiera hacer posteriormente la transacción bancaria. Eso sí, si uno se cantea, la tarjeta quedará bloqueada por el banco. Para contarnos su ponencia nos han puesto en antecedentes, con el estándar del NFC (por ejemplo, que va a 13,56 MHz), o que hay fabricantes que sólo cumplen parte de las especificaciones y otra parte la hacen propietaria. También el uso del estándar EMV para el uso de tarjetas bancarias y el hecho de que para realizar este ataque no hace falta ser root.

Justo después de hablarnos de este ataque realizado con Android, ha llegado Sebastián Guerrero (@0xroot) para hablarnos de la forma en la que Apple guarda cierta información de la huella digital (TouchID) y su explotación para el Apple Pay. Según podemos resumir, para Apple soncompletamente seguros e inaccesibles los datos de la huella capturada con el sensor, empleado para desbloquear el teléfono, hacer micropagos, doble factor de algunas aplicaciones. Pero resulta, que si se busca, está la posibilidad de activar el modo debug del lector. Y con este modo puesto a on, se accede a todos los datos de la huella: cuántas veces se ha capturado, la posición.... De tal forma que esos datos se podrían utilizar para bypasear la protección para la que estaban pensados.

Después de los móviles, Alejandro Ramos (@aramosf) nos ha hablado de 6 formas de atacar una empresa y las 6 formas de defenderla ante esos ataques. Además, ha hecho una encuesta que se tenía que rellenar a medida que iba haciendo la ponencia, pero en mi caso, no me ha sido posible rellenarla. Los problemas: con las credenciales, el sofware ataques de red, privilegios, introducir o llevarse datos de la empresa...  Estos son los distintos problemas que uno se puede encontrar en una empresa. ¿Soluciones? Modificar el Ptsfit.dll o usar doble factor, parches y alertas sobre SW, ARP inspection o DHCP snooping o NAP, eliminar el acceso a las consolas a quien no le haga falta, y, por último, inspeccionar el SSL de las navegaciones o evitar ciertos dominios como los que se hayan creado hace menos de 20 días.

La siguiente charla la ha dado José Selvi (@JoseSelvi) nos ha hablado de HSTS (Http Strict Transport Security). De lo que se trata es que los navegadores, ya sea por una lista pre-cargada, o porque el servidor lo indique, tiren de HTTPS durante un tiempo determinado. Si después no se le indica lo contrario, trabajarán en claro. Su idea es, haciendo un ataque Man In The Middle, forzar a que el horario de la máquina tenga una hora que se corresponda con un instante de tiempo en el que ya debería de funcionar en claro. Como hoy en día los sistemas operativos ponen su hora con NTP, sólo hay que forzar a que pongan la hora de nuestro servidor horario. Así podremos realizar el ataque a los datos que transmita en la navegación. Hay que tener en cuenta los distintos comportamientos según el sistema operativo. Por ejemplo, si Windows detecta más de 15 días (¿o son horas?), rechaza el cambio. Nos ha hablado de las distintas conversaciones con Google y el comportamiento del Chrome.

La última charla ha sido la de Eduardo Cruz (@edcrossed), el cual nos ha hablado de cómo ha podido hacer ingeniería inversa al chip de una consola arcade. Para ello ha necesitado, entre otras cosas, una serie de ácidos muy nocivos y mortales para poder "agujerear" la cerámica que recubre los transistores que forman el chip de la consola, además de necesitar un microscopio magnético (o profesional). Nos ha enseñado cómo con un emulador, y a base de los que ha ido descifrando de los distintos transistores (según la transparencia, si me acuerdo bien, NPN). Porque, el problema estaba en que esas máquinas tenían una cucaracha que era la que se encargaba de dar la clave para que se pudiera arrancar la máquina. Y al terminarse la pila, esa clave se perdía, quedando la tragaperras inutilizada. Gracias a esta ardua labor, durante más de 6 meses, y con un "descifrador" que se ha montado con una placa Arduino, ha podido conseguir su objetivo.

Y esto ha sido todo lo que se ha contado hoy viernes.  Mañana sábado, más.

jueves, 5 de marzo de 2015

Crónicas: RootedCon 2015, día 1

Hoy ha sido el primer día de la RootedCon 2015.

Después de decidir ir en transporte público, la mejor opción ha sido tirar para la estación de tren de San Fernando desde Atocha. Una vez en San Fernando, iba a buscar un taxi cuando he visto un autobús. Después de preguntar, me han comunicado que con el bus 281 llegaría al hotel Auditorium, donde se celebra el evento por segundo año consecutivo. Ha sido subirme al autobús, y en unos 5 o 7 minutos estaba en el hotel. Ha sido casi visto y no visto.

Lo bueno de estar en este hotel es que el aforo de la sala es muchísimo mayor, por lo que habrá mucha menos gente de la que quiere asistir que se quede en tierra sin posibilidad de conseguir una plaza. Lo malo: que está un poco a desmano de todo. Hay una autopista (o autovía, lo mismo da) en medio, y no es que se tengan muchas posibilidades o facilidades para la comida. A ver, nos han conseguido unos tickets para poder comer allí mismo en el hotel (****) por 20€, si no recuerdo mal, en bufet. O la posibilidad de llamar a comida a domicilio, que te la llevan casi, casi hasta adentro del hotel (el año pasado, unos cuantos lo hicimos). Mi posibilidad ha sido llevar unos bocadillos y me los he comido mientras que los compañeros pedían el suyo en el sitio del año pasado.

A lo largo del día te vas encontrando con todos los compañeros de los demás años. Que eso está muy bien.

¿Qué hemos podido ver en este primer día?

Como de costumbre, lo primero de todo es la keynote. Además de darnos la mala noticia de que Aladdin había fallecido, Román (@patowc) nos ha detallado, en la medida de lo posible, en qué se destina la cuantía de las entradas. Parece ser que hay intentos de conseguir las entradas al precio reducido sin realmente tener "derecho" o sentido para ello. Ejemplo: Pedir entrada de estudiante y después emitir factura. ¿Estudiante o profesional? Además, nos han dado las estadísticas de las visualizaciones de los vídeos, tanto en Vimeo como en Youtube. Y la importancia de que, con la traducción simultanea, ya está el doblaje hecho, por lo que llega antes a otras partes del mundo y no es tan sencillo que se fusilen los trabajos hechos en la península.

Con la keynote terminada, empezó su charla David Barroso (@lostinsecurity). Su charla ha tratado sobre los distintos sistemas de arranque de los ordenadores (en general): la BIOS y la UEFI. Ha dado un repaso a la historia de la BIOS. Por ejemplo, cómo se pudieron infectar las primeras BIOS y para resolver el problema, se añadió una de reserva, para sobreescribir la principal si se veía corrupta. Y cómo se pudo saltar esa protección (dual BIOS), por lo que se saltó a lo que llamaron quad BIOS (además del anterior sistema, tirar de un CD con la flash y un software para sobreescribirla si fuera necesario). Como ejemplo de "ataque" a la BIOS nos ha puesto un fragmento de una serie en la que muestra cómo la empresa Phoenix hizo ingeniería inversa para sacar el código de la BIOS de IBM. Nos ha dado una visión que tiene con respecto a los rings del sistema. Como sabréis, se suele hablar de anillos para las zonas del sistema donde se puede acceder. El ring 0 (cero) es kernel. Pues ha pasado a hablarnos en números negativos (-1 [hypervisor], -1,5 [los botkits entrarían aquí], -2 [modo SMM de los microprocesadores], -2,5 [ls infección de estas PROMS va aquí] y -3). Ha pasado por la historia de las distintas infecciones de estos chips, desde el 94, pasando por el 2007, incluso llegando a finales del año pasado.

Después de un buen descanso, y con unas cuantas conchas Codan en el cuerpo, el fiscal Jorge Bermúdez (@ender_halon) nos ha dado otra ponencia estupenda sobre leyes y hácking ético. Ha recalcado que ha hablado de temas sobre la ley de enjuiciamiento criminal, no la penal. En estos temas siempre insisten en la desactualización de la ley: 1882. Y todos los parches que se le han ido haciendo. Sobretodo en la posibilidad de abrir las cartas por parte de un juez y en presencia de su secretario, como primera versión. O su primer service pack, autorizar a escuchar las conversaciones telefónicas (¿o eran telegráficas?), como un primer SP. El siguiente punto es el anteproyecto de ley, de lo que ha tratado el resto de su ponencia. Sobretodo ha recalcado distintos ejemplos y el problema de que las leyes anteriores siempre hablaban de temas físicos. Como ahora en las comunicaciones también influyen los ordenadores, software, etc, se ha incluido en el anteproyecto la posibilidad de interceptar, no sólo lo que involucra el tema físico, sino también lo lógico y virtual. Este tema permitiría pinchar, por ejemplo, la telefonía VoIP. O cómo legislar el uso de bichos por parte de la policía. O cómo gestionar la "identidad fingida" por parte de un agente en internet. Y muchos más supuestos, pero estos son bastante descriptivos.

El siguiente ponente, que era Christian López, no ha podido hacer su ponencia.

Andrej Dereszowski, (@deresz666) nos ha hablado, en un perfecto inglés, del que he podido entender bastante a oído descubierto (sin pinganillo para la traducción simultánea), nos ha hablado de un rootkit llamado Turla. La problemática al principio (y muy típica), de que las casas antivirus lo llamen de una manera o de otra. Nos ha hablado de distintos nombres que ha recibido a lo largo del tiempo (AgentBTZ en 2006, Pfinet en 2009 y Snake en 2011). Pero también, me ha parecido entenderle que para él, son bichos distintos, ya que funcionan de manera diferente, y nos ha enseñado esas diferencias. De hecho, parece ser que había un sistema de repositorios en los que se pudieron encontrar nombre de desarrolladores del bichito. Los ataques empleados solían tener 4 fases, de la 0 a la 3. Mmmh... Como curiosidad: un amigo suyo fue infectado este APT. Le daba un pantallazo azul. Cuando fue a hablar con la casa de antivirus, le dieron un parche... Y así, este rootkit se hacía estable en sus sistema.

Yaiza Rubio (@) y Féliz Brezo (@febrezo) nos han habado de distintos tipos de carteras para las criptomonedas y sus distintos tipos de ataque. Los tipos de carteras: Genéricas/Random, validity, mentales y multifirma (varias personas firman para realizar la transferencia). O el almacenamiento: local, mental y en la nube. También han pasado por los distintos criterios para dar prioridad a la transferencia: la cantidad elegida (a más cantidad, más prioridad), el tiempo que lleva en la cartera (cuanto menos tiempo, más prioritario), Han propuesto tres retos, de los que parece, según he podido leer, que ya se ha resuelto como mínimo, uno de ellos.




Y después hemos tenido la mesa redonda, que como de costumbre, ha tenido mucha chicha. De lo más importante que se ha hablado, además de preguntar a los que la componían, si eran hackers (cada uno ha dado su opinión), el tema candente ha sido si hace falta tener un carnet o autorización especial del gobierno para serlo. El problema viene porque el lobby de las empresas de seguridad privada quieren que se tenga que pedir un permiso especial por parte de la empresa que quiera realizar las auditorías de seguridad, y que cueste una pasta. Además, no se podrían hacer siendo autónomo. Y haría falta que hubiese en la empresa un director de seguridad con nosecuantas certificaciones y cada empleado tiene que tener el carnet... Son varias cosas más, pero, así, en síntesis, es eso.

Así, lo más sintetizado posible, es lo que nos han contado hoy. Mañana viernes, más, y seguro que, como mínimo, igual si no mucho mejor.