El malware bancario Emotet: desarrollo de la amenaza

El verano de 2014 la compañía Trend Micro anunció que había descubierto una nueva amenaza, el troyano bancario Emotet. En la descripción se indicaba que el programa malicioso interceptaba el tráfico para robar datos de las cuentas de los usuarios. Le daremos a esta modificación el nombre condicional de “Versión 1”.

El otoño del mismo año, nuestra compañía descubrió una nueva versión de Emotet, que nos llamó la atención por lo siguiente:

• Los creadores del troyano empezaron a usar tecnologías de robo automático de dinero de las cuentas de las víctimas, con una tecnología denominada “autogiro”.
• El troyano tenía una estructura modular: se componía de un módulo de instalación, un módulo de troyano bancario, un módulo dedicado al robo de contactos de MS Outlook y un módulo destinado a organizar ataques DDoS (Nitol DDoS bot).
• Los creadores del troyano hicieron esfuerzos para pasar desapercibidos: de una forma consciente no atacaban a los usuarios de la zona RU, los ataques estaban dirigidos a bancos alemanes y austriacos (otros conocidos troyanos bancarios no se caracterizan por escoger sus blancos), el nombre de dominio del servidor de los “autogiros” del troyano cambiaba con frecuencia (una o varias veces al día).

De aquí en adelante llamaremos “Versión 2” a esta modificación de Emotet (cuyo bot contiene y transmite al servidor de administración las cifras 1 y 7, lo que por lo visto significa que el autor del troyano considera que esta es la compilación versión 1.7).

Ambas versiones del troyano atacaban a los clientes de bancos alemanes y austriacos.

Hemos venido haciendo un atento seguimiento a la versión 2 de Emotet, pero en diciembre de 2014 dejó de estar activa, porque los servidores de administración dejaron de contestar a los equipos infectados. La última instrucción enviada desde los centros de administración la registramos el 10.12.2014 a las 11:33:43, hora de Moscú.

Pero la seriedad con que los autores de este troyano enfrentaron su desarrollo y el alto nivel de automatización de su funcionamiento no dejaban dudas de que esto todavía no era el fin. Y así resultó ser. Después de una breve pausa, Emotet ¡apareció de nuevo! Le asignaremos el nombre provisional de “Versión 3” a esta modificación de Emotet (cuyo bot contiene y transmite al servidor de administración las cifras 1 y 16, lo que por lo visto significa que el autor del troyano considera que esta es la compilación versión 1.16).

En esencia, Emotet versión 3 no se diferencia mucho de la versión 2. Las principales diferencias atañen al nivel de camuflaje del troyano, que es mayor. Entre las novedades que notamos, destacamos las siguientes:

• El troyano tiene una nueva llave RSA pública, y a pesar de que los protocolos de comunicación que Emotet versión 2 y 3 usa para conectarse a los centros de administración son idénticos, si se usa una llave antigua, el bot no recibirá una respuesta correcta del centro de administración.
• Los escenarios (scripts) de los autogiros están parcialmente limpios de información de depuración y comentarios.
• ¡Nuevos blancos! Emotet ahora tiene también como blanco a los clientes de bancos suizos.
• Ha sufrido un ligero cambio la tecnología de incrustación de código en el espacio de direcciones de explorer.exe. La versión 2 usaba el esquema clásico de incrustación de código: OpenProcess+WriteProcessMemory+CreateRemoteThread. La versión 3 usa sólo dos pasos del esquema anterior – OpenProcess+WriteProcessMemory; el lanzamiento de la incrustación del código se hace modificando el código de la función ZwClose en el espacio de direcciones del proceso explorer.exe, algo que también se logra usando WriteProcessMemory.
• Emotet versión 3 se resiste a que lo diseccionen: si el troyano detecta que lo han lanzado en un equipo virtual, siguen funcionando como de costumbre, pero usa otra lista de direcciones de servidores de administración. Pero todas estas direcciones son falsas y sirven sólo para engañar a los investigadores.
• El troyano casi no contiene renglones de texto: todos los renglones que pudiesen alertar a los investigadores están cifrados mediante RC4 y se descifran en la memoria asignada justo antes de su uso, después del cual se destruyen.

En general, tenemos la impresión de que en la versión 2 se puso a prueba en condiciones reales las principales tecnologías usadas por el troyano bancario y esta versión se usó como base para escribir la versión 3, que pasa mucho más desapercibida.

