A principios de septiembre tenía que escribir un artículo para presentarlo como propuesta para la certificación GOLD GCIA de GIAC (SANS). Este documento tenía que estar relacionado con el tráfico de red y la detección de intrusos, orientado al análisis forense.

Del conjunto de distintas ideas que tenía en mente, pensé en las veces que me había encontrado con un registro (log) de un servidor Web, en el que se requería emplear expresiones regulares usando listas blancas y negras de patrones que identificasen de entre todas las entradas del registro cuáles podían identificar un incidente de seguridad.

Adicionalmente a las listas negras y blancas, tenemos una serie de herramientas de detección de intrusos a nivel de sistema, donde dado un registro de un servidor es capaz de detectar alertas a partir de unas reglas previamente creadas. Un ejemplo de estas herramientas fue expuesto con anterioridad por José Luis Chica donde se empleó la herramienta OSSEC.

Teniendo en cuenta estos motores de reglas, uno de los entornos con mayor número de reglas son las herramientas de detección de intrusos a nivel de red, como por ejemplo Snort. El principal problema de las herramientas de detección de intrusos a nivel de red es que los datos de entrada requieren justamente eso: tráfico de red, pero el técnico dispone del registro del servidor y no del tráfico de red que lo generó.

Por tanto, para poder usar estos motores de reglas es necesario ser capaz de leer ese registro de entrada y a partir de éste, generar el tráfico de red oportuno, de forma que dicho tráfico de red pueda ser inyectado en una herramienta de detección de intrusos a nivel de red. Con esta idea programé una pequeña herramienta (prueba de concepto), la cual es capaz de leer el fichero de registro de un ISS, Apache, Nginx o IBM Web Seal y guardar en un fichero PCAP el tráfico de red que generó dicho registro.

Para entenderlo mejor vamos a ver un ejemplo de uso de la herramienta, donde se dispone de un registro de un servidor web Apache donde una IP atacante (y ficticia) ha realizado una auditoría Web con la herramienta Nikto:

Por ello vamos a proceder a usar la herramienta Log2Pcap para que recree el tráfico de red correspondiente al registro del servidor. Lo primero es indicar donde está el fichero del registro, que se trata de un servidor Apache, la IP y puerto del servidor Web que ha sido auditado:

Como resultado tenemos un fichero llamado “result.pcap” que ocupa 168 K. Dicho fichero ya puede ser leído por todas las herramientas de red que tengan la capacidad de leer el fichero PCAP, como por ejemplo Tcpdump o Tcpflow:

De la misma forma que puede ser inyectado en este tipo de herramientas, también puede ser inyectado en un Snort para que emplee el motor de reglas en búsqueda de posibles ataques:

Dando como resultado las siguientes alertas:

El código fuente de la herramienta lo podéis encontrar aquí mientras que la documentación la tenéis explicada aquí. Siento que el inglés no sea el mejor pero el documento fue escrito hace aproximadamente cinco meses.

Respecto a la evolución de la herramienta, la segunda versión está casi terminada. La herramienta ha sido prácticamente reescrita desde cero y se han añadido funcionalidades como poder inyectar el tráfico a un interfaz de red sin ser necesaria la creación del fichero PCAP, API orientada a objetos e integración con Plaso.

En lo concerniente a las limitaciones la más importante es obvia: se depende totalmente de la integridad y de la información almacenada en dicho registro. Durante el desarrollo de la herramienta caí en la cuenta que prácticamente la mayoría de servidores web no registran por defecto las variables enviadas por POST. Por lo tanto, aunque la herramienta está preparada para leer registros con parámetros POST, si el servidor no está configurado adecuadamente se está perdiendo mucha información. La segunda limitación viene dada al intentar establecer una línea de tiempo, puesto que en ningún momento la herramienta relaciona la alerta de Snort con la entrada del registro que generó la alerta.

Otro punto importante a entender es que la herramienta no pretende sustituir a las expresiones regulares, a los motores de detección de intrusos a nivel de host o cualquier otro método usado previamente. El objetivo de la herramienta es ofrecer otra opción más que pueda proporcionar más información al técnico que gestione el incidente.

