Tester Jobs Requirements (VIDEO GAME)

Es desde hace doce a�os que vengo escribiendo este blog y nunca he escurrido el bulto cuando algo sucede, y por eso escribo hoy de este tema que tantos titulares ha despertado. Los que trabajamos en seguridad inform�tica sabemos que �estar seguro� no es una meta a la que se pueda llegar con 100% de certidumbre, y lo entendemos como la gesti�n de un riesgo que hay que manejar. No hay soluciones sencillas a problemas sencillos. Nos reportan bugs a nosotros y nosotros reportamos bugs a otras empresas. Es el d�a a d�a de nuestro trabajo.

Figura 1: El ataque del ransomware WannaCry

Ayer un ransomware nos afect� en unos equipos de red, como a muchas otras empresas de los m�s de 70 pa�ses que han sido detectados ya. El ransomware tiene como objetivo cifrar los archivos del equipo infectado para pedir un rescate v�a BitCoins, en este caso 300 USD ( no tiene como objetivo robar datos) , y se distribu�a con un dropper enlazado en un correo electr�nico que no era detectado por muchos motores de antimalware. 

Figura 2: Detecciones de la primera muestra de WannaCrrypt en VirusTotal

Hoy ya s�, porque muchas empresas hemos colaborado con las casas de antimalware para que lo firmen -.

Figura 3: Detecciones en la �ltima comprobaci�n

 El esquema de ataque era:

- Fase de infecci�n: Spam masivo a direcciones de correo electr�nico con un enlace de descarga del dropper (el que descargar el payload) o explotaci�n de servicio vulnerable expuesto a Internet o conexi�n de equipo infectado a la red local. 

- Cuando se descarga el dropper se infecta con el ransomware la m�quina.

Figura 4: Alerta del CCN-Cert publicada al poco de comenzar el ataque

- Desde la m�quina infectada se escanea la LAN en busca de equipos vulnerables a MS17-10 para infectar a ese equipo tambi�n y continuar la infecci�n. Tal y como anunciaba el CCN-CERT inmediatamente.

Lo cierto es que este esquema, aprovech�ndose de las primeras infecciones, ha dado con muchos equipos en las LAN de muchas empresas que no estaban actualizados con los �ltimos parches de seguridad. Esto es as�, porque en algunos segmentos internos de algunas redes, el software que corre en esos equipos necesita ser probado con anterioridad y el proceso de verificaci�n y prueba de los parches no es tan r�pido en los segmentos internos como en los externos porque el volumen de software interno suele ser mucho mayor y de mayor sensibilidad para la continuidad del negocio.

Figura 5: WannaCrypt en NHS en inglaterra

A pesar del ruido medi�tico, este ransomware no ha conseguido mucho impacto real, y como se puede ver en la billetera BitCoin que utiliza, el n�mero de transacciones de momento va solo por 8 en una de las tres direcciones que utiliza este malware, tal y como se puede ver en la imagen siguiente. Es decir, solo se ha pagado por el rescate a esa direcci�n por 8 equipos en todo el mundo.

Figura 6: Direcci�n BitCoin con transferencias realizadas

En total, unos 6.000 USD en todo el mundo en el �ltimo recuento:

Figura 7: las direcciones usadas

Por supuesto, lo ideal es que esto no fuera as�, pero en muchas ocasiones surgen incompatibilidades entre software a medida creado en las empresas que dan soporte al core de negocio, y los nuevos parches. En muchas unidades, donde no existen esas limitaciones con largos procesos de verificaci�n para garantizar que todo va bien, no ha pasado absolutamente nada con este ransomware. Para evitar el impacto de tener un equipo con un proceso de actualizaci�n m�s largo, se contrarresta con procesos de copia de seguridad continuo y pruebas de planes de contingencia permanentes. De hecho, el mapa de infecciones de WannaCry, el buen hacer de los equipos de respuesta a incidentes lo mantiene en n�meros muy bajos - no solo en pagos, sino en n�mero de direcciones vivas infectadas en todo el mundo -

