Malware con nombres de ficheros sospechosos

Mientras escribía el anterior post me empecé a plantear porque en el nombre de esos troyanos que habíamos recibido por e-mail se habían utilizado un chorro de "_"  justo después del nombre, terminado en .doc, y la extensión del fichero, que era la de un ejecutable de Windows, .exe; el objetivo, como ya mencioné, está claro, es el de confundir al usuario para que llegue a creer que lo que está recibiendo es un fichero de Word de Microsoft Office, es decir un .doc, haciendo énfasis la utilización del icono asociado al ejecutable de Word. Mi planteamiento no era el objetivo en sí, sino de porque utilizar guiones bajos y no utilizar espacios en blanco ya que seguramente es más fácil confundir a la posible víctima debido a su invisibilidad.

Así que, ya que me lo plantee, he decido probarlo y ver si realmente los espacios en blanco cumplirían mejor su objetivo que los guiones bajos utilizados y teniendo en cuenta la vista que estemos utilizando en explorador  de ficheros. Los resultados han sido los siguientes:

1. Vista detalles
   
   
   
   
   
   Como podemos ver en la imagen anterior, los espacios en blanco es la mejor opción para la eficacia del engaño. De los tres ficheros que aparecen, el de en medio no tiene ningún carácter entre el .doc y la extensión y en en el caso de no tener activada la opción de "Ocultar las extensiones de archivo para tipos de archivos conocidos" sería la más eficaz porque entonces no aparecerían los "..." en el extremo derecho de la columna "Nombre", pero teniendo dicha opción desactivada queda delatada la verdadera extensión del fichero, algo que es lo que pretenden evitar los espacios en blanco o lo guiones bajos.
   No obstante esta vista puede ser la que mejor convenga para detectar que realmente es un ejecutable, ya que en la columna "Tipo" aparece lo que realmente son los ficheros, así que si la posible victima ve eso, fácilmente puede detectar que se trata de un engaño.
   
   
2. Vista lista
   
   
   
   
   
   En esta vista, si el ancho de la ventana, bueno concretamente el de la zona de listado de ficheros y carpetas, es mayor que el número de caracteres utilizados para ocultar la extensión, y tenemos desactivada la opción de ocultación de extensiones, comentada en el punto anterior, claramente queda delatada la extensión en cualquiera de las tres opciones. En el caso de tener activada opción de ocultar extensiones, en ninguno de los tres casos se detecta la extensión real, aunque en el caso de  utilizar guiones bajos dará indicios a pensar que algo raro sucede; esto mismo también sucede si aún teniendo desactivada dicha opción, la longitud horizontal de la ventana de lista de archivos y carpetas es inferior a la del nombre real del fichero (nombre con los caracteres para ocultar la extensión), tal y como podemos ver en la imagen de a continuación.
   
   
   
   
   
   
3. Vista iconos
   
   
   
   
   
   Este tipo es muy similar a la del punto 1, el resultado sería el mismo, pero el usuario no tendría la posibilidad de ver de manera rápida que el fichero se trata de un ejecutable, ya que en esta vista no tenemos una columna informativa sobre el tipo de fichero.
   

Aunque hay otras vistas disponibles, no he citado más porque el resultado del resto  no aportaría nada nuevo ya que el comportamiento de cualquiera de estas es igual  a alguna de las 3 mencionadas.

El objetivo de este post no ha sido ni mucho menos generar nuevas ideas a los atacantes, ya que para mí los atacantes maliciosos son mi enemigo del día a día, además la idea es muy simple y de carácter no técnico; si he decido escribir esto es para poner en alerta al usuario del día a día que no duda cuando recibe estos ficheros aunque se vea de lejos que el e-mail no va dirigido a él y/o a su empresa y/o ha su responsabilidad dentro de ella y que si con el truco de los guiones bajos está colando, con el uso de espacios seguro que todavía colaría más.
Este tipo de avisos los tengo que estar dando yo a los usuarios de la empresa para la cual trabajo para concienciar les que la industria del malware es un peligro real y presente hoy en día , aunque la mayoría de las veces me llevo comentarios del tipo "informáticos estáis obsesionados con la seguridad y  sois unos exagerados y lleváis este más allá de la realidad", aunque yo no voy a desistir por escuchar este tipos de gilipolleces. Considero que explicarles este tipo de medidas de como detectar técnicas sencillas de engaño les puede ayudar a que eviten ciertos contagios, tanto en sus equipos personales como en los de la empresa,  quedando claro que los problemas generados en estos últimos  me atañen a mí.

