Suplantación de identidad sobre el aire en redes GSM

Corría el año 2000 y el Canal Satélite Digital y VíA Digital estaban en pleno auge, igual que las tarjetas smartcard con un microcontralador PIC 16F8xx como las SilverCard y GoldWafer para "hackear" estos servicios. Todos teníamos un programador TE20 para poder escribir los datos en los microcontraladores y el TE21 o Phoenix para leer las tarjetas originales smartcard ISO 7816.

Entonces apareció él, se llamaba SIM EMU y era un programa que podíamos cargar en el PIC 16F84 para emular una tarjeta SIM. Para que la tarjeta fuese funcional 100% era necesario leer dos parámetros de la tarjeta SIM original; el IMSI y el número secreto Ki de 128 bit (wikipedia.org, apartado "Authentication key Ki"). Esto se podía hacer con el lector TE21 utilizando cualquiera de los programas disponibles: cardinal68, sim scan, etc (creo que todos ellos ya no están soportados por sus desarrolladores, pero se pueden encontrar gracias a Don Google). 

Fue cuando aprendimos el proceso "RUN GSM ALGORITHM" (el proceso encargado de generar la respuesta SRES (algoritmo A3) y la clave de cifrado Kc (algoritmo A8) al recibir un número aleatorio RAND de la red GSM, ver documento Specification of the Subscriber Identity Module - Mobile Equipment SIM - ME interface GSM 11.11) y que había dos tipos de tarjetas SIM; las que tenían implementada la versión 1 del algoritmo, llamado COMP128v1 y las nuevas con la versión 2; COMP128v2. Sólo podemos someter al ataque de fuerza bruta a aquellas tarjetas que tengan implementado el algoritmo COMP128v1, puesto que es el único que se consiguió romper.

Entonces se necesitaba acceso físico a la tarjeta SIM para poder suplantar la identidad de un usuario de la red GSM.

¿Qué ha pasado desde entonces hasta ahora?

Gracias a las nuevas herramientas para monitorizar el tráfico GSM (OsmocomBB, SDR, USRP...), podemos ver en nuestro wireshark cómo la red GSM y el terminal realizan el proceso de autenticación pero no desde el punto de vista de la tarjeta SIM, sino la señalización entre el equipo (ME) y la red GSM. Teóricamente cada vez que encendemos el teléfono y en determinadas circunstancias, como por ejemplo: hand-over entre celdas (nos desplazamos en coche y cambiamos de antena GSM), al activar servicios de la red GSM (realizar o recibir llamadas o mensajes) la red GSM nos debe solicitar autenticarnos en la red, enviando a nuestra SIM la petición "RUN GSM ALGORITHM".

¿Porqué no hacer un par de pruebas con cada operador para analizar el comportamiento de la red? ¿Cada cuánto tiempo solicita la red a mi móvil/SIM que se autentique? …¡¡ Manos a la obra !!

La herramienta seleccionada fue OsmocomBB corriendo en un portátil con Ubuntu (Layer 2 y 3) y en un Motorola C118 (Layer 1), de tal modo que puedo ver las trazas en el wireshark mientras me muevo y realizo llamadas. Cuando todo está listo, una vuelta por la M40 haciendo llamadas y enviando SMS.

osmocom lanza el firmware Layer1 en el móvil

motorola C118 corriendo firmware Layer1

aplicación "mobile", capa 2y3, solicita el PIN

wireshark recibiendo la señalización de nuestro móvil

Al analizar las trazas, la gran sorpresa es que no todas las redes (operadoras) tienen el mismo nivel de seguridad/rigurosidad con la autenticación. No voy a dar nombres, pero encuentro que en una red GSM, tras encender el móvil y realizar 3 llamadas, en ningún momento la red me ha solicitado autenticarme. Este caso más sangrante me lleva a seguir con una nueva prueba, un ataque de suplantación de identidad sobre el aire. Los TMSI circulan tranquilamente (sin cifrar) por el aire en mi celda … ¿Qué pasaría si programo una tarjeta SIM sólo con un TMSI y clave Kc de cifrado válidos?

Si un hipotético atacante quisiera conocer cuales son el TMSI , el Kc y la localización (celda) de una víctima a partir de su número de teléfono, es perfectamente posible y ya ha sido tratado en varias sesiones del Chaos Computer Club (27C3, 28C3 y 30C3).

 En esta prueba no voy a utilizar un IMSI válido, lo que vamos a hacer es inventarnos un IMSI que la red reconozca como suyo (ojo al MNC) y que el resto de dígitos serán aleatorios, ídem para la clave Ki; aleatoria. Para llevar a cabo todo este proceso he utilizado un lector/programador de smartcards SCM SCR3310 con una tarjeta SIM programable sysmoSIM y el software cyberflex.

 