Figura 8: Mapa de infecciones de WannaCry en tiempo real

Muchos pueden pensar que el problema es que se es lento haciendo la verificaci�n de que un parche no rompe nada, o que no se deber�a hacer porque los parches ya vienen probados, pero la realidad es que en redes de empresas con la cantidad de tecnolog�a que generamos diariamente en Telef�nica, no se puede arriesgar la continuidad de negocio de un sistema que da servicio a los clientes por un problema con un parche, as� que se invierte m�s en responder ante un posible riesgo de que sea explotado con medidas de detecci�n y respuesta, en lugar de arriesgarse a que algo falle en la prevenci�n r�pida. Y no es porque el parche est� mal, sino porque puede afectar al funcionamiento de cualquier m�dulo del sistema completo.

Nuestro equipo de seguridad y respuesta ante incidentes

A nosotros nos afect� esta pieza de ransomware en un determinado segmento, como a muchas otras empresas por desgracia, y debido a que la gesti�n de los riesgos es una prioridad, el equipo encargado de ocuparse de la seguridad interna de la red Telef�nica de Espa�a opt� por primar la protecci�n de los servicios de los clientes y cortar la posible expansi�n por la LAN interna, para lo que, en el momento en que se detect� el ataque, se decidi� responder con una desconexi�n de posibles equipos infectados para que el servicio que damos a nuestros clientes continuara.

Figura 8: El e-mail avisando a los compa�eros de las medidas de control

Hasta aqu�, todo normal en un proceso habitual de un equipo de respuesta a incidentes cuando en una compa��a se cuela un malware que no ha sido detectado por las medidas de seguridad - y son muchas - que se tienen instaladas. Y a investigar para solucionar el problema lo antes posible sin que afecte a lo m�s importante, los datos y la seguridad de los servicios de los clientes.

A m�, por motivos personales, me pill� de vacaciones, pues como todo buen trabajador hab�a solicitado desde hac�a m�s de un mes, una semana de vacaciones que ten�a marcada a fuego para comenzar antes de ayer jueves. Poco a poco, ayer viernes, me fueron contando lo sucedido y, atendiendo a todo el mundo hice lo que he hecho siempre, ser transparente y no escurrir el bulto y apoyar a los compa�eros que ten�an esta situaci�n.

Cort� mis vacaciones y me sum� a comit� de crisis que est� lidiando con esta situaci�n, aunque ellos mismos est�n m�s que preparados y se valen para resolver este tipo de situaciones a las que los que trabajamos en seguridad nos enfrentamos peri�dicamente. Por la seguridad de Telef�nica velamos miles de personas. De hecho, esta crisis ha sido m�s medi�tica en las redes sociales que en la realidad interna de Telef�nica, donde los equipos infectados est�n controlados y est�n siendo restaurados. Me un� para aportar lo que pueda a compa�eros que saben lo que se hacen y que tienen m�s que claro lo que tienen que hacer.

A algunos en las redes sociales le ha llegado a sorprender que las decisiones de seguridad interna en un momento de una infecci�n por malware de unos equipos no las tome yo, pero eso es porque mis responsabilidades directas son las de CDO (Chief Data Officer), donde est�n las unidades de LUCA (la unidad de BigData y Data Analytics para clientes), ElevenPaths (la unidad de ciberseguridad global para clientes), Aura y la 4� Plataforma (que presentamos en el Mobile World Congress). A�n as�, me apunt�, me apunto y me apuntar� a ayudar encantado a mis compa�eros, y a los compa�eros de otras empresas que tambi�n han llamado pidiendo colaboraci�n y ayuda.

Ser Resilliance

Los que estamos en esto sabemos que alcanzar el 100% de seguridad es un hito solo al alcance la imaginaci�n de los que no saben de seguridad, y nosotros haremos lo que los que trabajamos en esto sabemos hacer: Seguir mejorando para minimizar el riesgo. Intentar mejorar nuestro trabajo para que el n�mero de incidentes se reduzca y, lo que es m�s importante, para que nuestros clientes puedan seguir disfrutando de sus servicios.

