domingo, 14 de mayo de 2017

Análisis del ransomware WannaCry

A estas alturas, ya todos los ciudadanos debemos saber casi por obligación qué es un Ransomware y más aún, en estos días (14 de Mayo de 2017) con el ataque masivo que se ha producido con el ransomware WannaCry. Un "juguete" más de los cyber-delincuentes que parece ser que han hecho uso del exploit EnternalBlue/DoublePulsar "fugado" de la NSA (National Security Agency US).


Básicamente se trata de un "malware" que codifica todos tus archivos importantes para pedirte una recompensa, por supuesto económica, a cambio de devolvértelos a su estado normal.


Así que, voy al grano con un pequeño y rápido análisis que acabo de hacer sobre este malware.






Partimos de una muestra capturada de dicho malware, la cual es un archivo binario (un ejecutable en sistemas operativos Windows). Un primer vistazo rápido para ver que tipo de archivo tenemos entre manos nos muestra lo siguiente:





Como podemos ver, se trata de un archivo PE de 32 bits, a priori programado en C++ y parece ser que utilizando el IDE de Microsoft Visual C++ 6.0. En este caso el malware viene como un archivo ejecutable con nombre "diskpart.exe" obviamente para intentar engañar a los técnicos haciéndoles creer que se trata de la herramienta del sistema que nos permite gestionar las particiones de un disco duro.

A continuación y como de costumbre echamos un vistazo a las secciones para ver si nos encontramos con las típicas de "casi" todo ejecutable de estas características o, por el contrario vemos alguna otra con nombre extraño que nos haga pensar que se trata de un binario compactado o empaquetado:


A priori nada raro que nos haga sospechar que estamos ante un empaquetado, aunque no tiene por que ser así. En cualquier caso, el siguiente paso que hago es echar un vistazo a la sección de datos y finalmente a la de recursos ".RSRC" la cual arroja una "grata" sorpresa. En los recursos tenemos una entrada con nombre "XIA":


Así que voy a ver que hay en ese recurso con un editor hexadecimal y en cuanto veo los caracteres de su comienzo, no hay duda, se trata de un archivo comprimido "ZIP", como vemos con su clásica cabecera "PK" comenzando en la dirección (OFFSET) previamente calculada (0x000100F0):


Ya os podéis imaginar cual es el siguiente paso que sigo, la adrenalina ya está a niveles casi descontrolados, así que a por ello ¿Qué habrá dentro de ese ZIP? Procedo en primer lugar a extraerlo del binario principal y guardarlo en un archivo, para su posterior descompresión.

¡Vaya! Resulta que se trata de un archivo comprimido en formato ZIP con contraseña. Bueno, ahora me tocará pegarme con el debugger para localizar la password, pensé en un primer momento. Pero, ¿y si antes miro las cadenas del binario principal?, para ver si los "inútiles" de los cyber-delincuentes no han sido del todo precavidos, o son unos novatillos. Pues voy a por ello y ¡zás! la suerte y la mediocridad de los cyber-delincuentes (menos mal) están de nuestro lado, como podemos ver en este pantallazo:


Ahí podemos ver una la cadena de texto, entre otras muchas, que nos abrirá las puertas al ZIP y por lo tanto nos permitirá descomprimirlo: 'WNcry@2ol7' Obviamente esto no salió a la primera, salió a la tercera ;)

Descomprimo el archivo ZIP para ve que me encuentro en su interior y esto es lo que hay:

Unos cuantos archivos interesantes con la extensión "WNRY", un par de archivos ejecutables con nombres: "TASKDL.EXE" y "TASKSE.EXE" que por buenas prácticas renombré a la extensión ".BIN" y finalmente una carpeta (directorio de toda la vida) llamada "MSG" y en cuyo interior nos encontramos con esta lista de archivos que hacen referencia a idiomas:


Todos como vemos también tienen esa curiosa extensión "WNRY" hemos de suponer que por abreviar el propio nombre del ransomware "WANNACRY". Por lo que se de analizar otros ransomware, posiblemente sean los pantallazos que muestran este tipo de malwares para pedirte la recompensa, pero eso ya lo veré.


Hasta este momento, parece obvio que el malware lo primero que va a hacer es extraer su recurso "XIA", descomprimirlo con la password mencionada y posiblemente comenzar a ejecutar uno de los dos archivos ".EXE". A partir de ahí comenzará muy probablemente a buscar archivos en el ordenador que cumplan ciertos requisitos, tipo documentos, archivos de proyectos de software conocido, etc. básicamente mirará sus extensiones (.DOC .PDF .JPG .PNG .C .CPP .TXT y un largo etc.)