Debemos tener en cuenta todos los ficheros (EF) que residen en la SIM dentro del directorio (DF) GSM 7F20, y en particular el LOCI "6F 7E", es aquí donde vamos a poner nuestro TMSI objetivo, puesto que el fichero LOCI contiene concatenados el TMSI seguido del "Location Area Information", nuestra última posición conocida por la SIM. El LAI a su vez se compone de: MCC + MNC + LAC (Location Area Code). Para España el MCC es 214 y el MNC depende de la red (ver en Don Google). Os dejo algunos comando útiles para movernos por la SIM (para ver el listado completo ver la referencia anterior GSM 11.11):

STATUS: a0f2000002 (debemos comenzar la sesión siempre con status)
a0a40000023f00    (selecciona el MF)
a0a40000022fe2    (selecciona el EF ICC ID)
a0b000000a        (muestra el contenido)
a0a40000027f20    (selecciona el DF GSM)
a0a40000026f07    (selecciona el EF IMSI)
a0b0000009        (muestra el contenido)
a0a40000026f7e    (selecciona el EF LOCI)
a0b000000b
a0a40000026f20    (selecciona el EF Kc)
a0b0000009
a0a40000026f30    (selecciona el EF PLMN sel)
a0b0000096

El resultado: tras grabar los resultados a la tarjeta SIM programable, un primer intento falla: recibo LOCATION UPDATE REJECT. Vuelto a intentar y … Sorpresa !! Veo el nombre del operador en la pantalla del teléfono, me doy a prisa en llamar a mi amigo Ramón y … funciona, llamada con éxito, me he suplantado a mi mismo.

Conclusión

El resultado de esta prueba/ataque depende de muchos factores a tener en cuenta;

- Celda y Location Area: cada celda y cada LA tienen parámetros distintos, que funcione en una "zona" no quiere decir que vaya a funcionar en toda España (y viceversa)

- Configuración de la red: el tiempo de "refresco" de nuestra clave de cifrado Kc y del TMSI depende de cada red, es posible que durante nuestros ensayos la red solicite a la tarjeta SIM que se autentifique, pero al no tener un Ki válido, lógicamente será automáticamente rechazada la SIM y la clave Kc puesta a "FFFFF…."

- Para evitar estos ataques, no podemos hacer nada. Son el resultado de faltas graves de seguridad en la red GSM. Si un atacante no pudiese conocer mi TMSI u obtener la clave Kc a partir de una captura, la suplantación nunca podría funcionar. Si aún así, dichas claves se refrescasen en cada petición de servicio a la red GSM, la suplantación sería mucho más costosa, prácticamente imposible.

La conclusión más evidente es la falta de seguridad, a día de hoy, en las redes GSM. Si quereis ver cómo son de seguras las redes GSM, visitad la web GSMmap.

Recuperar contraseñas o administrar usuarios en Windows

Lo que parece una vulnerabilidad en realidad no lo es, esta es una debilidad de la protección de memoria presente en todos los sistemas operativos y por lo tanto no excluye a GNU/Linux, FreeBSD, Windows ni siquiera a Mac OS X.

Esto realmente no es nuevo, desde hace muchos años los armadores de computadoras o “técnicos” lo han usado por mucho tiempo, se requiere estar frente a la PC. Por lo que en realidad es un método que sirve para entrar a una computadora de la que no se tiene la clave y no encuentras al dueño para que te la proporcione.

Durante el arranque y antes de que ingrese algún usuario el sistema operativo tiene que realizar tareas como administrador o root para lanzar los servicios o incluso para dejar ingresar a los usuarios.

Por ejemplo en GNU/Linux el archivo /etc/shadow contiene las contraseñas de los usuarios pero solo root puede leerlo, esto significa que el proceso de login de GNU/Linux y cualquier Unix debe tener el UID 0 o de root al momento de autenticar la contraseña de lo contrario el usuario nunca se podría logear, una vez logeado el proceso termina y se migra al UID que le corresponde al usuario diferente a 0, si fuera modificado el binario del login se podria crear un backdoor

En Windows esto no es diferente, de hecho es peor ya que Windows ni siquiera cumple al 100% con Posix.

Durante el arranque y hasta que se ingresa un usuario todo funciona con la memoria de Sistema que incluso es superior a un usuario administrador, desde el Windows XP y seguramente hasta el Windows 8 por default viene activado el servicio de accesibilidad para discapacitados el cual se activa presionando en cualquier momento 5 veces la tecla shift, el proceso se lanza con el programa sethc.exe. Al igual que con GNU/Linux si alguien aprovecha a modificar los procesos previos al LOGIN podrá crear un backdoor.

