Nota: Es preciso aclarar que no existen pruebas concluyentes para atribuir la autoría de la mayoría de acciones y hechos descritos en este artículo a personas físicas, Estados, actores no estatales o a determinados servicios de inteligencia. Por ello, se hablará casi siempre de presuntos o supuestos, así como las acciones. Los servicios secretos israelíes son conocidos por su extremo hermetismo y secretismo, así que la mayoría de la información que proviene de ellos es difícil de contrastar; en ocasiones dicha información proviene de una única fuente. Todo lo expuesto a continuación está nutrido de información pública que puede consultarse abiertamente.

La Unidad 8200 (en algunas publicaciones conocida por Central Collection Unit of the Intelligence Corps, o también Israeli SIGINT National) es una unidad que pertenece a los cuerpos de inteligencia de las Fuerzas de Defensa de Israel, cuya misión es la captación de señales de inteligencia y procesado de las mismas (desde llamadas, mails, ondas o satélites). Su función es similar a la NSA o el GCHQ. Hay que recordar que el servicio militar es obligatorio para todo el mundo en Israel, y según se comenta en algunos foros, “cazadores” de talento “peinan” las escuelas del país para incorporar a la Unidad 8200 a los más predispuestos para estas tareas.

La demanda de “productos” TI militares de vanguardia, la gran inversión que realiza Israel en TI y la llegada de casi medio millón de inmigrantes titulados universitarios de la ex Unión Soviética en los 90, han empujado el sector de la alta tecnología hasta el punto de que Tel-Aviv es una de las 10 grandes ciudades de alta tecnología del mundo con su Silicon Wady. Dentro de esta alta tecnología destaca la relacionada con el ámbito de la ciberseguridad, y en parte, culpa de ello la tiene la Unidad 8200.

Empresas del sector conocidas como Palto Alto Networks, Imperva, Check Point, Seculert, Akamai o Radware (entre muchas otras) han sido fundadas por ex-miembros de la unidad 8200 y, un vistazo rápido a LinkedIn, nos muestra la alta cualificación de los mismos.

Otros analistas de la Unidad 8200 podrían formar parte de corporaciones privadas como Hazard Threat Analysis, Ltd (Terrogence), especializadas en recolección de información de inteligencia contraterrorista de fuentes OSINT. Probablemente muchos vendrán de la Unidad Hatzav, que parece ser una unidad subordinada a la 8200, centrada en recopilación de información de fuentes abiertas. Algunas fuentes comentan que son capaces de monitorizar y traducir toda la prensa y medios árabes las 24 horas del día.

Se presupone que hacen uso de la Base de Urim SIGINT, que es una de las instalaciones militares más importantes para la captación de señales de inteligencia del mundo, en las que se que recopilaría información de interés interceptada y útil para AMAN (Dirección de inteligencia militar israelí).

Mencionar que Israel tiene en marcha el programa Ofeq, una serie de satélites de reconocimiento (“satélites espía”), destinados a uso militar e inteligencia con una cobertura optimizada para Oriente Medio. Sin embargo, se desconoce si la Unidad 8200 tiene relación directa con Ofeq para recopilar información, o si existe alguna unidad IMINT para tal fin.

Base de Urim (desierto de Néguev). Fuente: Google Maps

En cuanto a operaciones conocidas, u otras acciones relevantes, no hay demasiada información pública al respecto, tal y como hemos comentado. Insisto en que las atribuciones de las acciones/operaciones son meramente suposiciones, ya que no hay ningún tipo de confirmación oficial al respecto de la participación de esta Unidad. En orden cronológico:

2007. Según diversas fuentes (ver cable de Wikileaks relacionado), participarían en la Operación Orchard, en la que fuerzas aéreas israelíes atacaron Al-Kibar (nombre del objetivo) en Siria, en el que había un supuesto reactor nuclear encubierto. Según la prensa, a través de la Unidad 8200, y con una tecnología similar al Suter estadounidense (desarrollado por la Unidad Secreta de las Fuerzas aéreas norteamericanas, Big Safari), la Fuerza Aérea Israelí fue capaz de atravesar el espacio aéreo sirio sin ser detectados por los radares. Anteriormente Israel había llevado operaciones similares a ésta, como la Operación Ópera en 1981, por la que se atacó un reactor nuclear en construcción en Irak.

2010. Aparece Stuxnet, malware avanzado con capacidad de cibersabotaje industrial, enmarcado dentro de la Operación Olimpic Games, y atribuido, según los medios, a Israel (Unidad 8200) y USA. Duqu llegaría en 2011 y Flame en 2012, ambos con grandes analogías y paralelismos a Stuxnet y por tanto supuestamente procedentes de los mismos autores.

2013. Snowden filtró el memorando completo por el que se ponía de manifiesto que la NSA compartía información con la Unidad 8200 desde el 2009 generando una gran polémica porque no se filtraba nada.

Ese mismo año el periódico alemán FOCUS, publicaba que Israel acusaba al gobierno de Bashar Al-Assad de usar armas químicas en Siria. Parte de la investigación llevada a cabo para lanzar estas acusaciones la podría haber llevado a cabo la Unidad 8200 a través de la interceptación de comunicaciones en las que se evidenciaba este hecho.

2014. LLegaba la noticia de que Israel frustraba un atentado de Al Qaeda en Tel-Aviv contra la embajada estadounidense. Algunas fuentes indican que la operación de contra-terrorismo fue llevada a cabo por la Unidad 8200 y los servicios de inteligencia.

Este mismo año, un grupo de 43 miembros la Unidad 8200, a través de un carta abierta dirigida al primer ministro Netanyahu y al jefe del estado mayor israelí, Benny Gantz, rechazaban participar en acciones contra los palestinos por cuestiones morales.

2015. Este mismo mes de junio, saltaba a la palestra, Duqu 2.0, malware avanzado para ciberespionaje atribuido presuntamente a Israel, detectado por Kaspersky en sus propias redes internas, y además en varios objetivos relevantes en el marco de las negociaciones internacionales sobre el programa nuclear iraní, y en el evento del 70 aniversario de la liberación de Auschwitz.

Comentar, por último, que las fechas citadas respecto a la aparición de las operaciones/malware son de cuando se hizo pública su existencia, no de cuando se crearon, que, en la mayoría de los casos se desconoce.

Las últimas noticias al respecto del futuro de la Unidad 8200 son que van a formar parte del futuro Cyber Command de ejército israelí que se prevé esté operativo en dos años. En aras de unificar funciones, el nuevo Cyber Command israelí estará dotado de capacidades ofensivas/defensivas – hasta ahora llevadas a cabo por la Unidad 8200- y además por otros grupos relacionados con la inteligencia militar.

Solo sabemos que no sabemos nada.

La entrada Unidad 8200 aparece primero en Security Art Work.

¿Quiénes son y a qué se dedican?

Hacking Team es una empresa de ciberseguridad que realiza software, el cual se puede considerar de dudable legitimidad ya que su función es conseguir/recopilar información sensible y de carácter privado.

Dicha empresa tiene una suite de seguridad, compuesta por un gran número de herramientas y funcionalidades. Esta suite se conoce como Da Vinci. Como es de esperar, se puede personalizar para cada cliente, dependiendo de necesidades y presupuesto.

Tienen (o tenían, ya que a raíz de lo sucedido, dudo que continúen siendo clientes…) un gran abanico de clientes, entre los cuales se encuentran gobiernos y fuerzas del orden de diferentes países como Alemania, Arabia Saudita, Australia, Azerbaiyán, Bahrein, Chile, Chipre, Colombia, Corea del Sur, Ecuador, Egipto, Emiratos Árabes Unidos, España, Estados Unidos, Etiopía, Honduras, Hungría, Italia, Kazajstán, Luxemburgo, Malasia, Marruecos, México, Mongolia, Nigeria, Omán, Panamá, Polonia, República Checa, Rusia, Singapur, Sudán, Suiza, Tailandia, Uzbekistán, Vietnam… Y cómo no, (¡qué curioso!), entre ellos está España.

Figura 1: Imagen que muestra España como cliente de Hacking Team

En su página web oficial, incluso encontramos un vídeo donde se anuncian y promocionan explicando lo que hacen: Hacking Team Commercial

Resulta curioso que una empresa de este tipo se anuncie tranquilamente y de esta manera, pero claro, en realidad llegamos siempre al mismo punto: que ellos diseñen este tipo de herramientas, ¿está mal? Desde mi punto de vista, el diseño del software en sí mismo no está mal. Lo que está mal es el uso que se le da a la herramienta, con qué fin se utiliza. (Aunque tampoco es el objetivo de este post generar una polémica sobre lo que está bien y mal…)

Orígenes

En el año 2001 un par de programadores italianos, Alberto Ornaghi y Marco Valleri, publicaron una herramienta open source y gratuita llamada Ettercap. Este software es capaz de interceptar tráfico de red, capturar contraseñas, además de conseguir escucha activa contra una serie de protocolos comunes.

Como os imagináis, esta herramienta se hizo muy popular y cuenta la leyenda que la policía de Milán se puso en contacto con ellos para darle uso en función de sus necesidades. Así, la policía de Milán se convirtió en el primer cliente oficial de la pequeña consultoría que mantenían ambos desarrolladores. De ahí nacería con el tiempo Hacking Team.

¿Qué ha pasado y qué podemos encontrar?

¿Y por qué todo este rollo? (Esperemos que no sea un rollo, es una manera de hablar :-) ) ¿Por qué esta noticia? ¿Por qué este post? La noticia viene porque la empresa de la que hemos estado hablando hasta ahora ha sido hackeada. Resulta un tanto irónico pero sí, la empresa “hackeadora” ha sido hackeada, y se ha publicado en Internet una gran cantidad de información muy interesante: software que generaba la empresa, clientes que pagaban por sus servicios, etc…

Si contabilizamos los datos que les han extraído, estamos hablando de alrededor de 400GB de almacenamiento. (El que tenga la feliz idea de descargarse el archivo .torrent que prepare disco duro, ancho de banda y paciencia jejeje).

El día 6 de este mes fue cuando empezó todo. Este fue el día más terrorífico para la gente de Hacking Team. Hackearon su cuenta de Twitter y publicaron en su nombre enlaces desde los cuales podemos obtener la información sensible extraída y almacenada por ellos.

Figura 2: Imagen que muestra el tuit publicado Hacking Team

También se han desvelado correos donde se muestra que fuerzas del orden compraban y pagaban por el uso y soporte de dicho software. La imagen que se muestra a continuación es un correo electrónico de un empleado de la DEA pidiendo soporte para la actualización de los Rcs a la última versión:

Figura 3: Correo electrónico que muestra a la DEA en contacto con Hacking Team

Como se ha mencionado anteriormente, se han encontrado también datos de países como Azerbayan, Russia, Arabia Saudí o Emiratos Arabes Unidos. Varios de estos gobiernos están en el punto de mira de las organizaciones internacionales de defensa de los derechos humanos. El caso más llamativo es el de Sudán. Uno de los documentos publicados es una factura de 480.000 euros firmada por el servicio de inteligencia sudanés con fecha junio 2012. Tres años después, Hacking Team declaró ante el representante de Naciones Unidas en Italia que la empresa jamás había tenido negocios relacionados con ese país.

Figura 4: Imagen que muestra un contrato con Sudán

Y así hay varios ejemplos más que podríamos mencionar en este artículo, pero no acabaríamos nunca… Lo más curioso que he encontrado y que es lo último que añadiré es un repositorio de github, en el cual se van añadiendo herramientas interesantes que utilizaba la empresa Hacking Team y que ofrecían.

Ahora bien, creo que no debo dar ninguna charla ni discurso sobre el uso que se le debe dar a la información añadida en este artículo.

Por último, si queréis seguir leyendo cosas curiosas al respecto os recomiendo que os paséis por este perfil de Twitter: @evacide

Fuentes:

• http://hipertextual.com/2015/07/hacking-team-hackeado
• http://es.gizmodo.com/hacking-team-asi-funciona-la-empresa-hackeada-contrata-1715945205
• http://es.gizmodo.com/caos-en-hacking-team-pide-a-sus-clientes-dejar-de-util-1716089992
• http://internacional.elpais.com/internacional/2015/07/07/actualidad/1436220111_034556.html
• Figura 1: https://xnet-x.net/gobierno-espanol-hacking-team/
• Figura 2: http://www.csoonline.com/article/2943968/data-breach/hacking-team-hacked-attackers-claim-400gb-in-dumped-data.html
• Figura 3: https://twitter.com/rj_gallagher/status/618176144106500096/photo/1
• Figura 4: http://es.gizmodo.com/hacking-team-asi-funciona-la-empresa-hackeada-contrata-1715945205

La entrada Hacking Team: El espionaje como negocio aparece primero en Security Art Work.

No hace falta explicar qué ha pasado con #HackingTeam, ¿verdad? El pasado domingo se desató un revuelo en redes sociales, blogs, páginas de noticias,etc. HackingTeam había sido hackeado, pwned.

Así que la gente preparó palomitas, preparados para digerir todo lo que había pasado (y estaba por pasar).

La cosa se ponía interesante: el CNI y la Policía aparecían como clientes de HackerTeam. Pero, ¿realmente la gente no se lo esperaba?

Quiero decir, al menos de un servicio de inteligencia. Ya se dieron a conocer detalles de quién utilizaba supuestamente (o podía haber utilizado) FinFisher. Si existe el negocio MaaS (Malware-as-a-Service) ¿por qué no?

Es más barato que contratar a un equipo de expertos que desarrollen desde cero una solución similar para servicios de inteligencia y/o gobiernos. Ahora se están pidiendo explicaciones y entiendo que el CNI no las dé.

¿Acaso van a decir para qué lo han utilizado? Que lo han hecho está más que claro… no van a mojarse más (IMHO). Así pues, se abrió la caja de pandora. Desde entonces, se han publicado 400GB de información con todo tipo de regalitos: Zero Days, Exploits, Códigos Fuente, pasaportes, etc.

Empezamos con la siguiente captura:
 

Aquí el link a la imagen del código para que se pueda apreciar mejor.

Sin duda, mosquea. ¿Quiere decir que las autoridades pertinentes de los países clientes utilizaban esto para incriminar a alguien en delitos de pedofilia? No hay nada que lo demuestre, pero el código está ahí y la sospecha está servida…

Otro de los temas más comentados, y menos mal que ya está corregido, es el de Adobe Flash Player. Otro de Flash… Yay! Quiero decir, no es que no sea crítico. De hecho ese es el problema: que está siendo explotado activamente ya por varios exploit kit, ‘Ojocuidao’. Tampoco me extraña que sea de Flash, otra vez, cuya frecuencia de actualización tiende a infinito. Para más info sobre el exploit podéis visitar la web de TrendMicro.

Otros regalitos que se han encontrado en la ‘caja de pandora’ son otros tantos exploits que permiten la escalada de privilegios en Win8 y Ubuntu. También se sabe de APKs con gran cantidad de permisos que, junto con el nombre de las app, no extrañaría que fuese utilizado/vendido por Hacking Team para comprometer dispositivos móviles.
 

¿Alguien ha podido comprobar que estas aplicaciones sean realmente maliciosas? ¿Alguien ha comprobado su comportamiento? No he podido verificar esta información, pero no creo que se haga esperar demasiado. Por lo tanto, estamos ante un hecho que no se olvidará fácilmente… porque además, hemos podido comprobar que como es habitual, en casa del herrero, cuchillo de palo.

No se puede ir dando consejos y procedimientos y luego tener cosas como estas. Por ejemplo, la contraseña empleada en el mysql de HackingTeam:
 

Y ya para colmo, esta imagen que ya deja claro el “nivel” de seguridad que tenía Hacking Team:
 

Parece que esta gente sólo sabía de exploiting… o no. ¡Quizá hasta lo habían subcontratado! Y de ahí esas “perlitas”.

Solo puedo añadir una cosa más. Muchachada, ¡no descuidéis la seguridad!

La entrada ¿Abierta la caja de pandora? Hacked Team. aparece primero en Security Art Work.

