Ataques en redes Fibre Channel

Fibre Channel (con topología Fabric) es una tecnología utilizada habitualmente para montar redes de almacenamiento SAN.

Este tipo de redes tradicionalmente no ha sido objetivo de atacantes casuales debido a su dificultad (muchas diferencias con la tecnología TCP/IP habitual) y a su localización (normalmente segmentos internos de grandes empresas).

Esto ha hecho que el riesgo percibido y por lo tanto el esfuerzo dedicado por las compañías a securizar este tipo de redes normalmente no haya sido muy alto.

Sin embargo con la tendencia actual, de atacantes cada vez más profesionales, este tipo de actividades maliciosas se ha vuelto más común.

Y es que las redes Fibre Channel son un objetivo muy jugoso para este tipo de ataques ya que es en ellas donde reside la mayor parte de la información de una compañía.

Los ataques más habituales en redes SAN son:

- Compromiso de las contraseñas de administración (a nivel de interfaz IP).
- Suplantación de WWN o WWN-spoofing (a nivel Fibre Channel).

Aunque por supuesto existen muchos otros.

NOTA: WWN o World Wide Name es el identificador de nodo en una red Fibre Channel.

Compromiso de la administración

La forma de ataque más habitual contra redes SAN consiste en el compromiso de las credenciales de administración utilizadas para configurar los dispositivos, normalmente desde un interfaz Web accesible desde la red IP.

Esto puede producirse por distintas vías, por ejemplo:

- PCs de administradores infectados.
- Uso de protocolos de administración inseguros (HTTP, Telnet).
- Conservar las credenciales por defecto.
- Uso de contraseñas débiles.

Una vez el atacante ha obtenido acceso al panel de control de algún componente de la red SAN, puede obtener información valiosa sobre la configuración de la misma para intentar conseguir acceso a los discos virtuales que le interesen desde otro equipo conectado a la red Fibre Channel.

Suplantación de WWN

Este ataque se puede producir cuando no existe un mecanismo efectivo de control de acceso a los recursos de la red SAN.

En redes Fibre Channel no es habitual el uso de protocolos de autenticación que permitan comprobar que el nodo que solicita acceso a un disco virtual es quien dice ser, de forma que muchas veces el control de acceso a un recurso se realiza solamente en base al WWN del nodo.

El uso de los WWN para segmentar una red SAN se considera adecuado, pero de cara a la seguridad no es la mejor opción ya que los WWN se pueden cambiar de forma similar a como se cambian las direcciones MAC en las tarjetas de red Ethernet.

Para realizar un ataque de este tipo el atacante necesita:

- Tomar control de un equipo conectado a la red Fibre Channel.
- Averiguar el WWN de un nodo que tenga acceso a la información que busca.

Tomar control de un equipo conectado a la red Fibre Channel no suele ser una tarea compleja ya que el atacante ya está dentro de nuestra red y probablemente ya tenga acceso a varios sistemas. Solo necesita que uno de ellos esté conectado a la SAN.

Para averiguar un WWN interesante puede, por ejemplo:

- Comprometer la administración de algún dispositivo de la red SAN, como ya se ha visto.
- Enumerar los HBAs conectados a la red (si el controlador lo permite).
- Realizar un barrido de los WWNs validos. Los WWNs se componen de 8 bytes, pero la mayoría de ellos son fijos para un mismo fabricante y modelo de HBA; de forma que normalmente solo es necesario realizar un barrido de los 2 o 3 últimos bytes.

Conclusiones

Las redes SAN son un elemento más a la hora de securizar una organización y no
deben ser pasadas nunca por alto en un proceso de este tipo ya que son, cada vez más, objetivo de ataques profesionales.
 

Ramón Pinuaga

Dept. ACSS S21SEC

Nace la Agencia de Certificaciones de Ciberseguridad creada por S21sec y el Instituto de Ciencias Forenses y de la Seguridad