Una vez que Windows ha arrancado el sethc.exe es protegido por la memoria de sistema, significa que ni siquiera un usuario administrador podría tocar esos archivos, pero. ¿Si la protección no estuviera activa? ¿ Si Windows no estuviera corriendo… ?

Si reinicias una PC con cualquier sistema operativo que te permita acceder a NTFS y modificar archivos podrías sin problemas modificar los archivos.

Ni siquiera es muy complicado, el mismo Windows tiene a la mano el programa perfecto con el cual sustituir el sethc.exe, el cmd.exe, cmd es el símbolo de sistemas o consola de Windows, los que saben moverse en las consolas saben administrar las maquinas sin requerir entornos graficos.

Lo único que se requiere hacer es sustituir sethc.exe por cmd.exe , de esta manera cuando se presione 5 veces shift será lanzada la consola.

el comando para lanzar el administrador grafio de usuarios es

Control userpasswords2

Esto debe funcionar en incluso en Windows 8 aunque no lo he probado, como saben compro cada copia de Windows original, ya que no me gusta ser pirata, pero la versión 8 es la primera versión de Windows que jamás saque siquiera de su empaque.

Ver mas grande

Ver mas grande
Con el siguiente video puedes ver la prueba de concepto.

También puedes trolear o jugar bromas, borrando hasta el último usuario de la maquina.

Localizar un usuario Whatsapp por IP con imagenes en el URL ¿ Eso es lo que de verdad te preocupa ?

ay varios artículos que alarman del uso de imágenes ligadas a un URL en el whatsapp para rastrear su IP y luego su localización.

Hasta cierto punto es posible invadir la privacidad de alguien, pero rastraerlo por IP suena demasiado loco, especialmente por que la mayoría de los aparatos de Internet en el hogar usan IP variables, si envía la imagen mientras esta conectado al 4G la ip que obtendrá sera la del operador telefónico que es compartida por miles de personas al mismo tiempo

El asunto de la IP aunque es un factor de riesgo para a quien tenga la paranoia de ser perseguido…. es algo casi absurdo y mas tratándose de un dispositivo móvil.

Al momento de escribir este articulo el Whatsapp en Android y en iOS se negaron a abrir imágenes aun teniendo configurado las descargas automáticas de las mismas, tal vez la gente de Whatsapp ahora facebook vio el mismo problema que veo yo.

El problema real que distingo es la capacidad de alguien de hacer maldad, enviando URL con imágenes haciendo que el dispositivo las descargue causándole una facturación por datos móviles de 4G, esto si importa por que es dinero real , por lo que mientras otros se preocupan por cosas ridículas como la ip yo veo que es posible lastimar el bolsillo de alguien con el asunto de las imágenes de URL en el whatsapp.

Sobre el asunto de hacer capturar datos del usuario enviando URL con o sin imágenes

Ver mas grande
No se puede proteger al usuario de si mismo, de todos modos cualquier sitio que visites seguramente guardara un registro de tu dispositivo con la información de la versión de sistema operativo y navegador y no tiene que ser un sitio de malware lo hacen todos por lo que recabar información del dispositivo y solo sirve para presumir a alardear que eres hacker cuando en realidad esa información no sirve par nada ya que dependes de que el usuario caiga en la trampa y si es de los que caen la menor de las importancias sera saber si el dispositivo es vulnerable, por que para entonces ya le habrás instalado un APK con los permisos dados por el mismo usuario.

Malware Analysis "Policia Federal"

Hola, bien despues de algunas semana sin escribir, esta ocasion quuiero compartir un analisis de malware muy a detalle del funcionamiento del mismo , rutinas desencriptadores,strings, inyeccion a proceso victima, el cual despues de varios dias estar escribiendo pude terminar este el cual trata principalmente de reversing, en unos dias liberare una herramienta seguro servira de mucho luego les comento de que trata!! :D 3:)

La muestra analizada es acerca de un ransomware que usurpa la identidad de la policía federal. Ransomware es un tipo de malware (software malintencionado) que los criminales instalan en su PC sin su consentimiento y les da a los criminales la capacidad de bloquear su equipo, luego presentará una ventana emergente con un aviso que dice que su ordenador que se encuentra bloqueado y afirma que no podrá acceder al mismo a no ser que pague.

VER ONLINE (PANTALLA COMPLETA) Y DESCARGAR DOCUMENTO

 

CREANDO MALWARED DESDE CERO 2

Ya hace más de una semana que prometí subir esta segunda parte, pero me han surgido algunos problemas personales y demás preparativos para el próximo curso y demás cosas que me han retrasado un poco pero ya regreso sin problemas.
Este capítulo lo llamaremos “comenzando con el desarrollo del virus” Desde ahora empezaremos con el desarrollo de nuestro  malware, pero vamos, que no podemos iniciar sin antes explicar cosas muy básicas para empezar a programar, les explicare algunas cosas básicas de la programación en Radasm y dejare algunas referencias sobre programación en este IDE