Ser administrador del dominio o disponer de credenciales de acceso con máximos privilegios a repositorios de ficheros, bases de datos o sistemas ERP no sirve de mucho a la hora de plasmar los riesgos de la organización auditada en un informe, ya que “negocio”, muchas veces, no concibe las consecuencias que puede suponer el disponer de tales capacidades.

Es por eso que después de la fase de explotación y elevación de privilegios, comienza desde mi punto de vista la más importante de todas, la de obtención de información y toma de evidencias. De nada sirve conseguir ser administrador de un dominio Windows si no se pueden obtener datos sensibles o ejecutar acciones que puedan suponer un impacto para el auditado. Es en este momento donde entra en juego esta simple pero potentísima herramienta: OpenDLP.

Este software, que se despliega mediante un GUI Web en la máquina del pentester, permite realizar búsquedas masivas de información en miles de equipos de forma simultánea y con una baja carga, tanto para la máquina objetivo como para el equipo del auditor. A diferencia del buscador de Windows que identifica los patrones de búsqueda en los nombres de los documentos, OpenDLP permite inspeccionar el contenido de los ficheros mediante expresiones regulares. Como su nombre indica es un DLP o herramienta de prevención de fuga de información, pero la verdad es que dista mucho de las capacidades de las soluciones comerciales, por lo que para este propósito no lo recomendaría. Sin embargo descaradamente, OpenDLP ha sido desarrollado para cubrir la fase comentada anteriormente, dentro de un test de intrusión.

OpenDLP puede ser descargado desde su página web en Google Code en dos sabores: código fuente y máquina virtual. Yo recomiendo el segundo ya que nos evita problemas de instalación y dependencias y podemos levantar la VM (VMWARE/VIRTUALBOX) cuando necesitemos de sus servicios.

Tras levantar la máquina virtual copiaremos en primer lugar un ejecutable sc.exe de un equipo Windows XP/2000 32 bits a “/var/www/OpenDLP/bin/”, ya que por temas de licencias este no puede ser distribuido con la solución.

A continuación instalaremos el certificado “client.p12” en nuestro navegador favorito, que nos permitirá conectar al servicio web, introduciendo la siguiente contraseña.

username: dlpuser
password: OpenDLP

Bien, ya tenemos el servidor levantado, que no nos engañe el interfaz Web 3.0 optimizado para Mosaic 0.1Beta, la herramienta esconde capacidades muy potentes.

OpenDLP nos permite realizar básicamente 3 tipos de búsquedas:

1. Búsquedas sin despliegue de un agente de ficheros en la maquina objetivo, a través de SMB o SSH. No recomendable para más de 1 máquina bajo análisis ya que ha de conectarse al recurso remoto, descargarse todos los archivos y analizarlos en local en la máquina del pentester. Una locura si nos disponemos a evaluar 200 equipos.
2. Búsquedas mediante el despliegue de agente en la máquina remota. Recomendado y tremendamente potente, ya que nos permite ejecutar de forma paralela cientos de búsquedas sin la consiguiente carga en el equipo, ya que es el agente de cada máquina objetivo la que se encargará de realizar el trabajo, remitiendo de forma periódica sus avances al servidor. Destacar que la carga en el equipo auditado es baja y no apreciable por el usuario del mismo.
3. Búsqueda sin despliegue de agente en bases de datos Mysql y MSSQL. Nuevamente se recomienda lanzarlo de forma secuencial unitaria, sino queremos que se eternice la búsqueda.

Por último como capacidad adicional, es posible realizar el despliegue del agente de búsqueda a través de una sesión de Metasploit abierta, feature muy interesante también que no he llegado a probar.

Vamos a ver ahora como realizar una búsqueda básica. En primer lugar necesitamos identificar qué queremos buscar, para lo que definiremos en la pestaña de ”Expresiones regulares” las cadenas objetivo. En este punto la imaginación es nuestra mejor aliada, plasmando mediante REGEX aquellas palabras que puedan suponer información confidencial o sensible para la organización. En un principio OpenDLP viene con una serie de expresiones destinadas a detectar números tarjetas bancarias. Esto puede ampliarse con por ejemplo, las siguientes REGEX (en rojo) que identifiquen otro tipo de información. Debemos ser cuidadosos en este punto, ya que la calidad de nuestras expresiones regulares marcará la tasa de falsos positivos. En posteriores entradas daré una lista de las que yo utilizo.

En segundo lugar definiremos un Profile de tipo “Agente de Windows”. Tras introducir el nombre de nuestro nuevo perfil tal y como muestra la imagen siguiente, deberemos tener en cuenta los siguientes aspectos.

Introduciremos un usuario y contraseña con privilegios de administrador en las máquinas a analizar, si este es un usuario de dominio (admin del dominio) por ejemplo, estableceremos el nombre del mismo (en este caso prueba.com). Destacar que OpenDLP permite también realizar las búsquedas sin conocer las credenciales a través de técnicas de Pass-the-hash (brutal). Por lo que respecta a los demás parámetros de la captura los dejaremos por defecto.

A continuación prestaremos atención al parámetro “Regular expresions” que nos permitirá seleccionar las REGEX que queremos ejecutar sobre los equipos, incluyendo la definidas previamente por nosotros.

En este punto hay que tener cuidado con el parámetro UploadURL , el cual define la ruta del servidor OpenDLP a la cual los agentes subirán los resultados y el progreso de la búsqueda. Por algún problema desconocido este parámetro a veces no se setea automáticamente de forma correcta, lo que se soluciona con un simple reinicio de la VM. Tras configurar el usuario y contraseña utilizado por los agentes para subir la información (u: ddt, p: OpenDLPagent) estableceremos el número de despliegues de forma concurrente que queremos realizar. Este parámetro afecta tan solo al despliegue inicial del agente, no a la búsqueda concurrente, por lo que no pondremos un valor muy alto.

A continuación configuraremos una nueva búsqueda mediante “Scans-> Start New Scan”, definiendo el direccionamiento a analizar y el Profile que hemos creado anteriormente.

Tras lanzar la búsqueda podemos ver el estado de la ejecución en “View Results”. Destacar en esta parte los diferentes estados en los que puede estar un agente (Step):

• Desplegando el agente.
• Identificando lista blanca de archivos (que directorios y archivos ha de excluir).
• Buscando.
• Finalizado.

En cualquier momento es posible parar/ pausar o desinstalar un agente en la máquina remota, no dejando rastro de las acciones realizadas. Asimismo se pueden consultar los resultados remitidos hasta el momento sin necesidad de que la búsqueda termine; como ejemplo la captura siguiente muestra cómo se presentan los hallazgos. Simple pero efectivo, OpenDLP nos permite descargarnos el archivo para visualizarlo tan solo dándole un click en el respectivo enlace (muy rápido además y nuevamente brutal).

En conclusión, OpenDLP nos permite en muy poco tiempo identificar información sensible de la organización bajo análisis, de una forma eficaz y fácil. Si a este proceso le añadimos algunas técnicas de “Rapid pentesting” que aceleran notablemente la fase de explotación (en otro post), podemos llegar al cliente, darle a un botón, ponernos las gafas de sol y abrirnos una cervecita, quedándonos tan solo redactar el informe, ¿tiene alguien algún script en Python por ahí…?

La entrada OpenDLP para pentesters aparece primero en Security Art Work.

En un post anterior hablé sobre el crimen organizado en el mercado negro y siguiendo un poco la misma temática, vamos a ver de forma breve en este post algunos de los delitos orientados en este caso al sector bancario, además de las técnicas y métodos que utilizan los delincuentes para llevarlos a cabo.

Phishing

Probablemente es la reina de las técnicas de fraude online. El phishing es una técnica empleada por los delincuentes que mediante ingeniería social o por distribución de malware tiene como finalidad obtener información privada para acceder de manera no autorizada a determinados servicios, suplantando para ello la identidad legítima del titular.

La vía más utilizada de esta técnica es mediante correo electrónico, aunque existen variantes, descritas a continuación, dependiendo del método que se emplee.

Smishing

Consiste en la técnica de obtener información privada a través de mensajes SMS o MMS. Aunque su uso ha tenido un decremento considerable en comparación con hace unos años, todavía se pueden dar casos de este tipo.

Normalmente, se envía el mensaje suplantando una entidad bancaria, informando al usuario que ha habido un error de validación con la tarjeta y que ha sido bloqueada por motivos de seguridad, por lo que deben rellenar un formulario a través de la web para activarla.

Tal y como se espera, la web no es legítima, por lo que los usuarios si rellenan el formulario entregarán todos los datos relativos a su tarjeta a los criminales.

Vishing

En este caso los delincuentes contactan directamente con la víctima a través de llamadas telefónicas. Entre otro tipo de estafas, es común simular una entidad bancaria, informando al usuario que su tarjeta ha sido utilizada de forma fraudulenta, y al igual que en otros casos, se pide al usuario los datos bancarios, número de tarjeta, PIN, CVV y fecha de caducidad, con el supuesto fin de comprobar la identidad del usuario y posteriormente ser atendido por un operador, aunque evidentemente esto nunca llega a suceder una vez han sido robados los datos.

Whaling

Esta técnica es un caso similar al phishing tradicional, pero con la diferencia que los correos electrónicos suplantan una identidad bancaria legítima y van dirigidos hacia un destino específico, usuario habitual de banca online. El objetivo suelen ser personas con altos cargos en compañías, empresarios, o personas con importantes activos económicos.

Pharming

La finalidad del pharming es que el usuario acceda a una página maliciosa controlada por el criminal, empleando la técnica de pharming que consiste en modificar el servicio de DNS para que el usuario cuando quiera acceder a la página legítima se muestre la fraudulenta. De este modo, todo parece transparente para el usuario final, ya que ni ha tenido que pinchar en un enlace ni llevar a cabo ningún comportamiento de riesgo.

Skimming

En este caso, esta técnica es más compleja y costosa que las anteriores, ya que se trata de realizar una clonación física de las tarjetas bancarias. No vamos a entrar en detalle como sería el proceso completo (ya que esto da para otro post), simplemente mencionar que el proceso de clonación consiste en obtener la información almacenada en la banda magnética y posteriormente clonar la tarjeta físicamente.

En los delitos que hemos comentados de robo de información bancaria, todos convergen a lo mismo: obtener la información de acceso a banca online de las víctimas y también en otros casos toda la información de la tarjeta bancaria. Llegado ese punto, ¿qué hacen los delincuentes con esa información? No hay mucho misterio: robar el dinero de las víctimas y que éste llegue a manos de los cibercriminales. Para poder recibir dicho dinero los delincuentes utilizan unas personas intermedias llamadas mulas o muleros.

Una mula o mulero, en el contexto de delitos informáticos, es una persona que actúa de intermedia entre las víctimas y los criminales. El modus operandi es el siguiente: mediante diferentes técnicas se convence a personas de que reciban una cantidad de dinero, quedándose un porcentaje de dicha cantidad. El resto del dinero deben enviarlo al destino que los delincuentes le indican, normalmente mediante compañías de envío internacional de dinero como MoneyTransfer, MoneyGram, Western Union, etc. Por ejemplo, una persona recibe 3000 euros, se queda con 600 euros, y los 2400 euros restantes los envía a un destino diferente.

El método tradicional de captación de mulas se realiza mediante el envío de correos electrónicos ofreciendo una oferta de empleo para trabajar desde casa, con una dedicación de pocas horas a la semana, flexibilidad horaria y con una suculenta compensación económica.

La oferta de trabajo tiene un aspecto similar al de la siguiente imagen:

Al igual que otras estafas de phishing, dependiendo de la capacidad de los criminales, este tipo de correos estará más elaborado o menos. Los correos más elaborados adornan este tipo de estafas con detalles de todo tipo de detalles como logotipos, explicaciones argumentadas o una página web de consulta (obviamente ilícita), por lo que a mayor complejidad de elaboración aumenta de forma proporcional la credibilidad por parte de las víctimas.

Sin embargo existen otras vías para captar muleros. Por ejemplo, se suelen mandar correos para captar colaboradores en campañas de ayuda para zonas afectas por crisis, guerras o desastres naturales. En estos casos, se solicitan a los muleros que colaboren como parte de la cadena de remisión de dinero a los damnificados. Deben proporcionar una cuenta de bancaria donde recibirán un importe económico donado por parte de particulares y empresas que deberán reenviar a los responsables de la organización humanitaria.

Una vez que los criminales han captado a las mulas, se establece una red con ellos con el fin de asegurar la disponibilidad para que se puedan realizar las transferencias. Las redes de mulas se utilizan de manera que se permita a los criminales distribuir y minimizar los riesgos. Realizar esto de forma distribuida asegura que si una mula se arrepiente y se queda con el total del dinero recibido (lo que en cualquier caso no parece una táctica muy recomendable) o las transferencias se detectan como fraudulentas, los criminales no pierdan el total del dinero estafado.

Los muleros son un factor fundamental en la cadena de ejecución de este tipo de delitos, ya que sin su colaboración el dinero robado no se puede materializar y llegar a mano de los criminales.

Muchos muleros es muy probable que no sepan que se trata de una estafa, por lo que aunque son víctimas, pero en el momento que colaboran con los criminales se convierten en estafadores, cómplices y culpables del delito.

La entrada El estafador estafado aparece primero en Security Art Work.

En la anterior entrada analizamos ciertas características estáticas que nos daban una idea de lo que hace o lo que podría llegar a hacer la librería. Ahora en esta segunda entrada vamos a analizar las funciones que exporta la librería. Para el análisis estático de la librería nos vamos a apoyar en las herramientas radare2, pestudio y ollydbg.

Como ya vimos en la anterior entrada con la herramienta PEstudio se exportan cinco funciones:

Ordinal 1: 0x000013F4

La primera que vamos a analizar es la función que está situada en el offset 0x000013F4 y que tiene como ordinal el número 1:

Como vemos, lo que hace la función es devolver un puntero que está almacenado en la dirección de memoria 0x1002f010+4. Si miramos qué hay en esa dirección vemos que lo que el puntero nos devolverá es lo siguiente:

La dirección devuelta es 0x10001148. En entradas posteriores analizaremos lo que hay en esta dirección. Por tanto, esta función devuelve un puntero a esta dirección: 0x10001148.

Ordinal 2: 0x000013DD

La segunda función que analizamos es la situada en el offset 0x000013DD y que tiene como ordinal el 2. Vemos como en el caso anterior el código de la función:

La función devuelve 1 en el caso de que se ejecute con éxito y ahora vamos a ver cada una de las funciones que llama. La primera que llama es 0x10001bb2:

Esta función reserva memoria en la dirección 0x1002F6C8 y copia 20 bytes desde el puntero pasado como argumento a la función.

La siguiente función  que se llama desde el código es 0x10001ca9:

Después de haber avanzado en el análisis de la función se ha visto como en su interior se llama a otra función (0x10026e10) a la que se le pasa como argumento la dirección 0x1002f024, lugar donde se ubicará código descifrado.

En la función 0x10026e10 vemos primero de todo que se utiliza el algoritmo de cifrado RC5 o RC6 para descifrar información (tal y como nos advierten en https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf).

Un aspecto destacado es la utilización de las constantes 0xb7e15163 y 0x61c88647. Si buscamos en Google estas dos constantes, sobretodo la primera, vemos como se relaciona rápidamente con los algoritmos de cifrado RC5/RC6 (esto ya nos lo advierten en el propio pdf anterior “Equation_group_questions_and_answers.pdf” en la pregunta 15; una pena haber leído a posteriori este detalle). En el artículo nos indican como el grupo Equation utiliza estas constantes, y nos explican que utilizar la constante 0x61c88647 con una resta no es algo habitual.  A continuación vemos las constantes en la función:

Visto que la función tiene esta capacidad, nos interesa ver dónde descifra la información y qué información descifra. Haciendo un análisis de la función vemos que el punto donde guarda el resultado en memoria es en el punto resaltado en rojo en la siguiente imagen:

Para obtener qué está descifrando utilizamos ollydbg y vemos en el punto al que hacemos referencia arriba cómo se ha descifrado una porción de memoria:

Las cadenas de interés descifradas que podemos ver en la zona de memoria son:

• “SYSTEM\CurrentControlSet\Control\Session Manager\MemSubSys”
• win32m.sys

Por tanto esta función lo que hace es descifrar una determinada información que probablemente sea utilizada por otras partes de la librería.

Ordinal 3: 0x000013F0

Esta función es muy simple y devuelve un 1 cuando se le invoca:

Ordinal 4: 0x00001408

A la función 4 se le pasa un puntero y a partir de ahí se inicializan los siguientes words con los valores: [0, 3, 1, 0x10000]:

Según los informes que hay por la red, todo apunta a que se trata del código de versión de la DLL.

Ordinal 5: 0x00001425

Por último analizamos la función 5 que recibe dos parámetros, el primero el puntero donde se va a realizar la copia de la cadena 0x80ab y el segundo parece ser el que activa que se realice esa copia.

Con este pequeño análisis ya tenemos una idea de lo que hacen las funciones que exporta la librería. En la próxima entrada nos centraremos en la función que maneja el interface de comandos.

La entrada Análisis de nls_933w.dll (II) aparece primero en Security Art Work.

En esta nueva entrega vamos a ver una técnica para detectar un debugger sin recurrir a librerías del sistema como ocurría en las entregas anteriores (ver la anterior y la primera). Se basa en un concepto muy simple para detectar el “step-by-step” (paso a paso) cuando se está analizando la aplicación dentro de un debugger.

Como ya sabemos, la mayoría de los debuggers permiten avanzar de forma diferente en la ejecución del programa. Por ejemplo, en OllyDbg:

• Run (F9) → Ejecuta el programa hasta llegar al final o hasta encontrar una interrupción.
• Step into (F7) → Ejecuta una sentencia del programa cada vez (“step-by-step”).
• Step over (F8)→ Ejecuta el programa sin entrar a analizar las funciones (calls)
• etc. (Ver menú “Debug”)

Cuando analizamos una aplicación, lo normal es que en alguna sección que consideremos importante o crítica nos detengamos a analizarla con detalle. En estos casos, la ejecución “step-by-step” nos facilita el trabajo. Ahora supongamos el siguiente código de alto nivel:

t1=time();
//sección critica
for (i=0;i<100;i++)
{
   código;
}
t2=time();
t3=t2-t1;

Primero se calcula el tiempo actual (t1), posteriormente se ejecuta una sección de código de la aplicación, se vuelve a calcular el tiempo actual (t2) y por último, se obtiene la diferencia de ambos tiempos (t3). En una ejecución normal de la aplicación, el tiempo total empleado en ejecutar el código intermedio (sección crítica) entre las funciones de tiempo es X. Si se ejecutara en un debugger y avanzáramos paso a paso a través del código intermedio, el tiempo total sería mucho mayor que X.

De esta forma, podemos estimar el tiempo medio de ejecución de esa sección de código en condiciones normales; si el tiempo empleado es mucho mayor, puede que la aplicación esté siendo debuggeada y, entonces, procedemos a realizar las acciones pertinentes para dificultar el análisis.

A continuación se presenta el código del crackme en lenguaje C:

/*****************************************************************
* File:		crackme03_GetTickCount.c
* Description:	Es un crackme que implementa la protección 
* 		anti-debugging basada en la función GetTickCount()
* Date: 	06/07/2015
* Author: 	reverc0de
* Twitter:	@reverc0de
* Site:		www.reverc0de.com
* Github:	https://github.com/reverc0de/saw-anti-debugging	
*****************************************************************/
#include 
#include 

int main(void)
{
unsigned long t1,t2,t3;
	int i,x;
	t1 = GetTickCount(); //Tiempo en milisegundos
	//Código intermedio
	for (i=0;i<10000000;i++)
	{
		x = i; //Código de relleno
	}
	t2 = GetTickCount(); //Tiempo en milisegundos
	t3 = t2-t1; //Tiempo empleado
	printf("t1: \t%ld\nt2: \t%ld\nt2-t1: \t%ld",t1,t2,t3);
	//Si el tiempo empleado es mayor a 100 ms, entonces está siendo debuggeado
	if (t3 > 100) 
	{
		MessageBox(0, "Debugger detectado!!","Crackme03 GetTickCount",MB_OK);
		exit(0);
	}	
	MessageBox(0, "Debugger NO detectado!!","Crackme03 GetTickCount",MB_OK);
	return 0;
}

El crackme utiliza la función “GetTickCount()()” de la API de Windows para el cálculo de los tiempos. Esta función devuelve el número de milisegundos desde que se arrancó el sistema (uptime).

Se ha estimado que el tiempo necesario para consumir el bucle no lleva más de 100 ms, por lo que si el tiempo final es superior, el mensaje con “Debugger detectado!!” será mostrado.

Al igual que en las entradas anteriores, podéis descargar el crackme ya compilado y los sources en la carpeta “crackme03_GetTickCount” del repositorio:

• https://github.com/reverc0de/saw-anti-debugging

Una vez descargado el binario “crackme03_GetTickCount.exe” lo ejecutamos, obteniendo los siguientes resultados:

El tiempo total de ejecución ha sido de 46ms y, como está por debajo de los 100 ms estimados como máximo, el mensaje mostrado es el correcto, ya que no se está debuggeando.

Ahora vamos a cargar el crackme en OllyDbg. Si ejecutamos la aplicación con F9, los resultados son similares a si se ejecuta fuera del debugger. Efectivamente, el crackme no ha detectado el debugger, pero esta técnica se basa en la detección del “step-by-step” del debugger. Para mostrarlo, vamos a establecer los siguientes breakpoints:

Address         Descripción
0040153B       GetTickCount, t1
0040155A       Salto bucle for
00401561       GetTickCount, t2
00401594       Comparación tiempos
00401598       Salto condicional

Ejecutamos la aplicación con F9 y se detendrá en el primer breakpoint donde obtiene el tiempo actual (t1). A continuación de esta función de tiempo se encuentra la implementación del bucle “for”. Se puede ver como se incrementa el contador en 1 hasta llegar al valor de 9999999 (0x98967f).

Si a partir de aquí avanzamos paso a paso con F7, lo que hacemos es interrumpir la ejecución normal del programa y el tiempo que perdamos en recorrer las sentencias del bucle se irá incrementando hasta superar con creces el tiempo de 100 ms.

Después se encuentra de nuevo la función “GetTickCount()” (t2). Acto seguido calcula la diferencia de tiempos (t3) y los muestra con la función “printf()”.

Ahora, en la dirección 00401594 donde teníamos otro breakpoint, se puede ver cómo realiza la operación de comparación de la diferencia de tiempos (t3) y 100 ms (0x64).

El resultado de esta operación actualiza el valor del flag “Z” poniéndolo a 0. “CMP” establece “Z=0” si los operandos son distintos, y “Z=1” si son iguales.

El mensaje mostrado viene definido por el salto condicional que se encuentra en la siguiente sentencia (“JBE”). “JBE” salta a la dirección indicada (en este caso, hacia el mensaje de debugger no detectado) si los flags “Carry (C)” o “Zero (Z)” están activados. En nuestro caso ambos flags están a 0, por lo tanto, el salto no se realiza y se muestra el mensaje de debugger detectado.

Al igual que en los crackmes anteriores, podemos modificar el tipo de salto para evadir esta protección. No vamos a entrar en más detalles ya que el proceso se ha visto en las entregas anteriores.

Consideraciones a tener en cuenta:

• Si no se realiza un análisis “step-by-step” de la sección crítica de código, o si no se realiza una interrupción por un breakpoint dentro de la sección crítica, entonces no se detectará el debugger.
• La sección crítica puede ser cualquier código de relleno, o bien, código necesario de la aplicación propenso a ser analizado detenidamente.
• Es conveniente complementar esta técnica con alguna más, así mejoramos la probabilidad de detectar el análisis.
• El tiempo estimado para ejecutar la sección crítica debe ser lo suficientemente amplio para que se ejecute en diferentes ordenadores de forma normal.
• Hemos usado la función “GetTickCount()” de la API de Windows, pero podría haberse implementado con otras funciones propias del lenguaje C, por ejemplo, mediante la librería “time.h”.
• “GetTickCount()” tiene ciertas limitaciones, por ejemplo, se limita a un uptime del sistema de máximo 49,7 días. Además, no es recomendable su uso para calcular tiempos demasiado precisos, su precisión se encuentra entre 10-16 ms, pero suficientes para nuestra prueba de concepto.

La entrada Jugando con técnicas anti-debugging (III) aparece primero en Security Art Work.

En éste mi primer post, os hablaré acerca de cómo poner en práctica las habilidades de hacking de una persona. Para ello existen múltiples plataformas que permiten que cualquiera mediante una serie de desafíos con diferentes niveles de dificultad, obtenga una visión de su nivel en cuanto a habilidades de seguridad informática se refiere.

¿Qué son las competiciones “Capture The Flag”?

Capturar la bandera (CTF por sus siglas en inglés) son un tipo de competiciones de seguridad informática que se realizan de manera online, orientadas tanto para aprendices como para expertos en seguridad de todo el mundo. Abordan un amplio rango de aspectos de seguridad como:

• Criptografía
• Análisis binario
• Ingeniería inversa
• Explotación web
• Seguridad de dispositivos móviles
• etc.

Los estilos más comunes de juego en estas competiciones son dos aunque hay muchos más:

Jeopardy

En este juego existen diferentes desafíos dentro de un amplio rango de categorías con variación de puntos en cada uno de ellos. Los equipos ganan puntos por cada desafío resuelto, los cuales suelen incluir encontrar algún tipo de prueba (bandera) que demuestre que se ha resuelto el desafío, como por ejemplo un string de texto. Algunas de las categorías son web-exploits, forense, criptografía, etc.

Cuanto más difícil sea el desafío más puntos se consiguen con su resolución. Cuando la competición termina se hace la suma de puntos, la cual será la que determine la posición de cada jugador en el ranking.

Las competiciones más famosas en cuanto a este estilo son DEFCON y CSAW.

Attack-Defense

Estas competiciones suelen variar pero casi siempre incluyen una defensa de la red. A cada equipo se le proporciona un servidor/red y debe defenderlo contra ataques, los cuales pueden provenir de los organizadores de la competición o también de otros equipos participantes. Los puntos serán conseguidos cuanto mejor defiendas los servicios y la propia red. A veces en estas competiciones se espera que los participantes ataquen y defiendan a la vez. Para probar que se ha ganado la competición, el equipo ganador habrá de conseguir la contraseña root del servidor objetivo, ésta es considerada la bandera en la competición.

Una de las competiciones más famosas es CCDC.

Otros

Hay muchos otros tipos de juegos, aunque los más famosos son los dos anteriores. Por ejemplo, otra competición es la que se conoce como King of the Hill donde los equipos intentan ganar el control de un servidor vulnerable y mantenerlo en su propiedad frente a otros atacantes durante el máximo tiempo posible. Cuanto más tiempo se tenga el control del servidor, más puntos se consiguen.

También me gustaría comentar que además de estas plataformas online se pueden entrenar las habilidades en seguridad informática siguiendo las instrucciones de libros como “The Hacking Playbook 2” y de tutoriales en formato vídeo como los que se pueden encontrar en SecurityTube.

Aunque en estos casos tan solo se tiene que seguir los diferentes pasos para lograr el objetivo en práctica, los más curiosos intentan lograr el mismo objetivo tomando diferentes caminos y consiguiendo unos mejores resultados e incluso llegando más lejos que siguiendo las instrucciones, enriqueciendo así sus habilidades ante estos desafíos.

Para finalizar y como resumen, las personas interesadas en el mundo hacking tienen una oportunidad de probar todas sus técnicas en un entorno controlado debido a que en este tipo de competiciones las organizaciones establecen diversas reglas de juego para controlar el correcto funcionamiento de la competición. El incumplimiento de esas reglas son penadas con la exclusión del participante, por ejemplo conductas destructivas o ataques de Denegación de Servicio, entre otras.

Desde este post queremos animaros a participar en estas competiciones con el objetivo de desarrollar vuestras habilidades y a la vez de pasar un buen rato, además de conocer gente del mundillo haciendo que cualquier participante se empape de sabiduría.

Os dejo algunos links para más información, relacionados con CTF:

• En este link podréis encontrar diferentes competiciones en las que podréis participar.
• En este otro encontrareis una lista de links para practicar vuestras habilidades.

PD: Me encantaría que los lectores con experiencia en estas plataformas o en estas competiciones escriban su opinión para tener mejores referencias y enriquecer este post, con el objetivo de que salgamos todos beneficiados.

La entrada Capture The Flag aparece primero en Security Art Work.

A menudo cuando se analiza el tráfico de red, podemos encontrarnos patrones pertenecientes a los ya conocidos Angler EK, Nuclear EK y Magnitude EK.

Normalmente vendidos en el mercado negro, un Exploit Kit (EK) es un conjunto de herramientas que automatiza la explotación de vulnerabilidades en el cliente, dirigidas a navegadores y plugins que un sitio web puede invocar como Adobe Flash Player, Microsoft Silverlight, Adobe Reader, Java, etc., para infectar equipos mientras se navega por Internet en lo que se llama drive-by download attacks.

Dichos patrones pueden ser detectados por reglas de snort como:

ET CURRENT_EVENTS Cushion Redirection
ET CURRENT_EVENTS Possible Nuclear EK Landing URI Struct T1
ET CURRENT_EVENTS Malvertising Redirection to Exploit Kit Aug 07 2014
ET CURRENT_EVENTS DRIVEBY Nuclear EK Landing May 23 2014

Después, analizando los logs de navegación para averiguar si el equipo ha sido infectado, podemos encontrar situaciones parecidas a esta:

(1) 1431XXXXXX.176   2212 X.X.X.X TCP_MISS/200 59981 GET http://oapsnschmelzsicherung.xxxxxxxx.com/xxxx_xxxxx_stubbornness_uprise/500125099916354311 - ROUNDROBIN_PARENT/ X.X.X.X text/html

(2) 1431XXXXXX.284    351 X.X.X.X TCP_MISS/200 40950 GET http://oapsnschmelzsicherung.xxxxxxxx.com/gUumBTs1ZmB5LXoesyPvFlZqU014qtKBap7VY3eJbtxXK81S - ROUNDROBIN_PARENT/ X.X.X.X application/x-shockwave-flash

(3) 1431XXXXXX.736   1569 X.X.X.X TCP_MISS/200 163950 GET http://oapsnschmelzsicherung.xxxxxxxx.com/Wb_gLKuEtf9-CCiAvIAtEVGnHsOrDIlvJjYBsAo-s2AJ8yv0 - ROUNDROBIN_PARENT/ X.X.X.X application/octet-stream

Como podemos observar, el navegador del usuario contacta con una web (1) que carga un objeto flash (2). Este objeto flash intenta explotar alguna vulnerabilidad de Adobe Flash Player y si lo consigue, descarga un fichero binario que resulta ser un bicho malo-malísimo (3) que es ejecutado, quedando el equipo infectado.

Pero, ¿siempre siguen este patrón? Últimamente, nos hemos encontrado en nuestro SOC el siguiente patrón perteneciente a Nuclear EK:

(1) 1431XXXXXX.948   2932 X.X.X.X TCP_MISS/200 745 GET http://6kfhhj1sfip7aht5erua5xi.xxxxxxxx.org/index.php? - ROUNDROBIN_PARENT/X.X.X.X text/html

(2) 1431XXXXXX.495   1495 X.X.X.X TCP_MISS/302 509 GET http://6kfhhj1sfip7aht5erua5xi.xxxxxxxx.org/watch.php? - ROUNDROBIN_PARENT/X.X.X.X text/html

(3) 1431XXXXXX.228    730 X.X.X.X TCP_MISS/200 7005 GET http://6kfhhj1sfip7aht5erua5xi.xxxxxxxx.org/SE4AHwUeBFxWC1oIA0RWCkJVU19EVlcQR1YFG1tMVVZXBFcMU0IdEFcQRF5DChwNQFA.html - ROUNDROBIN_PARENT/X.X.X.X text/html

