- Empiezan a aparecer las primeras grabaciones de las charlas de la 30c3 que se está celebrando en Hamburgo. Han prometido editarlas posteriormente, pero de momento, nos sirve para tener algo con lo que entretenernos.
- Matjaz Skorjanc (más conocido como Iserdo), el programador del software de administración remota utilizado para montar la red Mariposa, encarcelado finalmente en Eslovenia tras su detención en 2010.
- En TheHackerBlog comentan que las shells R57.GEN.TR contienen una puerta trasera para comprometer a todos aquellos que las usen.
- En N3XAsec nos hablan de CloudFlare Unmask, prueba de concepto de una herramienta online que permitiría obtener la dirección real tras servicios que se encuentren protegidos mediante CloudFlare.
- Tras la polémica con el affair RSA y NSA y la supuesta colaboración mútua, algunos de los ponentes confirmados para la próxima RSA Conference han decidido rechazar su invitación. Entre ellos, Mikko Hypponen de F-Secure incluso escribe una carta abierta a la atención de los CEO de EMC y RSA.
- Joernchen de Phenoelit publica un advisory de seguridad en el que muestra multitud de vulnerabilidades graves en Fat Free CRM, el CRM programado en Ruby-On-Rails.
- Más información acerca del compromiso de las tiendas Target, se confirma que los PINs de los clientes fueron robados. Los responsables de Target comentan que los PINs estaban cifrados con TripleDES...
- No solo se atacan a las monederos virtuales de Bitcoins, esta vez han hackeado monederos de Dogecoins
29 diciembre 2013
28 diciembre 2013
Hoy vamos a destripar uno de los dispositivos tecnológicos más antiguos, presente en multitud de iglesias: los sistemas de velas eléctricas. Pueden parecer dispositivos tontos, pero todo lo contrario.
Como casi todo hoy en día, tienen su corazoncito, su puerto ethernet, puerto USB y como no, ¡su propio firmware!
Foto cortesía de hoy.com.ec Las velas eléctricas son la nueva moda en las iglesias de Cuenca |
Debido a que todavía estamos trabajando junto con el proveedor para el parcheo de las vulnerabilidades, en el presente post únicamente podremos mostrar una breve introducción del sistema y algunas de las conclusiones fruto del trabajo realizado durante meses y meses. Veremos como, By Default, la seguridad de estos sistemas deja mucho que desear.
Funcionamiento interno (hardware)
El mecanismo del portavelas es muy sencillo. Os mostramos un pequeño diagrama a continuación (vista aérea):
Diagrama de funcionamiento del portavelas eléctrico |
El mueble consta de dos partes: el circuito de LEDs (1) y la placa base (2). Esta última es la que contiene la lógica de, una vez introducida la moneda por la ranura, determinar cual de las luces pertenecientes a todo el circuito debe encenderse. El modo por defecto es aleatorio y puede configurarse, junto a otros parámetros, a través de una interfaz web.
Analizando el firmware
Tras determinar el fabricante del dispositivo (el cual no podemos desvelar de momento), nos dirigimos a su página web para descargar el último firmware disponible.
Una vez descargado, hacemos ingeniería inversa sobre el fichero y os podemos adelantar las conclusiones más llamativas tras el análisis:
- El sistema operativo corresponde con creoendiOS, personalizada por el fabricante cuya base corresponde con el sistema OpenWRT.
- La contraseña por defecto de root es "aguabendita".
- La contraseña por defecto del usuario admin para el panel web de administración es "innominepatris", todo junto.
- Posee los siguientes puertos abiertos:
- 22/TCP - SSH para administración remota por consola
- 80/TCP - Administración web
- 443/TCP - Administración web segura
- 666/TCP - Puerto de administración a modo de backdoor, que permite acceder a la administración sin necesidad de introducir usuario o contraseña.
Dirigiéndonos al funcionamiento principal del sistema (encender velas con monedas), se detectó un demonio corriendo sobre el sistema operativo, llamado "monitMoneda", sobre el cual recaía la funcionalidad de comprobación del tipo de moneda, para posteriormente encender más o menos velas según la ofrenda:
- 5 céntimos = 1 vela
- 50 céntimos = 10 velas
- 1 euro = 15 velas
Curiosamente, existía un caso dentro del bloque selector, en el que había otra casuística: monedas de 500 pesetas. Si bien aparentemente el dispositivo no aceptaba moneda diferente a euros, el fabricante mantuvo la moneda de 500 pesetas para que una vez introducida, se activase un modo de depuración para el sistema.
En el próximo post, enseñaremos cómo fue posible, gracias al modo de depuración y el acceso completo al menú de administración del sistema, conseguir algo como lo siguiente:
Escribiendo mensajes personalizados con velas eléctricas (sin ofrenda) |
Iremos actualizando el siguiente enlace a modo de wiki con más información acerca de la investigación, y permaneced atentos al blog, ¡sobretodo para la segunda parte!
27 diciembre 2013
Cuando me contactó Óscar Banchiero y me estuvo contando sobre el proyecto que tenía en mente, relacionado con aunar un montón de herramientas para Windows, relacionadas con seguridad, catalogadas y preparadas en un sólo disco, poniéndolas a disposición del público gratuitamente, dije: "¡Menudo trabajo que se va a pegar este tipo!”
Hace relativamente poco, me indicó que la página web del proyecto ya estaba lista, que se llamaría Pengowin y que me enviaba el acceso previo para poder darle un vistazo al surtido de herramientas que había.
La fecha de lanzamiento de la misma es hoy 27 de Diciembre de 2.013, por lo que podéis acceder a la web http://pengowin.com.ar y descargar de forma directa el repositorio completo.
La clasificación comprende herramientas de análisis de puertos, footprinting, scanners de vulnerabilidades, esteganografía, metadatos, wireless, forense, etc,...
La verdad es que el trabajo que se ha pegado Óscar con el proyecto, me consta que es brutal. Tanto a la hora de decidir qué herramientas descargar y poner a disposición en el repositorio para su uso, como el bajarlas una a una y ofrecer esta primera versión actualizada.
La fecha de lanzamiento de la misma es hoy 27 de Diciembre de 2.013, por lo que podéis acceder a la web http://pengowin.com.ar y descargar de forma directa el repositorio completo.
La clasificación comprende herramientas de análisis de puertos, footprinting, scanners de vulnerabilidades, esteganografía, metadatos, wireless, forense, etc,...
La verdad es que el trabajo que se ha pegado Óscar con el proyecto, me consta que es brutal. Tanto a la hora de decidir qué herramientas descargar y poner a disposición en el repositorio para su uso, como el bajarlas una a una y ofrecer esta primera versión actualizada.
Le sugerí, vía DMs por twitter, que habría estado genial que al igual que se hace con Linux, montase una distribución Windows que fuese autoarrancable, del tipo Windows Bart PE, con las herramientas instaladas, generando versiones diferentes cada cierto tiempo, según surjan las necesidades de actualización.
Espero que, algún día, Pengowin exista también en modo distribución Windows Live, aunque sea únicamente con alguna de las herramientas instaladas.
Espero que, algún día, Pengowin exista también en modo distribución Windows Live, aunque sea únicamente con alguna de las herramientas instaladas.
Os dejo con el video de presentación de Pengowin y os invito a descargar este primer repositorio y que dejéis vuestro feedback a Óscar, así como las sugerencias de herramientas que creáis útiles para incluir en el repositorio en futuras versiones.
26 diciembre 2013
En el post anterior se trataron los temas más generales que se vieron en la charla de 7ENISE sobre la actualidad del malware en Android. En este segundo post pretendo realizar un resumen sobre las vulnerabilidades más importantes
que aparecieron en Android desde julio de 2013 (varias de ellas se
presentaron en la Blackhat/DEFCON).
1. El caso de la vulnerabilidad en SecureRandom
A principios del mes de agosto saltó una noticia relacionada con una supuesta vulnerabilidad en las aplicaciones de gestión de carteras bitcoin de Android. No fue hasta el 11 de agosto cuando se publicó un post al respecto en la página bitcoin.org en el cual se alertaba de un problema en la generación de números aleatorios en Android que provocaba que cualquier monedero generado desde alguna aplicación de este sistema operativo era susceptible a ser robada. Tres días más tarde, se publicó un post en el blog de desarrolladores de Android en el que se dieron detalles técnicos de la vulnerabilidad y el código que tenían que incorporar los desarrolladores a sus aplicaciones para solucionar el problema.
Podéis acceder al código que soluciona esta vulnerabilidad en el propio post "oficial". Simplemente tendréis que añadir a vuestra aplicación la clase "PRNGFixes" y llamar a "PRNGFixes.apply()" al iniciarla.
2. Modificación del orden de uso de las suites criptográficas
Relacionado con el caso anterior (aunque no diese mucho que hablar) se hizo público un estudio en el que se mostraba como, desde el año 2010, en Android se había modificado el orden de preferencia de las suites criptográficas para SSL y se había pasado de AES256-SHA a RC4-MD5 (claramente vulnerable).
Si nos fijamos en la evolución del orden de preferencia entre las diferentes versiones de Android (ver Figura 1) podemos observar cómo éste era correcto hasta la versión 2.2 y cómo en versiones posteriores se estableció un nuevo orden manualmente en el propio código de Android, generando uno que prioriza suites criptográficas inseguras (ver Figura 2).
Figura 1 - Orden de preferencia de suites criptográficas |
Figura 2 - Cambio del orden de prioridad de las suites criptográficas |
Buscando una posible explicación a tan extraña situación se llegó a la conclusión (no-verificada) de que es posible que se tomase esta decisión por temas de compatibilidad (es un order definido por Sun en 2002). Tomad vosotros vuestras propias conclusiones...
3. Vulnerabilidad Master-Key
Durante la conferencia BlackHat USA 2013 la empresa Bluebox hizo pública una vulnerabilidad presente en las librerías de manejo de ficheros comprimidos en Android que permitía realizar la instalación de APKs modificados sin que la comprobación de la firma de éstos fallara[1].
Como todos sabemos, cualquier aplicación de Android ha de estar (auto)firmada por su desarrollador. Este procedimiento consiste en calcular el hash(SHA1) de cada uno de los ficheros del APK, y añadir éste junto con el nombre del fichero, en el archivo MANIFEST.MF que, posteriomente, será firmado con la clave del desarrollador (ver Figura 3). En el momento en el que se modifica un fichero de un APK, al intentar instalarlo en un dispositivo Android se comprobará el hash de cada uno de los ficheros que contiene con el registrado en el fichero MANIFEST.MF y en el caso del fichero modificado éste no será el mismo por lo que la instalación fallará (en el caso de que se añada uno nuevo ocurrirá lo mismo).
Figura 3 - Fichero MANIFEST.MF |
Ahora bien, ¿qué ocurre si introducimos entradas duplicadas? Ahí se encontraba la vulnerabilidad... Debido al uso de varias librerías diferentes de manejo de ficheros comprimidos en el proceso de instalación, no se controlaban correctamente los ficheros con entradas duplicadas y, por tanto, al comprobar el hash el proceso no fallaba (existía el fichero legítimo) pero finalmente se instalaba la aplicación con los ficheros modificados (ver Figura 4). Para evitar esta situación, actualmente se comprueba si existe alguna entrada duplicada y, en tal caso, se anula el proceso de instalación (ver Figura 5).
Figura 4 - Fichero APK con entradas duplicadas |
Figura 5 - Parche que comprueba si existen entradas duplicadas |
Posteriormente aparecieron nuevas técnicas[2][3] adicionales a la que mostró Bluebox que permitían seguir modificando aplicaciones sin que la comprobación de la firma de los APKs se viera afectada.
Para comprobar si una aplicación hace uso de alguna de las técnicas que se han publicado, puedes utilizar la aplicación Bluebox Security Scanner u otras como el portal de Zscaler. Con respecto a parchear nuestro sistema (4.3-), se puede hacer uso de aplicaciones como ReKey (pero... ¡requieren root!).
4. Otras vulnerabilidades
A parte de las vulnerabilidades comentadas en los puntos anteriores, también mencioné otras igualmente interesantes, como:
Vulnerabilidad en WebLogin[4]
En la conferencia DEFCON 21 Craig Young de Tripwire mostró una vulnerabilidad existente en el "sistema de autenticación en un solo clic" de Android. Este servicio nos permite generar tokens para distintos servicios de Google sin necesidad de reautenticarnos constantemente. La vulnerabilidad consistía en un error del servicio WebLogin (ya os hablé de él en el post sobre XMPPloit) que permitía otorgar a un token autorización para acceder a todos los servicios de Google (y no únicamente al servicio para el que el usuario lo había autorizado). Por lo tanto, una aplicación podía solicitar un permiso no-crítico como el de acceso al calendario de la cuenta, y apartir del mismo, obtener acceso a los correos de Gmail, archivos en Drive e incluso a Google Play -con lo que ello conlleva...-.
Vulnerabilidades en Firefox[5]
En septiembre Sebastián Guerrero (viaForensics) hizo pública una vulnerabilidad en Firefox para Android que permitía acceder a los ficheros internos de la aplicación (p.e cookies) y a los de la SDCard (lectura permitida para cualquier aplicación). Si bien no permitía una explotación remota (limitándose mucho su usabilidad), se podría haber combinado con otra vulnerabilidad que se publicó en esas fechas que permitía la ejecución automática del instalador de aplicaciones en Firefox (nuevamente, requiere ingeniería social, no es un ataque automático). Su explotación seguiría siendo bastante limitada pero con mayor proyección.
Vulnerabilidad en Cerberus Anti-Theft[6]
En este caso se trata de una vulnerabilidad que afectaba a la conocida aplicación de gestión remota y antirobo de dispositivos Android. Resulta que era posible comprobar si un determinado IMEI estaba registrado en el sistema y, en caso afirmativo, el servicio de Cerberus devolvía el usuario asociado a dicho IMEI y el hash(SHA1) de la contraseña. Si bien hasta aquí ya resulta una situación anómala y delicada (permite realizar un "crackeo" offline de la contraseña), se descubrió que el proceso de recuperación de contraseñas únicamente requería el IMEI del dipositivo y la nueva contraseña. Por lo tanto, uniendo ambos casos nos encontramos con que era posible resetear la contraseña de cualquier dispositivo que utilizara Cerberus y obtener el usuario asociado para poder controlar remotamente el dispositivo. En el caso de que os queráis montar vuestro propio MDM y no depender de servicios de terceros, podéis probar ownMdm (XDADevelopers)
Vulnerabilidad en WebView[7]
En el 6ENISE y en la NocONName 2012 estuve presentando una técnica para inyectar dinámicamente código malicioso en aplicaciones Android que a priori parecen inofensivas[8]. Durante estas ponencias comenté otra técnica que se había presentado ese mismo año en BlackHat USA que consistía en modificar el código JS para modificar el comportamiento de la aplicación y ejecutar código nativo a través de JSBridge. Si bien siempre se comentaba que la aplicación debía de contener el código nativo al que llamase el JS (por ejemplo, el método concreto de envío de SMS), posteriormente se demostró que, dado que por defecto los métodos eran exportables (permitían su invocación a través de JS), no era necesario contener los métodos en la aplicación sino que se podía realizar una llamada directamente a las APIs del sistema. Por lo tanto, ahora únicamente era necesario que la aplicación maliciosa (o "victima" si se estaba explotando en cualquier aplicación que incorporara el componente WebView) tuviera el permiso SMS para que pudiera hacer uso del mismo a través de JS, ver Figura 6). A partir de la versión 4.2 de Android es el propio desarrollador el que tiene que marcar con "@JavascriptInterface" qué métodos son accesibles a través de JS.
Figura 6 - Ejemplo de acceso a APIs del sistema a través de JS |
En el próximo y último post terminaremos de analizar las vulnerabilidades que faltan, veremos por encima algunas amenazas pendientes y terminaremos con la demo que mostré.
Información de interés relacionada con el post:
[1] Android Master-Key presentation - Bluebox
[2] Chinese Hackers discovered second Android master key vulnerability - The Hacker News
[3] Yet Another Android Master Key Bug - Jay Freeman
[4] Android WebLogin: Google's Skeleton Key - Craig Young
[5] How I met Firefox: A tale about chained vulnerabilities - Sebastían Guerrero (viaForensics)
[6] Cerberus anti-theft – an exploit allowing you to access any device - Paul's blog
[7] WebView addJavascriptInterface Remote Code Execution - MWR Labs
[8] Google Play, ocultación de malware y ExynosAbuse > Pwned! - Luis Delgado
[4] Android WebLogin: Google's Skeleton Key - Craig Young
[5] How I met Firefox: A tale about chained vulnerabilities - Sebastían Guerrero (viaForensics)
[6] Cerberus anti-theft – an exploit allowing you to access any device - Paul's blog
[7] WebView addJavascriptInterface Remote Code Execution - MWR Labs
[8] Google Play, ocultación de malware y ExynosAbuse > Pwned! - Luis Delgado
[*] Quick & dirty PoC for Android bug 8219321 discovered by BlueboxSec - Pau Oliva (@pof)
[*] Zip File Arbitrage (PoC for 8219321, 9695860, and 9950697)v - Ryan Welton
[*] Hey, you know Android apps can 'access ALL' of your Google account? - The Register
[*] Hey, you know Android apps can 'access ALL' of your Google account? - The Register
----------------------
Artículo cortesía de Luis Delgado.
25 diciembre 2013
Allá por 2001 irrumpía en el mundo de los videojuegos una beta de un juego llamado Uplink desarrollado por una pequeña empresa británica llamada Introversion, formada por tres personas (ahora con más colaboradores). Se trataba de un videojuego del género de puzzles cuya trama consistía en realizar intrusiones en servidores de grandes empresas, utilizando diversas herramientas.
Dos de los miembros de Introversion preparando envíos por correo de las copias del videojuego (foto por PCGamer) |
Todo esto, obviamente, virtualmente y sobre sistemas no reales, todo eran simulaciones (direccions IPs de mentira y contra el estándar...aunque algún nombre de corporación si que os sonará...). El juego ha sido analizado por diferentes medios tanto de la prensa en papel como digital, podréis echar un vistazo a las reviews en este enlace.
Seleccionando una localización (gateway) para el comienzo de nuestras acciones |
Comenzamos con el nivel "novato" y poco hardware y herramientas de seguridad con los que poder mejorar nuestras intrusiones. La empresa Uplink Corporation nos irá encargando una serie de misiones en forma de puzzles: borrar ficheros concretos en servidores ajenos, modificar las notas y calificaciones de una persona, introducirse en sistemas bancarios para realizar transferencias de dinero, robar ficheros para posteriormente enviarlos, vulnerar paneles de autenticación, falsificar documentación dentro de repositorios de ficheros ajenos, y un largo etc. A medida que vayamos ganando misiones y ascendiendo en rango, se nos proporcionarán más dispositivos que nos facilitarán los hacks (más CPU, velocidad para procesos de fuerza bruta...) o retrasarán la detección de nuestras acciones por otros (gracias a bouncers o proxies que podremos utilizar para conectarnos a los sistemas objetivo). Y como no, una banda sonora que nos acompañará en nuestras andanzas.
El administrador del sistema nos ha detectado... |
De lo más destacado es que, con el paso de los años, se ha formado una gran comunidad alrededor en la que los desarrolladores han compartido diferentes mods y temas, que permitirán ampliar el juego con más experiencias lejos de la estándar.
Rompiendo el cifrado para el acceso a la base de datos de criminales |
No sirve para aprender técnicas de hacking, pero si para pasar un rato divertido. El juego, además de las plataformas típicas (Windows, Linux y Mac OS X), cuenta con versión para iOS (iPad) y Android (Google Play Store), que nos permitirá disfrutar de este videojuego en cualquier lugar.
Si te bajas la demo, lo adquieres, o tuviste la oportunidad de disfrutar del juego en estos últimos años, ¡cuéntanos tu experiencia en los comentarios!
23 diciembre 2013
La empresa 11Paths ha presentado Latch, una servicio que hace las funciones de lo que han denominado pestillo digital, por el paralelismo al proteger al usuario incluso aunque le hayan robado sus llaves.
El sistema es brillantemente sencillo, se basa en minimizar el tiempo de exposición para lo que permite habilitar y deshabilitar el acceso a una cuenta, sea del tipo que sea, mediante una aplicación móvil.
Imaginamos que yo soy usuario de una página web que requiere usuario y contraseña. Si alguien obtiene esos datos podrá conectar sin problemas haciéndose pasar por mi. Me robará mi información. Latch es un interruptor que deja inactiva la cuenta cuando yo no la uso, además me avisará con una notificación en mi móvil si alguien trata de identificarse con mis credenciales y el acceso esta bloqueado.
Funciona de tal forma que a los sistemas en la nube de Latch nunca le llegarán datos del usuario, ni el nombre de usuario, ni la contraseña. Nada. Tan solo ordenes de activar y desactivar una aplicación.
Si eres un usuario es tan sencillo como descargar la aplicación móvil para iPhone, Android o Windows Phone y registrarte con un usuario y contraseña de Latch. Las webs o servicios que añadan soporte te pedirán que introduzcas un código que se genera desde el móvil para emparejarlos. Una vez hecho, en el móvil se mostrará un interruptor para abrir o cerrar el acceso.
En el caso de que quieras integrarlo en tu pagína web es tan sencillo como llevar a cabo un par de peticiones REST a su API, que está perfectamente documentada en la web desarrolladores de Latch. También hay SDKs para los lenguajes más populares como python, php, java, .NET, ruby o C. Si quieres usarlo en algún blog es aun más fácil, ya que tienen plugins para los gestores de contenidos más conocidos, como Joomla, Wordpress, Drupal o incluso tiendas online como Prestashop. Tres clicks y está funcionando.
Para probarlo a fondo lo he integrado en el servicio GLFTPD, creando un par de scripts en bash. Los pasos han sido sencillos.
Lo primero fue darme de alta como desarrollador y crear un ApplicationID y Secretkey para mi aplicación. Estos datos son necesarios para hacer llamadas a la API, que tan solo permite tres funciones: emparejar/desemparejar dispositivos y comprobar el estado de un usuario.
Añadir una nueva aplicación. |
Para activar el servicio los usuarios deben emparejar sus móviles y mi FTP, para luego poder comprobar si está habilitado o deshabilitado el acceso. Así que para registrarlos cree un script que pide el código que genera el móvil. Con este código del móvil, junto al ApplicationID y el Secret genero una petición HTTP contra el servicio de Latch que devuelve un hash de usuario denominado AccountID y que guardaré en un nuevo fichero con una relación de usuario:hashAccountID
El script de registrar se llamará mediante un comando FTP del tipo "SITE", que más tarde configuraré en el GLFTPD.
El funcionamiento del registro funcionaría tal y como muestra las siguientes imagenes:
Fase de registro en Latch 1. |
Fase de registro en Latch completada. |
El siguiente paso es comprobar mediante otra petición HTTP si el usuario está habilitado o no justo después de que introduzca la contraseña. Para ello GLFTPD ejecutará un script (status.sh) en el que verificar el AccountID justo después de recibir el comando FTP "PASS". Si el usuario no se ha dado de alta (o no es usuario de Latch) se le deja pasar. Si es usuario y está a "off", se le bloquea el acceso mediante un "sleep" hasta que de timeout. Si está en "on" pues se le deja pasar.
Cuando un usuario tiene desactivado el servicio y trata de conectar, en el móvil se muestra la alerta y se prohíbe el acceso:
Aplicación Latch con bloqueo activado. |
Y por último, configurar el servidor GLFTPD (glftpd.conf) para que use los scripts. Por supuesto, hará falta hacer que 'wget' funcione dentro del chroot del servidor ftp.
22 diciembre 2013
- Investigación y análisis de la vulnerabilidad grave de exposición de token de Office 365
- eGarante ha lanzado la iniciativa «tu décimo seguro» para permitir de una forma legalmente válida, compartir participaciones mediante el correo electrónico.
- El listado definitivo de Scott Hanselman con herramientas para desarrolladores y usuarios avanzados para Windows de 2014
- Publicados los resultados de la iniciativa The DNS Census 2013, que nació con la idea de proporcionar una recopilación gratis de los dominios registrados, así como sus registros DNS. El listado contiene más de 2,5 billones de registros DNS obtenidos entre 2012 y 2013.
- Desde Toolswatch se lanza el listado del Top de herramientas de seguridad de este 2013 cuyo ranking ha sido votado por los lectores de Toolswatch.org.
- La web de poker online con Bitcoins, SealsWithClubs, ha sido hackeada esta semana. Se publicó en el foro de InsidePro un listado con más de 42,000 usuarios y hashes de contraseñas.
- La NSA podría haber pagado a RSA 10 millones de dólares para utilizar un algoritmo de cifrado que pudiese incluir una puerta trasera. La polémica está servida.
- Se lanza el CTF para el próximo 30C3, el anuncio oficial en este enlace. Este año será organizado por los CCCAC y tendrá lugar desde el 27 hasta el 29 de Diciembre.
- En el blog de Erratasec, cómo deshabilitar la luz de la webcam en Windows para evitar detectar que se está utilizando.
- Se publica la versión 1.5 de WinAppDbg, módulo de python que permite a los desarrolladores programar rápidamente scripts de instrumentación en Python bajo entornos Windows.
21 diciembre 2013
Fue este año en Pereira - Colombia, en el CSI, donde conocí a Walter Cuestas y junto con el resto de ponentes amigos, tuvimos interesantes discusiones que (también) llevaban como temática aspectos de seguridad.
En Perú el evento de hacking por excelencia hasta ahora es el Limahack, en el que Walter participaba en ediciones anteriores como organizador. Sin embargo, este año, ha querido montar un evento nuevo, apoyado por la UPC (Universidad Peruana de Ciencias Aplicadas) y en cuya organización también forma parte gente de Limahack. Tras unas bromas por twitter con Walter, me llegó un correo en el que me invitaba a asistir como ponente a Peruhack, gracias al patrocinio de, entre otros, Startlabs y ESETLA. Así que el último cruce de charco que me he pegado este año ha sido a uno de los países de Latinoamérica que aún tenía sin marcar en mi lista de visitados.
El primer día que llegué, tras deshacer maleta, ducha, etc,… el propio Walter hizo de Cicerone por diferentes partes de Lima: el distrito de Miraflores, parte del centro de Lima, el museo de la gastronomía,… culminando la mañana con un restaurante de comida típica peruana, donde el ceviche, los tiraditos y el arroz con mariscos me dieron a entender que sería una semana estresante, y gratificante a la vez, para el estómago.
Por la tarde fuimos a la Universidad donde se celebraría el evento, para comprobar las salas en las que se impartirían al día siguiente los diferentes talleres. La UPC es impresionante! Universidad privada de grandes medios técnicos, seguridad física bastante estricta y hasta un Starbucks en su interior. Ese día, por culpa del jet lag, me retiré temprano al hotel.
Los dos días siguientes impartí el taller “Buenas Prácticas de Seguridad en Entornos Corporativos”. Atendieron al mismo unas 15 personas, por lo que el aforo del laboratorio que me asignaron estaba casi completo.
El viernes 13 de Diciembre, era cuando se celebraba el evento en sí. Al igual que otros, se decidió que habría dos Stages. Los ponentes eran en su gran mayoría peruanos. Uno de los objetivos que tenía Walter al montar Peruhack era promocionar el talento nacional, dando la oportunidad de exponer a profesionales de seguridad de Perú. De hecho, el único foráneo, era yo.
La apertura del evento, corrió por cuenta del propio Walter, en la que expresó la motivación de Peruhack.
La primera charla a la que asistí fue la de Jean Del Carpio, que fundamentalmente dio una charla sobre las bases del exploiting explicando desde los propios fundamentos de los registros de un procesador, memoria, funcionamiento de pila, instrucciones en ensamblador, etc,… y todo en una hora!
La siguiente charla que asistí fue la de Camilo Galdós un joven loco por la seguridad, hablando sobre bug bounty, contándonos los diferentes fallos XSS que ha encontrado en sitios webs importantes como Ebay, Facebook, Adobe, Paypal, etc…. Camilo explicó el proceso de contacto con estas grandes corporaciones, así como las diferentes trabas que ponen a la hora de reconocer una vulnerabilidad como tal, e incluso el tiempo que demoran en remunerar el tiempo de trabajo invertido. Hasta dos años en algún caso!
Con esto de las dos stages y que tenía trabajo pendiente de clientes en España, tuve que estar a caballo entre el evento y otros compromisos. En este evento impartí dos charlas: “Buenas prácticas forenses: casos reales con Linux e IOS”, que pese al horario en que me tocó darla (justo después de comer) resultó bastante divertida e interactiva.
Más tarde atendí a una entrevista que me hicieron para la Marina Peruana, y al final del evento, tras la interesante intervención del abogado Erick Iriarte, tuve la oportunidad de dar mi segunda conferencia. Se supone que la keynote se hace al inicio de los eventos, pero en este caso, Walter me indicó su preferencia por hacerla al final. La charla que dí como keynote fue la última versión de “LIOS #FF: A tool for IOS Forensics”, con un montón de nuevas funcionalidades, que por el feedback recibido, fue igualmente interesante.
Los siguientes dos días, mis anfitriones, Camilo y John Vargas, junto con Rafa Revert, amigo español residente en Lima, me llevaron a sitios emblemáticos para un freak como yo: La famosa calle Wilson, donde te venden “sowar”, “jackin”, “baseh de datoh”, “correos eletrónicos” y cualquier libro que hayas imaginado, relacionado con informática, en modo fotocopias o empastado como si fuera real. Esto fue sin duda algo que me impresionó. Me quedó claro que los peruanos son curiosos por saber de informática, redes, programación y seguridad... de hecho, llevan el sistema operativo hasta los lugares más recónditos del cuerpo
El resto, cervezas a montones, el barrio chino, calles del centro, ceviche por doquier, pollo a la brasa, el mall Larcomar, la calle de las pizzas, etc,…
Todo esto acompañado con una alta dosis de camaradería, humildad, humor y ganas de hacerte sentir como en casa, incluso proveyéndome de Internet 24x7, compartido con un router por 3G, con un SLA sobradamente cumplido.
Por todo esto y más, público peruano asistente al Peruhack, Walter, Camilo, John y Rafa: Muchísimas GRACIAS, de corazón!
20 diciembre 2013
Cuando todo el mundo en Estados Unidos aprovechaba el fin de semana del pasado Black Friday para hacer compras con increíbles rebajas, y desgastar sus tarjetas de crédito...otros obtenían los datos de dichas tarjetas de crédito, comprometido así uno de los comercios americanos más importantes, con más de 2000 tiendas físicas, Target.
En este caso los usuarios que realizaron compras a través de su portal online o en tiendas de Canada no están afectados, pero sí todos aquellos que realizaron pagos con tarjetas de crédito entre el 27 de Noviembre y el 15 de Diciembre podrían haberse visto afectados.
Hasta ahora, tras varias comunicaciones publicadas por la propia empresa, se conoce que la información robada por estos ladrones digitales correspondería con los siguientes datos:
- Nombre completo del cliente
- Número de tarjeta de crédito o débito
- Fecha de caducidad
- Código de seguridad CVV
Básicamente se ha obtenido la información que reside en las tracks de las tarjetas magnéticas, datos más que suficientes para poder reproducir su funcionalidad y poder realizar compras totalmente ajenas, suplantando por completo la identidad de las víctimas.
No es el primer caso de robo importante de información referente a tarjetas de crédito. Contábamos por aquí en Abril del año pasado la intrusión sobre Global Payments, sobre el cual también se conoció el acceso a información raíz de las tarjetas que procesaba.
Caída de las acciones de Target Corp (TGT) tras el anuncio del compromiso a sus clientes |
Por desgracia, todavía no tenemos detalles técnicos acerca de lo ocurrido, únicamente que parece que la intrusión se realizó sobre los propios puntos de venta. Esperamos que en los próximos días podamos conocer algo más. A fecha de hoy, la investigación sigue en pie.
Otro de los casos relevantes y similares a este, tal y como recuerda Brian Krebs en este post, es el de TJX en el año 2007, sobre la cual se comprometieron también más de 40 millones de tarjetas de crédito. En este caso, la intrusión se llevó a cabo a través de la red inalámbrica de una de sus tiendas, a través de la cual se accedió a la red de la sede central.
Referencias:
[+] Sources: Target Investigating Data Breach - Krebsonsecurity.com
[+] Target Says Data for 40 Million Shoppers Was Stolen - nytimes.com
18 diciembre 2013
Han pasado ya 3 añazos desde que liberásemos la chuleta para Nmap 5 en este mismo blog. Más de 33.000 descargas de los PDF y decenas de versiones nuevas de la herramienta.
Tampoco es que haya cambiado demasiado en todo este tiempo, un par de parámetros se han renombrado (como el caso de -sP que pasa a ser -sn o -P0 que se convierte en -Pn). También he añadido la opción --script-updatedb que actualiza los scripts NSE de la herramienta a su última versión.
Los ejemplos de ejecución los mantengo porque me siguen pareciendo adecuados, aunque con los cambios arriba mencionados:
Análisis rápido: nmap -T4 -F
Análisis rápido (puerto 80): nmap -T4 --max_rtt_timeout 200 --initial_rtt_timeout 150 --min_hostgroup 512 --max_retries 0 -n –Pn -p80
Análisis de ping: nmap -sn -PE -PP -PS21,23,25,80,113,31339 -PA80,113,443,10042 --source-port 53 -T4
Exhaustivo lento: nmap -sS -sU -T4 -A -v -PE -PP -PS21,22,23,25,80,113,31339 -PA80,113,443,10042 -PO --script all
Trazado de ruta rápido: nmap -sn -PE -PS22,25,80 -PA21,23,80,3389 -PU -PO --traceroute
Imágen reducida de la chuleta de Nmap6 |
Podéis descargar la versión en español: Nmap6 cheatsheet esp v1.pdf
El mismo documento en inglés: Nmap6 cheatsheet eng v1.pdf
17 diciembre 2013
Hace unas semanas, mis buenos amigos de Sophos Iberia, Juan Antonio Gallego y Pablo Teijeira, me invitaron a conocer, en sus oficinas de Madrid, a Vanja Svajcer, uno de sus mejores expertos en malware e investigador principal de Sophoslabs. Tras una muy agradable conversación, en la que tratamos unos cuantos trending topics de la seguridad pasada y presente, tuve al oportunidad de enviar a Vanja un correo con varias preguntas.
Primero que nada introduciros una pequeña BIO de Vanja:
Vanja Svajcer es un veterano de la industria, con más de 15 años de experiencia en malware y búsqueda de vulnerabilidades. Vanja se unió a Sophos en 1998, trabajando en la detección de virus para MS-DOS y macro para Word, y progresó para llegar a ser un reconocido experto en el campo de la protección ante el malware. A través de su carrera en Sophos, Vanja fue el responsable de desarrollo de sistems automáticos de análisis, tecnología de detección de comportamiento, análisis de vulnerabilidades y tiene patentes en dichas áreas. Recientemente, su interés incluyó malware para sistemás operativos para dispositivos móviles y Linux. Es speaker habitual en conferencias de seguridad como EICAR, Virus Bulletin, RSA, Infosecurity y Websec.
SbD: Vanja, diariamente vemos cómo se desarrolla la industria del malware desarrolla más rápido que la de del antimalware. ¿Son los antivirus útiles actualmente?
Vanja: Creo que estaremos de acuerdo que el software antivirus es todavía muy útil a día de hoy. En un estudio reciente, Microsoft usaba su MSRT (Microsoft Software Removal Tool) para medir la efectividad media del software antivirus, comparando el ratio de infección de ordenadores protegidos con software antivirus versus los que no lo estaban o con el antivirus sin actualizar. El estudio de Microsoft muestra claramente que, los ordenadores desprotegidos, tienen al menos 5 veces más probabilidad de ser infectados que los protegidos (Mira en http://www.microsoft.com/security/sir/story/default.aspx#!antivirus_statistics para más detalles)
Sin embargo, la efectividad de las técnicas estándar de antivirus, que incluyen todas las de inspección de contenidos de ficheros antes que el fichero se ejecute en el ordenador está disminuyendo cada vez más.
Pero, definitivamente deberíamos considerar que el software antivirus de hoy es muy diferente al de hace 10 o incluso 5 años. Mientras que en el pasado, los antivirus sólo se metían en detección en el contenido de ficheros individuales, hoy hay tres partes principales de protección, que son el contenido (tradicional), reputación y por último pero no menos importante, comportamiento. Estos tres componentes pueden ser observados individualmente. Por ejemplo, mi navegador está intentando acceder a una URL con mala reputación o en cualquier combinación, mi navegador ha accedido a un sitio de reputación media que ha lanzado una descarga de un fichero Jar de Java ofuscado (detección de contenido) y que el runtime de Java ha lanzado la descarga de un fichero ejecutable PE (comportamiento + contenido). Las nuevas tecnologías anti-malware están siendo desarrolladas constantemente.
Lamentablemente, mucha gente, incluso en la comunidad de seguridad, creen que el antivirus está descatalogado pero no ofrecen otra alternativa viable y suficientemente simple para poder desplegar en cientos de millones de ordenadores. Se podría discutir si la seguridad debería ser construida en el sistema operativo, pero esto no es claramente el caso con Windows, e incluso algunos sistemas operativos más modernos, como Android.
Algunas decisiones de diseño consciente que la gente toma mientras construye el Sistema Operativo vuelven a cazarles en el futuro y se hacen progresivamente más difícil de parchear con el tiempo.
Un ángulo prometedor en la seguridad Endpoint es el también llamado “whitelisting” en vez de bloquear contenido malo, el producto puede securizar el sistema permitiendo sólo el despliegue de software bueno conocido.
Aún, hay problemas con esta aproximación puesto que no tiene en cuenta ficheros de datos tradicionales que pueden contener contenido ejecutable, sin mencionar código Javascript en páginas HTML. Por supuesto, whitelisting es una combinación de inspección de contenido y de reputación, y por tanto igualmente aplicable a la tecnología de blacklisting.
Por tanto, pienso que aún hay vida, en el futuro próximo, para las tecnologías antivirus (quizá sera mejor llamarlas Securidad Endpoint)
SbD: ¿Por qué los anti-malware no aplican técnicas de hardening cuando son instalados? (cosas como monitorización del registro, deshabilitar servicios innecesarios, aplicaciones al arranque, fichero /etc/hosts, cambios en la configuración de proxy de sistema, etc,…)?
Vanja: Esta noción es de nuevo algo incorrecto. La mayoría del software de seguridad tiene un componente de tiempo real que monitoriza y previene potencial comportamiento malicioso. Algunas personas también se refieren a estos componentes como bloqueadores de comportamiento o HIPS (Host Intrusion Prevention System).
En esencia, el software de seguridad instala hooks en los modos usuario y kernel que permiten interceptar eventos de sistema. Estos eventos pueden ser inspeccionados individualmente o como parte de una secuencia, de manera que el software de seguridad pueda decidir si permitir, bloquear o modificar el evento (por ejemplo redirigiendo una escritura de registro en un valor shadow de registro)
Algo de lo que estoy justamente seguro que el software antimalware no hará, es deshabilitar servicios innecesarios porque para hacer eso deberíamos saber que servicios no son necesarios. Si el servicio no es malicioso, creo que deshabilitarlo no es tarea del software antimalware, sino del sistema operativo o del sistema de gestión de software que permite al usuario o al administrador, aplicar varias políticas de control sobre los servicios de sistema.
SbD: En Security By Default, mi compañero Yago hizo un PoC sobre una herramienta que era eficaz contra el ransomware... ¿Cómo hacéis en Sophos para proteger a los usuarios contra este tipo de malware? ¿Consideráis las sugerencias de los usuarios para mejorar vuestros productos?
Vanja: Este es un concepto muy interesante y debería ser aplicado a cualquier herramienta de seguridad. Hasta ahora nuestra política no era añadir contenido adicional a un ordenador y hacer que los usuarios se confundan más con ficheros de nombres aleatorios apareciendo en sus sistemas. El principio de ficheros señuelo es útil, pero también puede requerir que el usuario final entienda más sobre seguridad. También necesitan ser capaces de distinguir ficheros creados por el software de seguridad y ficheros que puede haber creado software malicioso.
En endpoint, Sophos usa una combinación de detección de contenido (inspección de ficheros y memoria) para proteger contra amenazas como el ransomware. Además de eso, nuestra solución UTM bloqueará conexiones salientes a servidores C&C utilizados por malware como CryptoLocker.
SbD: ¿Cuál es tu opinión sobre los troyanos esponsorizados por los Estados, en los que tienes que tener en una lista blanca algún tipo de malware que “ayude a los gobiernos” para actuar contra el cibercrimen, atacando población sospechosa?
Vanja: Hasta ahora, sólo he oido que los gobiernos han estado preguntando a algunos fabricantes de seguridad sobre la posibilidad de añadir a una lista blanca sus troyanos, pero no estoy al corriente que Sophos haya sido uno de ellos. El concepto de malware de gobiernos no es nuevo. Sophos ha expresado publicamente nuestra opinión cuando el gobierno desarrolló malware allá por 2001 con el caso del backdoor del FBI conocido como Magic Lantern (la puedes ver aquí http://www.sophos.com/en-us/press-office/press-releases/2001/11/va_magiclantern.aspx) y no creo que hayamos cambiado nuestra opinión desde ese momento.
Después de todo, nuestro objetivo es proteger todos nuestros usuarios contra el malware, sea éste distribuido por cibercriminales o por gobiernos. Otro caso es Bundes Trojaner que muestra que lo detectamos http://nakedsecurity.sophos.com/2011/10/10/german-government-r2d2-trojan-faq/
He encontrado igualmente esta discusión muy interesante: https://www.schneier.com/blog/archives/2013/12/how_antivirus_c.html
SbD: Vanja, muchas gracias por haber compartido tu tiempo con nosotros y con nuestros lectores!
16 diciembre 2013
Sí, parece que el periodo de tiempo que comprende Diciembre-Enero está gafado para el mundo PKI.
En 2012 padecimos el caso Trustwave, hecho público en febrero pero con origen en esa época. En enero del 2013 tuvimos el caso TURKTRUST, y ahora, en Diciembre, tenemos el caso ANSSI. El denominador común de estos tres incidentes es un certificado de CA subordinada (con capacidad de emitir a su vez certificados para cualquier host) que 'en teoría de forma no intencionada', es empleado para generar certificados indebidos.
A estos casos de 'negligencia', tenemos que sumar en el acumulado, los hackeos de Comodo y Diginotar.
En total 5 casos bastante graves que afectan a la integridad del mundo PKI en el periodo 2011-2013. Contando que hablamos de un grupo relativamente reducido de entidades, es un mensaje que habla muy a las claras sobre cosas que no se están haciendo bien.
Está claro que el modelo, del cual me declaro defensor, necesita ajustes. Hay alternativas rupturistas como Convergence que, pasado ya un tiempo, han suscitado poco interés / implantación.
Por contra, lo que sí está siendo tomado muy en cuenta por los grandes fabricantes son mejoras al sistema que lo hagan más robusto. Por ejemplo el 'certificate pinning', lanzado y defendido por Google (no en vano Chrome es pionero en esto) y también por Microsoft a través de EMET. De hecho, gracias a Chrome se ha descubierto el caso ANSSI.
En este sentido, hay que destacar una nueva iniciativa 'EmetRules' nacido en el lab de I+D de Eleven Paths y que facilita el uso de pinning en EMET.
Complementando al pinning, mi aportación particular es SSLCop, que intenta separar las CAs de confianza en las que te interesa confiar y en las que no, mediante criterios geográficos.
Cualquier persona que haya usado SSLCop y sea hispana, seguro que ya tenía bloqueadas de antemano a TURKTRUST y ANSSI, puesto que una es de Turkía y otra de Francia. Países en los que, a priori, no necesitamos confiar puesto que sus entidades reconocidas no las necesitamos.
¿Un mini manual de buenas prácticas para usuarios?
1- Usa EMET
2- Usa EmetRules
3- Usa SSLCop
4- Usa Google Chrome
5- Para Firefox, usa CertPatrol
15 diciembre 2013
- Semana destacada para ElevenPaths, con importantes anuncios, entre ellos, su nuevo producto Latch, que permite la protección de nuestras identidades digitales, así como la liberación de Foca Final Version, correspondiente con la Foca PRO pero gratuita a partir de ahora. El evento dónde presentaron estos y otros productos formó parte del Innovation Security Day de Telefónica, que podréis volver a ver en este enlace.
- El Consejo de Seguridad Nacional presidido por el presidente del Gobierno, Mariano Rajoy, ha aprobado en su reunión del 5 de diciembre la Estrategia de Ciberseguridad Nacional. Podréis consultar el PDF con toda la información en este enlace.
- Ejecución remota de código en Wordpress 3.5.1. En el post de Vagosec, se explica el exploit para el plugin Lightbox Plus ColorBox.
- Vulnerabilidad 0day en la solución corporativa Open Source de correo electrónico Zimbra, en la que se ha descubierto que es posible la inclusión de ficheros locales.
- En Infosec Institute, gran post (primera parte) que explica con todo detalle la integración de Nessus en Metasploit.
- Más de 840,000 registros de pacientes en riesgo tras el robo de los portátiles de dos empleados.
- En Una al día, vulnerabilidad de ejecución de código arbitrario en Samba (CVE-2013-4408)
- Ejecución remota de código PHP en eBay descubierta por el investigador alemán David Vieira-Kurz. Se incluye video en el post como prueba de concepto para la demostración de la vulnerabilidad.
Suscribirse a:
Entradas
(
Atom
)