Los productos de Kaspersky Lab detectan este troyano, sin importar su versión, como Trojan-Banker.Win32.Emotet. Además, detectamos aparte los componentes de Emotet:

• El módulo de modificación del tráfico HTTP(S), como Trojan-Banker.Win32.Emotet.
• El módulo spam, como Trojan.Win32.Emospam.
• El módulo de recolección de direcciones de correo, como Trojan.Win32.Emograbber.
• El módulo de robo de cuentas de correo electrónico, como Trojan-PSW.Win32.Emostealer.
• El módulo destinado a la organización de ataques DDoS, como Trojan.Win32.ServStart.

En lo que se refiere a este último módulo, destacamos los siguientes aspectos: también lo hemos visto usado en combinación con otros programas maliciosos. Suponemos que es un cripter el que lo agrega a Emotet. Es muy posible que los autores de Emotet no sepan nada sobre la presencia de este módulo en su software malicioso. Sea como sea, los centros de administración de este módulo no responden y el módulo no se actualiza (fecha de compilación: 19 de octubre de 2014).

Infección

En este momento conocemos una sola vía de propagación del troyano bancario Emotet, mediante el envío masivo de mensajes spam con adjuntos o enlaces maliciosos.

Los adjuntos son archivos ZIP comunes y corrientes, dentro de los cuales está el descargador de Emotet. Los ficheros dentro de los archivos tienen un nombre largo, por ejemplo rechnung_november_2014_0003900028_2014_11_0029302375471_03_444_0039938289.exe. Esto está hecho a propósito: el usuario que abre el archivo en el navegador estándar de Windows puede no ver la extensión .exe, ya que parte del nombre del fichero puede no visualizarse. A veces no hay adjunto, y en el texto del mensaje hay un enlace a un fichero o archivo ejecutable malicioso.

Más abajo ponemos ejemplos de mensajes usados para propagar el troyano Emotet.

Versión 2 (enlace al programa malicioso):

Versión 2 (archivo adjunto):

Versión 3 (enlace al programa malicioso):

Los mensajes que hemos descubierto son una imitación casi exacta de mensajes de compañías conocidas, como DHL International GmbH y DHL International GmbH. Incluso las imágenes contenidas en los mensajes se descargan desde los servidores oficiales telekom.de y dhl.com.

Si el mensaje contiene un enlace a un fichero malicioso, se lo descargaba desde las direcciones de sitios legítimos, pero hackeados.
hxxp://*******/82nBRaLiv (para la versión 2)
o
hxxp://*******/dhl_paket_de_DE и hxxp://*******/dhl_paket_de_DE (para la versión 3).

En Emotet versión 3, al hacer una solicitud tipo hxxp://*/dhl_paket_de_DE, se enviaba al usuario un archivo ZIP desde una dirección similar a
hxxp://*/dhl_paket_de_DE/dhl_paket_de_DE_26401756290104624513.zip.
El archivo contenía un fichero EXE con un nombre largo (para camuflar la extensión y el ícono de documento PDF).

Descarga del troyano

El fichero del troyano está empaquetado por un cripter, cuya principal función es confundir al antivirus. Una vez lanzado y procesado el cripter, transfiere el mando al módulo principal del descargador de Emotet. Éste debe afianzarse en el sistema, conectarse al servidor de administración, descargar módulos adicionales y ejecutarlos.

La consolidación en el sistema se realiza de una forma bastante estándar: Emotet versión 2 se guarda a sí mismo en “%APPDATA%Identities” con un nombre aleatorio de 8 caracteres (por ejemplo wlyqvago.exe), se agrega a la carpeta de autocarga (HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun) y borra su fichero mediante la ejecución de un fichero bat, que se crea en %APPDATA% con el nombre “ms[7_cifras_al_azar].bat”.

Emotet versión 3 se guarda a sí mismo en “%APPDATA%Microsoft” con un nombre similar a “msdb%x.exe” C:Documents and SettingsAdministratorApplication DataMicrosoftmsdbfe1b033.exe), se agrega a la carpeta de autocarga (HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun) y se borra a sí mismo mediante la ejecución de un fichero bat (que se crea en %APPDATA%del%x.bat).