Iniciamos abriendo radasm, como ya vimos en la primer parte, al crear un nuevo proyecto teníamos la opción de elegir una plantilla, pero en este caso no queremos usarla..

Bien Lo siguiente es tener la pantalla limpia y empezaremos por copiar ahí dentro, el siguiente código que solo lanzara un mensaje pero es ideal para comenzar a explicarles..

Copien lo siguiente:

Algunos se preguntaran porque no escribo el texto,  pero lo ideal es que lo transcriban lo que se ve en la imagen y eso les ayudara para entender para que se sirve cada parte, les explicare a detalle:
.386
Esto le dice al ensamblador que vamos a usar el conjunto de instrucciones del 80386, también podemos usar .486, .586., .486p, etc.

.model flat, stdcall
Esto indica el modelo de memoria, en Win32 hay un solo tipo de memoria, la plana (flat).
El SO (sistema operativo), para optimizar el proceso de manejo de memoria la fragmenta en bloques, a los cuales llama ‘páginas de memoria’, esta ‘pagina’ representa el bloque mínimo de memoria a leer o a escribir, normalmente en Windows es de 4Kb.
Para poder manejar este esquema utiliza unas tablas denominadas ‘tablas de páginas’ por medio de las cuales relaciona secciones de esa memoria que nosotros utilizamos con memoria física real.
Cuando referenciamos una dirección de memoria, Windows traduce la dirección virtual en una real, luego verifica si está cargada en memoria. En caso de que no sea así genera lo que se llama un ‘fallo de página’ y la carga en memoria RAM para que la podamos utilizar.

stdcall
Indica al ensamblador el orden que debe seguirse para pasar parámetros, ‘izquierda a derecha’ o ‘derecha a izquierda’

option casemap:none
Su función es indicarle al compilador que distinga entre mayúsculas y minúsculas.

includelib
Sirve para indicarle al compilador que librerías necesitamos que nos importe para poder ejecutar nuestro programa.
Dentro de nuestros programas en Windows, nos ofrece una serie de funciones llamadas APIs (Application Programming Interface), que significa ‘Interface de Programación de Aplicaciones’. Estas funciones residen en librerías de enlace dinámico (DLLs) como son kernel32.dll, user32.dll, etc.
Este proceso se realiza por medio de las famosas  IT (Import Table) e IAT (Import Address Table) las cuales veremos mas adelante.

.data
.data nos sirve para declarar variables.

 .code
code es donde se encuentra el código ejecutable de nuestro programa.

El IDE nos facilita algunas cosas por ejemplo al escribir alguna API, en el caso de MessageBox, nos ayuda indicándonos que parámetros ubicar, el handle, el offset del texto, el caption,etc

Ahora bien, en el menú podemos configurar la ruta donde se encuentra nuestro debugger, por ejemplo, hacemos click en “opciones”, seguidamente “fijar rutas” :

Y únicamente en la casilla debug buscamos la carpeta y listo, guardamos los cambios, para posteriormente presionar el método abreviado “Control + D” y automáticamente nos abrirá el programa dentro de nuestro debugger:

Si vemos con atención los parámetros empiezan a empujar con PUSH a la pila (stack) desde el último parámetro al primero, desde style, terminando en Howner que es el hWnd o handle de la ventana.

La pila o stack es un área de memoria usada por el programa para guardar variables
Temporales, argumentos de funciones, direcciones de memoria, etc.
Se basa en una metodología denominada LIFO (last in, first out), o sea que el último en entrar será el primero en salir. Para entender mejor esto imaginemos una pila de libros, donde vamos poniendo uno encima del otro y cuando queremos sacar uno empezamos siempre por el que tenemos en la parte superior.

¿Cómo podemos conocer un poco mas sobre las apis y descripción sobre su funcionamiento?, así como los parámetro que debemos usar?
sencillo, podemos buscar en google, lo cual microsoft nos ofrece mucha ayuda:

Como ven, la información que nos brindan es muy detallada, podemos apoyarnos siempre de esta manera.
Lo mismo podríamos buscar la API ExitProcess y ver una descripción de sus parámetros y como funciona.


Ahora bien ya que hayan absorbido esta información, los siguientes donde entraremos directo a las tecnicas de programacion del bicho serán mas sencillos, pero igual me gustaría dejarles enlace a unos tutoriales de programación en este entorno por si alguien quiere practicar antes de comenzar con la parte mas interesante!  Que es lo que a completa este capítulo!, sin más les dejo el enlace :
http://uppit.com/dv2h7cowgatg/Programacion_MASM+RADASM.rar

CREANDO MALWARED DESDE CERO -1