(4) 1431XXXXXX.140    856 X.X.X.X TCP_MISS/200 19268 GET http://6kfhhj1sfip7aht5erua5xi.xxxxxxxx.org/V09AH0gbAksHHwYeBFxWC1oIA0RWCkJVU19EVlcQR1YFG1tMVVZXBFcMU0IdEFcQRF5DChwNQFBMUQNQHAMJTQNUBhkCU05TBgQBUwVUAgQDH1QOAQ - ROUNDROBIN_PARENT/X.X.X.X application/octet-stream

(5) 1431XXXXXX.833    985 X.X.X.X TCP_MISS/200 25634 GET http://6kfhhj1sfip7aht5erua5xi.xxxxxxxx.org/V09BYHT6dy87JNDTYGE5KIdehJHS98bHUJ5wcrNQFBMU5aQNQH2Tase44FJUSGDJFGfhO45MAHdfRAIROAMJsTNUBhkCU05TBgSHY1Ahg3JFYE7HCT - ROUNDROBIN_PARENT/X.X.X.X application/octet-stream

Observamos unos contactos con páginas html (1)(2)(3) y descarga de un par de ficheros binarios (4)(5), pero no encontramos el objeto utilizado para explotar alguna vulnerabilidad que infecte el equipo. ¿Cómo lo han hecho? ¿Acaso el usuario ha descargado conscientemente el ejecutable? O… ¿el objeto no está identificado correctamente por el proxy?

Para poder estudiarlo detenidamente, se ha buscado un ejemplo similar a este caso en malware-traffic-analysis.net donde podemos descargar un fichero PCAP para el análisis; ejemplo #1.

Al abrir el fichero PCAP con Wireshark, podemos filtrar por http y comprobar que el patrón es similar al detectado por nosotros:

(1)
-> GET http://on2wyqlx7ny7x9plbfu6vg7.filmizlemefullhd.org/index.php?p=enhwZmJhPWFpeWhvcGsmdGltZT0xNTAyMTExNjM4MzYyNzYyODQ1NCZzcmM9MTc3JnN1cmw9d3d3LnByaW1laGVhbHRoY2hhbm5lbC5jb20mc3BvcnQ9ODAma2V5PTU5QUU1QzE3JnN1cmk9Lw==
<- HTTP/1.1 200 OK

(2)
-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/watch.php?kcppp=MTE3NzU5ODg2Nzk3NjRlY2M0MmJiNDk3M2NmZGVkM2Fl
<- HTTP/1.1 302 Found, Location: http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html

(3)
-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html
<- HTTP/1.1 200 OK

(4)
-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs
<- HTTP/1.1 200 OK

(5)
-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BV4NBkQDAQ9SHwMfBh1SDFcCDwBRBVcHHVUOSwABAE0FUBlQUg0ZBkVnFHwARhgzRFc
<- HTTP/1.1 200 OK

Ahora podemos analizar el código HTML de cada página para entender su funcionamiento extrayéndolas con Wireshark desde File / Export Objects / HTTP.

En el próximo post, analizaremos estos ficheros.

¡Saludos!

La entrada Destripando Nuclear EK (I) aparece primero en Security Art Work.

vFeed es una herramienta muy interesante de ToolsWatch que recolecta información sobre vulnerabilidades utilizando multitud de fuentes; entre otras:

• Estándares de seguridad, como CVE, CWE, CPE, OVAL, CAPEC, CVSS, etc.
• Herramientas de explotación y auditoría de vulnerabilidades, como Nessus, NMap, Metasploit, etc., así como páginas web y bases de datos de seguridad ofensiva, como milw0rm o Exploit-DB
• Alertas de fabricantes: Red Hat, Microsoft, Cisco, Debian, etc.
• Firmas de sistemas IDS, como Snort o Suricata

El resultado es una base de datos SQLite que agrega y relaciona toda esta información a través del identificador CVE de una vulnerabilidad determinada, de modo que contando, por ejemplo, con el identificador de un script de la herramienta Nessus, es posible obtener toda la información disponible en el resto de fuentes de información: exploits disponibles en Metasploit o Exploit-DB, alertas de fabricantes relacionadas con la vulnerabilidad en cuestión, posibles firmas de sistemas IDS que nos permitan detectar un intento de explotación de la misma, etc.

Esta base de datos es gratuita, y puede descargarse y consultarse a través de una API en Python, disponible en GitHub:

$ wget https://github.com/toolswatch/vFeed/archive/master.zip

$ unzip master.zip 
Archive:  master.zip
4992a98cb8fb8b95c69e1387bc51554722802bca
   creating: vFeed-master/
  inflating: vFeed-master/.gitignore  
  inflating: vFeed-master/CHANGELOG.rst  
  inflating: vFeed-master/LICENSE    
  inflating: vFeed-master/README.rst  
   creating: vFeed-master/docs/
 extracting: vFeed-master/docs/read.me  
  inflating: vFeed-master/docs/vFeedApi User Guide - beta release.pdf  
   creating: vFeed-master/vfeed/
  inflating: vFeed-master/vfeed/__init__.py  
  inflating: vFeed-master/vfeed/api.py  
  inflating: vFeed-master/vfeed/config.py  
  inflating: vFeed-master/vfeed/exportxml.py  
  inflating: vFeed-master/vfeed/info.py  
  inflating: vFeed-master/vfeed/search.py  
  inflating: vFeed-master/vfeed/stats.py  
  inflating: vFeed-master/vfeed/update.py  
  inflating: vFeed-master/vfeed_calls_samples.py  
  inflating: vFeed-master/vfeedcli.py  

$ cd vFeed-master/

El script vfeedcli.py facilita el acceso a la misma funcionalidad disponible a través de la API directamente desde la línea de comandos:

$ ./vfeedcli.py 

-----------------------------------------------------------------------------
vFeed - Open Source Cross-linked and Aggregated Local Vulnerability Database
                                                               version 0.5.0
                                         https://github.com/toolswatch/vFeed
-----------------------------------------------------------------------------

[usage 1]: python ./vfeedcli.py  
[info] Available vFeed methods:
Information  ==> get_cve | get_cpe | get_cwe | get_capec | get_category
References   ==> get_refs | get_scip | get_osvdb | get_certvn | get_bid | get_iavm
Risk         ==> get_risk | get_cvss
Patchs 1/2   ==> get_ms | get_kb | get_aixapar | get_redhat | get_suse | get_debian | get_hp
Patchs 2/2   ==> get_mandriva | get_cisco | get_ubuntu | get_gentoo | get_fedora | get_vmware
Assessment   ==> get_oval | get_nmap | get_nessus | get_openvas 
Defense      ==> get_snort | get_suricata
Exploitation ==> get_milw0rm | get_edb | get_saint | get_msf | get_d2

----------
[usage 2]: python ./vfeedcli.py export 
[info]: This method will export the CVE as vFeed XML format

----------
[usage 3]: python ./vfeedcli.py search  | 
[info]: This method searches for CVE or CPE. It returns useful information that will help 
        you dig deeper.

----------
[usage 4]: python ./vfeedcli.py stats or latest_cve
[info]: Available stats methods
Global statistics   ==> get_stats
Latest Added CVEs   ==> get_latest 

----------
[Update]: python ./vfeedcli.py update
[info]: This method will update the SQLite vfeed database to its latest release

Los nombres de las opciones se corresponden con cada uno de los métodos de la API. Para descargar la base de datos SQLite, se utiliza la opción update:

$ ./vfeedcli.py update
[install] getting fresh copy of vfeed.db. It may take a while ...
[progress 100 %] receiving 45324199 out of 45324199 Bytes of vfeed.db.tgz 
[info] decompressing vfeed.db.tgz ...
[info] Cleaning compressed database and update file

La base de datos, una vez descargada y descomprimida, pesa unos 223 MB a fecha del presente.

$ file vfeed.db 
vfeed.db: SQLite 3.x database

$ du -h vfeed.db 
223M    vfeed.db

Para hacernos una idea de toda la información contenida en la misma, podemos utilizar el método get_stats:

$ ./vfeedcli.py get_stats
---------------------------------------------------------------
vFeed.db Statistics
Distinct values of CVEs and associated third party references
Database build (latest update date): 7162015
---------------------------------------------------------------

[+] Vulnerability Information and References
    [-] Common Vulnerability Enumeration (CVE): 71016
    [-] Affected Products or Common Platform Enumeration (CPE): 175873
    [-] Common Weakness Enumeration (CWE) types: 496
    [-] Common Attack Pattern Enumeration and Classification (CAPEC) types: 226
    [-] SecurityFocus BID: 32980
    [-] OSVDB - Open Source Vulnerability Database advisories: 22370
    [-] CERT.org Vulnerability Notes: 4184
    [-] DOD-CERT Information Assurance Vulnerability Alert (IAVA): 1168
    [-] Scip AG Security Advisories: 72941

[+] Third Party Vendors Patches and Advisories
    [-] IBM AIX APARs Patches Advisories: 1996
    [-] Suse Patches Advisories: 2154
    [-] Ubuntu Patches Advisories: 1826
    [-] VMware Patches Advisories: 84
    [-] Cisco Patches Advisories: 716
    [-] Debian Patches Advisories: 2949
    [-] Fedora Patches Advisories: 2714
    [-] Gentoo Patches Advisories: 1410
    [-] HP (Hewlett Packard) Patches Advisories: 1969
    [-] Mandriva Patches Advisories: 1697
    [-] Microsoft Bulletins Advisories: 1321
    [-] Microsoft KB Advisories: 2132
    [-] Redhat Patches Advisories: 4306
    [-] Redhat Bugzilla Advisories: 12464

[+] Exploits and Proof of Concepts
    [-] Exploit-DB Proof of Concepts and exploits: 2886
    [-] Metasploit Exploits or Modules: 1360
    [-] Milw0rm Proof of Concepts and exploits: 5560
    [-] Saint Corporation Proof of Concepts and exploits: 944
    [-] D2 Elliot Web Exploitation Framework: 34

[+] Third Party Security Scanners Scripts
    [-] Nessus Security Scripts: 49679
    [-] OpenVAS Security Scripts: 27101
    [-] Nmap NSE scripts: 34
    [-] Open Vulnerability Assessment Language (OVAL) definitions: 26127

[+] Open Source Intrusion Detection Rules
    [-] Snort Detection Rules: 1333
    [-] Suricata Detection Rules: 5020

Como se observa, la cantidad de información recogida es ingente, y toda relacionada entre sí a través del identificador CVE de las vulnerabilidades.

Por ejemplo, para la vulnerabilidad de Flash CVE-2015-3113, podríamos obtener una descripción básica y fechas de publicación y modificación:

$ ./vfeedcli.py get_cve CVE-2015-3113
[cve_description]: Heap-based buffer overflow in Adobe Flash Player before 13.0.
0.296 and 14.x through 18.x before 18.0.0.194 on Windows and OS X and before 11.
2.202.468 on Linux allows remote attackers to execute arbitrary code via unspeci
fied vectors, as exploited in the wild in June 2015.
[cve_published]: 2015-06-23T17:59:01.960-04:00
[cve_modified]: 2015-06-24T14:58:37.283-04:00

Enlaces o referencias de interés relacionadas con la vulnerabilidad:

$ ./vfeedcli.py get_refs CVE-2015-3113
 ------- 
[reference_id]: CONFIRM
[reference_link] https://helpx.adobe.com/security/products/flash-player/apsb15-14.html

[stats] 1 Reference(s)