Por último solo quiero mencionar que en el post anterior ya hice mención que los antivirus/antimalware y más concretamente los filtros antispam que también analizan los ficheros adjuntos podrían llevar un mecanismo de alerta, en el caso de los primeros, y de mover el correo al buzón de SPAM, en el caso de los segundos, solo por el simple hecho de que los nombres de los ficheros tuviesen un patrón asociado a la distribución de malware como lo es el citado en este post; sin duda creo que sería de gran ayuda para evitar contagios con técnicas tan técnicamente simples como estas.

Hasta la próxima enfermos.

Facturas para no olvidar

Ayer en la empresa volvimos a recibir otro de los famosos troyanos, un .exe, camuflados  en un ZIP, con icono de Microsoft Word y con el clásico nombre en cual aparece la palabra "Factura" por algún lugar y ".doc" justo antes de un chorro de guiones bajos que preceden su verdadera extensión (.exe).

Hace no más de un mes, recibimos un fichero de este tipo, menos mal que el usuario receptor fue precabido y me avisó antes de ejecutar nada, ya que el mail con el que llegaba, cantaba un bastante lo que traía con él. En ese momento estábamos probando nuestro nuevo proveedor de correo por lo que en fase de pruebas y que un filtro antispam y antivirus no parase ese mail con un fichero adjunto, que por su nombre y extensión gritaba "Soy un troyano", era para suspender la fase de pruebas y no contratar sus servicios.

Como no me gusta sacar conclusiones a la ligera, lo analicé con el antivirus corporativo que tenemos y al obtener un falso negativo, se me ocurrió subirlo a Virus Total; el resultado fue desolador tan solo 1 de los 41 motores lo detectaba, así que decidí subirlo a varias veces durante unos cuantos días y postear los resultado obtenidos aquí.

El servicio antispam y antimalware se salvaba de que no lo contratásemos, ya que con ese índice inicial de detección no podemos justificar que el servicio no es el correcto. 

Como de nuevo esta vez el motor antispam y antimalware lo ha vuelto a dejar pasar sin ningún tipo de advertencia, lo he subido, como hice con el anterior, a Virus Total y el resultado ha sido:

• En mi primer análisis por mi parte, ya que ya había sido analizado una vez dos horas antes aproximadamente, un solo motor lo detectaba; podéis ver el informe aquí.
• En mi segundo análisis, medido día más tarde aproximadamente, lo detectaban cuatro motores; podéis ver el informe aquí.

Así que de nuevo estamos no veo lícito realzar reclamación alguna ya que el índice de detección cuando nos ha entrado es extemadamente bajo.

No obstante si que veo lógico abrir una reclamación por no detectarlo como SPAM, ya que con un mega potente motor antispam y antimalware que está en la nube, así es como lo venden, no dé ningún tipo de advertencia o catalogue el mail como SPAM, solo por el simple hecho de llevar un .exe comprimido en un ZIP y con nombre que obedece el clásico patrón comentado al inicio de este post.

Para finalizar solo me gustaría añadir que los antivirus podrían añadir un sistema de advertencia al usuario al estilo de "Posible fichero malicioso", cuando detectasen ficheros con nombres con patrones sospechosos, no creo que sea tan difícil añadir un sistema de advertencia de este tipo, ¿no?

Hasta la próxima enfermos.

Physical Broadcast Traffic Attack

Introducción

En esta entrada voy a explicar una incidencia que tuvimos ayer y que provoco una caída en toda regla de la infraestructura de red de la empresa, cuando digo de la empresa, no es de una sede, sino de más de una, en este caso de 3 de 4 que tenemos.

No voy a explicar, nada innovador, aunque el nombre pueda hacer pensar en eso, pero si algo muy estúpido que dejo durante casi un ahora la infraestructura de red y la telefonía fuera de servicio y media hora más funcionando a medias tintas, provocando, como es de suponer, ciertas perdidas económicas en la empresa y horas de trabajo de más sin remunerara de ciertos empleados para recuperar ese tiempo de improductividad.

Arquitectura de interconexión entre sedes

La empresa tiene la siguiente arquitectura de red de interconexión entre sedes:

• 4 sedes intercomunicadas entre ellas a través un backbone ofrecido por un ISP.
• 3 de las sedes están interconectadas en un topología en estrella a través de un canal de fibra óptica. Madrid como nodo central y Barcelona y Bilbao como nodos periféricos.
• Los canales de fibra se interpretan como una conexión directa, es decir que el ISP solo enlaza el tráfico de un extremo al otro, corriendo de parte de la empresa la manera como gestionar el trafico por dicho canal.
• Las sedes también se encuentra interconectadas por una infraestructura paralela, proporcionada por un router DSL en cada sede; en este caso la infraestructura de red del ISP es quien enruta a el trafico a la sede correspondiente.
• La cuarta sede que no está conectada con el canal de fibra óptica, Málaga, solo está enlazada a través del router DSL con el resto de las sedes.
• Distinto rango de red local en cada una de las 4 sedes.

Os dejo un esquema para su mejor compresión.

Esquema de la arquitectura de la interconexión de red entre sedes

Problemas de fondo

Uno de los problemas que detecte hace un mes y medio aproximadamente, snifando la red para analizar otras tareas que no vienen a cuento en este post, y que nunca había verificado antes porque cuando yo empecé a currar aquí la infraestructura de red de interconexión de sedes por fibra óptica ya existía y lo dí por supuesto después de la información que me habían facilitado mis compañeros que estuvieron en el momento de su instalación, es que el broadcast de cada una de las redes interconectadas llega al resto.

El problema que esto provoca es evidente, una inundación de las redes con paquetes que no sirven para nada, no obstante el día a día no provoca grandes estragos. Solo decir que este problema está en la lista de resolución de problemas, pero la prioridad que tiene es baja, ya que las directrices que nos llegan, sin tener ni voz ni voto, nos indican que estos asuntos no tienen relevancia en el negocio, así que mejor nos dediquemos ha hacer las otras que si las tienen.

El "ataque"

Bueno llegado a este punto voy a explicar en que consistió el "ataque", entre comillas ya que no fue intencionado.

El problema vino de un usuario que había venido con su portátil y se había sentado en uno de los lugares donde tenemos un switch de 5 bocas, de esos que no superan los 40 €, ya que es la manera que usamos para ampliar una única boca disponible de un despacho sin la necesidad de tirar nuevo cableado; no obstante esto solo lo tenemos en puntos muy localizados, ya que la oficina de Barcelona, por lo general, los accesos físicos a red están bien distribuidos y cableados. Cuando el usuario abandono su lugar la oficina, se le ocurrió conectar el extremo del cable conectado a su equipo a una de las bocas libres del switch de 5 bocas, creando un bucle físico y directo.

A partir de aquí ya nos podemos imaginar que sucedió, la red empezó a inundarse con los paquetes de broadcast que llegaban a una de esas bocas, ya que entre ellas se iban realimentando.

Las consecuencias

Las consecuencias del "ataque" fueron las siguientes:

• Denegación de servicios en todo los aparatos conectados en la red de Barcelona. Cuando digo todos, son todos; los switches colapsados con tanto broadcast, a raíz de esto las comunicaciones entre las máquinas (usuarios y servidores) se les denegaba los distintos servicios no de manera total pero si parcialmente, que igualmente impedía trabajar, además el router DSL también estaba colapsado, incluso lo manifestaba con parpadeos de luces inhabituales y para completar el DOS, la centralita telefónica también denegaba su servicio, no funcionaba ni las llamadas internas ni externas, es decir como si se hubiese apagado, esto se debe a que la centralita tiene un interfaz de red ethernet para poder ser administrada y parece que un su fabricación y diseño no se tiene encuentra como una parte no importante de su servicio, es decir que no es capaz de tirar al suelo el servicio ethernet y dejar intacto el servicio de telefonía frente aun problema de este tipo.
• Debido a la configuración que hay actualmente de interconexión entre sedes, comentado en el apartado anterior, "Problemas de fondo", todo el broadcast llegó a las otras dos sedes, Madrid y Bilbao, produciendo un efecto similar, solo salvando se las centralitas, porque estas no tienen el servicio de administración vía ethernet.

Bien, todo esto fue una gran putada, nos volvimos locos viendo que pasaba y haciendo hipótesis de lo que podía estar sucediendo, viendo si lo que podía fallar era un swith, cual de ellos, si el problema podía venir por parte de la infraestructura de red del ISP, etc.

Finalmente después de varias pruebas, todo parecía que era un switch de Barcelona, uno de conexión de máquinas de usuarios, o eso o algún equipo que estaba enviando paquetes de broadcast o corruptos; así que mientras pasaba las conexiones de ese switch al switch de backup  iba monitoreando la red para ver si las nuevas bocas que iba pinchando provocaban alteraciones, hasta que finalmente, como la Ley de Murphy indica, fue una de las últimas bocas que pinché y al ir visitar la localización de esa boca fue cuando me comenta uno de los usuarios que habían al lado del "atacante", "Cuando se ha ido ha conectado su cable ahí".