Para evitar confusión quiero comentar que existe otra herramienta perteneciente al motor de Samba que usa el mismo nombre. La cual hace justamente lo que su nombre indica: coge un fichero samba y genera un fichero PCAP. He de reconocer que nunca he usado dicha herramienta y que no conocía la existencia de la misma. Ambas tienen propósitos totalmente distintos, protocolos distintos y nada en común. He mantenido el nombre Log2Pcap porque es la metodología de nombre empleado para este tipo de herramienta. Posiblemente en la segunda versión, y dada las nuevas funcionalidades, le cambiaré el nombre a LogWeb2Net.

Para finalizar agradecería que los lectores me enviasen el fichero log de cualquier otro servidor Web no soportado hasta la fecha, lógicamente anonimizado antes del envío. Con un par de líneas donde se traten diferentes métodos como GET y POST sería suficiente.

Recientemente un usuario del blog pregunto por qué en las reglas de detección de Malware con Snort, cuando se quiere detectar la consulta DNS hacia ciertos dominios sospechosos, se emplean ciertos caracteres y condiciones como la comprobación “byte_test:1, !&, 0xF8, 2;“. Para explicarlo vamos a tomar como ejemplo la siguiente regla VRT para la detección del malware Gauss:

alert udp $HOME_NET any -> any 53 (msg:"BLACKLIST DNS request for known malware domain 
bestcomputeradvisor.com - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; 
content:"|13|bestcomputeradvisor|03|com|00|"; fast_pattern:only; metadata:impact_flag 
red, policy balanced-ips drop, policy security-ips drop, service dns; 
reference:url,gauss.crysys.hu/; reference:url,www.securelist.com/en/blog/208193767

[Read more…]

Recientemente he tenido que jugar con la biblioteca Scapy para Python. Ésta permite crear cualquier tipo de paquete de red con un par de simples comandos, incluso para protocolos no existentes mediante paquetes RAW.

En este caso pondré de ejemplo la necesidad de tener que enviar paquetes TCP a un puerto determinando usando cualquier combinación de flags TCP, con el objetivo de evaluar el comportamiento de la pila TCP al recibir cualquier combinación de flags.

Hay que tener en cuenta que no estamos hablando de permutaciones, puesto que es lo mismo enviar un paquete con el flags Syn y Ack que enviar un paquete con los flags Ack y Syn. Sí, seguramente habrán recordado la frase “el orden de los factores no altera el producto“. Por tanto es necesario generar cualquier combinación teniendo en cuenta que el orden no afecta y que no se desea enviar más paquetes de los estrictamente necesarios.

[Read more…]

Hoy voy a contarles una historieta que me ha ocurrido con un dispositivo Thunderbolt, empleado en la mayoría de equipos de sobremesa o portatiles de la compañia Apple y cuyo diseño fue llevado a cabo por la compañía Intel. Este puerto fue presentado por Apple hace cosa de un año como alternativa al HDMI, USB y FireWire ya que emplea tecnología óptica que permite grandes tasas de transferencias de datos de entorno a 10Gbps empleando el puerto como multiuso: video de alta definición y transferencia de gran volumen de datos.

Como buen talibán, esto… aficionado de Apple que soy, adquirí el Mac Book Air nuevo (ahora ya viejo) con el nuevo puerto ThunderBolt, aunque no tuviera ningún dispositivo para este puerto todavía, el portátil y la propaganda lo valían. Para quien no conozca el portátil indicarle que no dispone de interfaz de red (RJ45) donde conectar un cable de red, pero Apple para subsanar este posible requisito vendía un adaptador USB para poder conectar el portátil a un cable de red, todo ello al módico precio de 29 euros. El problema de este dispositivo es que no permitía tasas de transferencia reales superiores a los 3mb/s, algo bastante lento si tenemos NAS en red y necesitamos copiar los videos de “nuestras vacaciones en alta definición” de 20GB por video (you known what I mean).

Por ello, Apple sacó recientemente un adaptador Thunderbolt a RJ45 donde se aseguraban unas transferencias de red de entorno a 60 MB/s, una gran mejora respecto al dispositivo USB. Como buen consumidor que soy, fui a la tienda de Apple Store a adquirir mi nuevo y flamante cacharrito al módico precio de ¿27 euros? ¿Cómo? Qué raro… hacía una semana habia visto que costaba 29 euros y no 27 euros. Pues mejor… supongo.

Fue entonces cuando llegó la sorpresa, llego a mi casa, conecto el dispositivo y… ¡no pasa nada! No me detecta nada, no hay nada; reviso las actualizaciones pendientes pero no hay actualizaciones pendientes. Es entonces cuando, después de santiguarme, busco en Google el motivo por el cual el dispositivo no funcionara, que claramente indica que necesito la versión software 1.2 del Thunderbolt desarrollaba exclusivamente para dar soporte al adaptador RJ45. El problema es que la actualización había desaparecido de la faz de la tierra. No se podia descargar de Apple Store y la página no estaba disponible.

Sigo buscando información y leo que la actualización estaba causando problemas a un gran número de usuarios, a los que les dañaba el arranque de Mac Os X. Esta es la razón de que Apple actuase de la mejor forma posible: eliminó la actualización, bajó 2 euros el precio del producto y dejó a los usuarios que habiamos comprado el dispositivo sin posibilidad de poder usarlo. Una semana después mi portátil me indica que hay una nueva actualización: “Actualización Thunderbolt 1.2”, que pasa de ocupar los 170K byte de su predecesora a 220Kbytes (aproximadamente, no recuerdo los valores de memoria). La gracia de todo esto es que Apple seguía llamandola igual que la que dañaba el arranque de algunos Mac OsX, es decir, ambas eran la 1.2 sin ninguna diferenciación entre ambas.

Resumiendo. Sacas un producto con un firmware que daña el arranque de algunos Mac OsX, de modo que en cierto modo tus clientes pasan a ser beta testers de tus productos, eliminas la actualización de tu producto sin notificarlo pero sigues vendiendo el producto en tu web aunque no pueda ser utilizado y para acabar de arreglarlo sacas el parche unas semanas después sin indicar nada en las release notes, como si aquí no hubiera pasado nada (si esto lo hace otro fabricante hubieramos visto la repercusión, pero en este caso era Apple: “Think different” con tu procesador Intel x86).

Como cualquier historia, esta también tiene moraleja. Vamos con ella.

Aunque en mi caso este problema no ha supuesto más que una pequeña molestia temporal que no era otra que no poder utilizar el adaptador comprado y seguir funcionando a la velocidad del caracol, cabe imaginar qué puede haber supuesto para una empresa cuya plataforma principal sea Apple, una actualización en masa del controlador de este dispositivo, dado que al parecer la solución planteada pasaba en general por la reinstalación del sistema operativo.

Aunque el personal de seguridad solemos hacer mucho énfasis en la necesidad de instalar los parches las actualizaciones que proporcionan los fabricantes, lo cierto es que esta práctica sólo hace frente, en general a una dimensión de la seguridad: la confidencialidad, mientras que puede, como en el ejemplo que comentaba, poner en riesgo otra como es la disponibilidad, probablemente mucho más importante cuando se trata de equipos de usuario final (donde la información está alojada en repositorios comunes y no en el propio equipo) de los cuales depende de manera directa la productividad.

Por tanto, la moraleja de la historia es que sin quitarle la importancia que se merecen a las actualizaciones de los fabricantes, su aplicación “descontrolada” puede dañar seriamente el funcionamiento de una organización. De ahí la necesidad de poner en marcha aplicaciones internas de distribución de actualizaciones (por ejemplo, tipo WSUS para Windows) y por supuesto, cuando nos vamos a entornos corporativos o servicios críticos, los parches deben ser aplicados siempre primero al entorno de preproducción y tras la verificación de funcionamiento, al de producción con su correspondiente gestión de cambios (como es natural deberá ser igual al de producción o de lo contrario estaremos haciendo el tonto).

No hay que olvidar nunca que, para bien o para mal, las combinaciones de hardware y software es tan grande que nuestro entorno puede tener características que el fabricante no haya tenido en cuenta o haya podido reproducir. Así que como siempre, mejor prevenir que curar.

Hace un año decidí alquilar una vivienda y como el resto de gente de a pie, decidí publicarlo en una web de venta y alquiler de inmuebles. Para ello procedí a registrarme introduciendo información básica como nombre, DNI, dirección, teléfono, etc. Adicionalmente tuve que emplear mis datos bancarios para pagar mejoras como “siempre visible / destacado”, publicar vídeos, imágenes de mayor resolución, primero en la búsqueda, etc.

Después de estar un buen rato entre subir fotos, ordenarlas y redactar la descripción de la vivienda me di cuenta que me habían enviado un correo de la web en donde había dado de alta el inmueble. Era el típico correo de bienvenida donde se me indicaba entre otra información mi usuario y mi contraseña, en texto en claro por supuesto.

Entonces tuve una idea fugaz: si me han mandado la contraseña en texto en claro… ¿no será porque la están almacenando en texto en claro? Y que mejor forma que confirmarlo que emplear los métodos de recuperación de contraseña ante una pérdida de la misma, así que me da por recordar la contraseña donde se indica literalmente “enviadme mi contraseña!”. ¡Sorpresa! Me envían al correo mi contraseña en texto en claro.

Lanzado como soy yo, me pongo en contacto con la web mediante correo electrónico y amablemente les indico que por favor cifren las contraseñas en la base de datos, a lo que recibo una contestación donde se me agradece la información proporcionada y que lo tendrán en mente como mejora.

Un año después he vuelto hacer la prueba y como supondrán todo sigue exactamente igual:

Lo siguiente era consultar con el Departamento de Consultoria de nuestra empresa, para preguntarles si era obligatorio cifrar las contraseñas, ya que aunque yo desde el punto de vista técnico lo tenía clarísimo, desde el punto de vista de la LOPD no lo tenía tan claro. La contestación fue que ese tipo de aspectos estaban regulados por el siguiente artículo:

Mi pregunta ahora es para ustedes. En calidad de usuario preocupado por la seguridad de sus datos, ¿debería informar a la Agencia Española de Protección de Datos o les envío un segundo correo para que me vuelvan a indicar que lo introducirán en sus mejoras próximamente? De momento ya les he mandado un segundo correo haciendo alusión al artículo 93, al que estoy esperando respuesta.

Les tendré informados.

Tras la primera parte que vimos el otro día, en esta entrada vamos a ver el uso de Security Manager y la correcta configuración del protocolo SSL sobre un Apache Tomcat.

Respecto al primero, vamos a configurar Security Manager para que restrinja el uso de ciertos métodos y clases que puedan implicar un riesgo para el servidor de aplicaciones. Estas restricciones se definen en el fichero catalina.policy. Para activar Security Manager será necesario añadir las siguientes dos entradas en el arranque de Tomcat:

-Djava.security.manager 
-Djava.security.policy=$CATALINA_BASE/conf/catalina.policy  

Nota: si se usa el script por defecto de arranque en vez de JSVC se debe añadir el tag -security, que realmente hace lo mismo: añadir las dos entradas anteriores.

Un ejemplo práctico de Security Manager sería una aplicación con un fallo de seguridad donde un posible atacante ha conseguido subir una Web Shell para intentar ejecutar órdenes en el servidor mediante el método Runtime.getRuntime().exec(). Al intentar ejecutar dicho método Security Manager impedirá su ejecución devolviendo la siguiente excepción:

java.security.AccessControlException: access denied

Donde sí se ha tratado adecuadamente la excepción, tal como se documento en la anterior entrada, únicamente se mostrara la página error.html cuando se intente ejecutar órdenes en el servidor mediante la Web Shell del atacante. Otro punto importante a tener en cuenta es la correcta configuración del registro de sucesos. Para ello se recomienda seguir los siguientes consejos:

• Aplicar una configuración adecuada para registrar la mayor información posible de los clientes que han realizado una solicitud a una aplicación del servidor Tomcat, añadiendo para ello la siguiente válvula al campo Host del fichero server.xml:

  <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    prefix="localhost_access." suffix=".log"
    resolveHosts="false"
    pattern="%t %h %H %m %s "%r" cookie:%{SESSIONID}c User- Agent:%{User-Agent}i " />
  

• Crear registros específicos para cada aplicación. Para realizar esta tarea es necesario especificar un fichero de logging.properties por cada aplicación desplegada en el directorio .../aplicacion/WEB-INF/clases/ donde aplicacion es el directorio de la aplicación. Dicho fichero tendrá la siguiente configuración:

  handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
  org.apache.juli.FileHandler.level = FINEST
  org.apache.juli.FileHandler.directory = ${catalina.base}/logs
  org.apache.juli.FileHandler.prefix = aplicacion.
  org.apache.juli.FileHandler.suffix = .log
  org.apache.juli.FileHandler.rotatable = true
  java.util.logging.ConsoleHandler.level = FINEST
  java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
  

• Emplear LOG4J para aquellas aplicaciones donde las librerías de registros por defectos de Tomcat no cumplan todos nuestros requisitos.

Para finalizar trataremos de configurar adecuadamente los conectores que empleen protocolos cifrados (conectores SSL) definidos en nuestro servidor de aplicaciones Tomcat siguiendo para ello los siguientes puntos:

• Forzar a los conectores que no cifran las comunicaciones a usar SSL mediante los siguientes pasos, llamado también redirección a conector SSL:

  1. En los conectores definidos en el fichero server.xml que no se empleen protocolo SSL se debe aplicar una redireccionan hacia un conector que emplee el puerto SSL:

  <Connector port="80" protocol="HTTP/1.1"
                  redirectPort="443"
  ...
  />
  <Connector port="443" protocol="HTTP/1.1"
                  scheme="https"
  ...
  />
  

2. Indicar que los métodos GET, POST y HEAD sean confidenciales añadiendo la siguiente entrada al fichero web.xml:

<web-app xmlns="http://java.sun.com/xml/ns/javaee" …>
...
    <security-constraint>
            <web-resource-collection>
                    <web-resource-name>Servidor Aplicaciones</web-resource-name>
                    <url-pattern>/*</url-pattern>
                    <http-method>GET</http-method>
                    <http-method>POST</http-method>
                    <http-method>HEAD</http-method>
           </web-resource-collection>
            <user-data-constraint>
                    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
            </user-data-constraint>
    </security-constraint>
</web-app>

• Impedir el uso de algoritmos y protocolos débiles. Para ello en la configuración de los conectores cifrados, definidos en el fichero server.xml, se deberá indicar que se desea usar TLS mediante la variable sslProtocol="TLS". Hay que tener en cuenta que el valor “TLS” en las últimas versiones de Tomcat identifica a la versión 1.1, y por tanto, acepta tanto TLS como SSL v3 pero no SSL versión 2, tal y como se especifica en la documentación del protocolo TLS v1.1.

  Será necesario definir que ciphers suite de los soportados por Java (ver enlace) se deben emplear. Estos presentan la siguiente forma:

  Proto_AlgClaveAsimetrica_WITH_AlgClaveSimetrica_tamClaveSim_AlgCompendio
  

Para esta restricción se pueden aplicar listas negras: aceptamos todos los algoritmos menos unos cuantos, como se recomienda en la entrada de SecurityByDefault, o se pueden aplicar listas blancas: solo permito los estrictamente indicados. Para gustos colores, pero en mi opinión prefiero aplicar listas blancas, es decir, indicar solo los que puedo usar.

En mi opinión, sin ser ni mucho menos un experto en algoritmos de cifrado, recomendaría usar TLS, algoritmos de curva elíptica o RSA como clave asimétrica, AES de 128 bits mínimo para clave simétrica y SHA como algoritmo de compendio:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

Por ello se definirán los cipher suite indicados con anterioridad en cada conector SSL creado en el fichero server.xml mediante la variable ciphers separados por comas:

<Connector port="443" protocol="HTTP/1.1"
scheme="https"
...
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA"
...
 />

Hay que tener en cuenta que para que pueda emplear algoritmos de curvas elípticas y algoritmos simétricos de más de 128 bits será necesario sustituir las librerías por defecto del Java JDK local_policy.jar y US_export_policy.jar por las suministradas en el paquete Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. Esto es debido a que por defecto el JDK está restringido a las leyes de EEUU donde no se permite más de 128 bits ni algoritmos de curva elíptica. Una vez sustituidas las librerías y reiniciado Tomcat ya se permitirá emplear dichos algoritmos, tal como se muestra a continuación:

$ openssl s_client -host localhost -port  443 -tls1 -cipher AES256-SHA
…
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
...

Con este par de pasos ya se dispondrá de un servidor Tomcat con una configuración de seguridad más o menos correcta ya que se han omitido una serie de configuraciones adicionales que se deberían aplicar para mejorar la seguridad del entorno, aspecto que queda fuera del contexto de esta entrada.

A raíz de la entrada de Guillermo Mir sobre el bastionado de Apache (parte I y parte II) y una entrada en el blog SecurityByDefault sobre cómo trabajar con SSL en Tomcat me he decidido a escribir una entrada sobre el bastionado de Tomcat que debía desde hace mucho tiempo a Manolo, quien no se olvidaba de recordármelo (N.d.E. como es mi obligación…).

En primer lugar indicar que la entrada se centrará en un correcto bastionado de Tomcat sobre un entorno Linux, puesto que sinceramente Tomcat en Windows no ofrece las mismas opciones, por muy Java que sea, que en un entorno Linux. Como documentar una guía de bastionado de Tomcat ocuparía muchas páginas, esta y la siguiente entrada tratará los principales puntos a tener en cuenta durante un bastionado adecuado. Para más información os remito a la documentación de Tomcat.

[Read more…]

Ayer domingo mientras pensaba qué excusa poner a mi compañero Raúl por lo del partido del Levante ante el Valencia —donde todo sea dicho de paso claramente nos robaron— me llegó un correo electrónico con una supuesta oferta de trabajo, tal como podemos ver en la siguiente imagen:

El enlace apuntaba a la siguiente dirección “http://anyhub.net/file/5r_v-oferta_838as32-pdf.exe”, donde como puede verse juega con la terminación “pdf” pero tiene extensión “exe”. Al analizar la cabecera del fichero vemos el “MZ” inicial típico de un ejecutable Windows; claramente todo apunta a Malware. Al buscar cadenas de texto en el binario mediante la herramienta “strings” vemos que el ejecutable contiene texto como el siguiente:

A la vista de estos primeros indicios, lo que hice fue introducir el fichero en una máquina virtual VMWare para ver qué es lo que realmente hace. Lo primero que observamos es que al binario le han puesto el icono de un PDF de Acrobat Reader para hacer pasar al fichero por PDF a ojos de un usuario inexperto:

Al hacer click sobre el fichero no se ejecuta aparentemente nada, simulando de esta manera que el fichero no se ha abierto correctamente. No obstante, si analizamos los procesos en ejecución vemos que realmente sí que se está ejecutando el programa:

Como hemos visto con la orden strings, parece ser que se trata de un troyano con claros síntomas de intentar obtener datos bancarios, por lo que ejecutamos Internet Explorer y comenzamos a navegar por distintas Webs, sin detectar nada anómalo hasta que entramos en una web bancaria, donde el navegador se cierra y nos aparece la siguiente ventana de Windows, bastante elaborada a nivel gráfico para simular ser una pantalla auténtica del sistema de seguridad de los sistemas Windows:

Al pinchar sobre “Aceptar” se abre una pequeña aplicación con título “Microsoft Internet Security Banking Connections”, tal como vemos en la siguiente captura:

Si se pincha sobre el botón inferior derecho “Activar a mi equipo la conexión segura…” se abre una nueva ventana donde se invita a introducir los datos de nuestra tarjeta de crédito. En nuestro caso se introdujeron (obviamente) datos falsos:

Tras esto, capturamos el tráfico de red que se generaba al hacer click sobre “Activar”, obteniendo como resultado que el malware emplea el recurso “send.php” de la web “elequipodelbarrio.com.ar”, enviando los datos de la tarjeta de crédito en la variable “data” por POST mediante protocolo HTTP. Esto puede verse en la siguiente captura de pantalla:

Al acceder a la web “elequipodelbarrio.com” vemos que aparenta ser una Web legítima con comentarios de varias personas incluidos, tal como se puede ver en la siguiente imagen:

Lo que hace pensar en dos posibles opciones: que la web haya sido comprometida o que se trate de una falsa web para no generar alarma. En mi caso procedí a enviar la alerta al CSIRT-Cv para que gestionasen la alerta temprana.

Para finalizar indicar que se trata de un troyano “típico” sudamericano, más enfocado a intentar engañar al usuario inexperto con pantallas y un entorno gráfico bastante conseguido, que a emplear métodos realmente complejos como es el caso habitual de los troyanos rusos. Lo que me ha llamado la atención es que al subir el binario a VirusTotal no me indicó que hubiera sido subido con anterioridad por otro usuario, y a su vez, que solo 6 de los 42 antivirus hayan reconocido al Troyano como tal:

Me gustaría poder realizar un reversing del troyano para saber si reconoce la URL bancarias por dirección de URL, por ciertos caracteres de texto que identifican un banco o por cualquier otro motivo, pero por desgracia mañana me llega un libro muy esperado “El temor de un hombre sabio” y es una tarea que va a tener que esperar unos días.