Después de consolidarse en el sistema, Emotet recibe la lista de los nombres de todos los procesos iniciados y calcula el hash del nombre de cada proceso, comparándolo con el valor 0xB316A779, que es el hash usado por el nombre del proceso explorer.exe. De esta manera Emotet encuentra el proceso al que incrustará su cuerpo. A continuación el troyano descarga su cuerpo principal y lo incrusta en el proceso explorer.exe.

Comunicación con el centro de administración

El principal módulo del troyano (el descargador) se comunica con el servidor de administración usando cifrado RC4.

El puerto al que se dirige el descargador está indicado de forma inequívoca en su código: 8080.

Direcciones de los centros de administración

Las direcciones IP de los servidores de administración de Emotet están estrictamente especificadas en el código del bot. Son varias y en uno de los ejemplares de la versión 2 eran 30 (remarcamos que 3 direcciones de la lista de abajo pertenecen a recursos legítimos conocidos):

hxxp://109.123.78.10
hxxp://66.54.51.172
hxxp://108.161.128.103
hxxp://195.210.29.237
hxxp://5.35.249.46
hxxp://5.159.57.195
hxxp://206.210.70.175
hxxp://88.80.187.139
hxxp://188.93.174.136
hxxp://130.133.3.7
hxxp://162.144.79.192
hxxp://79.110.90.207
hxxp://72.18.204.17
hxxp://212.129.13.110
hxxp://66.228.61.248
hxxp://193.171.152.53
hxxp://129.187.254.237
hxxp://178.248.200.118
hxxp://133.242.19.182
hxxp://195.154.243.237
hxxp://80.237.133.77
hxxp://158.255.238.163
hxxp://91.198.174.192
hxxp://46.105.236.18
hxxp://205.186.139.105
hxxp://72.10.49.117
hxxp://133.242.54.221
hxxp://198.1.66.98
hxxp://148.251.11.107
hxxp://213.208.154.110

En la versión 3 que analizamos, los centros de administración eran 19:

hxxp://192.163.245.236
hxxp://88.80.189.50
hxxp://185.46.55.88
hxxp://173.255.248.34
hxxp://104.219.55.50
hxxp://200.159.128.19
hxxp://198.23.78.98
hxxp://70.32.92.133
hxxp://192.163.253.154
hxxp://192.138.21.214
hxxp://106.187.103.213
hxxp://162.144.80.214
hxxp://128.199.214.100
hxxp://69.167.152.111
hxxp://46.214.107.142
hxxp://195.154.176.172
hxxp://106.186.17.24
hxxp://74.207.247.144
hxxp://209.250.6.60

Comunicación con el servidor de administración durante la ejecución en un equipo virtual

Emotet versión 3 contiene una lista más de direcciones de los “centros de administración”, que luce así:

p>hxxp://142.34.138.90
hxxp://74.217.254.29
hxxp://212.48.85.224
hxxp://167.216.129.13
hxxp://91.194.151.38
hxxp://162.42.207.58
hxxp://104.28.17.67
hxxp://8.247.6.134
hxxp://5.9.189.24
hxxp://78.129.213.41
hxxp://184.86.225.91
hxxp://107.189.160.196
hxxp://88.208.193.123
hxxp://50.56.135.44
hxxp://184.106.3.194
hxxp://185.31.17.144
hxxp://67.19.105.107
hxxp://218.185.224.231

El troyano trata de enviar solicitudes a estas direcciones si descubre que se lo está ejecutando en un equipo virtual. Pero ninguna de estas direcciones es la dirección correcta de un centro de administración, y el bot no logra ningún resultado cuando intenta comunicarse con ellos. Lo más probable es que esto se haya hecho para engañar al investigador y hacerle creer que los servidores de administración del troyano están muertos. Un truco parecido se usó anteriormente en el célebre troyano bancario Citadel.

La detección de los equipos virtuales está organizada de una forma bastante sencilla, según los nombres de los procesos típicos de las diferentes máquinas virtuales. El hash del nombre de cada proceso en el sistema se calcula usando el siguiente algoritmo:

Algoritmo de cálculo del hash del nombre del proceso

El valor del hash obtenido se compara sucesivamente con una lista de valores almacenados en el troyano:

Hash de los nombres de los procesos usados para detectar máquinas virtuales

Nosotros hemos calculado los nombres de procesos para algunos hashes. Así, el hash 0xBCF398B5 corresponde al proceso vboxservice.exe; el hash 0x2C967737, al proceso vmacthlp.exe; el hash 0xE3EBFE44, al proceso vmtoolsd.exe y el proceso 0x61F15513 al proceso vboxservice.exe.