Conclusiones

Parece que hackearnos la red, aunque solo sea por un intervalo de tiempo aproximadamente una hora, es bastante más fácil que conectar un proyecto a un portátil, así que para la próxima vez que pueda suceder algo así, ya tenemos algo bastante fácil que mirar, antes de empezar a desmontar parte del rack de comunicaciones.

Por cierto, tener un rack bien organizado con switch de backup y una buena adecuación y organización del cableado del rack me ayudó a trabajar más ágil y eficazmente.

Hasta la próxima enfermos.

Conectando un disco de un RAID software de Windows 2000

Ayer en el curro tuvimos una incidencia con una de las máquinas que utilizamos como servidor de sistemas, es decir básicamente para almacenar software que instalamos en los equipos, almacenar alguna que otra documentación interna del departamento de TI y rodar ciertos software de tareas de mantenimiento de sistemas con un nivel de criticidad bajo o más bien nulo.

La incidencia básicamente se resumió en que el sistemas se fue colgando desde hacía unos días cada vez con mayor frecuencia hasta el punto que el tiempo de funcionando se redujo a menos de 8 horas, por lo que la prioridad de la incidencia aumentó, ya que con un intervalo de indisponibilidad inferior a 8 horas y en decrecimiento deja de ser operativa en toda regla.

El sistema operativo de esta máquina era un, prehistórico Windows 2000 Server; es lo que hay en un departamento con presupuesto bastante reducido y más aún en tiempos de crisis y con el estatus económico de España; la máquina tenía dos discos duros del mismo tamaño, los cuales en su día se tomó la decisión de crear un RAID 1 software sobre ellos con la propia herramienta integrada en Windows 2000 Server.

Una vez haber soltado el rollo del motivo de la incidencia y cual era el entorno de producción que nos interesa conocer para entender la situación, paso a explicar la fácil y rápida solución a esta historia que llegó a un punto que parecía que no iba a tener ese final feliz que si tuvo.

Para recuperar esa información durante el tiempo en que tardaremos en poner en marcha el nuevo entorno de producción, decidí pinchar ese disco en una de las máquinas, con Windows XP, que tenemos de backup como plan de contingencia de fallo de alguna de las workstation.

Al iniciar la máquina y ver que el disco a recuperar no se mapeao directamente en Mi PC como una unidad más, fui a la consola de "Administrador de discos" (Accesible a través de la consola de administración del equipo) y en ella me aparecía como que me detectaba el disco con "error" y otro disco inexistente que es el  otro que hace de espejo.

 Acceso a la consolad de administración de Windows XP

En este momento ya me estaba imaginando que recuperar el disco no sería tan sencillo, como pinchar lo y ya está, ya que aunque el formato fuera NTFS, es posible que el RAID software tuviese alguna que otra configuración que no siendo un Windows 2000 Server o un Windows Server de versión superior pudiese gestionar, es decir que desde un cliente Windows XP, no iba a poder recuperar lo de manera sencilla.

En ese momento antes de buscar otra máquina o algún software de recuperación, dando le un par de vueltas al asunto y mirando si desde la consola de administración de discos me daba alguna opción de recuperación,  se me ocurrió asignarle una letra a la unidad y ver que aunque lo marcase con error me dejase y después de eso ya veremos si se puede acceder o no.

El resultado fue satisfactorio, al asignarle una letra a la unidad del disco se  ha mapeado sin problema, totalmente accesible desde "Mi PC", como cualquier otro unidad y además el administrador de discos ha pasado de indicar como sistema de archivos "error" a indicar "NTFS"; así que la historia tuvo un final feliz y para otra vez ya sé que un disco que funciona como uno de los espejos de un RAID software de Windows 2000 se puede conectar a una máquina con un cliente Windows XP y siendo accesible como cualquier otra unidad.

 Administrador de discos de Windows XP

Como podemos ver en la imagen anterior el otro disco del espejo del RAID 1 aparece informado como que falta porque físicamente no esta. Podemos hacer que desaparezca de esa lista si no pensamos añadir el otro espejo, dando botón derecho sobre ese disco informado e indicando "Extraer", en el caso de querer activar el espejo sería, una vez conectado físicamente al equipo, la opción "Reactivar", pero esto último no lo he probado y no sé con toda certeza si funcionaría.

Hasta la próxima enfermos.