Bueno lamento traer este capitulo hasta ahora después de lo acordado, el problema es que tuve un pequeño contratiempo y no pude prepararla hasta ahora. Quiero comentarles que desde que inicie con la primer parte he recibido muchos comentarios y se ha obtenido una buena respuesta, ya que hay muchas personas que les ha gustado la idea pero también ha habido otro tanto que me han preguntado cual es la finalidad de hacer un curso sobre desarrollo de malware y pues bien mi respuesta es : “ La finalidad de hacer un curso en tutoriales sobre de desarrollo de malware es la misma que se pretende al redactar cualquier tipo de investigación del tema de la seguridad informática, y es compartir el conocimiento, es obvio que mientras conozcas y domines el tipo de ataque y cómo funcionan,  la manera de protegerte y prevenirlos será mucho más sencilla, es responsabilidad de cada quien la forma en que lo usen pero recuerden depende de cada uno hacer el conocimiento adquirido un arte, quedando claro esto quiero pasar con lo siguiente:
Como les comente la segunda y tercer parte serian algo pesadas, pues bien en estas primeras partes se definirá si estás preparado para lo que sigue, a continuación hablaremos  del lenguaje ensamblador, si ese mismo, pero vamos que no es nada del otro mundo, al contrario veras lo sencillo que resulta ser comprender tan maravilloso lenguaje y del cual dominándolo se pueden lograr muchísimas cosas, comenzamos.