Fijaros que curioso, un malware tan "dañino" que posiblemente no serviría PARA NADA, si todos nuestros archivos no tuvieran esas extensiones. Obviamente ya sacarían después alguna variante para atacar buscando en el contenido de los archivos para saber su tipo, pero de momento, en este caso no habría podido hacer NADA.

Y, finalmente, el malware intentará replicarse por la RED en la que se encuentre, aprovechándose de la vulnerabilidad en el servicio SMB, que dicho sea de paso se parcheó el 14 de Marzo del presente año 2017.

En fin, con más tiempo seguiría con el análisis, pero, el deber me llama y a estas alturas ya habrá muchas empresas/individuales haciendo un análisis más extenso del ransomware.

jueves, 11 de mayo de 2017

Parkinson Emma Project (Microsoft Build 2017)

Hoy me entero a través de la conferencia anual de desarrolladores Microsoft Build 2017 de una gran innovación que no se puede pasar por alto. Sin duda, esta es una de esas cosas que le hace a uno estar orgulloso de pertenecer a la especie humana y, sin duda nuevamente, esta otra de esas cosas que me hace sentir bien por pertenecer al mundo de las TI. Pues sí, así es, no todo lo que hacemos en el mundo de la tecnología busca destruir al ser humano (como algunos predicen), ni quitarle a la gente sus trabajos (como otros auguran), el problema en esos casos no es la tecnología, es el sistema político/económico que mueve el mundo.






La tecnología ha venido para ayudarnos, ha venido para facilitarnos la vida, ha venido para que no necesitemos trabajar tanto, y por más que le pese a muchos, la tecnología a venido para quedarse.

Más allá de esta apreciación personal, desde mi humilde blog no puedo menos que felicitar a Haiyan Zhang, la ingeniera que está detrás del "Proyecto EMMA" un wearable cuya finalidad es facilitar la vida a las personas que padecen Parkinson y para ello, ha estado junto a Emma Lawton, quien ha podido probar y experimentar con este wearable y ha juzgar por sus lágrimas, con unos resultados excelentes.






Pero, ¿Cómo lo hace? Hasta donde he podido ver, la idea, en apariencia sencilla, pero seguramente no tanto en la práctica, se vale de unos pequeños motores (LRA Coin style Motors), cuya finalidad es "contrarrestar" los "espasmos" producidos por el Parkinson en la zona de la muñeca, que es donde se coloca el wearable al estilo de un reloj de pulsera.






Para su investigación y desarrollo he podido "descubrir" que Haiyan Zhang, muy inteligentemente ha estado utilizando una placa de desarrollo de otra gran empresa como es Texas Instruments, concretamente creo que podría tratarse del modelo DRV2605LEVM-MD. Una placa de desarrollo producida por TI, la cual cuenta con 8 drivers del tipo DRV2605L, un microcontrolador del tipo MSP430F5510 con arquitectura RISC y de 16-bits, conexión USB para el PC, desde donde se podrá programar dicho microcontrolador, además de comunicarse con la placa de desarrollo, la posibilidad de controlar de manera independiente o sincronizada los 8 drivers mencionados, una librería de formas de onda, esta última entiendo que con el fin de controlar de una manera más suave y sincronizada el "vibrar" de los motores, etc.

Finalmente, todo esto se habrá convertido en una PCB diseñada a medida del wearable, el cual además parece contar con conexión bluetooth, con el fin, entre otras cosas de calibrar y adaptar el wearable a los distintos "patrones espasmódicos" de cada persona.


¡Congratulations Haiyan Zhang! A great project, a great research, a great innovation, thanks for that!

viernes, 5 de mayo de 2017

Transformada Rápida de Fourier (FFT) - 1

Una de las cosas (de tantas y tantas) que me ha llamado siempre la atención son los temas relacionados con DSP (Digital Signal Processing), el procesado digital de señales. Desde el diseño de filtros digitales (FIR - Finite Impulse Response e IIR - Infinite Impulse Response) hasta el análisis espectral, pasando por los conversores ADC y DAC, etc.


En esta ocasión quiero plasmar aquí para futuras consultas y para todo aquel al que le pueda venir bien, un pequeño estudio sobre una de las herramientas matemáticas más importantes en el procesado digital de señales, se trata de la Transformada de Fourier y más concretamente de la FFT (Transformada Rápida de Fourier).


La FFT es una herramienta o proceso matemático que nos permite transformar una señal en el dominio del tiempo al dominio de la frecuencia. Habitualmente solemos representar las señales en el dominio del tiempo, mostrando su amplitud y frecuencia en función del tiempo, pero en el caso de la transformada de Fourier de lo que se trata es de obtener los valores de frecuencia, amplitud o magnitud y fase de una señal "compleja" que puede estar compuesta por varias señales de distintas frecuencias y amplitudes, así como de una componente en continua (DC - Direct Current).