Datos transmitidos

Una solicitud al centro de administración luce de la siguiente forma en el tráfico (para la versión 2, pero las solicitudes de la versión 3 son similares):

Diálogo entre el bot de Emotet y su centro de administración

La ruta URL a la que se dirige el bot tiene el siguiente aspecto: «/722ffc5e/355c7a0a/», donde 722ffc5e – es una cifra que se calcula basándose en la información del marcador de acceso del usuario, y 0x355c7a0a = 0x722ffc5e xor 0x47738654 (el valor 0x47738654 está indicado explícitamente en el cuerpo del bot).

Los datos transmitidos por el bot y el centro de administración están cifrados mediante RC4 y las respuestas del centro de administración tienen firma digital. Es posible que esto se haya hecho para hacer más difícil interceptar el control sobre el botner: para que un paquete sea aceptado por el bot, debe estar firmado, lo que requiere contar con una llave secreta.

En el cuerpo del bot se encuentra la llave pública RSA. En el formato PEM para la versión 2 luce así:

Representación PEM de la llave RSA abierta contenida en el cuerpo del bot versión 2

Como ya hemos mencionado más arriba, en la versión 3 la llave era otra. En el formato PEM tiene el siguiente aspecto:

Representación PEM de la llave RSA abierta contenida en el cuerpo del bot versión 3

Para enviarse al servidor, el paquete se forma así:

1. Se genera una solicitud que incluye un identificador del equipo infectado, ciertos valores que suponemos son la versión del bot, información sobre el sistema (versión del sistema operativo, versión de los service packs, tipo de producto), un dword específico (cuyo valor en el ejemplar estudiado es 7), las sumas de control del módulo bancario e información sobre las inyecciones web. La información sobre las inyecciones contiene: la dirección de la página (con caracteres comodines) a la que hay que hacer la inyección; los datos precursores de los inyectados; los datos que van después de los inyectados y los datos inyectados en sí.
2. Una vez formada la solicitud, se calcula su hash SHA.
3. La solicitud se cifra mediante una llave RC4 de 128 bits generada al azar.
4. La llave RC4 generada se cifra mediante una llave RSA abierta.
5. El paquete resultante es una concatenación de los resultados obtenidos en los pasos 4, 2 y 3.

De esta manera, el paquete de la solicitud se puede representar en forma de esquema:

Estructura de la solicitud que el bot envía al servidor

En la respuesta del servidor llega un paquete con la siguiente estructura:

Estructura de la respuesta del servidor al bot

La respuesta puede contener información sobre las inyecciones web de Emotet, los módulos de Emotet y enlaces para descargar módulos externos (por ejemplo, un bot spam o actualizaciones del descargador).

Módulos

Como la aplastante mayoría de los modernos troyanos bancarios, Emotet tiene una estructura modular. Hasta hoy, hemos detectado los siguientes módulos:

Algunos módulos pueden funcionar independientemente del módulo loader, porque no importan ningún dato desde el mismo.

Toda la estructura del bot evidencia el alto nivel de automatización de su funcionamiento: es automática la recolección de nuevas direcciones de correo electrónico en las libretas de contactos de las víctimas, es también automático el envío de spam desde el descargador de Emotet y el robo de dinero del usuario. La participación del operador está reducida al mínimo.

He aquí, por ejemplo, el informe que el módulo outlook_grabber (de la versión 2 de Emotet) envía al delincuente después de apoderarse de la libreta de direcciones de Outlook.

Libreta de direcciones de Microsoft Outlook robada y enviada al servidor de los delincuentes

Merece la pena destacar un aspecto positivo: al intentar conectarse con uno de los servidores de los delincuentes, llega una respuesta que contiene «X-Sinkhole: Malware sinkhole», lo que significa que los datos robados no caerán en sus manos, porque en este momento el dominio que usaba Emotet versión 2 ya no está bajo el control de los autores del troyano.

Pero la cuestión es diferente en la versión 3. Así luce el informe del módulo email_accounts_grabber que envía Emotet versión 3:

Informe que contiene datos sobre las cuentas de correo del usuario

Es evidente que el servidor responde “200 OK”. Esto significa que los delincuentes han recibido los datos transmitidos.