(algunas partes de aquí es tomado del tutorial #3 del colega fabio escudero)


Assembler:
Registros del procesador:
Los registros los podemos ver como espacios físicos que residen dentro del procesador y se emplean para controlar instrucciones en ejecución, manejar direccionamientos de memoria y proporcionar capacidades aritméticas y lógicas. Siempre que hablemos de registros vamos a hacer referencia a los registros de 32 bits, los cuales aparecieron con los procesadores 386 en adelante, no a los antiguos registros de 16 bits que utilizábamos en programas DOS.
Registro generales:
EAX: registro acumulador, es un registro de propósito general pero también muy utilizado en operaciones matemáticas, es utilizado para obtener el valor de retorno de las API’s, CreateFileA.

EBX: registro base, se suele utilizar para direccionar el acceso a datos situados en la memoria. También como el registro eax lo podemos dividir en BX, BH y BL.

ECX: registro contador, se utiliza como contador en determinadas instrucciones. También podemos usar CX, CH y CL.

EDX: registro de datos, además de su uso general. También se lo utiliza en operaciones de Entrada/Salida. Podemos utilizar EDX, DX, DH y DL.

Registros de puntero:

ESP: es un registro que apunta a la dirección del último valor introducido en la pila, o sea del primero que podríamos sacar. Cuando ingresamos o sacamos valores del stack el SO lo actualiza automáticamente para que siempre apunte al último valor. De todas formas podemos modificarlo desde nuestro código, ya veremos cómo. Pueden utilizarse los 16 bits inferiores con SP.

EIP: este registro apunta a la dirección de la próxima instrucción a ejecutarse y se va modificando automáticamente según se va ejecutando el programa.


Registros de base:
EBP: se utiliza para direccionar el acceso a datos situados en la pila y también para uso general. Pueden utilizarse los 16 bits inferiores con BP.
Registros de índice:
ESI y EDI: estos registros se utilizan para acceder a posiciones de memoria, por ejemplo cuando queremos trasferir datos de un lugar a otro o cuando queremos comparar dos bloques de memoria contigua. ESI actúa como puntero al origen (source) y EDI como puntero al destino (destination).
Podemos acceder a los bytes inferiores con SI y DI.

Los flags:

Las banderas también son un registro de 32 bits, donde cada uno de estos bits tiene un significado propio, que generalmente son modificados por las operaciones que realizamos en el código, y los cuales se los utiliza para tomar decisiones en base a las mismas: comparaciones, resultados negativos, resultados que desbordan los registros, etc.

C (Carry o acarreo): se pone a uno cuando se efectúa una operación que no cabe en el espacio correspondiente al resultado.

P (Paridad): se pone a uno cuando se efectúa una operación cuyo resultado contiene un número par de bits con el valor 1.

A (Auxiliar): similar al de acarreo (C), pero para las operaciones efectuadas con números en formato BCD (Binary Coded Decimal), o sea decimal codificado en binario.

Z (Cero): se pone a uno cuando se efectúa una operación cuyo resultado es cero. Ojo con esto porque a veces confunde, si se pone en cero, el resultado es distinto de cero y viceversa.

S (Signo): se pone en uno si el resultado de una operación da como resultado un valor negativo

T (Detención): si está en uno el procesador genera automáticamente una interrupción después de la ejecución de cada instrucción, lo que permite controlar paso a paso la ejecución del programa.

D (Dirección): en este caso este flag no cambia por acciones realizadas, sino que lo modificamos desde nuestro código para afectar ciertas operaciones, ya que indica la dirección a utilizar en ciertos comandos (hacia adelante o hacia atrás), como por ejemplo en comparaciones de bloques de memoria contiguos. Para modificarlo utilizamos las instrucciones std y cld, que luego veremos.
O (Overflow o desbordamiento): se pone a uno cuando se efectúa una operación cuyo resultado cambia de signo, dando un resultado incorrecto.


Las instrucciones básicas:

Veremos algunas instrucciones básicas lo cual es esencial comprendas el funcionamiento de estas y aunque no es necesario las guarden de memoria pues podrían regresar a consultar este escrito en cualquier momento que surjan las dudas, veamos:

nop (No Operation): este comando literalmente no hace nada, su utilidad es para rellenar huecos en el código o para ocupar ciclos del procesador.

mov (Move): esta instrucción tiene dos operandos, y lo que hace es copiar el origen (representado en segundo lugar) en el de destino (en primer lugar). Por ejemplo si ponemos:
ejemplo:
“mov     eax, 24”
mov ecx, eax “
Lo que estamos haciendo aquí es mover el 24 al registro eax, para después mover el contenido del registro eax, al registro ecx.

xchg (Exchange): intercambia los contenidos de los dos operandos.

inc (Increment) / dec (Decrement): incrementan y decrementan respectivamente el valor indicado en el operando.

add (Add): suma los contenidos de sus dos operandos y coloca el resultado en el operando representado en primer lugar.

adc (Add with Carry): igual que la anterior, pero suma también el valor del flag de acarreo. Se utiliza para sumar valores mayores de 32 bits.

sub (Subtract): esta instrucción resta el contenido del segundo operando del primero, colocando el resultado en el primer operando.

sbb (Integer Subtraction with Borrow): esta instrucción es una resta en la que se tiene en cuenta el valor del flag de acarreo.

mul (Unsigned Multiply) / imul (Signed Multiply): estas instrucciones se utilizan para multiplicar dos valores. La diferencia entre las dos, es que en la primera no se tiene en cuenta el signo de los factores, mientras que en la segunda sí.

div (Unsigned Divide) / idiv (Signed Divide): Divide dos valores, y al igual que para mul hay dos instrucciones: una considera el signo, la otra no.

push (Push Onto the Stack): esta instrucción resta del registro ESP la longitud de su operando que puede ser de tipo word o double word (4 u 8 bytes), y a continuación lo coloca en la pila. Tiene unas variantes como pushad y pushf para guardar los valores de los registros y los valores de los flags.

pop (Pop a Value from the Stack): es la inversa de push, es decir que incrementa el registro ESP y retira el valor disponible de la pila y lo coloca donde indica el operando.

and (Logical AND) / or (Logical Inclusive OR) / xor (Logical Exclusive OR) / not (Negation): realiza estas operaciones lógicas bit a bit entre los operandos.

cmp (Compare): esta instrucción compara dos valores. Generalmente se utiliza acompañada de un salto condicional de acuerdo al resultado de esa comparación.

jmp (Inconditional Jump): indica un salto que no está sujeto a ninguna condición, es decir que se ejecuta siempre.
jz / je / jne / etc. (Conditional Jump): estas instrucciones se ejecutan condicionalmente de acuerdo a los valores de los flags.

call  (Call Procedure): efectúa el salto al punto de inicio de una subrutina. Además de esto, coloca en la pila la dirección de la instrucción siguiente, que será el punto de regreso después de ejecutarse la misma.

ret (Return from Procedure): complementa a la anterior y sirve para regresar a la instrucción siguiente a la que llamó a la subrutina. Para ello, efectúa un salto a la dirección contenida en la pila, quedando ésta como estaba antes del call.

loop (Loop According to ECX Counter): esta instrucción efectúa un bucle o loop un número de veces determinado por el registro ECX. Lo que hace esta instrucción es decrementar ECX, si llegó a cero sale del bucle, sino salta a la dirección indicada en la instrucción.

rep (Repeat): se utiliza en combinación con otra instrucción, lo que hace es repetir la misma la cantidad de veces indicada por ECX. Se utiliza por ejemplo con movsb, lodsw, etc.


Instrucciones de flags

clc (Clear Carry Flag): pone a cero el flag de acarreo (CF).

stc (Set Carry Flag): pone a uno el flag de acarreo (CF).

cld (Clear Direction Flag): pone a cero el flag de dirección (DF).

std (Set Direction Flag): pone a uno el flag de dirección (DF).

cli (Clear Interrupt Flag): pone a cero el flag de interrupción (IF).

sti (Set Interrupt Flag): pone en uno el flag de interrupción (IF).


Bien algo complicado si nunca has ocado este lenguaje, pero no se preocupen que no es necesario aprenderlo de memoria, podras regresar en cualquier momento si tienes dudas cuando continuamos, lo importante es que vayas adaptandote en este lenguaje.
Hasta aqui llego esta primer parte, pero aún no termina la parte pesada en el proximo hablaremos de la estructura PE y durante ese mismo comenzaremos algo ligero y mas divertido sobre los comienzos del desarrollo, asi que no desesperen ya que todo esfuerzo tiene una recompensa.

CREANDO MALWARED DESDE CERO 0

Bien les cuento, la idea de hacer una introducción (serie de tutoriales) sobre desarrollo de malware en un entorno de  windows x86 desde ASM que al parecer serán muchas partes ya que es un tema grande aun siendo solo una introducción nace desde hace un tiempo y de lo que siempre me invitaban a escribir al respecto cuando fui moderador en indetectables.net y hackxcrack.es , lo cual por cierto les recomiendo, son grandes foros relacionados a la inseguridad informática donde se habla de seguridad web, reversing/cracking, malware, exploits, etc , donde ronda gente grande en los temas, por ejemplo estuvo por ahí mi buen amigo German Sánchez  mejor conocido por otros en su web www.enelpc.com y que actualmente forma parte del equipo del gran Chema Alonso en elevenpaths (que muchos conocen y no hace falta presentación), así como el muchos otros colegas que hacían la estancia dentro del foro muy agradable con aportaciones muy buenas, lamentablemente por falta de tiempo he decidido alejarme un poco; regresando en lo que estaba, una introducción la cual también me inspiro a escribir sobre este tema es la de hace varios años redactada por fabio escudero (zeropad) al cual le mande un mail  para comentarle de mi proyecto y su respuesta fue “la idea es compartir información con la mayor cantidad de personas y que entre todos aportemos nuestro granito de arena.” y me ofrecio su ayuda en caso de necesitarla ,  claro que este será un tema algo parecido pero van cambiando muchas cosas a nuestro modo 3:).