En colaboración con el Instituto de Ciencias Forenses y Seguridad, vinculado a la Escuela Politécnica Superior de la Universidad Autónoma de Madrid, hemos creado la Agencia de Certificaciones de Ciberseguridad. Pionera en nuestro país, su misión es gestionar las Certificaciones de Ciberseguridad (CCS) para particulares, y las Acreditaciones de Ciberseguridad (ACS) para organizaciones.

La Agencia de Certificaciones de Ciberseguridad, nace con la vocación de velar por la fiabilidad, así como de dar fe documental de la superación de los criterios de evaluación y aceptación de la normativa de certificación en materia de seguridad digital.

El nuevo escenario de globalización y de gestión de riesgos en las Infraestructuras Críticas exige que los gobiernos y las empresas se preparen para garantizar su correcto funcionamiento. Esto supone para España situarse entre los líderes en este sector. Está pensada para dar servicio, tanto a aquellas personas cuya labor tenga que ver con tareas de seguridad del ciberespacio, como a cualquier organización que tenga que proteger datos confidenciales de clientes, personal, alumnos o productos.

Entre sus funciones principales se encuentra la de garantizar que las evaluaciones de conocimientos y destrezas se realizan mediante procedimientos rigurosos, fiables y contrastables. Asimismo, se encargará de dar fe documental de que las personas u organizaciones certificadas cumplen los requisitos contemplados en los criterios de certificación en cuanto a la capacitación idónea, actualización de conocimientos, y compromiso de buenas prácticas para el desempeño de tareas de ciberseguridad.

También, velará por el cumplimiento de la normativa de certificación y del Código de Conducta Ético-Profesional, así como de la aplicación del régimen disciplinario que contemplan. Además, se encargará de la concesión de la Certificación de Ciberseguridad (CSS), un sello de calidad que acredita la competencia de una persona u organización (organismo oficial, empresa o centro educativo) para desempeñar este tipo de labores.

La creación de las Certificaciones de Ciberseguridad del ICFS de la UAM supone un acontecimiento sin precedentes en este campo no sólo en España sino en Europa, ya que son las primeras surgidas de una institución pública española.

El próximo 14 de mayo tendrá lugar el acto de inauguración oficial de la Agencia en el salón de actos de la Facultad de Psicología de la UAM con la presencia del Rector de la UAM, D. José María Sanz, del Secretario de Estado de Seguridad, D. Ignacio Ulloa, y del Presidente del Consejo Social, D. Manuel Pizarro. Además, presentarán el proyecto los Directores de la Agencia de Certificaciones de Ciberseguridad D. Ricardo Vea de S21sec y D. Álvaro Ortigosa de la Escuela Politécnica Superior de la UAM.

Más información sobre la Agencia de Certificaciones en Ciberseguridad en http://acc.icfs.uam.es/.

Dpto.Marketing

¿Qué es un Sinkhole?

Hablando sobre naturaleza, un sinkhole - término inglés - define un hundimiento de tierra u hoyo. En el mundo de informática, sin embargo, se denomina sinkhole a una técnica de defensa contra botnets que puede neutralizar la misma completamente, puesto que trata de controlar el punto al que se conectarán los ordenadores infectados, atrayéndolos como si fuese un agujero de verdad.

Para tratar con un ejemplo real, vamos a ver cómo está siendo “sinkholeado” el troyano Mebroot, también conocido como Sinowal/Torpig. Antes de nada, debemos mencionar que esta familia de malware no se conecta únicamente a un único panel de control, sino que utiliza un algoritmo para generar los nombres de dominio a los que se conectará. 

Peticiones realizadas desde una maquina infectada

La generación de dominios continúa hasta que uno de ellos resuelva y se compruebe su validez. Esta técnica no es novedosa, y se utiliza para que la botnet sea más difícil de destruir, a la vez que permite poder recuperar la botnet en cualquier momento registrando un dominio futuro que se sepa que va a ser generado el día X. No obstante, tiene su desventaja, y es que cualquiera que conozca o descifre el algoritmo de generación de dominios podría ir un paso por delante y registrar uno de los dominios a los que se conectarán los bots.