¡Danos tu dinero!

La información sobre los datos incrustados en la página recibida por Emotet luce así después de desempaquetarla:

Descifrado de datos sobre las inyecciones web de Emotet versión 2

Descifrado de datos sobre las inyecciones web de Emotet versión 3

La diferencia esencial en los datos sobre las inyecciones de diferentes versiones es la siguiente: Emotet versión 3 tiene como blanco a los clientes de las organizaciones de crédito suizas. Hasta el momento no hemos visto scripts destinados al robo automático de dinero de las cuentas de los clientes de estas organizaciones de crédito, pero estamos convencidos de que pronto se escribirán.

A pesar de que algunos fragmentos del código HTML en el paquete descifrado son fáciles de leer, es difícil entender las reglas de aplicación de las inyecciones web según los datos descifrados. Más abajo en el formato JSON están algunas reglas de inyecciones web para un blanco, el sitio de uno de los bancos alemanes (Emotet versión 2).

Reglas de inyecciones web en el sitio de un banco alemán (Emotet versión 2)

El resultado de aplicar esta inyección web es crear un nuevo elemento del tipo <div> que tendrá el tamaño de toda la parte visible de la página y agregar un nuevo script al documento HTML. En el ejemplo aducido, el script se descargaba desde la dirección hxxps://*******.eu/birten/luck.php?lnk=js&id=44.

Son similares algunas de las reglas de inyecciones para un nuevo blanco, el sitio de un importante banco austriaco (Emotet versión 3)

Reglas de inyecciones web en el sitio de un banco austriaco (Emotet versión 3)

Es evidente que la estructura del fichero de configuración de las inyecciones web es clásica: se usan campos llamados provisionalmente data_before, data_after y data_inject (es decir, los datos que van antes y después de los inyectados y los datos inyectados en sí).

Merece la pena destacar que la dirección del host en el que se encuentra el fichero luck.php (para la versión 2) y a_00.php (para la versión 3) cambia con frecuencia, pero el resto de la dirección del script es la misma. Si el investigador hace una solicitud directa al script, sólo recibirá un mensaje de error. Pero en un ataque real, cuando el renglón

se agregue en la verdadera página del banco, el script se descargará con éxito.

Esto sucede porque el servidor de los delincuentes verifica el campo “Referer” del encabezado de la solicitud HTTP y envía el script sólo si la solicitud llega de la página de alguno de los bancos atacados por Emotet.

Al poner el Referer necesario, se puede recibir fácilmente el código del script.

Nosotros en Kaspersky Lab hemos obtenido los scripts destinados a la inyección en las páginas de los bancos atacados.

Tabla 1. Los blancos de Emotet versión 2, tipos de ataque y números de identificadores de los scripts cargados para lanzar estos ataques.

Tabla 2. Los blancos de Emotet versión 3, tipos de ataque y números de identificadores de los scripts cargados para lanzar estos ataques.

En uno de los scripts de Emotet versión 2, que se usaba para lanzar ataques a uno de los bancos alemanes, en los comentarios había este renglón:

Artefacto del script usado para lanzar ataques a un banco alemán (Emotet versión 2)

Es evidente que los desarrolladores de los scripts del ataque hablan en ruso.

Evasión de la autentificación de dos factores

La principal función de los scripts analizados es hacer giros fraudulentos desde la cuenta del usuario. Sin embargo el bot no puede evadir el sistema de autentificación de dos factores (Chip TAN o SMS TAN) por su propia cuenta, y para hacerlo necesita la ayuda del usuario. Para engañar a la potencial víctima se usan trucos de ingeniería social: un mensaje inyectado a la página web mediante el script le dice al usuario que en el sitio se están realizando trabajos de implementación de un nuevo sistema de seguridad y que el usuario no puede usarlo si no toma parte en sus pruebas en régimen de demostración.

Mensaje falsificado sobre el nuevo sistema de seguridad

Después pedía ingresar los datos reales de Chip o SMS TAN para realizar un “giro de prueba”:

Y por último, felicitaba porque la transacción se había hecho con éxito:

En realidad, en vez de un giro de prueba, el script hace un giro real desde la cuenta de la víctima a la cuenta de una tercera persona, el así llamado “drop”, y el usuario por sí mismo lo confirma mediante Chip TAN o SMS TAN.