El objetivo principal de esta serie de tutoriales que se irán liberando por partes es que al término se comprenda como funciona internamente un malware; comprendiendo paso a paso como se desarrollan y como es que realizan los procesos de infección y si todo marcha bien ustedes puedan desarrollar una muestra desde cero y ya obtenidos los conocimientos así apoyarse en el momento de querer analizar un malware a mano, empezaremos armando nuestro laboratorio y  explicare instrucciones basicas de ASM,  la estructura de los binarios win32, la cabecera, secciones, movimientos en memoria, uso del debugger, inyecciones de código hasta concluir con el desarrollo del bicho con un cifrado simple y quizás terminemos con algo mas complejo..

Esta primer parte empezaremos a armas nuestra mesa de trabajo, conociendo las herramientas y configurando en caso de ser necesario, ya teniendo todo listo podríamos pasar con detalles importantes para después empezar con el desarrollo de los bichos.

Laboratorio:

Maquina virtual: Windows 32 bits  ( windows xp o windows 7)

Masm32 –

(Pack Masm32 + Radasm)

Radasm (IDE) –

OllyDebugger 1.10 -

Todas las herramientas que usaremos para empezar son gratuitas y pueden ser descargadas sin problemas.

Conociendo y configurando las herramientas:

Masm32 , El Microsoft Macro Assembler (MASM) es un ensamblador para la familia x86 soportó una amplia variedad de facilidades para macros y programación estructurada, incluyendo construcciones de alto nivel para bucles, llamadas a procedimientos y alternación, este lenguaje es el que usaremos y el que mejor manejo, en la parte de abajo en la zona de “referencias” agregare algunos enlaces de tutoriales para que practique ligeramente sobre como desarrollar en masm que hoy en día sigue siendo de los assemblers más populares.

Ahora hablemos de nuestro IDE Radasm, les cuento, Radasm es un entorno integrado de desarrollo que nos permite programar en diferentes lenguajes pero en este caso usaremos únicamente MASM.

Para pasar a la parte de instalación he decidido usar una mini tool desarrollada por RVLCN que facilita instalar Masm32 en conjunto con Radasm (nuestro IDE) ya configurado en un solo paso:

Ya descargado desde el enlace de arriba, al correr la aplicación nos aparece la pantalla inicial

Seleccionamos la casilla “Instalar Radasm” seleccionamos ruta a instalar y presionamos “instalar” , al terminar nos dira que ha terminado y listo con eso nos ahorramos unos min.

Ya una vez instalado podríamos ir a la carpeta donde lo hemos instalado y abrimos el ejecutable “Radasm.exe”  para probar si ya esta todo configurado y listo para empezar a desarrollar