Supongamos que tenemos una señal compuesta por una componente en continua de 2 voltios, más una señal de 50Hz y 3.3 Voltios y otra de 75Hz 1.35Voltios, como la siguiente:


ph1 = pi*-30/180
ph2 = pi*90/180
S1 = 3.0 * cos(2*pi*50*t+ph1)
S2 = 1.5*cos(2*pi*75*t+ph2)
Signal = 2 + S1 + S2


cuya representación gráfica sería la siguiente:


Partiendo de esta base, podemos calcular la FFT por ejemplo utilizando MATLAB, de la siguiente manera:


Y = fft(Signal, N);     % Calculo de la FFT
YM = (abs(Y));         % Modulo o Magnitud de los N valores de la FFT
plot(YM(1:N));         % Grafica de la FFT


Lo que hacemos en primer lugar es calcular la FFT de la señal, lo cual dejará en el array 'Y' una lista de N valores de números complejos en la forma a+bi. Posteriormente, se calcula la magnitud o módulo de dichos valores y se almacena en un nuevo array 'YM' (sqrt(a^2 + b^2)) y finalmente mostramos la gráfica resultante, la cual podemos ver a continuación:




En esta gráfica ya podemos ver como en N=0 tenemos un pico con un valor de 512 y correspondería con una señal de frecuencia 0Hz, lo cual sabemos que se corresponde con la componente continua (DC) de la señal. El siguiente "pico" que observamos es el de la señal de 50 Hz con un módulo de 380 aprox. y por último otro pico que corresponde con la señal de 75Hz y un módulo de 190 aprox.


Llegados a este punto ya podemos ver como con la FFT estamos siendo capaces de obtener las distintas frecuencias que componen la señal "compleja" original.


En otro post, veremos como calcular la amplitud y la fase de ambas señales así como la tensión de la componente continua u offset de la señal original.

sábado, 26 de septiembre de 2015

Error "BUG" en Microsoft-Edge (TRK:0285936)

Microsoft TRK:0285936
Microsoft Case: 31110

Recientemente he notificado a Microsoft un "error" que he localizado en su nuevo navegador Microsoft-Edge. Se trata de un fallo en el parser del campo dedicado a la dirección o URL, el cual encontramos en la parte superior de la ventana del navegador.


Aunque Microsoft no lo considera una vulnerabilidad desde el punto de vista de la seguridad del sistema, si que están de acuerdo conmigo en que puede ser utilizado para realizar un ataque de Denegación de Servicio (DoS).


En fallo hace que Microsoft-Edge entre en una especie de bucle infinito que se dedica a abrir de manera continuada gran cantidad de nuevas pestañas vacías en el navegador. Esto, no solamente provoca una Denegación de Servicio sobre el equipo atacado, dado que impide que el usuario pueda navegar por internet, sino que además puede llegar a provocar una sobrecarga de la memoria (Heap exhaustion), ya que por cada nueva pestaña que se abre, se consume una cantidad de memoria que no es liberada.