Los datos sobre las cuentas para recibir el dinero robado no se indican en el script, sino que llegan desde el servidor de administración de los delincuentes mediante una solicitud especial. Como respuesta el servidor de administración devuelve un renglón con información sobre el “drop” para cada transacción concreta. En los comentarios de uno de los scripts se encontró este renglón:

Es evidente que los delincuentes habían probado sus scripts transfiriendo 1500.9 EUR a la cuenta de prueba.

Además, en este script se encontró la siguiente información sobre el drop:

En el script correspondiente de Emotet versión 3, destinado a lanzar ataques al mismo banco, también se encontró información sobre el drop, pero esta vez era otro:

Comparemos los campos de JSON __DropParam y los campos en el formulario legítimo de acceso demo al sistema online del banco atacado.

Formulario del sistema RBS del banco para giros dentro de Alemania o en la zona Single Euro Payments Area (SEPA)

Tabla 3. Correspondencia entre los datos del drop y los campos en el formulario de transferencia de dinero; explicación de los valores de los campos

Los campos JSON __DropParam corresponden a los campos en el formulario.

De esta manera, el bot recibe toda la información necesaria sobre el drop desde su servidor y organiza la transferencia, mientras que el usuario engañado confirma el giro mediante Chip TAN o SMS TAN y se despide para siempre de su dinero.

Conclusión

El troyano Emotet es una amenaza bancaria altamente automatizada, que está en pleno desarrollo y tiene blancos en determinados territorios. Su pequeño tamaño, los mecanismos de autopropagación usados y su arquitectura modular hacen que Emotet sea un arma muy efectiva en manos de los delincuentes informáticos.

Sin embargo, este troyano bancario no usa tecnologías que sean fundamentalmente nuevas y por lo tanto, un antivirus moderno puede garantizar una protección fiable contra la amenaza que representa.

Además, este troyano bancario no puede funcionar con éxito sin que participe el usuario: los creadores de Emotet usan activamente métodos de ingeniería social para alcanzar sus objetivos delictivos.

De esta manera, la atención constante y la conciencia técnica del usuario, en combinación con el uso de un antivirus moderno, es la garantía de una protección fiable no sólo contra Emotet, sino también contra otras amenazas bancarias que funcionan de forma similar.

Algunos MD5

Emotet versión 2:
7c401bde8cafc5b745b9f65effbd588f
34c10ae0b87e3202fea252e25746c32d
9ab7b38da6eee714680adda3fdb08eb6
ae5fa7fa02e7a29e1b54f407b33108e7
1d4d5a1a66572955ad9e01bee0203c99
cdb4be5d62e049b6314058a8a27e975d
642a9becd99538738d6e0a7ebfbf2ef6
aca8bdbd8e79201892f8b46a3005744b
9b011c8f47d228d12160ca7cd6ca9c1f
6358fae78681a21dd26f63e8ac6148cc
ac49e85de3fced88e3e4ef78af173b37
c0f8b2e3f1989b93f749d8486ce6f609
1561359c46a2df408f9860b162e7e13b
a8ca1089d442543933456931240e6d45

Emotet versión 3:
177ae9a7fc02130009762858ad182678
1a6fe1312339e26eb5f7444b89275ebf
257e82d6c0991d8bd2d6c8eee4c672c7
3855724146ff9cf8b9bbda26b828ff05
3bac5797afd28ac715605fa9e7306333
3d28b10bcf3999a1b317102109644bf1
4e2eb67aa36bd3da832e802cd5bdf8bc
4f81a713114c4180aeac8a6b082cee4d
52f05ee28bcfec95577d154c62d40100
772559c590cff62587c08a4a766744a7
806489b327e0f016fb1d509ae984f760
876a6a5252e0fc5c81cc852d5b167f2b
94fa5551d26c60a3ce9a10310c765a89
A5a86d5275fa2ccf8a55233959bc0274
b43afd499eb90cee778c22969f656cd2
b93a6ee991a9097dd8992efcacb3b2f7
ddd7cdbc60bd0cdf4c6d41329b43b4ce
e01954ac6d0009790c66b943e911063e
e49c549b95dbd8ebc0930ad3f147a4b9
ea804a986c02d734ad38ed0cb4d157a7

El autor expresa su agradecimiento a Vladimir Kuskov, Oleg Kupreev y Yury Naméstnikov por su ayuda en la preparación de esta publicación.