El proceso de fortificaci�n de una empresa exige poner todas las medidas de seguridad que sea posible siempre que una no afecte a otra. Y exige balancear las inversiones en prevenci�n (evitar que pase la seguridad a toda costa), detecci�n (lo antes posible cuando algo que sabes que puede pasar pase) y respuesta (responder para que la continuidad del servicio siga funcionando), es decir que la empresa sea ressiliance.

Ninguna empresa puede garantizar que no vaya a afectarle un malware u otro. Yo no lo har�a con ninguna. Recuerdo que no hace muchos meses un cliente que hab�a sido atacado me dijo: �Haz lo que sea pero garant�zame que nunca me va a volver a pasar�, Y yo respond� como hago siempre �Te puedo garantizar que �ste ya no te sucede, pero no que no te vaya a suceder otro distinto�.

Los que creen que se pueden evitar el 100% de los incidentes es que no saben nada de seguridad inform�tica. Lo que tienes que tener es un equipo que sepa detectarlos y responda de forma contundente para que el sistema inform�tico sea resistente. Y en Telef�nica se est� trabajando de esa forma para conseguir que, como se ha visto, los servicios de nuestros clientes no se hayan visto comprometidos.

Saludos Malignos!

PD: Quiero dar mi agradecimiento personal a los cientos de profesionales del mundo de la seguridad que han contactado con nosotros para informarse, apoyarnos, ofrecer ayuda, cambiar conocimientos y hacer, en definitiva lo que es nuestro trabajo. Gracias por vuestro apoyo. Son tantos y tantos que me costar�a ponerlos todos aqu�. Gracias, de coraz�n.

En 2015 os habl�bamos de Hidden Tear, el primer ransomware de c�digo abierto. Pocos meses despu�s crearon native-tear, un clon escrito en C++, y hoy os traemos go-cry otro port escrito en Go.


Go-cry es un proyecto que fue escrito para mostrar lo f�cil que es crear c�digo extremadamente malicioso, de hecho si observ�is el c�digo ver�is que es sumamente sencillo. Ya sab�is que el ransomware est� dise�ado para secuestrar los archivos m�s queridos de la v�ctima demandando grandes cantidades de dinero para desbloquearlos.

Go-cry se compone de dos partes, un servidor web y el software cliente. Los archivos de salida se situar�n en ./bin/

Se puede compilar con los par�metros -w -s para minimizar el tama�o del archivo. Para reducir a�n m�s el tama�o de los binarios Go, echa un vistazo al proyecto UPX.

Creaci�n de cliente y servidor web
    ./bin/windows_amd64.exe
    ./bin/windows_x86.exe
    ./bin/linux_amd64
    ./bin/linux_x86
    ./bin/macos (amd64)
$ make

Crear� los archivos

    ./bin/web[.exe]
    ./bin/cry[.exe]

Creaci�n de cliente para todos los sistemas operativos y arquitecturas comunes

$ make all

Crear� los archivos

    ./bin/windows_amd64.exe
    ./bin/windows_x86.exe
    ./bin/linux_amd64
    ./bin/linux_x86
    ./bin/macos (amd64)

Desinstalaci�n

Eliminar� todos los archivos del directorio bin:

$ make clean

Configurar el servidor web

Edita web/web.go y modifica los valores. Est�n comentados y son sencillos de entender.

Cliente

Edita el fichero config.go y modifica los valores correspondientes.

Si modificas la variable de tama�o de clave RSA Bits, consulta EncryptedHeaderSize. La longitud del texto cifrado RSA cambia dependiendo del tama�o de clave utilizado y no se calcula en tiempo de ejecuci�n.

Notas

Este programa no solicita dinero a la v�ctima. Simplemente cifra los archivos con las extensiones especificadas en la constante config.go ProcessMax y la env�a al servidor

Aviso legal

Go-cry s�lo puede ser utilizado para fines educativos.

Proyecto: https://github.com/redpois0n/cry