Cronología de comunicaciones entre mi persona y el equipo de seguridad de Microsoft:
  • El primer contacto con el equipo de seguridad de Microsoft lo realicé el día (03/09/2015) remitiéndoles un correo electrónico para notificar dicho hallazgo para que sus expertos lo analizaran en profundidad.
  • El equipo me responde el mismo día (03/09/2015 diciéndome que no se puede explotar remotamente y que por lo tanto no lo tendrán en consideración, ya que, entienden que es necesario tener acceso físico al equipo para poder explotar este fallo.
  • Ese mismo día (03/09/2015) les envío otro e-mail con una pequeña prueba de concepto para que vean que si puede ser explotado remotamente y además desde varios frentes distintos.
  • El mismo día (03/09/2015) me notifican que lo van a trasladar al equipo de análisis para su investigación.
  • El día (05/09/2015) me agradecen nuevamente la información facilitada y me indican que van a abrir un nuevo caso (nº 31110) y que el administrador de casos (Michael) se pondrá en contacto conmigo en cuanto tenga más información al respecto. Me piden que por favor, en un principio respete las "Directrices de divulgación de vulnerabilidades coordinada" y que no revele públicamente este hallazgo para permitir que los usuarios tengan la posibilidad de actualizar sus sistemas y estar protegidos ante eventuales ataques.
  • Así lo hago, y no revelo nada para evitar que "el lado oscuro" pueda hacer un mal uso de este fallo en Microsoft-Edge.
  • Finalmente, el día (18/09/2015) me contestan con el siguiente e-mail:
"After our investigation we have determined this to be user-recoverable temporary DoS. This does not meet the bar for security servicing and we will be closing out as wont fix."


Básicamente que se trata de una "Denegación de Servicio" y que no lo consideran un problema para la seguridad y que por tanto no se aplicará una solución al respecto.


NOTA: A día de hoy 26 de Noviembre de 2015, Microsoft ya ha aplicado un parche que repara este Bug. "De nada Microsoft, un saludo".


¡ADVERTENCIA! A continuación podéis probar el fallo encontrado en vuestro navegador (Microsoft-Edge) bajo vuestra responsabilidad, yo no me hago responsable de los daños que se puedan ocasionar en vuestros equipos. Para poder probar este "Bug" en vuestros navegador podéis pulsar sobre este LINK desde Microsoft-Edge y veréis el efecto de infinitas pestañas abriéndose y consumiendo la memoria de vuestro sistema.

Así que, ya sabéis, si estáis utilizando Microsoft-Edge que sepáis que existen una serie de "bugs" que pueden provocar una Denegación de Servicio en vuestro acceso a internet e incluso consumir la totalidad de la memoria de vuestros sistemas, eso sí, de momento no parece que vaya a haber una solución al respecto.


Ya veremos si en futuras actualizaciones corrigen estos problemas o por el contrario será el clásico "bug" que se arrastra durante años, espero que no.


NOTA: A día de hoy 26 de Noviembre de 2015, Microsoft ya ha aplicado un parche que repara este Bug. "De nada Microsoft, un saludo".

miércoles, 16 de septiembre de 2015

MIDLRT - Generate metadata files (.winmd)

If you are programming a custom Windows Runtime component by hand, one of things you must to do is generate the IDL (Interface Definition Language) file. Once you have that file, you can get the metadata file (.winmd) by using the "MIDLRT" tool.


MIDLRT is a command line tool used to create metadata (.winmd) files that represent the API of your own custom Windows Runtime component.


You can use this nice tool as easy as writing this command:


C:>midlrt filename.idl


One option you can specify is the "metadata_dir" option, like in this example:


C:>midlrt MyRuntimeComponent.idl /metadata_dir "C:\windows\system32\WinMetaData"


When the tool MIDLRT has finished his job, you will have the following files in your current directory:


  • dlldata.c
  • MyRuntimeComponent.h
  • MyRuntimeComponent.winmd
  • MyRuntimeComponent_i.c
  • MyRuntimeComponent_p.c


Another nice tool you can use with all this stuff is "WINMDIDL". This is also a command-line tool you can use to generate automatically IDL files from your metadata files (.winmd) like this:


C:>winmdidl MyRuntimeComponent.winmd

martes, 15 de septiembre de 2015

C++/CX & Xaml Data Binding

There is a few methods that you can use to make a C++/CX class with data-bindable capability. The most simple way is by adding an attribute to the class declaration:


[Windows::UI::Xaml::Data:Bindable]

public ref class SampleDataClass sealed
{
...
};


But, What about non-public classes? With the non-public classes you can declare the class by implementing either the ICustomPropertyProvider interface or IMap:


ref class SampleDataNonPublicClass sealed : Windows::UI::Xaml::Data::ICustomPropertyProvider
{
...
public:
virtual Windows::UI::Xaml::Data::ICustomProperty^ GetCustomProperty(Platform::String^ name);
virtual Windows::UI::Xaml::Data::ICustomProperty^ GetIndexedProperty(Platform::String^ name, Windows::UI::Xaml::Interop::Type type)
property Windows::UI::Xaml::Interop::TypeName Type
{
virtual Windows::UI::Xaml::Interop::TypeName get() { return this->GetType(); }


}

virtual Platform::String^ GetStringRepresentation()
{return this->ToString();
} };

jueves, 3 de septiembre de 2015

Windows Runtime DateTime to SYSTEMTIME conversion

This post is about how to make date/time conversion between Windows::Foundation::DateTime and SYSTEMTIME structure types. Let's go to see by example:


// First we obtain the current DateTime from Calendar class

Windows::Globalization::Calendar^ cal = ref new Windows::Globalization::Calendar();
Windows::Foundation::DateTime date= cal->GetDateTime();


// Here, we are converting DateTime to a 64bit value (UniversalTime format)
ULARGE_INTEGER time;
time.QuadPart = date.UniversalTime;


// Now convert the ULARGE_INTEGER to a FILETIME structure
FILETIME fileTime;
fileTime.dwHighDateTime = time.HighPart;
fileTime.dwLowDateTime = time.LowPart;


// And finally we get a SYSTEMTIME value by calling the FileTimeToSystemTime Windows Api.
SYSTEMTIME systemTime;
FileTimeToSystemTime(&fileTime, &systemTime);

With C++ and once again, we are doing many things to something simple but sometimes necessary.