Ahora seleccionamos en el menú “Archivo- Nuevo Proyecto” y nos aparecerá una ventana como esta:

Seleccionamos “Win32 app” y escribimos el nombre y descripción de nuestro proyecto, al presionar siguiente nos aparecera un lista con las plantillas disponibles:

Seleccionamos “Dialog app” que en este caso es la que nos interesa para probar, y si todo marcha bien nos mostraría una ventana de dialogo predeterminada, al presionar siguiente tendriamos todo el codigo que mas adelante explicare de que trata todo este rollo de codigo que es el que no hace mostrar una simple ventana de dialogo, presionamos “CTRL + f5″ y veamos:

Listo todo marcha bien y nos ha mostrado la ventana de dialogo tal cual esperabamos, por lo tanto todo está bien configurado.
Ahora les platicare acerca del debugger que usaremos, para los que no lo conozcan les platicare de él; Olly debugger es un debugger para programas en Windows de 32 bits y este es para trabajar en ring 3

Los procesadores X86 de Intel y compatibles tienen 4 niveles de privilegio:

Ring 0: mayor privilegio (nivel kernel), sobre este se ejecuta el sistema operativo
Ring 1
Ring 2
Ring 3: menor privilegio (nivel usuario)

Win32 solamente soporta ring 0 y ring 3, pero nosotros trabajaremos en nivel de usuario (ring 3)  por eso de mayor compatibilidad y además que debemos comenzar por un nivel muy basico, cabe mencionar que algunos bichos (rootkits) que se ejecutan en ring 0 son muy poderosos y empezar a jugar con nivel kernel y hacer mal resultaría desastroso.
Cuando trabajamos con ring 3 estaremos invocando a las API’s de Windows (de las que les explicare mas adelante)  y estas entraran a nivel kernel (ring 0) a ejecutarse y después retornar a nivel usuario, de esta forma nos aísla del ring 0.

Ya descargado nuestro debugger seleccionamos en el menú “file – open” y seleccionamos un ejecutable (el que sea) y veríamos algo como esto:




Es esencial conocer las partes de nuestro debugger, sigamos y les explicare una barra de los botones de nuestro debugger:

L: log data, muestra un detalle de lo que va haciendo el Olly (cuando arranca el programa, cuando genera un error, etc.)

E: executable modules, muestra todos los módulos que utiliza el programa debuggeado, el propio exe, las librerías que carga, etc.

M: memory map, como su nombre lo indica nos muestra un mapa de la memoria donde está nuestro programa, las dll que utiliza, etc.

T: threads, nos muestra los hilos de ejecución que utiliza nuestro proceso (esto lo vamos a ver luego con mas detalle)

W: windows, nos muestra las ventanas que tiene abiertas el programa

H: handles, son los manejadores que utiliza nuestro programa (también lo vamos a ver bien mas adelante)

C: cpu, la pantalla principal del Olly

/: patches, muestra los parches que se aplicaron al programa

K:  call stack of main thread, muestra los distintos calls a los que vamos entrando

B: breakpoints, nos muestra los distintos breakpoints que hemos puesto en nuestro programa (lo que hacen es interrumpir la ejecución y darle el control al debugger)

R: references, nos muestra las referencias cuando realizamos alguna búsqueda

Bien ahora configuraremos nuestro debugger de tal forma que se nos haga mucho mas comodo trabajar con él, para los que ya han tomado clase conmigo en el área de cracking de la certificación ya les será mas fácil hacer todo este procedimiento ;), para los que no, les explico vamos a la pantalla “disassemble” y damos click derecho nos aparecerá un menú en el cual haremos lo siguiente:

Bien esto es para que nos remarque con colores algunos saltos condicionales, incondicionales y llamadas, y quedara algo asi:

Lo que están remarcados como les explique son algunos saltos condicionales e incondicionales como los son (JNZ, JE, JMP,etc), también se han remarcado las llamadas (call). Lo que sigue es en el menú “options” del debugger modificar lo siguiente:

Esto es para que tengamos un cómodo control de a dónde se dirige el flujo del programa, mostrándonos una flecha al estar encima de algún salto condicional también nos indicara si el salto será tomado o no, algo como esto:

Creo que por ahora hemos terminado la parte del laboratorio y configurar las primeras y mas importantes herramientas (aunque despues en el transcurso agregaremos otras mas), les advierto que la segunda y tercer parte son las mas intensas y  pesadas de todo el curso, ya que trataremos temas como lenguaje ensamblador, estudio de la cabecera PE, estructura de los binarios, y conceptos de windows y demas detalles que son muy interesantey esenciales pero a veces un dolor de cabeza si no nos gusta leer. Aproximadamente para la cuarta parte en adelante estaremos entrando de lleno a programar nuestro primer bicho! metodos de inyeccion  y conceptos basicos de cifrado.