Como veremos a continuación, justo lo escrito arriba está pasando con la muestra que hemos analizado, y es que el servidor  que finalmente se pudo resolver dicho día envió el siguiente mensaje:

Respuesta descifrada desde del C&C

El bot en cuestión recibió el comando NOOP junto con la nota pwned, indicándole que se quedara en espera (NO OPeration) y paró de generar más dominios.

Con esto, podemos decir que el servidor malicioso ha sido reemplazado por uno controlado presuntamente por investigadores de seguridad, y los propietarios de ese servidor podrán obtener inteligencia acerca del tamaño de la botnet, las IPs de las víctimas, hasta avisar los proveedores de servicios de internet de una infección posible.

Jozsef Gegeny

S21sec ACSS

Modelo Cliente-Servidor en dispositivos móviles

Analizando la aplicación Sybase Afaria para dispositivos Android (gratuita a través del play.google.com), podemos ver, entre otras, que como características tiene la posibilidad de gestionar ciertas acciones de forma remota.

Tras solicitar por dos veces la versión de evaluación de la maqueta (Sybase Afaria Server) que el propio fabricante dice ofrecer de forma gratuita y no obtener ningún tipo de respuesta, en un plazo de un año, opté por realizar el análisis sin el debido contexto, a modo experimental y sabiendo que cualquier conclusión ha de ser contrastada desplegando un entorno Cliente-Servidor adecuado.

A grandes rasgos, tenemos cinco posibles comandos de gestión remota del dispositivo.

- Hard-Reset.
- Hard-Reset incluyendo el borrado de la tarjeta SD.
- Borrado de datos PIM.
- Bloqueo de dispositivo.
- Desbloqueo de dispositivo.

Y la gestión de dichos comandos se realiza a través de la recepción de un SMS con un formato especifico.

Perfecto, para empezar, desempaquetemos la aplicación y veamos como se gestionan los SMS.

Para desempaquetar la aplicación, decompilar el código y obtener los recursos en texto plano, en mi caso, me serví de las herramientas dex2jar, apktool y jd-gui.

$ apktool d -s Afaria.apk Afaria_Desempaquetada
$ dex2jar.sh Afaria_Desempaquetada/classes.dex

En el fichero AndroidManifest.xml podemos ver que la gestión de SMS la realiza la clase AfariaSMSlistenerBroadcastReceiver.

  <receiver android:name=".AfariaSMSlistenerBroadcastReceiver">
    <intent-filter>
      <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
  </receiver>

La decompilación del código utilizando jd-gui es directa abriendo el fichero creado por dex2jar (classes_dex2jar.jar)

Siguiendo el flujo de ejecución, desde la recepción de un SMS, veremos que el tratamiento de posibles comandos lo lleva a cabo el método ‘SeedData.processCommand’ y no hay referencias a posibles verificaciones de integridad ni procedencia del mismo, exclusivamente se centra en verificar que el contenido del mismo cumple ciertos requisitos.

Analizando con más detalle el método ‘processCommand’ podremos deducir que el formato correcto de un SMS para la gestión remota ha de ser:

[@#!Afaria][Hash de 28 bytes de longitud][$\$CMD:][COMANDO]
(Los corchetes separan los diferentes campos del SMS, no forman parte del mismo)

Los posibles comandos son: WIPEALLDATA, WIPEPIMDATA, WIPEAPPDATA, LOCKDEVICE y UNLOCKDEVICE.

Con estos datos, ya podemos hacer una primera verificación y ver si realmente hay o no comprobaciones de integridad o procedencia.

$ emulator -avd DRDLABBOX &
$ adb install Afaria.apk

Una vez instalada y ejecutada, nos conectamos a la consola del emulador (habitualmente en el puerto 5554, pero siempre podemos confirmarlo con ‘adb devices’) y realizar el envío del SMS.

$ telnet 127.0.0.1 5554
sms send 15555215554 @#!Afaria0123456789ABCDEF0123456789AB$\$CMD:LOCKDEVICE

Como podemos ver en los propios logs del emulador (adb shell logcat), todo ha ido como esperábamos y el dispositivo ha sido bloqueado:

I/getSMSseedInfo(618): Requeried message count: 1
I/getSMSseedInfo(618): content://sms/inbox    summary: row[1] x column[4]
I/getSMSseedInfo(618): _id    1
I/getSMSseedInfo(618): thread_id    2
I/getSMSseedInfo(618): address    15555215554
I/getSMSseedInfo(618): body    @#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/getSMSseedInfo(618): processCommand:@#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/System.out(618):  The First Part of the SMS Message Is : 0123456789ABCDEF0123456789AB
I/System.out(618):  The rest of the SMS Message Is : $\\$CMD:LOCKDEVICE
V/LockPatternUtils(81): Initialized lock password salt
D/LockPatternUtils(81): lock password file changed



Para tener una segunda verificación de que no ha habido ningún comportamiento no esperado, podemos monitorizar el proceso de la aplicación con DDMS para ver los métodos utilizados o generar un grafo para tener una visión totalmente completa del flujo de ejecución seguido desde el envío del SMS.

Para ello, partimos de una imagen de Android limpia, instalamos nuevamente la aplicación (y ejecutamos), y utilizamos la herramienta DDMS para monitorizar el proceso.

Monitorizacion de proceso mediante ddms:
1. Seleccionar proceso a monitorizar
2. Seleccionar opción ‘Start Method Profiling’
3. Enviar SMS
4. Seleccionar opción ‘Stop Method Profiling’

Siguiendo estos pasos se nos abrirá la aplicación ‘traceview’, en la que podremos ver la pila de llamadas.



Finalmente si quisiéramos generar el grafo en base a la traza generada anteriormente con ddms, podemos utilizar dmtracedump.

$ dmtracedump -g trace.png ddms.trace

Con todo esto y en el contexto que se mencionó al inicio (sin un despliegue real del modelo Cliente-Servidor), hay datos suficientes para decir que es posible la ejecución remota de los comandos de gestión implementados en base al numero telefónico objetivo.

Pero más allá de un error de diseño en si mismo, destacaría que el análisis de aplicaciones para dispositivos móviles no siempre ha de centrarse en los conceptos inherentes a la nueva tecnología, a veces los conceptos clásicos; lógica de la aplicación, programación segura o los diferentes factores de autentificación, pueden darnos vectores de análisis muy interesantes.

Eugenio Delfa
Dept. ACSS S21SEC

En 2011 se detectó un incremento del 21% en los ataques a dispositivos móviles

Presentamos el segundo Informe sobre Malware en Smartphones, informe que nos permite reflejar la situación actual respecto a la seguridad de los smartphones, describiendo las principales amenazas detectadas, así como las medidas existentes para mitigar los riesgos asociados.

La popularización de este tipo de dispositivos ha sido vertiginosa, sobre todo debido a la gran oferta de tarifas planas que ofrecen todos los operadores y al acceso a atractivas aplicaciones gratuitas o de pago en las diversas plataformas, ya sean para el uso privado o profesional.

El principal problema detectado a raíz del estudio, es que los usuarios no son conscientes de los peligros que entraña no tener protegido su dispositivo móvil y como consecuencia de esto, las mafias existentes han ampliado sus horizontes de actuación y han incluido este sector entre sus objetivos. Un objetivo de gran crecimiento y alta remuneración.

La limitada concienciación en lo referente a seguridad de los usuarios y su consecuente comportamiento pueden ser los factores de mayor riesgo para los smartphones a corto plazo, por lo que en el informe, además de analizar los principales ataques que se han dado durante el 2011, se facilitan las claves para proteger nuestros dispositivos móviles:

Recomendaciones para proteger nuestro smartphone

1. Habilitar medidas de acceso al dispositivo como el PIN o contraseña si está disponible.
2. Configurar el smartphone para su bloqueo automático pasados unos minutos de inactividad.
3. Sólo instalar aplicaciones que provengan de fuentes de confianza.
4. Prestar atención a los permisos solicitados por las aplicaciones y servicios a instalar.

En 2011 en S21sec detectamos 7.000 vulnerabilidades

Presentamos el primer ‘Informe de Vulnerabilidades’ elaborado por el equipo de Ecrime donde se recogen los datos de las vulnerabilidades detectadas por S21sec en la última década. Este informe, pretende constituir una radiografía de las principales amenazas que afectan en la actualidad tanto a empresas e instituciones como a usuarios.

2011 ha sido un año marcado por la aparición de un elevado número de vulnerabilidades de alto riesgo y el número de vulnerabilidades se mantuvo relativamente constante entre un mes y otro, a excepción de marzo. El tercer mes del año registró un elevado número de vulnerabilidades sobre software de Apple que afectaron a un gran número de sus productos tales como iTunes, Safari, Apple IOS, Mac OSX, iPhones IOS, entre otros.

Se puede decir que hemos detectado un aumento de las vulnerabilidades, con un aumento de las explotaciones remotas de vulnerabilidades y una sofisticación de los troyanos orientados a la industria como ha sido el caso de Stuxnet o Duqu. Asímismo se puede observar una tendencia cambiante en los navegadores donde se refleja un cambio en la explotación de vulnerabilidades de Firefox a Chrome ya que este último está siendo el que mayor cota de mercado está alcanzando.

Este año seguiremos viendo un incremento de vulnerabilidades a dispositivos móviles gobernados por sistemas operativos como Android o iPhone OS. Actualmente existen unos 5.600 millones de móviles en funcionamiento (alrededor de un 77% de la población mundial dispone de uno), de los cuales unos 468 millones son smartphones y se estima que la cifra crecerá hasta 631 millones en 2015, por lo que, lógicamente, a más usuarios y más dispositivos se incrementará también el riesgo de vulnerabilidades.

El ‘Informe de Vulnerabilidades 2011’, elaborado por la unidad Ecrime de S21sec puede descargarse aquí.

S21sec

Campaña de spam simulando ser la Agencia Tributaria

Se tiene conocimiento de una campaña de fraude en la que los defraudadores se están haciendo pasar por la Agencia Tributaria española. El método de comunicación de esta campaña fraudulenta es mediante correos de spam.

En estos correos de spam, los delincuentes se identifican como la Agencia Tributaria, falseando el remitente del correo, y se nos informa de un supuesto reembolso que quieren hacernos efectivo, pero para el cual necesitan que les facilitemos primero ciertos datos..

Correo de spam, simulando ser la Agencia Tributaria

En el correo viene adjunto un fichero html, el cual nos invitan a descargar y abrir en nuestro navegador, para entonces rellenar los "datos necesarios", entre los que están los datos de la tarjeta de crédito.

Formulario fraudulento

Como es obvio, el formulario es falso y envía los datos a un servidor localizado en EEUU:

Servidor que recoge los datos robados

Un rápido vistazo al correo nos da una idea de que estamos ante un fraude, porque en la gran mayoría de los casos hay faltas de ortografía evidentes, o expresiones que resultan extrañas:

"..usted es elegible.."
"Descargue el formulario de devolución de impuestos unida a este mensaje.."
"Un reembolso se puede retrasar para una variedad de razones. Por ejemplo, la presentación registros inválidos o la aplicación después de la fecha límite."


Como conclusión, unas breves consideraciones:

- No facilitar los datos de la tarjeta (incluido el código de seguridad CVV), salvo en sitios web de confianza.
- La AEAT dispone a priori de todos nuestros datos.
- Dados los tiempos que corren resulta sospechoso que la Agencia Tributaria se ponga en contacto con nosotros por correo para devolvernos cualquier cantidad de dinero, ¿verdad?


Como siempre, el sentido común es el mejor aliado contra este tipo de fraudes.

Saludos.
Rubén Piñero
S21sec ecrime