Reglas para Snort o Suricata (en este caso la BD sólo tiene referencias a una regla de Suricata, pero tratándose de una regla ET está también disponible para Snort:

$ ./vfeedcli.py get_snort CVE-2015-3113

[stats] 0 Snort Rule(s)

$ ./vfeedcli.py get_suricata CVE-2015-3113
 ------- 
[suricata_id]: sid:2021364
[suricata_signature]: ET CURRENT_EVENTS Magnitude CVE-2015-3113 Jun 29 2015 M1
[suricata_classtype]: trojan-activity

[stats] 1 Suricata Rule(s)

También podemos obtener los scripts de Nessus, y exploits para Metasploit o de otras fuentes:

$ ./vfeedcli.py get_nessus CVE-2015-3113
 ------- 
[nessus_id]: 84365
[nessus_name]: Adobe Flash Player <= 18.0.0.161 RCE (APSB15-14)
[nessus_file]: flash_player_apsb15-14.nasl
[nessus_family]: Windows
 ------- 
[nessus_id]: 84383
[nessus_name]: FreeBSD : Adobe Flash Player -- critical vulnerabilities (d02f6b0
1-1a3f-11e5-8bd6-c485083ca99c)
[nessus_file]: freebsd_pkg_d02f6b011a3f11e58bd6c485083ca99c.nasl
[nessus_family]: FreeBSD Local Security Checks
 ------- 
[...]
[stats] 8 Nessus testing script(s)

$ ./vfeedcli.py get_msf CVE-2015-3113
 ------- 
[msf_id]: adobe_flash_nellymoser_bof.rb
[msf_title]: Adobe Flash Player Nellymoser Audio Decoding Buffer Overflow
[msf_file]: metasploit-framework/modules/exploits/multi/browser/adobe_flash_nellymoser_bof.rb

[stats] 1 Metasploit Exploits/Plugins

$ ./vfeedcli.py get_edb CVE-2015-3113
 ------- 
[edb_id]: 37536
[edb_file]: platforms/multiple/remote/37536.rb
[edb_link]: http://www.exploit-db.com/exploits/37536

[stats] 1 ExploitDB id(s)

Red Hat habría publicado un boletín de seguridad, el RHSA-2015:1184, relacionado con esta vulnerabilidad, así como un parche disponible en su Bugzilla:

$ ./vfeedcli.py get_redhat CVE-2015-3113
 ------- 
[redhat_id]: RHSA-2015:1184
[redhat_patch_title]: RHSA-2015:1184: flash-plugin security update (Critical)
[redhat_oval_id]: oval:com.redhat.rhsa:def:20151184

[stats] 1 Redhat id(s)
 ------- 
[redhat_bugzilla_issued]: 2015-06-24
[redhat_bugzilla_id]: 1235036
[redhat_bugzilla_title]: CVE-2015-3113 flash-plugin: code execution issue fixed in APSB15-14

[stats] 1 Bugzilla id(s)

Como último ejemplo, también sería posible obtener métricas CVSS sobre el riesgo asociado a la vulnerabilidad:

$ ./vfeedcli.py get_risk CVE-2015-3113
Severity: High
Top vulnerablity: True
    [cvss_base]: 10.0
    [cvss_impact]: 10.0
    [cvss_exploit]: 10.0
PCI compliance: Failed
is Top alert: 

$ ./vfeedcli.py get_cvss CVE-2015-3113
[cvss_base]: 10.0
[cvss_impact]: 10.0
[cvss_exploit]: 10.0
[AV (access vector)]: network
[AC (access complexity)]: low
[Au (authentication)]: none
[C (confidentiality impact)]: complete
[I (integrity impact)]: complete
[A (availability impact)]: complete

Una de las ventajas de vFeed con respecto a otras bases de datos es que es descargable al completo, por lo que todas las consultas se pueden realizar offline (lo cuál puede venir bien por ejemplo en un pentest).

Como se ha mencionado, el uso de la API en Python es análogo a las opciones de la herramienta CLI. Basta con obtener una instancia de la clase vFeed, asociándola a una vulnerabilidad concreta a través del identificador CVE, y ya es posible realizar todas las consultas anteriores, con la ventaja de que los resultados ya vienen devueltos como estructuras de datos de Python, lo que permite procesarlos cómodamente. Por ejemplo, para la vulnerabilidad GHOST:

$ python
Python S.2.g
Type "help", "copyright", "credits" or "license" for more information.

>>> from vfeed import vFeed

>>> vfeed = vFeed("CVE-2015-0235")

>>> vfeed.get_cve()
{'published': '2015-01-28T14:59:00.063-05:00', 'modified':
'2015-07-05T21:59:37.363-04:00', 'summary': 'Heap-based buffer
overflow in the __nss_hostname_digits_dots function in glibc 2.2,
and other 2.x versions before 2.18, allows context-dependent
attackers to execute arbitrary code via vectors related to
the (1) gethostbyname or (2) gethostbyname2 function, aka "GHOST."'}

>>> vfeed.get_snort()
{}

>>> vfeed.get_suricata()
{0: {'classtype': 'attempted-admin', 'id': 'sid:2020325',
'signature': 'ET EXPLOIT CVE-2015-0235 Exim Buffer Overflow
Attempt (HELO)'}, 1: {'classtype': 'attempted-admin',
'id': 'sid:2020326', 'signature': 'ET EXPLOIT CVE-2015-0235
Exim Buffer Overflow Attempt (EHLO)'}}

>>> vfeed.get_msf()
{0: {'id': 'wordpress_ghost_scanner.rb', 'file':
'metasploit-framework/modules/auxiliary/scanner/http/
wordpress_ghost_scanner.rb', 'title': 'CP Multi-View
Calendar Unauthenticated SQL Injection Scanner'},
1: {'id': 'exim_gethostbyname_bof.rb', 'file':
'metasploit-framework/modules/exploits/linux/smtp/
exim_gethostbyname_bof.rb', 'title':
'Exim and Dovecot Insecure Configuration Command
Injection'}}

>>> vfeed.get_nessus()
{0: {'family': 'Amazon Linux Local Security Checks', 'id': '81024',
'file': 'ala_ALAS-2015-473.nasl', 'name': 'Amazon Linux AMI :
glibc (ALAS-2015-473)'}, 1: {'family': 'Amazon Linux Local
Security Checks', 'id': '81829', 'file': 'ala_ALAS-2015-493.nasl',
'name': 'Amazon Linux AMI : php54 (ALAS-2015-493)'}, 2: {'family':
'Amazon Linux Local Security Checks', 'id': '82043', 'file':
'ala_ALAS-2015-494.nasl', 'name': 'Amazon Linux AMI : php55
(ALAS-2015-494)'}, 3: {'family': 'CentOS Local Security Checks',
'id': '81025', 'file': 'centos_RHSA-2015-0090.nasl'
[...]

Otra opción extremadamente potente es realizar las consultas directamente sobre la base de datos SQLite. Por ejemplo, podría interesarnos obtener todas las correspondencias entre plugins de Nessus y SID de Snort o Suricata, para implementar una vulnerability / intrusion detection crosscorrelation en nuestro correlador o nuestro SIEM. Lo tendríamos hecho con una simple consulta:

echo 'select nvd_db.cveid, map_cve_suricata.suricata_id,
    map_cve_nessus.nessus_script_id from nvd_db join
    map_cve_suricata on nvd_db.cveid = map_cve_suricata.cveid
    join map_cve_nessus on map_cve_suricata.cveid =
    map_cve_nessus.cveid;' | sqlite3.db > suricata-nessus-xcorrelation.txt

$ head suricata-nessus-xcorrelation.txt 
CVE-2003-0813|sid:2494|12206
CVE-2003-0813|sid:2494|21655
CVE-2003-0352|sid:2352|11790
CVE-2003-0352|sid:2352|11808
CVE-2003-0352|sid:2351|11790
CVE-2003-0352|sid:2351|11808
CVE-2003-0813|sid:2495|12206
CVE-2003-0813|sid:2495|21655
CVE-2003-0813|sid:2492|12206
CVE-2003-0813|sid:2492|21655

$ wc -l suricata-nessus-xcorrelation.txt 
12816 suricata-nessus-xcorrelation.txt

Algo así nos permitiría dar prioridad a las alertas IDS detectadas contra un activo que sabemos que es vulnerable (funcionalidad habitual en los SIEM y correladores). Aunque hay muchos otros métodos de obtener este tipo de correspondencias IDS/vulnerabilidades, contar con una fuente adicional para enriquecer la información, vFeed en este caso, siempre viene bien.

Otra cosa muy interesante que puede hacerse con vFeed es explotar la información de la CPE (Common Platform Enumeration), que también viene relacionada con las vulnerabilidades a través de los correspondientes identificadores CVE. Esto posibilita, por ejemplo, estudiar tendencias sobre determinadas plataformas o tecnologías.

sqlite> select count(distinct cpeid) from cve_cpe where cpeid
like '%:microsoft:%';
2348

sqlite> select count(distinct cpeid) from cve_cpe where cpeid
like '%:redhat:%'; 
1702

sqlite> select count(distinct cpeid) from cve_cpe where cpeid
like '%:adobe:flash_player:%';
316

sqlite> select count(*) from cve_cpe where cpeid
like '%:adobe:flash_player:%';
25787

Por ejemplo, podríamos obtener la cantidad de vulnerabilidades de Flash publicadas cada mes:

$ echo 'select strftime("%Y-%m", date_published) as day_month,
    count(distinct cve_cpe.cveid) from cve_cpe, nvd_db
    where cve_cpe.cveid = nvd_db.cveid and cpeid
    like "%:adobe:flash_player:%"
    group by day_month order by day_month;' | sqlite3 vfeed.db 
2005-12|1
2006-07|2
2006-09|2
2006-10|1
[...]

O para Java JRE:

$ echo 'select strftime("%Y-%m", date_published) as day_month,
    count(distinct cve_cpe.cveid) from cve_cpe, nvd_db
    where cve_cpe.cveid = nvd_db.cveid and
    (cpeid like "%:sun:jre:%" or cpeid like "%:oracle:jre:%")
    group by day_month order by day_month;' | sqlite3 vfeed.db
2001-08|1
2001-12|1
2002-03|2
2002-12|1
2003-11|1
[...]

Por ejemplo, en septiembre y octubre de 2014 se observa un pico en la cantidad de vulnerabilidades (en general, de cualquier tecnología) publicadas:

$ echo 'select strftime("%Y-%m", date_published) as day_month,
    count(distinct cveid) from nvd_db where
    date_published > "2008-01-01"
    group by day_month order by day_month;' | sqlite3

Se podría hacer un estudio similar sobre cualquier área de interés. Por ejemplo... ¿Vulnerabilidades asociadas a fabricantes de sistemas de control industrial?

vFeed puede ser útil también en pentests (complementando la información que Metasploit o Nessus ya agregan en conjunto), a la hora de redactar nuestros informes (para ampliar la información de cada vulnerabilidad con el resto de los datos obtenidos de las demás fuentes presentes en la base de datos), y un sinfín más...

La entrada vFeed: una BD de vulnerabilidades aparece primero en Security Art Work.

En el anterior post, conseguimos un ejemplo del caso a tratar. Teniendo los ficheros HTML extraídos con Wireshark, comenzamos su análisis.

(1) index.php

Simple; redirecciona sí o sí a (2) http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/watch.php?kcppp=MTE3NzU5ODg2Nzk3NjRlY2M0MmJiNDk3M2NmZGVkM2Fl.

(2) watch.php

El servidor responde a la petición del cliente:

HTTP/1.1 302 Found
Server: nginx/1.4.3
Date: Wed, 11 Feb 2015 16:39:20 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Expires: Wed, 11 Feb 2015 16:39:20 +0000
Location: http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html

De nuevo éste es redireccionado. Esta vez a (3) http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/BQdXBkRUTQg.html

Esta técnica se llama Cushion Redirection y consiste en obligar al cliente a dar saltos pudiendo de esta manera evadir filtros de navegación.

(3) BQdXBkRUTQg.html

No queda otra. Éste es el fichero HTML que tiene la chicha. En él encontramos texto sin sentido y código javascript claramente ofuscado.

Directamente vamos a desofuscar el código javascript y ver qué se cuece en su interior.

Una vez desofuscado, se comprueba que el objeto que explota la vulnerabilidad –en este caso hay varios pero nos centraremos en el objeto Flash– está siendo llamado desde un segundo javascript embebido en el código HTML y ofuscado en el texto, a priori, carente de sentido.

Este javascript, carga en tiempo de ejecución el objeto flash (4) Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs

-> GET http://zvqumcs1tsfct4sjvzot3p9.filmtane.com/Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs
<- HTTP/1.1 200 OK

Pasándole como parámetro FlashVars el string “exec=N3NNYPWYYgX3YW...” que actúa como parte del payload para el exploit.

NOTA: Debemos darnos cuenta que estos Exploit Kit se hacen para que sean lo más dinámicos posible y vender el mayor número de ellos. De esta manera, únicamente hay que cambiar esta parte del payload para que se adapte a las exigencias del comprador.

Antes de dejarlo por hoy, hay que preguntarse: si se está llamando a un objeto flash, ¿por qué el proxy lo detecta como tipo application/octet-stream y no como application/x-shockwave-flash?

En el próximo post, veremos por qué.

¡Saludos!

La entrada Destripando Nuclear EK (II) aparece primero en Security Art Work.

Subir escaleras, caminar, correr, dormir,… son algunas de las actividades que hoy en día monitorizamos. O “nos monitorizan”. Gran parte de los smartphones registran, por defecto, una parte de la actividad física que realiza el usuario, donde se registra –además- el día y la hora en que se realiza y en algunos casos incluso la ubicación donde se ha realizado. Pero hoy en día hay otro tipo de dispositivos que también registran este tipo de actividad y son más cómodos “de llevar”. Estos son los wearable, que como sabemos son pequeños dispositivos que “llevamos puestos” como pueden ser relojes, pulseras, gafas inteligentes, sensores en zapatillas, etc.

Desde luego, en muchos casos la información que registran estos dispositivos es muy útil. Más ahora que existe el síndrome “runner” y tantísimas personas practican este deporte. Los más avanzados utilizan relojes GPS que registran la velocidad, el ritmo, el recorrido y otras variables. Otros utilizan los smartphones con aplicaciones que también registran la actividad del corredor y además la mayoría permiten publicar en tiempo real esta información, así como la situación en el mapa de nuestro “atleta”. Es de sobra sabido que quien publica esta información se expone a que cualquier persona esté viendo lo que está haciendo, dónde está e incluso si mantiene una rutina, se la está dando a conocer para que la utilice a discreción.

Pero dejando a un lado la necesidad o no de obtener esta información (eso ya se lo leímos a Eusebio en “Corredores o Robocops”) debemos ser conscientes de la información que facilitamos. Aunque se pueden publicar los datos como hemos comentado, lo general es que esta información se mantenga privada y para acceder a ella sea necesario hacerlo desde el propio dispositivo o también, como sucede en la mayoría de ellos, a través de una plataforma web con un componente social. Generalmente para acceder a ésta es necesario acceder con unas credenciales de usuario/password.

Uno de los tipos de wearable más utilizados actualmente por la información que proporcionan y por su precio asequible (en comparación con la mayoría de pulsómetros) son las pulseras de actividad. Y sobre éstas quisiera contar una noticia que he leído y que me ha llamado la atención. Podría valer cualquier historia de las situaciones de cualquier saga de Antonio Sanz que os recomiendo leer, pero en primer lugar quería poneros en escenario del caso.

Imaginad un caso en el que una persona después de un fatídico accidente solicita un plus en la indemnización al supuesto autor de los hechos, porque debido al accidente no puede seguir realizando la misma actividad física que llevaba antes del suceso, ya que era una persona muy activa. Pensaréis… ¿cómo puede demostrarlo? ¿Quién sabe la actividad física que realizaba antes de ese momento? Podríamos pensar que como en todo juicio o denuncia, se citan unos testigos que dan su testimonio pero… ¿podría haber otro elemento probatorio? Sí, lo que estáis pensando: su pulsera de actividad. Al menos así lo pensaron los miembros de un prestigioso bufete de abogados de Canadá que solicitaron aportar como prueba de la actividad de su representado la información que su pulsera de actividad había registrado tanto antes como después del accidente.

¿Hasta qué punto es probatoria o podría ser relevante (o simplemente aceptada) este tipo de tecnología en un juicio? Desconozco la parte jurídica, pero este hecho es un caso más que pone de manifiesto cómo la tecnología está presente en todos los ámbitos de nuestra vida. Bien es cierto que el hecho de la actividad de una pulsera, e incluso la geolocalización de un dispositivo móvil, por sí mismos no demuestran que el portador de cualquier de estos dispositivos sea la persona afectada… a no ser que haya otras pruebas que lo corroboren, pero desde luego sí que es un elemento más de juicio y que puede llegar a ser determinante.

Este hecho me hace pensar la cantidad de dispositivos que almacenan información sobre nuestra rutina o actividad diaria (y entre otros me refiero a nuestros smartphones) y que en un caso puntual puede ser utilizada a nuestro favor o, quién sabe si de forma malintencionada… en nuestra contra.

La entrada Los wearable como testigo aparece primero en Security Art Work.

A finales del año pasado lanzamos a través de la cuenta de Twitter de @securityartwork una iniciativa para recopilar un listado de novelas o relatos relacionados con el mundo de la ciberseguridad. Pedimos a sus seguidores que hiciesen sus recomendaciones literarias tuiteando con el hashtag #novelaseguridad.

Hoy os traemos esta lista actualizada con las recomendaciones que habéis ido enviando. Os damos las gracias por vuestra colaboración y os animamos a seguir enviando vuestros tuits con más recomendaciones. El recopilatorio es de lo más interesante:

Probablemente aún sigan faltando muchos más títulos interesantes, pero éste es un listado de lo más apetecible para el que le interese este tipo de género. Como ya os hemos dicho, si queréis hacer vuestra aportación al listado os invitamos a que lo tuiteeis con el hashtag #novelaseguridad o bien lo añadáis en comentarios del post. Seguiremos actualizando la lista.

¿Cuál vais a leer este verano?

La entrada Actualización de novelas para adictos a la ciberseguridad #novelaseguridad aparece primero en Security Art Work.

(Ver partes I y II de esta serie)

En el anterior post nos quedamos a punto de saber porqué el proxy no identifica el objeto Flash como application/x-shockwave-flash. Veamos.

(4) Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs

Extraemos el objeto Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs desde Wireshark y comprobamos de qué tipo de fichero se trata:

$ file Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs 
Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs: data

$ file --mime Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs 
Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs: application/octet-stream; charset=binary

$ hexdump Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs -n128 -C
00000000  5a 57 53 17 ad 23 00 00  3a 21 00 00 5d 00 00 20  |ZWS..#..:!..].. |
00000010  00 00 3b ff fc 8e 19 fa  df e7 66 08 a0 3d 3e 85  |..;.......f..=>.|
00000020  f5 75 6f d0 7e 61 35 1b  1a 8b 16 4d df 05 32 fe  |.uo.~a5....M..2.|
00000030  a4 4c 46 49 b7 7b 6b 75  f9 2b 5c 37 29 0b 91 37  |.LFI.{ku.+\7)..7|
00000040  01 37 0e e9 f2 e1 fc 9e  64 da 6c 11 21 33 ed a0  |.7......d.l.!3..|
00000050  0e 76 70 a0 cd 98 2e 76  80 f0 e0 59 56 06 08 e9  |.vp....v...YV...|
00000060  ca eb a2 c6 db 5a 86 7b  47 de 99 5d 68 76 38 16  |.....Z.{G..]hv8.|
00000070  bd 93 3c d3 d0 9e d3 55  63 5a da b0 db 27 e6 7c  |..<....UcZ...'.||
 00000080
 

¡ZWS! Resulta que el fichero flash SWF ha sido comprimido usando el estándar LZMA para evitar la detección del exploit por parte de los antivirus. ¡Por eso el proxy no lo identifica correctamente!

Una vez solucionada nuestra duda… ¿y si seguimos investigando sobre este tipo de ficheros Flash?

Una búsqueda rápida en Google nos ofrece resultados de cómo podemos descomprimirlo y obtener el fichero flash original. En particular, me quedé con el primer resultado: swfzip.

$ python swfzip.py Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs exploit.swf
info : Input file: Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs
info : Output file: exploit.swf
info : Reading Bk8RH15VB1xLUk5SS1BXClYHDgVUBlNLV1UWVAkOGVQBTQZQVkQDXQs
info : lzma compressed swf detected.
info : Filesize in signature: 9133
info : Filesize decompressed: 9133
info : Generating uncompressed data
info : Compressing with zlib
info : Packing zlib header
info : Generating compressed data
File compressed with zlib, size decreased: -2% 

Notice: Recompressing may cause filesize increased

$ file exploit.swf 
exploit.swf : Macromedia Flash data (compressed), version 23

$ file --mime exploit.swf 
exploit.swf: application/x-shockwave-flash; charset=binary

$ hexdump exploit.swf -n128 -C
00000000  43 57 53 17 ad 23 00 00  78 9c 9d 7a 67 54 93 5b  |CWS..#..x..zgT.[|
00000010  b7 6e 12 08 a1 f7 de 3b  4a 0d 21 74 90 de 9b f4  |.n.....;J.!t....|
00000020  22 3d 24 10 3a 49 e8 20  45 8a 74 41 a4 29 82 20  |"=$.:I. E.tA.). |
00000030  4d 10 10 50 01 51 aa 80  28 4d 94 de 41 a5 89 74  |M..P.Q..(M..A..t|
00000040  e9 dc b8 f7 be e7 3b fb  dc 3b ee 8f bb fe ac 77  |......;..;.....w|
00000050  cd f2 cc 39 9f 39 b3 92  31 de 84 00 08 97 01 00  |...9.9..1.......|
00000060  ca 72 00 80 19 08 d0 a4  61 01 00 00 51 74 41 40  |.r......a...QtA@|
00000070  00 40 49 25 c4 c7 9b 3b  08 89 c1 a2 fd 7c 95 79  |.@I%...;.....|.y|
00000080

$ ./uncompress.sh exploit.swf 
uncompressing to ./uncompressed_exploit.swf

$ file uncompressed_exploit.swf 
uncompressed_exploit.swf : Macromedia Flash data, version 23

$ file --mime uncompressed_exploit.swf 
uncompressed_exploit.swf: application/x-shockwave-flash; charset=binary

$ hexdump uncompressed_exploit.swf -n128 -C
00000000  46 57 53 17 ad 23 00 00  78 00 04 e2 00 00 0e a6  |FWS..#..x.......|
00000010  00 00 18 01 00 44 11 19  00 00 00 7f 13 76 01 00  |.....D.......v..|
00000020  00 3c 3f 78 6d 6c 20 76  65 72 73 69 6f 6e 3d 22  |...    

¡Ahora sí! Una vez que tenemos el fichero SWF original, podemos decompilarlo con cualquier herramienta para este propósito, como el decompilador online http://www.showmycode.com/ obteniendo el código fuente en ActionScript del Flash.

NOTA: Para este caso usamos un editor online por comodidad y porque el fichero Flash es de acceso público. Para una investigación privada, es recomendable usar un decompilador de escritorio.

Con una ligera lectura del código, podemos entendemos que algo raro pasa. Tiene muy poca cosa, algo no cuadra.

Resulta que en ActionScript 3 es posible incrustar archivos SWF en un ByteArray y ejecutar este SWF en tiempo de ejecución. Además, para añadir una capa más de protección a este fichero incrustado, puede ser cifrado mediante operaciones XOR. Todo este proceso se puede aplicar tantas veces como se quiera, añadiendo numerosas capas de ofuscación y complicando enormemente el trabajo al analista. El fichero SWF decodificado, y por lo tanto el exploit en sí, solo existe en memoria, lo que podría dificultar la tarea de detección a un antivirus.

Más información sobre este método: http://www.veryinteractivepeople.com/?p=67

Pero, ¿podremos extraer el exploit y saber qué vulnerabilidad utiliza? Lo veremos en el siguiente post.

¡Saludos!

La entrada Destripando Nuclear EK (III) aparece primero en Security Art Work.

BRO es una herramienta open-source para el análisis de tráfico de red cuyo objetivo es reconocer actividades sospechosas.

El análisis de red reporta varios tipos de registros divididos según el protocolo y características como puede ser HTTP, DNS, SSL, FTP, sesiones IRC, SMTP, etc.

Para la captura de paquetes utiliza libpcap. Es capaz de analizar y detectar túneles (incluyendo Ayiya, Teredo, GTPv1) además de desencapsularlos para luego analizar su contenido.

Arquitectura

Se basa en dos componentes:

1. Motor de eventos (event engine): Reduce el flujo de paquetes, organizándolos para ser llevados a un nivel superior.
2. Interprete de Scripts (policy script interpreter): acciones a tomar cuando se detecta una actividad determinada.

Instalación

(La instalación se ha hecho en un sistema Debian Wheezy)

apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev libgeoip-dev
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
gunzip GeoLiteCity.dat.gz
cp GeoLiteCity.dat /usr/share/GeoIP/GeoIP

cd /usr/local/src
http://download.savannah.gnu.org/releases/libunwind/libunwind-1.1.tar.gz
tar -xvzf libunwind-1.1.tar.gz
cd libunwind-1.1
./configure && make && make install

wget https://googledrive.com/host/0B6NtGsLhIcf7MWxMMF9JdTN3UVk/gperftools-2.3.90.tar.gz
tar xzf gperftools-2.3.90.tar.gz
./configure && make && make install

wget  https://www.bro.org/downloads/release/bro-2.4.tar.gz 
tar -xvzf bro-2.4.tar.gz
cd bro-2.4
./configure –enable-perftool
make
make install
export PATH=/usr/local/bro/bin:$PATH

BroControl

BroControl es una shell interactiva para el manejo de BRO que tiene dos modos de operación:

1. stand alone: para administrar BRO de forma habitual (un nodo).
2. cluster mode: múltiples nodos actuando en conjunto para conseguir balanceo de la carga (BRO es mono-núcleo y puede trabajar con varios nodos para repartir el trabajo).

Instalación de broctl (modo stand alone):

cd /usr/local/bro/bin
python broctl install
creating policy directories ...
installing site policies ...
generating standalone-layout.bro ...
generating local-networks.bro ...
generating broctl-config.bro ...
generating broctl-config.sh ...
updating nodes ...

Ejecución de broctl:

./usr/local/bro/bin/broctl
Welcome to BroControl 1.4
Type "help" for help.

La primera vez que se usa broctl es recomendable usar el comando deploy (chequea la configuración de BRO: broctl.cfg, node.cfg y networks.cfg). El resto de veces se puede usar el comando start, pero si los ficheros de configuración nombrados antes se modifican, se deberá usar deploy.

[BroControl] > deploy
checking configurations ...
installing ...
removing old policies in /usr/local/bro/spool/installed-scripts-do-not-touch/site ...
removing old policies in /usr/local/bro/spool/installed-scripts-do-not-touch/auto ...
creating policy directories ...
installing site policies ...
generating standalone-layout.bro ...
generating local-networks.bro ...
generating broctl-config.bro ...
generating broctl-config.sh ...
updating nodes ...
stopping ...
bro not running
starting ...
starting bro ...

Comando status para ver el estado de BRO:

[BroControl] > status
Getting process status ...
Getting peer status ...
Name         Type       Host          Status    Pid    Peers  Started
bro          standalone localhost     running   31540  0      08 Jul 16:02:43

Para ver los scripts:

[BroControl] > scripts

 /usr/local/bro/share/bro/base/files/x509/__load__.bro
 /usr/local/bro/share/bro/base/files/x509/main.bro
 /usr/local/bro/share/bro/base/files/hash/__load__.bro
 /usr/local/bro/share/bro/base/files/hash/main.bro

 [...]

Ver estadísticas de tráfico de red:

[BroControl] > capstats

Interface             kpps       mbps       (10s average)
----------------------------------------
localhost/eth0        0.0        0.0

Mostrar la configuración:

[BroControl] > config
bindir = /usr/local/bro/bin
bro = /usr/local/bro/bin/bro
bro-expect-running = True
bro-host = localhost
bro-pid = 31540
bro-port = 47760
broargs = 
brobase = /usr/local/bro
[…]

En el caso de tener varios nodos en funcionamiento, se pueden detallar con el siguiente comando (en este caso solo muestra uno, el propio del equipo):

BroControl] > nodes
bro - addr=::1 aux_scripts= brobase= count=1 env_vars= ether= host=localhost interface=eth0 lb_interfaces= lb_method= lb_procs= name=bro pin_cpus= test_mykey= type=standalone zone_id=

Name         Type       Host          Pid     Proc    VSize  Rss  Cpu   Cmd
bro          standalone localhost     31540   parent  184M    45M  25%  bro
bro          standalone localhost     31542   child    97M    37M   0%  bro

Con el comando stop paramos la captura. Aquí se muestra la lista de procesos, una vez ejecutada la captura en BroControl:

ps aux|grep bro

root     11505  0.0  0.0  10812  1544 ?        S    13:16   0:00 /bin/bash /usr/local/bro/share/broctl/scripts/run-bro -1 -i eth0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto
root     11511 33.4  1.1 179304 45584 ?        Rl   13:16   1:54 /usr/local/bro/bin/bro -i eth0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto
root     11513  0.0  0.9  95296 38196 ?        SN   13:16   0:00 /usr/local/bro/bin/bro -i eth0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto

Para ver los log que se están capturando en tiempo real hay que visualizar el contenido de logs/current:

ls -l /usr/local/bro/logs/current/

-rw-r--r-- 1 root root   593 jul  9 13:16 communication.log
-rw-r--r-- 1 root root 14786 jul  9 13:23 conn.log
-rw-r--r-- 1 root root   384 jul  9 13:21 dhcp.log
-rw-r--r-- 1 root root 11056 jul  9 13:23 dns.log
-rw-r--r-- 1 root root  1185 jul  9 13:20 files.log
-rw-r--r-- 1 root root   327 jul  9 13:21 known_services.log
-rw-r--r-- 1 root root 20008 jul  9 13:16 loaded_scripts.log
-rw-r--r-- 1 root root   226 jul  9 13:16 packet_filter.log
-rw-r--r-- 1 root root   667 jul  9 13:16 reporter.log
-rw-r--r-- 1 root root    46 jul  9 13:16 stderr.log
-rw-r--r-- 1 root root   188 jul  9 13:16 stdout.log
-rw-r--r-- 1 root root  1918 jul  9 13:23 weird.log
-rw-r--r-- 1 root root   985 jul  9 13:20 x509.log

Una vez parada la captura los guarda en una carpeta con el nombre de la fecha y el día en /usr/local/bro/logs/ de forma comprimida:

ls /usr/local/bro/logs/2015-07-08/

communication.16:02:43-16:25:20.log.gz  dhcp.16:09:28-16:25:20.log.gz  http.16:11:55-16:25:20.log.gz     notice.16:22:43-16:25:20.log.gz   ssl.16:06:12-16:25:20.log.gz
conn.16:02:58-16:25:20.log.gz    dns.16:03:12-16:25:20.log.gz
[…]

Bro se puede lanzar de forma manual sin ayuda de BroControl, eligiendo las redes internas y la interfaz de la siguiente forma:

/usr/local/bro/bin/bro -ieth0 local "Site::local_nets += {192.168.1.0/24, 192.168.101.0/24, 172.10.0.0/16}"

Otra forma es definir primero las redes internas en el siguiente fichero:

vi /usr/local/bro/share/bro/site/local.bro

# This script detects DNS results pointing toward your Site::local_nets
# where the name is not part of your local DNS zone and is being hosted
# externally.  Requires that the Site::local_zones variable is defined.
@load protocols/dns/detect-external-names

redef Site::local_nets = {
        10.0.0.0/8,     # Red privada.
        192.168.0.0/16, # Red privada.
        172.16.0.0/12,  # Red privada.
};

También se puede definir la interfaz de captura y el tipo (standalone, es decir un solo nodo):

vi /usr/local/bro/etc/node.cfg

# This is a complete standalone configuration.  Most likely you will
# only need to change the interface.
[bro]
type=standalone
host=localhost
interface=eth0

Tipos de logs:

• conn-log: todas las conexiones vistas.
• notice.log: todas las conexiones potencialmente interesantes reorganizadas por BRO.

Políticas, directivas y plugins

Dentro de /usr/local/bro/share/bro/site/local.bro es donde se indica qué plugins, políticas y scripts van a ser cargados en el inicio. Se hace con la clausula “@load“. Por ejemplo, para cargar un script propio (en este caso, estando en el directorio /usr/local/bro/share/bro/site/, cargamos el fichero custom_script.bro):

@load custom_script

Existen muchos scripts en internet hechos por la comunidad, que se pueden descargar por ejemplo de:

• https://github.com/bro/bro-scripts
• https://github.com/trending?l=bro

Las políticas se dividen en frameworks, integration, misc, protocols y tuning. Se encuentran en /usr/local/bro/share/bro/policy/. Estas políticas deciden qué se captura (HTTP, DNS, RDP…) y cómo se captura el tráfico (búsqueda de patrones, reglas, etc…).

Las opciones generales de BRO se pueden configurar en /usr/local/bro/etc/broctl.cfg.

Además, BroControl tiene la posibilidad de integración de plugins escritos en python, que se encuentran en /usr/local/bro/lib/broctl/plugins. Éstos sirven para realizar acciones determinadas en BroControl antes o después de ejecutar una orden o crear nuestros propios comandos.

Visualización de Log

Para visualizar los logs se puede usar awk o bro-cut (/usr/local/bro/bin/bro-cut). En los ejemplos se usa bro-cut para facilitar la tarea. Con esta herramienta podemos visualizar las columnas que interesen y en el orden elegido de entre aquellas que aparecen al inicio del log:

1. conn.log

zcat /usr/local/bro/logs/2015-07-09/conn.17:31:55-17:35:26.log.gz|/usr/local/bro/bin/bro-cut ts id.orig_h id.orig_p id.resp_h id.resp_p proto orig_bytes|more 

1436455895.486565  172.20.3.31  5353   224.0.0.251    5353  udp  214
1436455895.486769  172.20.3.16  5353   224.0.0.251    5353  udp  214
1436455905.935003  172.20.3.31  42754  172.20.1.10      53  udp  86
1436455914.932816  172.20.3.31  49904  172.20.1.10      53  udp  84
1436455923.120296  172.20.3.31  56397  216.58.210.163  443  tcp  0
1436455918.937119  172.20.3.31  40130  172.20.1.10      53  udp  84
1436455931.674040  172.20.3.31  58464  216.58.211.206  443  tcp  711
1436455936.634502  172.20.3.31  51913  192.168.4.47   7272  tcp  10702
[…]

2. Resumen de conexiones

zcat /usr/local/bro/logs/2015-07-09/conn-summary.17:31:55-17:35:26.log.gz

>== Outgoing === 2015-07-09-17-31-31 - 2015-07-09-17-35-19
 - Connections  503.0 - Payload 958.1k - 
  Ports        | Sources                   | Destinations                 | Services        | Protocols     | States          |
  53     36.0% | 172.20.3.12#1       57.5% | 172.20.1.10#2          34.4% | -         47.1% | 6       51.9% | S0        40.6% | 
  80     34.2% | 172.20.3.31#3       36.0% | 255.255.255.255#4       4.0% | dns       38.8% | 17      47.5% | SHR       29.2% | 
  443    19.1% | 172.20.3.100#5       3.6% | 216.58.210.206#6        2.8% | http       2.1% | 1        0.6% | OTH       27.6% | 
  10001   3.6% | 172.20.3.16#7        1.2% | 216.58.210.198#8        2.2% | ssl        1.8% |           | SH             1.6% | 
  137     1.4% | 172.20.3.23#9        0.6% | 185.31.18.130#10        2.2% | dhcp       0.2% |           […]

3. DHCP

zcat /usr/local/bro/logs/2015-07-09/dhcp.13:21:06-13:47:10.log.gz

ts          uid  id.orig_h    id.orig_p    id.resp_h  id.resp_p  mac        assigned_ip  lease_time  trans_id

1436440866.978188  CD77rR2aoVO9fEPWp2  172.20.3.12  68  172.20.3.253  67  00:1b:bc:81:b3:89  172.20.3.12  7200.000000  3917337635
[...]

4. DNS

zcat /usr/local/bro/logs/2015-07-09/dns.17:31:38-17:35:26.log.gz|/usr/local/bro/bin/bro-cut ts id.orig_h id.orig_p id.resp_h id.resp_p query qclass qclass_name rcode_name TTLs |more 

1436456086.318043  172.20.3.12  31573  172.20.1.10  53  s0.cyberciti.org  -  -  NOERROR  86400.000000,60.000000,60.000000,60.000000,60.000000,60.000000,60.000000,60.000000,60.000000
1436456086.231939  172.20.3.12  25209  172.20.1.10  53  pagead2.googlesyndication.com  -  -  NOERROR  16.000000,16.000000
1436456086.816385  172.20.3.12  14904  172.20.1.10  53  bid.g.doubleclick.net  -  -  NOERROR  80549.000000,215.000000
1436456086.805647  172.20.3.12   6982  172.20.1.10  53  cas.fr.eu.criteo.com  -  -  NOERROR  789.000000
1436456086.816392  172.20.3.12  45815  172.20.1.10  53  cas.nl.eu.criteo.com  -  -  NOERROR  788.000000
1436456086.805911  172.20.3.12  56462  172.20.1.10  53  cm.g.doubleclick.net  -  -  NOERROR  80177.000000,262.000000
1436456086.805626  172.20.3.12  22517  172.20.1.10  53  fonts.googleapis.com  -  -  NOERROR  3039.000000,127.000000
[…]

5. HTTP (con la opción bro-cut –d la fecha se transforma el formato Epoc a human time):

zcat /usr/local/bro/logs/2015-07-09/http.17:32:26-17:35:26.log.gz|/usr/local/bro/bin/bro-cut -d ts id.orig_h id.orig_p id.resp_h id.resp_p method host uri referrer user_agent filename username password  |more 

2015-07-09T17:32:21+0200  172.20.3.31  42323  193.110.128.199  80  GET  www.marca.com  /  -  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36  -  --
2015-07-09T17:32:22+0200  172.20.3.31  44682  154.53.129.51  80  GET  estaticos03.marca.com  /deporte/img/v3.0/marca-apuestas.png  http://www.marca.com/  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
 Gecko) Chrome/43.0.2357.130 Safari/537.36  -  -  -
2015-07-09T17:32:22+0200  172.20.3.31  44682  154.53.129.51  80  GET  estaticos03.marca.com  /imagenes/2015/07/09/futbol/equipos/barcelona/1436427993_extras_portada_0.jpg  http://www.marca.com/  Mozilla/5.0 (X11; Linux
 x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36  -  -  -
2015-07-09T17:32:25+0200  172.20.3.31  44682  154.53.129.51  80  GET  estaticos03.marca.com  /deporte/img/v3.0/opinion/espanasemueve.jpg  http://estaticos03.marca.com/deporte/css/v3.1/portada_todos.css  Mozilla/5.0 (X1
1; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36  -  -  -
2015-07-09T17:32:25+0200  172.20.3.31  44682  154.53.129.51  80  GET  estaticos03.marca.com  /deporte/img/v3.0/1px_zonainferior_sindivision.gif  http://estaticos03.marca.com/deporte/css/v3.1/portada_todos.css  Mozilla
/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36  -  -  -
[…]

6. Software

zcat /usr/local/bro/logs/2015-07-09/software.17:32:21-17:35:26.log.gz |more

1436455941.576647  172.20.3.31  -  HTTP::BROWSER  Chrome  43  0  2357  130  -  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
1436456004.862866  172.20.3.31  -  HTTP::BROWSER  Chrome  43  0  2357  132  -  Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36

7. Ficheros

zcat /usr/local/bro/logs/2015-07-09/files.17:32:55-17:35:26.log.gz|/usr/local/bro/bin/bro-cut ts tx_hosts rx_hosts source analyzers mime_type filename total_bytes md5 extracted |more

1436456089.594059  185.31.19.133  172.20.3.12  SSL  X509,MD5,SHA1  application/pkix-cert  -  -  aaeepcf8b0d8596d2e0cbe67421cf7db  -
1436456089.597102  185.31.19.133  172.20.3.12  SSL  X509,MD5,SHA1  application/pkix-cert  -  -  9262sf3dfffe144f8b461c957e17f819  -
1436456089.597102  185.31.19.133  172.20.3.12  SSL  X509,MD5,SHA1  application/pkix-cert  -  -  aaeepcf8b0d8596d2e0cbe67421cf7db  -
1436456090.673853  85.31.217.175  172.20.3.12  HTTP  MD5,SHA1  image/jpeg  -  -  d2753665ae6cbb83d276fd0312c47bb9  -
1436456090.686528  216.58.210.206  172.20.3.12  HTTP  MD5,SHA1  application/javascript  f.txt  -  2677ave03fc503c1dfe50ed55c9ab45e  -
1436456091.049318  198.199.102.190  172.20.3.12  HTTP  MD5,SHA1  text/html  -  160  9f0b38c9a810496daebc8bd0894ad734  -
1436456091.347570  90.94.53.137  172.20.3.12  HTTP  MD5,SHA1  text/plain  -  -  adf5b8d2e96302466d849dee82703b1d  -
1436456092.071341  198.199.102.190  172.20.3.12  HTTP  MD5,SHA1  text/plain  -  581  727c0b2b9e9305115585ca7635affaff  -
1436456096.447983  74.86.144.194  172.20.3.12  HTTP  MD5,SHA1  image/x-icon  -  1150  7870256daf52ese443424357228f46e8  -
[…]

8. SSL

zcat /usr/local/bro/logs/2015-07-09/ssl.17:32:16-17:35:26.log.gz|/usr/local/bro/bin/bro-cut -d ts id.orig_h id.orig_p id.resp_h id.resp_p version cypher server_name established cert_chain_fuids|more 

2015-07-09T17:32:11+0200  172.20.3.31  58464  216.58.211.206  443  -    clients1.google.com  F  -
2015-07-09T17:32:16+0200  172.20.3.31  48987  173.194.45.87  443  -    www.google.es  F  -
2015-07-09T17:32:22+0200  172.20.3.31  37949  173.194.45.68  443  -    safebrowsing.google.com  F  -
2015-07-09T17:32:24+0200  172.20.3.31  57764  104.83.67.68  443  -    connect.facebook.net  F  -
2015-07-09T17:32:24+0200  172.20.3.31  47948  192.229.233.25  443  -    platform.twitter.com  F  -
2015-07-09T17:33:19+0200  172.20.3.31  56482  216.58.210.163  443  -    www.google.es  F  -
2015-07-09T17:35:00+0200  172.20.3.12  41520  199.96.57.7  443  TLSv11    -  F  FW3Cl5nRZj6aUmVXd,FforNn27NxJS9V6cR6
2015-07-09T17:35:00+0200  172.20.3.12  41519  199.96.57.7  443  TLSv11    -  F  FNcsSe3AXwIBMUXlnb,Fd0L5m1uPJlhShnRXe
2015-07-09T17:35:00+0200  172.20.3.12  41518  199.96.57.7  443  TLSv11    -  F  F48I5m4wbVFMygDXOf,FLirav3GLwGeMgfAb5
2015-07-09T17:35:01+0200  172.20.3.12  44298  199.96.57.6  443  TLSv11    -  F  -
2015-07-09T17:35:00+0200  172.20.3.12  41522  199.96.57.7  443  TLSv11    -  F  FgN1X14PABOund1CS9,FZ7zMm1hy2mzakroC1
2015-07-09T17:34:56+0200  172.20.3.12  54285  185.31.19.134  443  TLSv11    -  F  FYgMaa4Twxjkprxayj,FqAyHtKCG0D8qO5e6
2015-07-09T17:34:51+0200  172.20.3.12  57748  66.51.116.236  443  TLSv10    -  F  -
[...]

9. X509

zcat /usr/local/bro/logs/2015-07-09/x509.17:32:55-17:35:26.log.gz|/usr/local/bro/bin/bro-cut -d ts certificate.version certificate.serial certificate.subject certificate.issuer certificate.key_alg certificate.key_type certificate.key_length san.dnssan.urisan.emailsan.ipbasic_constraints.ca |more 

2015-07-09T17:32:55+0200  3  0C85CCFACE62F3DC  CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US  CN=Google Internet Authority G2,O=Google Inc,C=US  id-ecPublicKey  ecdsa  256  
2015-07-09T17:34:49+0200  3  27DEBBB719698B  CN=*.pleasantsolutions.com,OU=Domain Control Validated  CN=Starfield Secure Certificate Authority - G2,OU=http://certs.starfieldtech.com/repository/,O=Starfield Technologies\\, Inc.,L
=Scottsdale,ST=Arizona,C=US  rsaEncryption  rsa  2048  
2015-07-09T17:34:49+0200  3  0F8B2FB1A2840BE42DAADB14D9317C21  CN=www.github.com,O=Fastly\\, Inc.,ST=California,L=San Francisco,C=US  CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US  rsaEncryption  rsa  2048  
[…]

BRO IDS es un sistema de vigilancia muy completo ya que en una sola herramienta se tiene la posibilidad de capturar tráfico distinguiendo HTTP, SMTP, DNS, etc. Las posibilidades de BRO IDS son muchas, ya que existe una comunidad por detrás que desarrolla herramientas actuales, muy útiles para la detección de amenazas y además existe la opción de integración en sistemas de tratamiento de Log como ELK (Elasticsearch-Logstash-Kibana) o la inserción de logs en una base de datos al estilo de un PassiveDNS.

Fuentes:

• Seguridad y Redes.
• Documentación oficial.
• Comunidad.

La entrada BRO IDS: “el ojo que todo lo ve…” aparece primero en Security Art Work.

(Ver partes I, II y III de esta serie)

En el anterior post conseguimos obtener el SWF original, pero descubrimos que el exploit se encuentra incrustado en un ByteArray. ¿Conseguiremos extraerlo?

Primeramente necesitamos extraer el contenido almacenado por el ByteArray. Para ello, necesitamos un decompilador Flash de escritorio; Adobe SWF Investigator (It’s free!). Una vez instalado abrimos el último fichero obtenido: uncompressed_exploit.swf. Vamos a la ficha “Tag Viewer” y de todos los tags mostrados, seleccionamos “DefineBinaryData” y lo guardamos pulsando en “Dump to file” nombrado como “dump_exploit.bin”, por ejemplo.

Miramos el fichero “dump_exploit.bin” hexadecimalmente y nos fijamos en los tres primeros bytes, ya que si es un fichero Flash estos han de ser 5a 57 53 (ZWS) o 43 57 53 (CWS) o 46 57 53 (FWS) según lo que hemos estado viendo anteriormente.

$ hexdump dump_exploit.bin -n 3 -C
00000000  0e 03 07                                          |...|
00000003

Pero como sabemos, a estos bytes se les ha aplicado XOR para complicar su análisis. Según se ve en el código ActionScript, han usado el carácter “T” para realizar el cifrado XOR a cada byte. Por lo tanto, probamos a realizar la operación desde una consola Python con estos primeros bytes:

>>> ord("T") # Valor decimal en ASCII.
84
>>> chr(int('0x0e',16)^84) # 0x0e XOR 84
'Z'
>>> chr(int('0x03',16)^84) # 0x03 XOR 84
'W'
>>> chr(int('0x07',16)^84) # 0x07 XOT 84
'S'

‘Z’, ‘W’, ‘S’… ¿De qué nos suena? ¡Es un fichero SWF comprimido con LZMA como en la tercera parte de esta serie!

Rápidamente, desarrollamos un script que aplique XOR a todos los bytes del fichero binario.

#!/usr/bin/python
# -*- coding: utf-8 -*-

key = "T"
data_in = "dump_exploit.bin"
data_out = "out.bin"

file_in = open(data_in, "rb")
file_out = open(data_out, "wb")

while 1:
    byte = file_in.read(1) # Lectura byte a byte.
    if not byte: break
    xor = chr(int(hex(ord(byte)), 16) ^ ord(key)) # Aplica operación XOR.
    file_out.write(xor) # Guarda en un fichero el resultado de la operación.

file_in.close()
file_out.close()

Una vez ejecutado, obtenemos un fichero binario llamado “out.bin”.

$ file out.bin
out.bin: data

$ hexdump out.bin -n 128 -C
00000000  5a 57 53 17 f9 4d 00 00  f0 1b 00 00 5d 00 00 20  |ZWS..M......].. |
00000010  00 00 3b ff fc 8e 19 fa  df e7 66 08 a0 3d 3e 85  |..;.......f..=>.|
00000020  f5 75 6f d0 7e 61 35 1b  1a 8b 16 4d df 05 32 fe  |.uo.~a5....M..2.|
00000030  a4 4c 46 49 b7 7b 6b 75  f9 2b 5c 37 29 0b 91 37  |.LFI.{ku.+\7)..7|
00000040  01 37 0e e9 f2 e1 fc 9e  64 da 6c 11 21 33 ed a0  |.7......d.l.!3..|
00000050  0e 76 70 a0 cd 98 2e 76  80 f0 e0 59 56 06 08 e9  |.vp....v...YV...|
00000060  ca eb a2 c6 db 5a 86 7b  47 de 99 5d 68 76 38 16  |.....Z.{G..]hv8.|
00000070  bd 93 3c d3 d0 9e d3 55  63 5a da b0 db 27 e6 7c  |..<....UcZ...'.||
 0000008
 

Al tratarse de un caso similar al original (ver la tercera parte), se procede de la misma manera:

$ python swfzip.py out.bin exploit.swf
info : Input file: out.bin
info : Output file: exploit.swf
info : Reading out.bin
info : lzma compressed swf detected.
info : Filesize in signature: 19961
info : Filesize decompressed: 19961
info : Generating uncompressed data
info : Compressing with zlib
info : Packing zlib header
info : Generating compressed data
File compressed with zlib, size decreased: -21% 

Notice: Recompressing may cause filesize increased

$ file exploit.swf 
exploit.swf: Macromedia Flash data (compressed), version 23

$ ./uncompress.sh exploit.swf 
uncompressing to ./uncompressed_exploit.swf 
       
$ file uncompressed_exploit.swf 
uncompressed_exploit.swf : Macromedia Flash data, version 23

$ hexdump uncompressed_exploit.swf -n 128 -C
00000000  46 57 53 17 f9 4d 00 00  78 00 04 e2 00 00 0e a6  |FWS..M..x.......|
00000010  00 00 18 01 00 44 11 19  00 00 00 7f 13 76 01 00  |.....D.......v..|
00000020  00 3c 3f 78 6d 6c 20 76  65 72 73 69 6f 6e 3d 22  |...    

¡Tachán! ¡Ya tenemos el exploit! Vamos a decompilarlo usando de nuevo http://www.showmycode.com/ obteniendo el siguiente código ActionScript.

Le echamos un ojo y... ¡WOW! ¡Es una **** locura!

Investigando sobre el código, pueden observarse que hay varios métodos utilizados para comprobar la versión de Flash:

Normalmente, la comprobación de la versión de Flash se hace mediante funciones Javascript pero en este caso, al estar ejecutando este Flash directamente desde memoria, evades que un antivirus detecte dichos Javascripts durante la navegación.

Asimismo, vemos que lee los parámetros FlashVars y recoge la variable “exec”:

Ésta es procesada por diferentes métodos hasta llegar a uno usando como nombre de parámetro “url”. ¿Entonces la variable “exec” contiene la URL para la descarga del binario que realmente hace la infección del equipo?

Es una teoría, pero puede probarse fácilmente lanzando el exploit en un entorno vulnerable y modificando esta parte del payload desde HTML, viendo la solicitud que realiza.

Sin modificar el payload...

...se procede a ejecutar el exploit y éste realiza correctamente la petición de descarga a lo que es el bicho malo-malísimo (5) BV4NBkQDAQ9SHwMfBh1SDFcCDwBRBVcHHVUOSwABAE0FUBlQUg0ZBkVnFHwARhgzRFc

Pero ahora, si se modifica el payload cambiando unos cuantos bytes por otros...

...la solicitud cambia...

...quedando demostrada la teoría anterior.

Si se sigue tirando del hilo sobre el código, se llega a la parte más importante donde se observa que el exploit utilizado es el referente al CVE-2015-0311 el cual se explica detalladamente aquí.

Pueden verse el string “uncompress” y como genera el string “compress”...

...que son utilizados en las partes más críticas del exploit:

Y que como pueden verse, son muy similares al ejemplo enlazado más arriba. Finalmente, se puede subir alguno de los ficheros Flash a Virustotal y confirmar que el exploit utilizado es el correspondiente al CVE-2015-0311.

¡Saludos!

La entrada Destripando Nuclear EK (IV) aparece primero en Security Art Work.

En ocasiones cuando una organización decide mejorar la seguridad de su información se lanza de cabeza a por un SGSI, al cumplimiento de la LOPD, o directamente a implantar controles sobre sus activos, sin plantearse previamente qué es exactamente lo que necesita.

Los profesionales del mundo de la seguridad de la información insistimos en que la seguridad debe estar alineada con los objetivos del negocio, y esto es precisamente lo que un Plan Director de Seguridad (o PDS) se encarga de hacer: decidir lo que nuestra organización necesita en materia de seguridad.

¿Qué es un PDS?

No existe un ente u organismo oficial que establezca lo que es un PDS por lo que cada uno es libre de llevarlo a cabo como mejor considere.

Personalmente considero que esto es una ventaja ya que permite amoldar los PDS a la casuística de cada organización, pero a su vez hace que muchos traten de convertir su idea de PDS en la auténtica y verdadera senda a seguir creando confusión entre quienes no están familiarizados con el tema.

Maticemos que todo lo que contiene este post es mi visión particular, y que seguramente no coincida con otros planteamientos: un PDS es un plan que establece la hoja de ruta para mejorar la seguridad de la información.

Fin. Simplemente eso. Cualquier otra afirmación que hagamos acerca de lo que es un PDS nos impedirá poder crear un plan que se ajuste a las necesidades de negocio de cualquier organización.

¿Entonces un PDS no incluye implantar un SGSI?

Pues puede que sí, o puede que no.

¿Tiene sentido decir que un PDS por defecto incluirá la implantación de un SGSI? ¿Y una diferencial de la 27002? ¿O un pentest? Puede que nuestra organización ya tenga un SGSI, que esté alineada con otros estándares que no sean la 27002 o que no tenga servidores abiertos a Internet, por lo que no debemos cerrarnos a 4 puntos estándar.

Estamos de acuerdo en que una organización con un SGSI, con un buen nivel de madurez en los controles de la 27002 y con un plan de continuidad sólido, tendrá un buen nivel de seguridad por lo que seguramente será lo que nuestro PDS nos recomiende que hagamos, pero no lo asumamos como algo aplicable al 100% de los casos.

¿Cómo abordamos pues un PDS?

El PDS es un plan para mejorar la seguridad de la información, por lo que deberíamos empezar por saber cómo de seguros estamos y cómo de seguros queremos llegar a estar.

Dependiendo de cada organización este análisis cambiará:

• Es recomendable disponer de una política de seguridad que marque los objetivos de seguridad, lo cual nos ayudará enormemente a definir hasta dónde queremos llegar, aunque una declaración de intenciones por parte de dirección puede ser igualmente válida.
• Una organización que tenga claro que todo es un desastre, que su mayor problema son los continuos virus informáticos y la nula formación de sus usuarios, puede decidir rápidamente que la meta de su plan director de seguridad a corto plazo será securizar sus equipos y formar a los usuarios, y “luego ya veremos”. Esto también es un análisis para el PDS (poco ambicioso, pero lo es).
• Una organización con un nivel de seguridad medio que quiera un nivel de seguridad alto, seguramente necesite hacer un análisis de riesgos formal, un diferencial de la ISO27002 y un pentest exhaustivo para saber cómo de segura está, así como los niveles que es viable conseguir mediante un SGSI u otras soluciones.
• Una organización que ya disponga de un análisis de riesgos lo tendrá muy fácil para hacer este análisis teniendo simplemente que establecerse una meta.

Una vez tengamos claro dónde estamos, y dónde queremos llegar, será el momento de decidir qué acciones necesitamos llevar a cabo. Estas acciones, dependiendo de su magnitud, podrán ser tareas puntuales o complejos proyectos que se pueden desarrollar de forma independiente, como puede ser implantar un SGSI.

Análisis de situación + acciones ¿eso es todo?

Como ya hemos dicho, cada PDS es un mundo y no hay nada escrito al respecto, pero ahí van otras consideraciones que recomendamos tener en cuenta:

• Antes de empezar a ejecutar las acciones, deberíamos fijar indicadores para poder monitorizar si la seguridad de nuestra información ha evolucionado. Si nuestras acciones incluyen por ejemplo implantar un SGSI, éste ya incluye la toma y comparación de indicadores, pero si no es así recomendamos considerar la definición de indicadores.
• Hay quien dice que un PDS es un proceso que empieza y termina, sin tener mejora continua ni ser re-evaluado periódicamente. Consideramos imprescindible que la seguridad de la información sea un proceso vivo y continuo, por lo que para aquellas organizaciones que no tengan un proceso formal de mejora continua, una gran opción puede ser hacer un PDS nuevo cada año, o revisar y actualizar el que ya tienen.

Conclusión

Retomando la pregunta que da título al post, a prácticamente todas las empresas que consideran la información como uno de sus activos a proteger, les interesa implantar un SGSI, disponer de un plan de continuidad, hacer pentests periódicos, etc., pero estas tareas deben venir de una necesidad del negocio, y de un estudio que diga que realmente eso es lo que les interesa, y ese estudio, es el famoso Plan Director de Seguridad.

La entrada ¿Necesito un SGSI? ¿Y un plan de continuidad? ¿Y un pentest? Lo que necesitas es un Plan Director de Seguridad aparece primero en Security Art Work.

Queridos amigos,

Una vez más, como cada año por estas fechas, ha llegado el (tristísimo) momento de despedirse. Todo el mundo necesita un descanso de vez en cuando; también nosotros. Pero como estarán hartos de oír, esto no es un adiós, es un hasta luego; sí, lo sé, vaya con la frasecita de marras. Como les iba diciendo, nos retiramos a nuestros aposentos hasta el próximo 1 de septiembre, aunque si he de serles sincero, tampoco puedo garantizar que en un arranque de emotividad, morriña y entusiasmo aparezcamos algún día a saludarles con alguna entrada.

Durante estos (espero que) eternos, interminables, agónicos y duros días, pueden aprovechar para echar un vistazo a las interesantes entradas que hemos ido publicando estos meses, y si mientras cuentan nubes sacan un rato, no se pierdan la evolución de lo que se ha dado en llamar la peor vulnerabilidad jamás encontrada (ya, claro, hemos oído eso tantas veces; ¿no les recuerda al cuento de Pedro y el lobo?): Stagefright, cuyos detalles se presentarán en la BlackHat de este año. No sé si al final será tan grave, pero si se quieren comunicar conmigo mejor que utilicen alguna alternativa al MMS. Claro que no habré recibido más de cinco en toda mi vida, hace años que no me llega ninguno y en serio, ¿de verdad alguien utiliza todavía MMS? ¿Sí? Pues este es un buen momento para dejar de hacerlo.

Eso me recuerda a la entrada que escribió Samuel hace unas semanas sobre las vulnerabilidades en Android; ¿es de recibo o incluso, debería ser legal, que un fabricante se permita el lujo de dejar de emitir parches de seguridad para productos software que tienen apenas 2 años de antigüedad, cuando no ofrece la opción de actualizarse? Quizá tener la garantía de soporte durante X años sea un factor a valorar la próxima vez que se compre un móvil, y quién sabe si algún día lo veremos como un argumento comercial.

En fin, que me desvío del propósito del post. Que nos vamos de vacaciones. Que igual nos vemos por aquí algún día, igual no. Pero en cualquier caso, el martes 1 de septiembre volveremos a la carga, más y mejor, si es que eso es posible. Para acabar, déjenme aclarar que ustedes y yo no somos amigos, pero considérenlo un modo cordial de saludarles.

Pasen un muy buen agosto, allí donde se encuentren, sea cual sea su situación laboral. No volverán a vivir otro agosto de 2015, así que mejor será que lo aprovechen.

Vayan, vayan, no tengan miedo.

(La fotografía, libre de derechos y como verán muy instagramera, es de Unsplash en Pixabay)

La entrada Vacaciones aparece primero en Security Art Work.

Sí, hoy es 1 de septiembre, ese día “bipolar”. ¿Por qué bipolar? Porque hoy nuestras sensaciones se dividen. Por un lado solemos volver todos con frases como “¿Ya se han acabado las vacaciones?” “¿Ya es 1 de septiembre?” (…) y a la vez con caras que por un lado reflejan que te apetece reencontrarte con tu pequeña familia laboral pero echas taaaaanto de menos a tu sofá, a tu chico, a tu chica, la playa, la piscina, la montaña, ese libro, tu mascota, tu bebé, la familia…

En fin, sin ir más lejos hoy al volver a la oficina una compañera me ha dicho que llevaba la misma cara que una niña pequeña a la puerta de la guardería. No hace falta explicar más. Sí, es duro volver a la rutina.

Esa es la parte dura de que sea 1 de septiembre, que se han acabado las vacaciones. Por cierto vacaciones que hemos tenido.

Y ahora alguno estará preguntándose: “¿Seguro? Yo no he visto ninguna foto en Facebook que lo corrobore” Y es que tenemos que daros una noticia que hay mucha gente que no sabe, un super notición, ¿preparados? Se puede uno ir de vacaciones y no colgar ni una foto en Facebook, es posible, os lo prometemos. Es cuestión de acostumbrarse.

Hacer muchas fotos en vacaciones está bien, aunque de vez en cuando también se puede soltar la cámara de fotos (o el móvil en muchos casos) y vivir un poco el momento en vez de captarlo con un cámara, pero bueno… Lo que a nosotros nos queda más cerca es que no hay que colgar las vacaciones enteras en Facebook o en cualquier otra red social porque no es necesario, ni sano, ni seguro, ni nada… Y además lo que no quieres que se sepa, pues no lo hagas, porque una vez en la red ya se sabe que nada es secreto. Y si no que le pregunten a la gente que se había dado de alta en Ashley Madison.

En fin… Pasando a la parte buena del uno de septiembre, hay que pensar que al igual que el 1 de enero es el momento de marcarnos metas y objetivos e ir a por ellos. Nosotros como objetivo número 1 tenemos continuar creciendo en seguidores y lectores tan buenos como los que tenemos, además conseguir publicar todos los días laborales de aquí al 31 de julio de 2016 posts que lleguen y gusten a nuestros lectores…

Pues nada, empezamos el curso 2015 – 2016, ¡¡BIENVENIDOS!!

(Imagen libre de Collusor en Pixabay)

La entrada 1 de septiembre, un día bipolar aparece primero en Security Art Work.

Hoy les traemos una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre ingeniería social.
Esperamos que les guste.

El término ingeniera social, que bajo mi punto de vista es una infravaloración a la hora de hacer referencia al conjunto de técnicas de hacking que más facilidades proporcionan al atacante, es la punta de lanza de muchos ciberataques en la actualidad.

Hoy en día el uso de las redes sociales nos proporciona un lugar mucho más cómodo para movernos en este terreno, me explico brevemente. Hace algunos años cuando no existía Twitter, ni Facebook, ni muchas de esas cosas que tanto gustan, teníamos que conocer a la persona físicamente, buscar la amabilidad, convencer a alguien para conseguir acceso a datos, a un ordenador, recopilar información… Se hacía largo, eterno, y muy cansado en ocasiones. Era difícil mantener nuestro objetivo fuera del alcance porque el círculo social era reducido y la economía también.

Hoy en día es más sencillo, tenemos Facebook, Twitter, Linkedin, Badoo, Tinder, Happn, Loovod, y yo que sé cuántas tonterías más, tenemos el Meetic, tenemos el de los solteros más o menos exigentes… todo es para conectar, para ‘conocer gente’ pero con todas ellas también podemos saber dónde están esas personas, a cuántos km, metros, sus gustos, preferencias. ¿Cómo de difícil creen que es entablar una conversación con alguien afín a gustos como los tuyos? ¿Cómo de difícil es crearse una nueva personalidad digital?

No es nada difícil, luego solo hay que observar esos perfiles en esas aplicaciones, cómo de cerrados son, cuánta información nos dan… y arrastrarnos un poco hacia ese lado, buscar conexiones y trabajarnos la situación. Claro que ustedes podrán pensar que esto es muy fantasioso ¿para qué querría yo utilizar la ingeniería social con cualquiera? Pues por varios motivos, para captar información, para robar información o para tener una cabeza de turco, para instalar keyloggers, para unas cuantas acciones desalmadas.

¿Y por qué debo estar preocupado? Porque lejos de las sofisticadas técnicas de hacking con software que utiliza exploits 0-day, hay una entrada mucho más sencilla, el cara a cara -digital -. Si soy de un grupo radicalizado ¿por qué no conocer a algún trabajador de alguna obra pública más o menos grande para recabar información de boicoteo? ¿por qué no acercarme a algún trabajador de una joyería para conocer sus sistemas de seguridad físicos? ¿y si por ser amigo consigo un pase a una instalación de red eléctrica, de una presa, o de una central nuclear?

Porque la seguridad de mis datos no vale nada si yo mismo los regalo. Yo soy mi contexto y valgo en tanto y en cuanto la información que poseo.

¿Y si yo quisiera dejar en ridículo a una empresa? ¿si quisiera vender datos? ¿si quisiera captar nuevos clientes a través de un comercial o simplemente chantajear a partir de unas fotos comprometedoras? Mi primer punto de entrada es la persona y su contexto digital asociado.

Los dispositivos móviles se han convertido en la extensión de la vida social de una persona, allí permanece todo lo que ella es, pero no como dispositivo técnico si no como herramienta de relación social, el contexto de esta persona, cómo interactúa y con quién. ¿Y si tuviéramos una aplicación que nos diga qué camino recorre una persona todos los días o las ubicaciones que frecuenta de manera habitual? Una aplicación que enviara un correo con el uso del dispositivo, las webs que su propietario visita, las aplicaciones que tiene instaladas. ¿Quién se pregunta los permisos de una aplicación móvil y el motivo por el que los necesita? No me mientan que le dan a instalar sin pensarlo un segundo (no se mientan a ustedes mismos). ¿Sabemos realmente qué hace una aplicación o servicio en segundo plano con el permiso de ubicación o de contactos? Al final, el dispositivo móvil, tablet o smartphone es el punto de entrada para recabar información más potente de hoy en día, y si además la ofrecemos como si no pasara nada, cuan fácil es saber de alguien.

Podría ser real, o podría ser ficticio, hace bien poco conocí digitalmente (no físicamente) a un alto ejecutivo de una empresa importante, con sus gustos, preferencias, lugares donde ha estado, su hora de entrada y salida… ganarse la confianza de una persona no es difícil, acceder a sus redes sociales tampoco, y a partir de ahí hasta donde esa persona nos deje acceder. ¿Sería muy difícil conocer los datos corporativos a los que tiene acceso esa persona? No, no lo es. ¿Sería difícil recabar información de un proyecto específico o conseguir acceso a información catalogada como confidencial? Tal vez un poco más, pero es cuestión de tiempo.

La seguridad informática es compleja, es muy dura, es exigente técnicamente, pero piensen que siempre hay alguien dispuesto a hacer ese trabajo, y con un poco de esto y un poco de lo otro se pueden conseguir muchas cosas…

Hagan una prueba, ¿qué podrían conseguir en su puesto de trabajo simplemente con unas palabras y una mirada como un cachorrito desvalido de esos que se ponen tan monos que sería imposible no asarlos a la parrilla? Los tiempos que corren hacen que las corporaciones no solo tengan que concienciar si no poner barreras sociales en aspectos de seguridad. ¿Es más seguro un departamento donde la gente no conoce a las otras personas o uno donde todos se van a tomar cañas? ¿cuántos errores de seguridad o desastres de la empresa se nos escapan con una par de cervezas bien servidas?

No sean ingenuos, no estamos a salvo. Tampoco se me pongan paranoicos, ¿realmente tienen algo ustedes que alguien querría usar?

La entrada Técnicas de hacking: Ingeniería social aparece primero en Security Art Work.