AirWatch MDM Review

Hace un tiempo comenzamos a utilizar dispositivos Android en la empresa y se hizo evidente que necesitaríamos un software para administrarlos. Desde hace varios años utilizamos BlackBerry, para lo cual contamos con BlackBerry Enterprise Server (BES). Personalmente BES siempre me pareció una cagada, tiene sus cosas buenas y fue uno de los pioneros del rubro, pero las cosas no andan bien. Los servicios de BB en general siempre me parecieron una bosta. Que algún administrador de BES me diga si al menos una vez al mes (o a la semana) algún BB deja de sincronizar los mails y encuentra otro remedio más que desvincular el equipo y volver a vincurlarlo? si, a veces se soluciona con una reiniciada, pero muchas veces no! y lo peor es que es imposible saber la causa.

Bueno, dejando mi resentimiento hacia BES, volvemos a Android. Android es una plataforma muy buena, pero creo que no tan orientada a las empresas todavía. De a poco va queriendo, pero todavía le falta bastante. El tema es que los dispositivos Android parecen estar pensados solamente para el usuario hogareño. Para poder utilizar este sistema a nivel corporativo, necesitamos una herramienta que nos brinde ciertas funcionalidades.

Veamos primero qué es lo que se necesita para poder administrar dispositivos móviles en general, y luego nos adentraremos en AirWatch en particular.


Introducción MDM para Android

Mi experiencia me permite distinguir las siguientes necesidades, a la hora de administrar dispositivos móviles Android (u otros) corporativos:

• Uso de mail corporativo: Android soporta ActiveSync para poder utilizar un servidor de correo Exchange. La necesidad que identifico es poder administrar esta conexión desde un software centralizado.
• Políticas de seguridad: muy pero muy importante es poder aplicar restricciones a los equipos. Como la mayoría sabe, existen miles de aplicaciones maliciosas para Android. Si permitimos a cualquier usuario instalar cualquier cosa, vamos a tener un grave problema. Las políticas de seguridad deben permitir:
• Forzar uso de PIN o patrón para bloquear el dispositivo.
• Bloquear la instalación y desinstalación de aplicaciones. Así como no queremos que instalen nada, también queremos que no desinstalen software básico.
• Bloquear "reset to factory" del equipo. Si borran la configuración, después pueden hacer cualquier cosa.
>
• Bloquear el cambio de ciertas capacidades estéticas, como cambio de wallpaper.
• Instalación remota de aplicaciones: bien, no permitimos instalar aplicaciones al usuario, pero si el mismo necesita algo para sus tareas, debemos poder instalarselo. Estos usuarios puede que no estén físicamente en las instalaciones de la empresa, así que poder instalar aplicaciones desde el administrador, es un requisito.
• Uso de encripción: dado que los equipos pueden transportar información sensible, es necesario poder activar la encripción de la tarjeta de memoria y/o memoria del equipo.
• Bloqueo / Wipe remoto: si un dispositivo es robado o perdido, el administrador debe poder bloquearlo e incluso borrarlo para que no se accedan a los datos de la empresa.
• Configuración centralizada: tener que configurar muchos dispositivos de a uno, no solo estresa a cualquiera, sino que es una pérdida de tiempo. La mejor alternativa es realizar la configuración una vez, y que todos los dispositivos la apliquen al conectarse.

Los programas que proveen estas funcionalidades se denominan Mobile Device Management (MDM), y hay varios dando vueltas. El mismo BES es un MDM que implementa las funcionalidades descriptas. Uno de estos MDMs es AirWatch y en él me enfocaré el resto del artículo. AirWatch, según sus propias palabras, es el MDM líder a nivel empresarial.


AirWatch

Estuve utilizándo AirWatch durante un par de semanas, haciendo varias pruebas, y quería compartir mi experiencia con esta herramienta, por si alguno de ustedes está buscando algún MDM y está indeciso. Les comentaré tanto las cosas buenas, como las cosas malas que encontré al utilizarlo.

Para empezar, me pareció muy útil que soporte múltiples sistemas operativos (Android, iOS, BlackBerry, Symbian, Windows Phone, Mac OS X, entre otros). Si el parque de dispositivos no es homogéneo, como en nuestro caso, esto es una característica importante. Es importante observar aquí que no es la panacea. Si bien el soporte de sistemas operativos existe, en muchos casos el soporte es muy limitado. Por ejemplo, no podrán reemplazar BES por AirWatch para administrar los BlackBerry, ya que las características que AirWatch soporta para BB son muy (MUY) limitadas.
En cada opción de configuración de AirWatch, podrán observar al costado, qué sistemas operativos la soportan. Incluso dependiendo la versión del sistema operativo, puede que la opción esté disponible o no (por ejemplo, algunas cosas disponibles para Android 3, no están disponibles para Android 2). A favor de AirWatch hay que decir que en muchos casos la limitación la pone el sistema operativo. Si el sistema operativo no provee una forma de evitar el uso de la cámara, el software no podrá hacerlo.
Otro punto a tener en cuenta, es que la mayoría de las opciones de configuración para Android, sólo están disponibles para dispositivos SAFE (Samsung For Enterprises). Si no adquirieron dispositivos Android que sean SAFE, casi que ni les conviene utilizar AirWatch.

AirWatch implementa todos los puntos listados en la introducción, aunque no todos para todos los sistemas operativos. Para equipos SAFE, todas las opciones están disponibles, teniendo algunas limitaciones en cuanto a la granularidad.
Algo interesante es que AirWatch permite organizar los dispositivos en unidades organizativas (por ejemplo, departamento), y a los usuarios por grupos. Luego es posible definir perfiles (que incluyen políticas de uso, certificados, bookmarks, VPN, WiFi, etc) por unidad organizativa y por grupo de usuario. Esto brinda la flexibilidad de poder definir, por ejemplo, que ciertas restricciones se apliquen a los usuarios de comercial, que se encuentren en el grupo de usuarios atención al cliente. La organización de los grupos resulta un poco confusa al principio, pero luego del uso se va afinando.

La instalación remota de aplicaciones existe, pero no es del todo directa. Es posible distribuir tanto aplicaciones públicas, como adquiridas por la empresa (llámese APK). Es posible instalar las APK sin intervención del usuario, pero si es una aplicación de la Play Store, requerirá la intervención del usuario, algo para nada conveniente. Tal vez sea algo que me falló a mi, pero luego de varias pruebas, no logré que se instale algo directamente.

Dado que muchos dispositivos incluyen aplicaciones que tal vez no deseamos (Google trae algunas que en modo usuario son imposible desinstalar... llámese Gmail, G+, etc), es posible desinstalarlas/desactivarlas mediante AirWatch. Este es un punto muy a favor del software, dado que sin rootear el dispositivo no es posible eliminar ciertas aplicaciones. Además es posible restringir la instalación de aplicaciones y no permitir que el usuario desinstale las importantes. Esto se logra con los grupos de aplicaciones Blacklisted, Whitelisted y Required. Todas las listas se arman con los IDs de las aplicaciones. Cada aplicación tiene un ID único, como com.google.android.gm para GMail.

• Blacklisted permite listar las aplicaciones explícitamente prohibidas. Si una aplicación está en esta lista, no se podrá instalar.
• Whitelisted, si está activa, restringe que no se instale ninguna aplicación que no se encuentre en la lista.
• Required no permite que el usuario desinstale ninguna de las aplicaciones listadas.

Me parece importante remarcar que las aplicaciones que vienen "de fábrica" como GMail, seguirán instaladas incluso si utilizamos la Whitelist y no la incluímos. La única forma que logré de remover estas aplicaciones es listándolas explícitamente en la Blacklist.
El único aspecto negativo que encontré en esta funcionalidad, es que el sistema permite al usuario llegar hasta el último paso de la instalación antes de decirle "está prohibido instalar la aplicación". Estaría bueno que no lo permitiera de entrada.

Otro aspecto que en nuestro caso era importante, es dónde está instalado el servidor. Para empezar, AirWatch vende el servicio en la nube, es decir, está el servidor instalado en algún lugar del ciberespacio, y nosotros lo administramos remotamente. Consultando con un agente oficial, me indicaron que también es posible instalar el sistema on-site, es decir, tener nuestro propio servidor AirWatch. El requerimiento para hacerlo es contratar por lo menos 100 licencias, donde las licencias son por dispositivos... para hacer una prueba inicial no resulta muy atractivo tener que contratar 100 licencias. Como dato extra, cada licencia cuesta entre 5 y 6 dólares mensuales. No estoy para nada a favor de colocar datos de la empresa en la nube, mucho menos información de dispositivos, que incluye localización, registro de llamadas, mensajes, etc, pero en este caso, no tuvimos opción.

Algo que todavía no mencioné es que la interfaz de administración es Web. La interfaz es, a mi gusto, poco intuitiva y confusa. No es fácil familiarizarse con ella, e incluso luego de utilizarla un par de semanas, a veces no encuentro las cosas. Tal vez sea una mera impresión mia, pero conversando con mis compañeros de trabajo, les dio la misma sensación. La primer gran confución es la diferencia entre los usuarios. Existen dos tipos de usuarios, los administradores, y los "dueños" de dispositivos. Los primeros tienen permiso de administrar la aplicación, y mediante roles se puede restringir lo que pueden hacer. Los segundos se utilizan para registrar equipos. Es decir, cuando damos de alta un equipo, éste debe pertenecer a algún usuario, por lo que antes habrá que dar de alta el usuario. Cada uno de estos usuarios puede tener asignado uno o más equipos.
Otra confusión es dónde estamos parados. Como cada dispositivo pertenece a una unidad organizativa, si estamos en una de ellas, no podremos ver los dispositivos en otras (salvo que estemos en la OU raíz, donde podemos ver todos). Lo mismo sucede con los usuarios.
Un problema que encontré aquí es mover dispositivos o usuarios entre unidades organizativas... simplemente, no pude. Si el usuario tiene asignado un dispositivo que se encuentra en una dada OU, no se puede mover el usuario, y lo mismo pasa con los dispositivos.
Más allá de ser confusa, tengo para decir a favor de la interfaz que genera interesantes gráficos. El dashboard es muy visual y La información sobre los dispositivos es muy completa.

Un aspecto muy negativo, es la falta de documentación. Googlear cómo hacer algo en AirWatch es prácticamente inútil. Sólo se encuentran broshures de propaganda. Incluso en la página de AirWatch no encontrás los manuales! Tienen una sección de whitepapers que no me resultó muy útil. Por suerte, nuestro proveedor de AirWatch en la nube brindó un buen soporte a nuestras consultas, y nos entregaron un manual oficial... aunque este manual oficial no era muy completo tampoco. En fin, punto negativo en cuanto a documentación.


Agente AirWatch

La administración de los dispositivos se logra instalando un agente AirWatch en cada uno de ellos. Este agente se instala desde la Play Store de Google (en el caso de Android), y se registra en el servidor utilizando una URL de enrollment (que no es la misma que la de administración), el ID de la unidad organizativa, y un usuario del tipo "dispositivo" (no uno de administración).

Para la instalación encuentro como punto negativo que no se provea una APK. El uso de la Play Store de Google fuerza registrar una cuenta Google. Para un dispositivo corporativo, por qué la empresa debería tener cuentas Google? Parte del monopolio encubierto de Google.

Una vez que se registra el dispositivo, se aplica la configuración indicada por el servidor, la cual incluye el perfil del usuario. Acá encontré otro problema. Si bien el agente provee una forma de forzar la sincronización, la aplicación del perfil no siempre funciona. Tuve muchísimos problemas creando bookmarks desde el servidor. A veces el agente los borra, no se actualizan...

Encontré riesgoso el echo de no poder prohibir la desactivación del agente. Si bien encontré la forma de que el usuario no desinstale el agente (Required list, descripta anteriormente), no encontré la forma de que el usuario no desactive el agente. Una vez que se desactiva el agente, el usuario sigue teniendo las restricciones, pero el servidor pierde el contacto con el dispositivo.


Conclusión

AirWatch es un muy buen comienzo en la administración centralizada de dispositivos móviles. Sin embargo, creo que odavía tienen mucho camino por delante. Tal vez dependa mucho de la evolución de los sistemas operativos como Android, que seguramente tomarán un approuch cada vez más empresarial, como BB.
No utilizaría AirWatch como reemplazo de BES. Si tienen dispositivos BB, debido al limitado soporte, recomiendo seguir utilizando BES por más feo que sea :P

Como puntos a favor encuentro que:

•  Implementa las características más importantes de un MDM.
•  Brinda muy buena información sobre los dispositivos.
•  Permite una buena restricción de las aplicaciones instaladas y que no se pueden desinstalar.
•  Soporte de múltiples sistemas operativos.
•  Aplicación de políticas por grupos de usuarios y/o dispositivos. Facilidad de generar perfiles y aplicar uno o más a cada dispositivo.

En contra, encuentro que:

• La interfaz web de administración no es muy intuitiva.
• La documentación casi inexistente, ya que una vez que nos vamos adentrando en el software y queremos hilar más fino, no se encuentra información al respecto.
• El soporte de Android es principalmente para equipos SAFE, y salvo iOS, las características disponibles para el resto de los SOs es muy limitada.
• El agente falla cada tanto y no aplica correctamente los perfiles.
• Se requieren demasiadas licencias (al menos 100) para poder instalar el servicio on-site.

Mi resumen de la ekoparty 2012

Después de 2 años deseando ir, por fin se me dio y pude asistir a mi primer ekoparty, la recientemente finalizada ekoparty 2012, y la verdad que volví muy satisfecho. Si bien ya fui sabiendo que las charlas que se realizan en este evento son de muy buen nivel, la verdad es que superaron ampliamente mis expectativas. Los disertantes fueron de lujo y las charlas de muy buen contenido, mostrando vulnerabilidades nuevas, no publicadas en ningún lugar, así que fue un honor poder estar allí para presenciarlo.
No he ido a ninguna otra conferencia de este estilo, así que no tengo punto de comparación, pero por lo que he visto siguiendo otras como Black Hat y Defcon, creo que tenemos localmente un congreso de muy buen nivel.
Fui a todas las presentaciones, y por supuesto que tengo mis favoritas, así como algunas que no me llegaron tanto, ya sea porque yo no tenía el background suficiente para seguirlas, o porque al disertante le costaba transmitir las ideas, pero en general todas fueron muy buenas.
Algo que me sorprendió gratamente es la cantidad de investigación del tema que se realiza en Argentina, mostrando que si se nos da la posibilidad (económica y/o laboral) somos capaces de lograr muy buenos resultados. Los disertantes argentinos estuvieron en un gran nivel.

En fin, para los que no pudieron asistir, les dejo un pequeño resumen de las charlas que más me gustaron, lo cual no quiere decir que el resto fueran malas, sino que yo no pude sacarles tanto el jugo. Igualmente como verán, me gustaron casi todas =P

Cyberwar para todos: Cesar Cerrudo hizo un buen resumen y análisis (con muy buen humor) de lo que conocemos como Cyberwars. La presentación pretendía demistificar un poco las acusaciones continuas sobre quién ataca a quién, tratando de que tomemos conciencia que si bien los países se acusan entre sí sobre los ataques cybernéticos, es casi imposible determinar el origen real de los mismos. Además habló sobre el (nulo?) nivel de seguridad informática que tenemos en Argentina, esperanzado de que en algún momento quienes nos gobiernan tomen conciencia de la necesidad de contar con mecanismos para defendernos ante un eventual cyberataque.

Inception of the SAP Platform's Brain: Attacks to SAP Solution Manager: si bien no manejo mucho SAP, conozco la infraestructura y funcionamiento básico de este sistema, por lo cual esta charla me resultó muy útil. Juan Perez Etchegoyen nos habló de cómo tomar el control de SAP partiendo del componente que nuclea todas las conexiones: SolMan. A través de la presentación demostró cómo partiendo de un mandante sin privilegios y utilizando cuentas default o alguna vulnerabilidad específica, podía conectarse a SolMan mediante conexiones confiables (trusted) y tomar el control del mismo, para luego acceder al ambiente productivo. La joyita de la presentación (a mi gusto) fue utilizar Bizploit (herramienta de Onapsis) para tomar el control de un server *nix donde se encontraba instalado SAP =)

One firmware to monitor 'em all: Andrés Blanco y Matias Eissler hicieron un excelente trabajo de ingeniería inversa para poder inyectar código malicioso en firmware de placas wireless Broadcom, utilizadas por diferentes marcas en sus dispositivos (Apple, Samsung, Nokia, etc). Los muchachos partieron de un pedazo del driver instalado en el sistema de archivos del dispositivo para luego tomar control e instalar su propio código en el firmware de diferentes dispositivos. Debido a que el driver de estas placas es similar en todos los dispositivos, con lograr diseccionar el de uno, les es posible infectar a todos.

HTExploit - Bypassing your htaccess and beyond!: Esta turbo talk fue una de las que más me sorprendió debido a las implicaciones de lo que encontraron tomando como base algo muy simple. Maximiliano Soler y Matias Katz nos trajeron una herramienta (HTExploit) que mostraron en el último BlackHat de Las Vegas, la cual les permite acceder a páginas PHP cuyo acceso está restringido mediante archivos .htaccess. La falla que explota esta herramienta es que muchos archivos htaccess limitan el acceso utilizando la sentencia "Limit GET, POST", lo cual si bien limita el acceso mediante estos métodos, no restringe otros. Dado que PHP asume el método GET siempre que se utilice un método que desconozca, si un atacante utiliza, por ejemplo, el método PEPE, el mismo podrá bypassear el control de Apache y obtener las páginas... un lujo.

Bitcoin, MavePay and the future of cryptocurrencies: esta charla presentada por Sergio Lerner (creo que nada que ver con Alejandro Lerner...) me gustó porque desconocía este sistema de pagos P2P. Como fanático de sistemas P2P, conocer este Bitcoin me interesó mucho como un posible área de investigación. Sergio habló sobre distintos ataques que se pueden realizar para robar "dinero virtual" (Bitcoins) en esta red, además mostró distintas modificaciones sobre las que está trabajando (MavePay) para hacer al sistema más resistente a ataques, desmotivando el robo, favoreciendo el buen uso del sistema para obtener dinero de forma legal.

Fuzzing DTMF Input Processing Algorithms: si hay algo que me encanta son los ataques "locos", y este es uno de ellos. Rahul Sasi demostró cómo realizar ataques contra sistemas de reconocimiento de voz o pulsaciones de teclado, utilizados en telefonía (DTMF). Si bien no demostró como hacerlo, eventualmente podría realizar inyecciones SQL haciendo un simple llamado telefónico, o bien voltear todo un sistema bancario o de atención al cliente... realmente muy loco.

Cryptographic flaws in Oracle Database authentication protocol: en esta presentación, Esteban Fayo demostró vulnerabilidades en los protocolos nativos de autenticación en bases de datos Oracle 10 y 11. Cuando se elige utilizar la autenticación nativa de Oracle, es posible obtener, en dichas versiones de base de datos, el hash de las contraseñas almacenado en el session key enviado por el servidor en el handshake. Para hacerlo, debe contarse con el nombre de una base de datos y un nombre de usuario, que deberá obtenerse mediante otra técnica. Una vez que se obtiene dicho hash, es posible obtener la contraseña mediante un ataque offline, ya sea por diccionario o fuerza bruta. Con esto se reduce el trabajo de obtener una contraseña a romper un hash. La forma de obtener dichos hashes varía dependiendo de si se utiliza la versión 10 o la 11, según demostró Esteban en su presentación.

Satellite baseband mods: Taking control of the InmarSat GMR-2 phone terminal: probablemente la presentación con más humor de toda el congreso, donde Alfredo Ortega y Sebastián Muñiz mostraron los resultados obtenidos al jugar con un teléfono satelital, realizando ingenería inversa sobre el mismo de modo de modificar el firmware y así para poder sniffear e inyectar tráfico enviado entre el teléfono y el satélite. Realmente un trabajo excelente el realizado por este par que lograron el interés de todos a través de una presentación con mucho humor de por medio, algo que siempre ayuda a distender y llegar mejor a la audiencia.

Welcome to your secure /home, $user: un gusto personal el haber podido conocer a uno de los editores del blog Security By Default, Lorenzo Martinez Rodriguez, blog que sigo desde hace tiempo. Lorenzo presentó, también con muchísimo humor de por medio, las modificaciones que realizó sobre los sistemas instalados en su propio hogar para obtener en 2012 la casa del futuro. Mostró cómo es posible tener un hogar más seguro mediante grabación de videos en los momentos adecuados, detección de movimiento, detección facial para reconocer a las personas que ingresan en el hogar (OpenCV haar classifier cascade), detección de presencia mediante bluetooth, interacción con la alarma mediante internet, así como automatizar ciertas tareas llevadas a cabo diariamente. Sin dudas, una de las presentaciones más entretenidas de la jornada.

SinFP3: More Than A Complete Framework for Operating System Fingerprinting: si bien el fingerprinting es algo bastante conocido, me resultó interesante conocer, de la mano de alguien que lleva varios años en el tema, cómo se trabaja para distinguir y lograr la mejor precisión posible detectando sistemas operativos, tanto pasiva como activamente. Patrice Auffret es alguien que trabaja desde hace tiempo con SinFP3, una herramienta que vi en Backtrack en algún momento pero que reconozco nunca utilicé. Esta fue una de esas charlas que te dejan con ganas de contribuir y trabajar un poco en este tipo de detecciones.

4140 ways your alarm system can fail: presentación realizada por Babak Javadi y Keith Howell que nos introdujo al mundo de los sistemas de alarma, esos que utilizamos en nuestros hogaras y en los que deberíamos (?) confiar.  Al introducirme en un mundo que desconocía, realmente me dejaron con un sentimiento de mucha inseguridad (y eso que trabajo en seguridad...) al mostrarnos lo fácil (y cuando digo fácil, es FACIL) que es deshabilitar un sistema de alarmas una vez que se conoce su funcionamiento. Estos muchachos mostraron en vivo como podían desactivar alarmas mediante diferentes técnicas, como realizar fuerza bruta sobre los códigos del centro de mandos, puenteo de terminales, e inyección de tráfico wireless, entre otras cosas. Otra de las tantas buenas presentaciones de este congreso, que dejan mucho información interesante al asistente.

VGA Persistent Rootkit: Nicolás Economou y Diego Juarez nos mostraron el resultado de su trabajo con placas de video que tiene implicancias muy perturbadoras, dado que es poco y nada lo que podremos hacer si un atacante nos infecta. El trabajo realizado fue inyectar código malicioso en el firmware de las placas de video (mediante un upgrade utilizando programas provistos por los fabricantes), de forma que el malware tomará el control de nustra máquina antes de que se cargue cualquier otro sistema... creepy! Nicolás y Diego realizaron ingeniería inversa para agregar código en el bloque de memoria libre de las placas y llamarlo desde el código "legal" del controlador. Además trabajaron para hokearse en la interrupción 10h y lograr que el BIOS no elimine lo inyectado al cargar el sistema operativo. Todo esto fue mostrado en vivo, con algunos mínimos contratiempos ;) y nos dejaron muy sorprendidos. Un aplauso para estos muchachos.

Dirty use of USSD Codes in Cellular Network: otra charla de las que categorizo como "locas" con implicancias TERRIBLES para la telefonía móvil. Ravi Borgaonkar nos introdujo al mundo de los códigos USSD, muy utilizado en Europa y en su India natal, aunque no tannnn conocido en Argentina. Describiría los USSD Codes como similares a los web services, donde mediante un mensaje de texto una persona puede obtener servicios de distintos proveedores. Ravi demostró un exploit que le permite bloquear tarjetas SIM de smartphones Android (todas las versiones), tan solo visitando un link! Como si esto no fuera poco, también demostró como formatear a su estado de fábrica un celular con Android mediante un link, y cómo hacerlo mediante la lectura de un tag NFC! Un lujaso contar con este investigador que nos dejó a todos asombrados con su trabajo. Una de las charlas más aplaudidas de la jornada, algo muy merecido.

The CRIME Attack: la frutilla del postre fue la charla de Juliano Rizzo y Thai Duong quienes una vez más pudieron contra SSL/TLS, logrando obtener cookies en de una conexión encriptada, con un ataque similar al que presentaron el año pasado (BEAST). En esta ocasión, Juliano y Thai explotaron una vulnerabilidad introducida al utilizar compresión en TLS, la cual también está presente al utilizar el protocolo SPDY (reemplazo de HTTP introducido por Google) que también comprime el contenido de las conexiones. El exploit se basa en realizar un session hijack de la víctima para generar tráfico desde la misma contra una página web que utilice TLS (como por ejemplo twitter) y observar el tamaño de los paquetes comprimidos enviados por el servidor. Dado que los paquetes enviados están especialmente armados por el atacante, mediante la observación del tamaño de diferentes request comprimidos, es posible inferir de a un byte el contenido de la cookie encriptada. Los muchachos demostraron en vivo cómo obtener una de las cookies de twitter en pocos minutos, aunque debido a una modificación introducida a último momento por Thai antes de la presentación, no les permitió obtener la otra cookie necesaria para lograr una autenticación exitosa. Igualmente el exploit quedó demostrado al poder obtener una de las cookies y seguramente liberarán el código actualizado para poder llevar a cabo un ataque completo. Un gustaso poder ver a estos dos en acción luego de seguir su trabajo en las últimas dos ekoparty.

Resumiendo, me vine muy MUY contento con lo visto en el congreso y espero poder volver el año que viene. Quién sabe, tal vez alguna día tendré el honor de asistir como speaker =)

Monitoreo de red: OSSIM Review Parte III (Ntop, NFSen, Pads, P0f, Tcptrack, Arpwatch, OCS-NG)

Llegamos a la 3ra y última parte del review de OSSIM. A través de este review y de OSSIM conocí un montón de herramientas excelentes, que seguramente utilizaré mucho, y aprendí un poco más sobre herramientas que ya conocía. Para el que se perdió el resto del review, puede encontrar la parte 1 aquí, y la parte 2 aquí.

Para esta tercer entrega dejé las herramientas que realizan su trabajo pasivamente, sin interferir en el funcionamiento normal de la red. Estas herramientas trabajan observando el tráfico de la red y generando estadísticas o alertas según lo que observan. También hablaré sobre una excelente herramienta que permite mantener un inventario en tiempo real de los dispositivos de la red.


NFSen

NFSen o Netflow Sensor, es un front-end web para las herramientas de flujo de red nfdump. A través de este front-end podemos ver gráficos de flujos, paquetes y Bytes usando RRD (Bases de datos Round Robin). Además es posible setear alertas e incluso programar plugins propios para procesar el flujo de red.
En cuanto al manejo de los gráficos NFSen es bastante flexible, permitiendo seleccionar intervalos de tiempos, tipo de gráficos (lineares, logarítmicos, etc), ver resumen estadístico, crear filtros, etc. Se pueden crear perfiles donde el usuario puede customizar lo que desea ver, con qué colores, en qué intervalo.

Como NFSen funciona sobre la base de NFDUMP, describiré un poco de qué trata esta última.
NFDUMP es un conjunto de herramientas encargadas de recolectar y procesar flujos de datos en la red que funcionan por línea de comandos. Las herramientas que componen NFDUMP son:
- nfcapd: el demonio que captura el flujo de red. Lee datos de la red y los almacena en archivos, los cuales va rotando automáticamente cada n minutos.
- nfdump: vendría a ser el dump de los datos almacenados por nfcapd. Esta herramienta sirve como visualizador de los datos almacenados por nfcapd. La sintaxis es similar a la de tcpdump, y puede crear varias estadísticas del tipo "top N" basado en flujos de datos IP, ports, etc.
- nfprofile: otro que lee los datos almacenados por nfcapd. Estos datos se pasan a través de un conjunto de filtros y los datos filtrados se almacenan en nuevos archivos.
- nfreplay: simplemente hace forward de los datos almacenados por nfcapd hacia otros hosts.
- nfclean: permite borrar los datos viejos.
- ft2nfdump: permite convertir datos de herramientas de flujo desde archivos o de la stdin al formato nfdump.

NFDUMP entonces permite analizar el flujo de datos en la red del pasado y hacer un seguimiento de patrones de tráfico interesantes continuamente.


Ntop

Otra gran herramienta que permite ver el uso de la red. Ntop lleva su nombre por la analogía con el comando top de Unix que muestra el uso de la memoria, CPU, etc, de los procesos.
Ntop, al igual que nfdump, lee los datos de la red, los almacena en archivos y a partir de ellos genera gráficas visualizables a través de una interfaz Web (port 3000 por defecto). Ntop es mucho más completo que nfdump, porque no solo distingue entre tráfico udp, tcp, icmp, etc, sino que también distingue protocolos de la capa aplicación, como ser HTTP, SNMP, SSH, DNS, etc.
La variedad de gráficas que Ntop es capaz de generar hacen que el administrador tenga una excelente visión de lo que sucede en la red. Se pueden generar gráficas por host, e incluso distingue que servidores ejecuta un dado host.
No hay mejor resumen de lo que se puede hacer con Ntop que el que nos da su autor en la página:

* Ordenar el tráfico de red de acuerdo a varios protocolos
* Mostrar el tráfico de red ordenado de acuerdo a varios criterios
* Mostrar estadísticas del tráfico
* Almacenar en disco estadísticas del tráfico en formato RRD (Round Robin Database)
* Identificar la identidad (e.g. direcciones de e-mail) de computadoras de usuarios
* Identificar pasivamente (i.e. sin enviar paquetes de prueba) el Sistema Operativo de los hosts
* Mostrar la distribución del tráfico IP entre varios protocolos
* Analizar el tráfico IP y ordenarlo de acuerdo a la fuente/destino
* Mostrar la matriz del tráfico IP de la subred (quién está hablando con quién)
* Reportar el uso del protocolo IP ordenado por tipo de protocolo
* Actuar como recolector de flujo de red para los flujos generados por routers (e.g.Cisco) y Juniper o switches (e.g. Foundry Networks)
* Producir estadísticas del tráfico tipo RMON

Pueden aprender más sobre ntop en los documentos recomendados en la página oficial.


Pads

Pads cuyo significado es Passive Asset Detection System (Sistema de Detección Pasiva de Activos) es un sniffer que a través de signatures detecta activos. Los activos pueden ser dispositivos o servicios ejecutándose en la red. La idea detrás de PADS (como comenta su autor en la página oficial) es ser un nmap que funcione de forma pasiva, esto es, sin enviar un solo paquete a la red.

El funcionamiento es simple, Pads sniffea la red y a través de signatures va detectando servicios y hosts que existen en ésta, y loguea lo que detecta. De esta forma se puede hacer un mapeo de la red sin generar tráfico. Claro está que este tipo de detección es menos precisa que un escaneo activo como el de nmap, pero es muy útil cuando este último no es una opción viable.


P0f

Passive OS Fingerprinting (p0f) es otra herramienta de detección pasiva que permite obtener el fingerprint de Sistemas Operativos sin enviar un solo paquete a la red. Esta herramienta permite hacer un mapeo host->SO de los hosts que existen en la red, sin que estos se enteren. El funcionamiento es similar al de escaners activos como nmap, revisando TTL, TCP Windows size, DF (don't fragment), TOS (Type of Service), etc, de los paquetes que llegan a la máquina.


Arpwatch

Herramienta simple pero muy útil a la hora de detectar intrusos. Arpwatch observa las MACs que existen en la red, y mantiene un archivo con su IP asociada, el timestamp de la última vez que se vió en la red, y genera notificaciones en caso de haber cambios. De esta forma, es posible detectar si una IP asociada a una dada MAC ahora está asociada a otra MAC. En una red donde las máquinas suelen conservar su IP por largos períodos de tiempo (o estar fijas), el uso de una IP por otra máquina (con su dada MAC) es una situación sospechosa.
Esta herramienta permite por ejemplo detectar ataques Man in the Middle, suplantación de proxies, servers DNS, HTTP, etc.


Tcptrack

Conocido como el 'top' (por el comando Unix) de las conexiones TCP, Tcptrack es un sniffer que muestra información sobre las conexiones TCP que ve en una dada interfaz. Al igual que las herramientas anteriores, ésta funciona de forma pasiva, observando conexiones TCP y siguiendo el rastro del estado, mostrando la lista de conexiones de forma similar al comando top de Unix.



OCS-NG

Luego de hablar sobre herramientas de detección de intrusos, vulnerabilidades y monitoreo de la red, nos encontramos con OCS Inventory NG (Open Computer and Software Inventory Next Generation) que nos permite mantener un inventario actualizado en tiempo real de los dispositivos existentes en la red.
OCS-NG cuenta con 4 componentes principales:
- servidor de base de datos: que almacena la información del inventario (puede ser MySQL 4.1 o posterior),
- servidor de comunicación: maneja la comunicación HTTP/S entre la base de datos y los agentes (Apache 1.x, 2.x),
- servidor de despliegue: almacena la información de los paquetes a desplegar (requiere HTTPS),
- consola de administración: front-end web que permite al administrador realizar consultas a la base de datos (Apache 1.x, 2.x y PHP 4.1 o superior).

El funcionamiento se basa en instalar un agente en cada host que se desea inventariar, y mantener un servidor (o repartido en varios servidores) la base de datos con el manejador de los datos enviados por los agentes. Cada agente envía los datos del inventario de la máquina a través de HTTP/S al servidor de comunicación, utilizando archivos XML comprimidos con Zlib. Luego un administrador puede revisar su inventario a través de la interfaz Web.

OCS soporta la mayoría de los sistemas operativos, incluyendo GNU/Linux, Windows, Mac, Solaris, AIX, y *BSD.

Si bien no tuve la oportunidad de probar esta herramienta (viene instalada por defecto en OSSIM, pero no desplegué agentes), a partir de los screenshots se puede observar que es muy completa, mostrando información de discos, sistema de archivos, CPU, memoria, dispositivos, controladores, etc. Una herramienta muy interesante, para tener en cuenta.


To be continued...

Hey, cómo? esta no era la última parte? bueno, si y no. Esta es la última parte del review, donde describí las herramientas que trae OSSIM y el OSSIM en sí, pero todavía no acabé de hablar sobre el monitoreo. Estoy preparando un documento sobre la configuración que le estoy haciendo para que las herramientas reporten lo que me interesa, disminuyendo falsos positivos. Si bien OSSIM funciona correctamente out-of-the-box, realmente hace falta un tuneo fino para que nos sirva lo reportado, la cantidad de información reportada por defecto es abrumadora, al igual que la cantidad de falsos positivos.
También les hablaré sobre configuraciones de seguridad y otras yerbas. Tal vez realice algún artículo (tal vez más de uno) dedicado exclusivamente a Snort, la compleja herramienta de detección de intrusos. El tiempo dirá...

Monitoreo de red: OSSIM Review Parte II (Nagios, Nessus, OpenVAS, Osiris)

Como lo prometí, heme aquí escribiendo la segunda parte del review del OSSIM. Para el que no haya leído la primera parte, puede encontrarla aquí.
Para repasar un poco las cosas, recordemos que OSSIM es una herramienta que agrupa los resultados de muchas herramientas para mostrarlos de forma uniforme al pobre encargado de monitorear la red. La lista de herramientas que se ejecutan de fondo es grande y en la primer parte repasé, además de OSSIM, los IDSs Snort y OSSEC. En esta entrega veremos un poco más sobre herramientas de monitoreo y escaneo de red. Arranquemos nomas con el repaso.


Osiris

Continuando con la seguidilla de IDSs del artículo anterior, OSSIM también trae Osiris, un HIDS centrado en el monitoreo de integridad del host. Este se utiliza para monitorear cambios en una red de hosts a través del tiempo y reportando estos cambios al administrador(es).
Actualmente, el monitoreo incluye cambios en el filesystem. Osiris toma snapshots periódicos del filesystem y los almacena en una base de datos. Estas bases de datos, así como las configuraciones y los logs, son almacenados en un host de administración central. Cuando se detectan cambios, Osiris loguea estos eventos en el log del sistema y opcionalmente envía un e-mail al administrador.
Además de los archivos, Osiris también monitorea listas de usuarios, listas de grupos, y módulos del kernel o extensiones.

La arquitectura de Osiris está basada en tres componentes:
- consola de administración (osirisimd): debe estar instalada en un host confiable porque es a donde se almacena la información sobre los hosts administrados, incluyendo configuraciones, logs, y bases de datos.
- un agente de escaneo (osirisd): proceso que se ejecuta en cada host monitoreado. Es el responsable de escanear el filesystem local y enviar los datos al host administrador.
- aplicación de administración CLI (osiris): la utiliza el administrador para administrar los detalles de los hosts escaneados. Se comunica directamente con la consola de administración.

osiris <==> osirismd <==> osirisd

Pueden leer más sobre Osiris en su handbook.


Nessus

Pasamos de la detección pasiva a la activa por un momento. Nessus es un programa de escaneo de vulnerabilidades. Su función es escanear los hosts que el usuario desea, detectando primero los ports que tienen abiertos y luego enviando una batería de test para comprobar qué hosts son vulnerables. A partir de los resultados obtenidos, Nessus arma un detallado informe con las vulnerabilidades de cada host, describiendo cada vulnerabilidad, el nivel de riesgo que representa y las posibles formas de mitigarla.
Esta herramienta ahorra horas de pruebas al auditor de red (el sueño del pentester), y permite que personas sin tanto conocimiento sobre exploits pueda conocer los problemas en la red y las soluciones.
Nessus es una herramienta muy completa y flexible, permitiendo agregar tests (plugins) de vulnerabilidades, los cuales deben ser escritos en NASL (Nessus Attack Scripting Language), un lenguaje de scripting optimizado para interacción de red personalizada. Además es posible realizar auditoría de passwords y verificar el nivel de parches aplicados en Windows si el usuario provee las credenciales necesarias.
El reporte generado por Nessus se puede exportar en varios formatos como texto plano, XML, HTML y LaTeX, además del formato propio de Nessus.

En sistemas Unix Nessus está compuesto por un demonio nessusd encargado de realizar es escaneo, y un cliente que controla el escaneo y muestra los resultados. La versión Windows, en cambio, es un solo ejecutable que contiene todo.

Realmente esta herramienta es extremadamente útil, no sólo porque realiza un escaneo automatizado excelente (cubre una amplísima variedad de pruebas), generando reportes bien descriptivos, sino también porque es muy fácil de utilizar. La primera vez que corrí Nessus quedé muy sorprendido por su capacidad, no he conocido otra herramienta que realice un escaneo automatizado tan bueno. Generalmente los escaneos automatizados cubren algunos aspectos, pero fallan en detectar muchas vulnerabilidades, dejando la mayor parte del trabajo a la persona que realiza la auditoría.

Penosamente Nessus dejó de ser libre en 2005. La compañía detrás de Nessus (Tenable Network Security) cerró el código en su versión 3 y ahora venden los plugins. Por suerte todavía mantienen un conjunto de plugins gratuitos pero que sólo pueden utilizarse en casa o en empresas sin fines de lucro (ver Nessus FAQ). Si quieren utilizar Nessus en entornos con fines de lucro, deben comprar la versión profesional.
Por ello la gente de Alien Vault (empresa detrás de OSSIM) creó su propio conjunto de plugins gratuitos y licenciados bajo la GPLv2.


OpenVAS

Además de Nessus, OSSIM incluye OpenVAS (OpenSource Vulnerability Assessment Scanner), el fork libre de Nessus, creado a partir del motor en Nessus 2 (que era libre). Se entiende a partir de esto que OpenVAS funciona igual a Nessus y persigue el mismo propósito, escanear en busca de vulnerabilidades.
Esta herramienta tiene algunas limitaciones y no llega a ser Nessus, pero el trabajo detrás es interesante, porque además se pueden utilizar los plugins libres de Nessus.


Nagios

OK llegamos a una de mis favoritas. Sin dudas Nagios es una de las herramientas más interesantes para el monitoreo de redes, aunque también una de las más complejas para customizar y mantener. Como bien dicen en el manual oficial "Relax - it's going to take some time".
Nagios es de las herramientas más complejas, pero permite a un administrador tener una visión central del estado de los hosts de la red. A través del monitoreo de hosts, Nagios puede enviar alertas en caso de fallas. La descripción de la funcionalidad es simple, monitorear hosts y alertar en caso de fallas. Además posee un front-end web desde donde se puede observar el estado de la red.

Nagios se basa en un demonio central que recibe datos de plugins y los almacena en una base de datos. La configuración de todo el sistema se realiza a través de archivos de texto. Nagios no incluye mecanismos de chequeo de estado de hosts y servicios, deja este trabajo a los plugins. Simplemente se limita a ejecutar los plugins, recibir los resultados, procesar los resultados y ejecutar las acciones necesarias.

Lo bueno del sistema de plugins es que abstraen a Nagios del chequeo en sí, logrando que sea extremadamente flexible y extensible, abarcando varias plataformas. Los plugins pueden ser scripts o ejecutables que se pueden ejecutar desde la línea de comandos.


Si bien todo el monitoreo se puede realizar desde una sola máquina, algunos plugins requieren que se instale un agente monitor en la máquina que deseamos monitorear. Ejemplo de este caso es cuando deseamos monitorear el uso de CPU, memoria, disco, de alguna máquina en particular. El agente monitor se comunica con el server Nagios para enviar la información necesaria.
Actualmente existen plugins para monitorear varios dispositivos y servicios incluyendo:
* HTTP, POP3, IMAP, FTP, SSH, DHCP
* Carga de CPU, Uso de Disco, Uso de Memoria, Usuarios Actuales
* Unix/Linux, Windows, y servidores Netware
* Routers y Switches

Alertar sobre fallas es la principal función de Nagios, pero éste también es capaz de ejecutar event handlers. Los event handlers, al igual que los plugins, son comandos del sistema (ejecutables o scripts), y tratan de arreglar el problema antes de notificarlo. Entre los usos se incluye:
* Reiniciar un servicio que falló
* Ingresar un ticket de problema en un sistema helpdesk
* Loguear información del evento en una base de datos
* Reboot del sistema (hay que tener mucho cuidado con este)

Como dije anteriormente, Nagios es muy muy completo. La configuración no es simple, pero está muy bien documentada. Lleva un tiempo hasta que logramos que nos alerte lo que deseamos, o tomar las acciones necesarias. Al principio puede resultar bastante molesto la cantidad de alertas arrojadas, pero gracias a la configuración de umbrales, y a la inteligencia para detectar flip-flos (cuando un servicio/host cae y se levanta muchas veces en un intervalo corto de tiempo) es posible lograr el funcionamiento deseado.


To be continued...

Una vez más, la cantidad de información sobrepasó el tamaño que pensaba y necesitaré terminar de describir las herramientas de OSSIM en un nuevo artículo. Resta entonces hablar sobre herramientas de monitoreo pasivas como Arpwatch, Tcptrack, p0f, Pads; graficadores de tráfico como Ntop, NFSen, y una de inventariado llamada OCS-NG.
Vengo bastante encaminado, así que probablemente termine la revisión en un par de días. Las herramientas que restan son muy interesantes y vale la pena saber de que tratan, así que stay tuned.

Monitoreo de red: OSSIM Review Parte I (OSSIM, Snort y OSSEC)

Hace tiempo en la empresa deseamos instalar un servidor de monitoreo, y por suerte el último mes volvieron realidad mi sueño (si me contento con poco...). Ya tenía en mente cómo sería la máquina para monitorear, tendría un GNU/Linux (tal vez debian o CentOS), y herramientas como ntop, Nessus y snort, pero no mucho más. Pero la cosa cambió cuando Javi me recomendó utilizar la distribución AlienVault OSSIM (Open Source Security Information Management). Esta distribución esta diseñada pensando en el monitoreo, e incluye todas aplicaciones libres destinadas a tal fin, ya configuradas y listas para usar.
La distribución lleva el nombre de la herramienta OSSIM, la cual se encarga de juntar los resultados retornados por las diferentes aplicaciones y mostrarlos en una interfaz Web única, desde donde el administrador puede observar todo lo que sucede en la red.
Si bien la instalación es muy simple y todo sale funcionando en cuestión de minutos, es necesario conocer las aplicaciones que corren de fondo para así entender los resultados retornados, y configurar el sistema para visualizar la información que nos interesa. Esta customización la vengo haciendo hace algunos días, y a partir de ella aprendí para qué sirve cada herramienta.

Como la funcionalidad de OSSIM se basa en las herramientas que corren por detrás, haré un mini-review de cada una. El review lo dividiré en partes porque son varias herramientas y muchas tienen varios componentes por lo que harían el artículo demasiado extenso. En esta primera parte hablaré de OSSIM en sí y de dos de los IDSs que trae, en las próximas examinaré el resto de las herramientas.


OSSIM

Como dije anteriormente, esta herramienta, desarrollada por la gente de AlienVault, se encarga de recolectar los datos entregados por las diferentes aplicaciones de monitoreo y mostrarlos a través de una interfaz Web. Realmente me sorprendió el nivel de integración que tiene OSSIM con el resto de las herramientas (que describiré abajo), logrando abstraer al administrador de lo que sucede de fondo. En lugar de tener que mirar por separado miles de logs, la interfaz Web junta todos los datos en un solo lugar y permite así tener vistas detalladas de cada aspecto de las redes, hosts, servidores, etc.

OSSIM se divide en tres programas: ossim-server, ossim-framework y ossim-agent. Además utiliza una base de datos para almacenar los eventos y la información necesaria para plugins.

- ossim-server: este programa es un demonio que se ejecuta en background y se conecta con la base de datos para obtener/ingresar datos desde los agentes y el framework. El propósito principal de este programa es:

# recolectar datos de los agentes y otros servidores
# priorizar los eventos recibidos
# correlacionar los eventos recibidos de diferentes fuentes
# realizar la evaluación de riesgos y disparar alarmas
# almacenar eventos en la base de datos
# reenviar eventos o alarmas a otros servidores

Pueden leer más en la documentación oficial sobre servidor.

- ossim-framework: es otro demonio que ejecuta tareas misceláneas, no realizables por los agentes, servers o el front-end. Este accede tanto a la base de datos de conocimiento del OSSIM, como a la BD de eventos. El propósito principal de este programa es:

# leer/escribir archivos del filesystem, evitando que el server web lo haga directamente.
# ejecutar comandos externos.
# ejecutar en background tareas que requieran uso intensivo de CPU, para acelerar la visualización y el análisis.

Pueden leer más en su documentación oficial sobre framework.

- ossim-agent: se instala un agente en cada máquina que deseamos utilizar como monitor (llamadas sensores). Los agentes se encargan de recolectar todos los datos enviados por los diferentes dispositivos conectados a la red, estandarizar estos datos para que OSSIM pueda entenderlos, y luego enviarlos al servidor.
Pueden leer más en la documentación oficial sobre agentes.

Dados los tres programas anteriores, la arquitectura de OSSIM se divide en 4 elementos:
1. Sensores
2. Servidor de Administración
3. Base de Datos
4. Frontend
En la configuración default, los sensores se encargan de realizar las tareas de IDS, Vulnerability Scanner, detección de anormalidades, monitoreo de red, recolección de datos de routers, firewalls, e incluso pueden funcionar como firewall. Los sensores se encargan de enviar toda la información al servidor de administración, luego de haberla estandarizado.
Por su parte, el servidor de administración contiene el framework y el servidor OSSIM. Este servidor se encarga de recolectar la información de todos los sensores y normalizar, priorizar, coleccionar eventos, así como realizar análisis de riesgo. Además se encarga de realizar backups, inventarios on-line, y ejecución de escaneos.
La base de datos almacena eventos e información útil para la administración del sistema.
El frontend, como ya mencioné, es una aplicación web donde se puede visualizar todo lo que sucede.

La magia utilizada para estandarizar los datos recolectados de los diferentes programas, se realiza a través de plugins. Cada herramienta que se utiliza, debe tener su correspondiente plugin en OSSIM.
Existen dos tipos de plugins:
- Detectores: encargados de leer los logs creados por las diferentes herramientas y estandarizarlos para que el Agente pueda enviarlos al servidor. Ejemplos típicos de plugins detectores son snort, p0f, arpwatch, pads, etc.
- Monitores: reciben pedidos del servidor OSSIM y los envían a la herramienta correspondiente, obtienen la respuesta y le avisan al servidor si la herramienta acepta lo que se le pide. Ejemplos de monitores son el nmap y tcptrack.

Como ven, OSSIM es un sistema bastante complejo. En la documentación oficial pueden encontrar cómo crear plugins propios, así como también cómo crear políticas para generar alertas y acciones. Realmente vale la pena estudiarlo y utilizarlo.


Snort

Snort es uno de los IDSs utilizados por OSSIM. Por si todavía no conocen este tipo de herramientas, IDS significa Intrusion Detection System, o sistema de detección de intrusos. Los IDSs utilizan distintas técnicas de análisis para alertar al administrador en caso de ver acciones sospechosas. Snort en particular es un NIDS (N de Network) que se encarga de analizar el tráfico de red, inspeccionando el contenido de los paquetes para disparar alertas, o incluso, realizar algún tipo de acción cuando detecta trafico sospechoso. Snort es el IDS más utilizado mundialmente, y es probablemente el más completo de su tipo.
Como bien dice en el FAQ oficial, snort realiza análisis de protocolo, búsqueda/matching de contenido, y puede detectar una gran variedad de ataques y pruebas, como buffer overflows, escaneo sigiloso (stealth) de ports, ataques CGI, intentos de fingerprint de SOs, pruebas SMB, y mucho más.

La idea es simple (implementarla no lo es tanto), Snort sniffea la red y a través de un conjunto de reglas decide si el tráfico es sospechoso. Las reglas contienen la información que debería contener un paquete para considerarlo sospechoso, como ser la IP origen, el port origen, la IP destino, el port destino y el contenido del paquete. En las reglas se pueden utilizar expresiones regulares y se debe incluir un mensaje que describa qué es lo que detecta.
Además del motor de detección, Snort provee preprocesadores. Los preprocesadores permiten a los usuarios y programadores extender la funcionalidad de Snort. El código de los preprocesadores se ejecuta antes del motor de detección, pero después de que el paquete fue decodificado.

Snort es muy flexible y permite al usuario crear sus propias reglas y preprocesadores. Las reglas se almacenan en path/snort/rules/ y tienen una sintaxis simple, los preprocesadores requieren programación. Un artículo interesante para revisar es el de O'Reilly Write Your Own Snort Rules . Por supuesto, la mejor referencia de Snort es la guía de usuario proporcionada por Sourcefire (la empresa detrás de Snort).


OSSEC

Otro de los IDSs provistos por OSSIM, en este caso, un HIDS (H de Host). Un sistema de detección de intrusos basado en el Host se encarga de analizar los datos del host y detectar a través de ellos si el host está siendo víctima de algún ataque. OSSEC realiza esta tarea analizando logs, checkeando integridad, monitoreando la registry de Windows, detectando rootkits, y generando y respondiendo en tiempo real.
Los IDSs basados en análisis de logs son llamados LIDS (L de Log), porque detectan errores (o ataques) usando logs como su fuente de información primaria.

OSSEC (desarrollado por Trend Micro) está formado por un administrador (manager) central de monitoreo, que recibe información desde agentes, syslog, bases de datos y dispositivos sin agentes (agentless).


El manager almacena las bases de datos del chequeo de integridad de archivos, los logs, los eventos, y las entradas de auditoría del sistema. Todas las reglas, decodificadores y configuraciones importantes se almacenan en el manager.
Los agentes son pequeños programas que se instalan en los sistemas que deseamos monitorear, estos coleccionan información en tiempo real y se la envían al manager para ser analizada.
En los sistemas donde no se puede instalar agentes (Agentless), OSSEC puede realizar monitoreo de integridad de archivos.

OSSEC corre en la mayoría de los sistemas (Windows, Linux, OpenBSD/FreeBSD, y MacOS), y el análisis lo realiza a través de reglas escritas en lenguaje XML. Al igual que Snort, estas reglas son relativamente simples de escribir y se basan en la búsqueda de patrones (se pueden usar expresiones regulares) en los archivos analizados. También se pueden crear reglas compiladas, escritas en lenguaje C.

Como se habrán dado cuenta, OSSEC es una herramienta muy potente. Pueden aprender más de OSSEC leyendo el FAQ de la página, donde encontrarán varios tutoriales.


To be continued...

Como dije al principio del artículo, OSSIM posee muchas herramientas, las cuales son complejas y tienen grandes funcionalidades. Entre las herramientas más complejas, me falta escribir sobre Nagios, Ntop, Osiris y OpenVAS. Además me falta describir herramientas más simples en arquitectura pero extremadamente útiles como arpwatch, p0f, tcptrack, pads, spade y Snare. Esperen la próxima entrega, la cual espero no demorar demasiado...

review: McAfee ePolicy Orchestrator (ePO)

En la empresa donde trabajo utilizamos el antivirus McAfee, y realmente me sorprendió la funcionalidad provista por la herramienta de administración ePolicy Orchestrator (conocido como ePO entre los amigos). El otro día tuve una capacitación al respecto y me dejó con una muy buena imagen del software, el cual es un lujo para el administrador.

Si bien McAfee puede no ser el antivirus con mejores referencias en los reviews de detección, la realidad es que no me puedo quejar. En el tiempo que llevo trabajando aca no hemos tenido serios problemas con virus, más allá de las clásicas detecciones.

Para el que no la conozca, ePolicy Orchestrator es una herramienta que nos permite administrar los antivirus instalados en todas las máquinas de la red, permitiendo ver reportes muy customizables (cientos de opciones) sobre lo que sucede en la red, además de facilitarnos la tarea de actualizar los motores de antivirus instalados en cada máquina, como así también establecer políticas.

Esta completísima herramienta nos deja organizar la red en grupos de máquinas y establecer políticas por grupos. También es posible establecer políticas por máquina, o para todas las máquinas.

Las políticas son instrucciones sobre cómo actuar ante diferentes eventos. A través de ellas podemos hacer cosas como forzar que el antivirus siempre elimine un archivo cuando está infectado, o avisar al usuario para tomar acción. También es posible fijar los servidores de actualización de cada grupo de máquinas.
Pero eso no es todo, también podemos establecer políticas sobre a qué archivos o claves de registro puede acceder el usuario, o proceso, reportando o negando la acción. Lo mismo para los ejecutables que puede abrir cada usuario. Permite una granularidad muy fina sobre qué puede y qué no puede hacer un dado usuario, grupo, o máquina.

La parte de reportes es, como dije, excelente. Nos permite ver estadísticas e información sobre los eventos que ocurren en la red. Es así como podemos rápidamente observar cuáles fueron los virus con más detecciones, las máquinas/usuarios que reportaron mayor cantidad de infecciones.
Todo es customizable a través de filtros, y podemos armar reportes (muy flexibles) con los datos que más nos interesen y enviarlos por mail.

Toda esta magia se lleva a cabo instalando un servidor Orchestrator y agentes en cada máquina. El agente no es el antivirus, sino el que se comunica con el servidor para obtener los comandos. A través de los agentes podemos enviar comandos para que se instale un antivirus o alguna otra herramienta de McAfee (antispam, firewall, etc).
Los agentes se comunican con el servidor cada ciertos intervalos de tiempo (que se pueden customizar). Cada vez que se conecta al servidor puede obtener comandos (políticas, acciones, configuraciones, etc) o enviar reportes sobre lo que sucedió en la máquina donde se encuentra instalado. Si hay algo para hacer, el server se lo indica y el agente procede.


Como se habrán cuenta, el funcionamiento es idéntico al de una botnet, con un servidor de comandos y los bots que son los agentes.

Este sistema hace la vida del administrador de red más placentera (si es que puede ser placentera), porque de esta forma todo trabajo se realiza administrando un servidor en lugar de tener que ir máquina por máquina cambiando configuraciones. La consola se accede a través de interfaz web y permite tener distintos niveles de usuarios. Es posible crear roles de usuarios con sus correspondientes vistas.
El administrador se limita a armar las configuración que desea y el servidor se encarga de hablar con los agentes y ocuparse de que las cosas se hagan. Si algo falla, el servidor lo reporta.

Imagínense, el admin puede decir, quiero que todas estas máquinas no puedan ejecutar tal proceso, o quiero que estas máquinas utilicen este motor de antivirus, o quiero que me reporten tales datos... es realmente un lujo.

Además de la parte administrable, el Orchestrator nos permite reducir el uso de ancho de banda porque funciona como servidor de updates. Es decir, Orchestrator se conecta a la página de McAfee, descarga los updates y luego lo distribuye a todas la máquinas de la red interna.
También es posible tener repositorios de updates separados al orchestrator por si nuestra red está dividida en sectores, o por si tenemos muchas máquinas y no queremos saturar al pobre Orchestrator.

En resumen, considero esta herramienta un lujo. Posiblemente existan soluciones de otros proveedores de antivirus que sean similares a esta, pero no creo que puedan tener mucho más de lo que ésta trae.
Si deben administrar cientos de máquinas en una organización utilizando Windows, les recomiendo que le den un vistazo a este excelente producto.

Quiero dejar en claro que cuando hablo de excelente herramienta, me refiero a funcionalidad. Este, como todo software, tiene sus problemas de vulnerabilidades. Existen versiones de agentes vulnerables a exploits tan graves como remote code execution. Es claro que tener un programa más en la máquina escuchando en un puerto genera un problema más de seguridad. Esto se puede mejorar instalando firewalls locales y filtrando todo acceso que no provenga del Orchestrator.

Si desean leer un poco más sobre este producto, descarguen la guía de ePolicy Orchestrator provista por McAfee, la cual provee información sobre arquitectura, funcionamiento, instalación y algún que otro dato más.

KOOBFACE, el worm de Facebook

Hoy les traigo el review de una pieza magistral de malware: KOOBFACE. Esta singular software viene dando vueltas hace meses por distintas redes sociales de mucha importancia, siendo la más popular Facebook, gracias a la cual se ganó el nombre (koobface es un anagrama de facebook).

Actualmente este worm se dispersa, además de Facebook, por MySpace, hi5, Bebo, Twitter y Friendster, entre otros. Como suele suceder con la mayoría del malware importante, éste se dispersa por máquinas Windows, así que los *nixeros estamos a salvo =P

A lo largo del review voy a seguir la excelente explicación hecha por la gente de Trend Micro, llamada The Real Face of KOOBFACE.

KOOBFACE está formado por varios componentes, cada uno con una funcionalidad distinta. Estos componentes están dispersos en varios archivos que forman una bootnet (ver la imagen - cortesía de Trend Micro). La cantidad de componentes que forman esta botnet es increíble, haciendo del malware una pieza digna de investigar.



La forma de propagación no es nada del otro mundo. Uno recibe un mensaje en Facebook o alguna otra red social con un comentario llamativo que referencia un link a un "video" en "youtube". Digo "video", porque en realidad cuando seguimos el link llegamos a una página (llamada YuoTube...) que nos dice que nuestra versión de Flash está desactualizada y que para poder ver el video necesitamos instalar un ejecutable... ehhh alguien en su sano juicio no le daría instalar... ehhhh... mejor sigo con la explicación. Para el que tenga poca imaginación, aclaro que el ejecutable no es otra cosa que un downloader, el cual se encarga de descargarnos los componentes del KOOBFACE (si le dieron click están listos...).

La gente de Trend Micro dividió los componentes en las siguientes categorías:
- KOOBFACE downloader
- Componentes de propagación por redes sociales
- Componente Servidor Web
- Propagandeador e instalador de antivirus falso
- Rompedor de CAPTCHA
- Ladrón de datos
- Hijackers de buscadores Web
- Cambiador de DNS
como ven, son varias categorías, osea, el malware es bien completito, trae un poco de todo.
Cada uno de estos componentes es interesante, así que describo brevemente cada uno de ellos.

El downloader se encarga de determinar en qué redes sociales el usuario es miembro. Esto lo hace revisando las cookies del navegador. Una vez que sabe en qué redes el usuario tiene cuentas, se conecta al Command Y Control (C&C) y descarga los componentes que el C&C le indique.
KOOBFACE tiene la habilidad de armarse a medida para cada usuario, dependiendo de en qué redes sociales el usuario es miembro. Por ejemplo, si el usuario es miembro de Facebook y Twitter, el C&C le indica al downloader que se descargue las componentes de propagación para estas dos redes sociales.
Además de las componentes de propagación, el C&C le indica qué otras cosas le interesaría que la máquina del usuario haga, descargando alguno de los otros componentes.

Los componentes de propagación son los encargados de enviar los mensajes en las redes sociales, los cuales harán que otros usuarios se infecten si instalan el downloader. Estos componentes básicamente contactan el C&C, obtienen los mensajes y las URLs a postear, postean el mensaje y URLs en la página de cada red social, y también envían mensajes a la bandeja de entrada de otros usuarios.
Los componentes de propagación comprenden varios binarios, los cuales fueron construidos especialmente para manejar un site de red social en especial.
El gran enganche en la propagación está en que uno suele confiar en los links que envía un amigo y no piensa que puede tratarse de algo malicioso...

El componente Web server hace de nuestra máquina un lindo punto de distribución de malware. Una vez que el web server se instala en nuestra máquina, éste se registra en el C&C. El C&C le indica a nuestro nuevo, flamante e indeseado web server que actúe como proxy o como un redireccionador para distribuir otros componentes de KOOBFACE.
Este componente sirve las páginas falsas de YouTube, las cuales terminan en el downloader.

El propagandeador e instalador de antivirus falso se encarga de convencer al usuario de que su máquina está infectada lanzando ventanas de advertencia con links a antivirus falsos.

El rompedor de CAPTCHA usa una idea interesante, en vez de hacer el trabajo molesto de desenmarañar los CAPTCHAs para poder publicar cosas automáticamente, hacer que usuarios infectados resuelvan los CAPTCHA y usar el resultado obtenido!
Para hacer esto, el malware descarga la imagen con el CAPTCHA de alguno servidor C&C y amenaza al usuario a resolverlo con un mensaje inductor de pánico, el cual tiene un contador regresivo que reza "tiempo antes de apagar"... si el usuario no escribe lo que dice en el CAPTCHA KOOBFACE no apaga la máquina, sino que vuelve a reiniciar el contador. El contador está impuesto porque los CAPTCHAs tienen un tiemout, si no se resuelven en un dado tiempo, se genera un nuevo CAPTCHA.

Entrando en los componentes más riesgosos, nos encontramos con el ladrón de datos. El ladrón de datos roba IDs de Windows, perfiles de Internet, credenciales de e-mail, ftp y mensajeros instantáneos (GAIM, ICQ, Trillian, etc). Los datos robados son encriptados y enviados al C&C.

Los Hijackers de buscadores Web interceptan las búsquedas en Google, Yahoo, etc y las redirigen a dudosos sitios propios. Los sitios a donde vamos a parar nos muestran los resultados listando compañías que pagan a los administradores de KOOBFACE y no son sitios con buena reputación...

El cambiador de DNS modifica los servidores DNS utilizados por la máquina del usuario para que apunten a servidores DNS administrados por gente de KOOBFACE. Estos servidores interceptan los sitios que el usuario visita y envían en su lugar paginas con malware o phishing. Estos servidores DNS también bloquean el acceso a páginas de antivirus o de seguridad!


Como pueden observar, KOOBFACE puede hacer mucho y lo hace muy inteligentemente.
Para terminar, los de Trend Micro publicaron además una lista de las 8 cosas que seguramente no conoces acerca de KOOBFACE, es interesante como para enterarse rápidamente a qué nos enfrentamos.


Conclusiones

Como se habrán dado cuenta, KOOBFACE es una red compleja muy bien pensada y diseñada que abarca varias ramas de malwares y se propaga como chisme. Viene dando vueltas desde diciembre de 2008 (tal vez antes) y cada semana leo alguna noticia relacionada al tema, por lo que está muy activa actualmente.
La gran conclusión de todo esto es, NO INSTALES NADA QUE NO ESTES SEGURO!, no den click a lo pavo en todo lo que se quiera instalar. No le hagan caso a los alertas de antivirus falsos! No sigan cualquier link! Hotmail no se cierra! (uhh, eso pertenece a otro post...)

review: Nine Ball + FFSearcher

No es secreto que la web se presta para todo tipo de hackeos, pero en estos últimos meses se dieron casos de inyección masiva que infecto miles de páginas y a través de ellas se infectó a miles de workstations de usuarios.
El caso que nos compete en esta entrega es Nine Ball y uno de los malwares que instala, el troyano FFSearcher. Nine Ball (según websense) infectó más de 40.000 sitios web legítimos en las dos semanas observadas, desde los cuales se infectaron miles de máquinas con FFSearcher a través del uso de múltiples exploits.

Los sitios web infectados (con un código ofuscado para no ser detectado) redirigen al usuario, de forma transparente, entre diversos sitios, terminando una serie de exploits que, si tienen éxito, instalan el troyano. Esto es, si un usuario visita un sitio web infectado, es redirigido a través de una serie de sitios web que son propiedad del atacante, terminando en la página final (ninetoraq.in, gracias al nombre de esta se nombró al malware Nine Ball) que contiene el código de los exploits. La última página visitada almacena la dirección IP del pobre e ignorante usuario (ignorante en el sentido que no se entera de todo lo que está pasando). Cuando el usuario visita una de las páginas infectadas por primera vez, éste es redirigido hasta llegar a la página con el exploit, pero si el usuario ya ha estado en alguna de las páginas, la redirección es hacia el sitio legítimo y no infectado ask.com.
Ustedes se preguntarán, y para qué hace esto???... bueno, es una genialidad del autor, de ésta forma le complica la vida a los analizadores del malware, porque sólo podrán observar el comportamiento una sola vez por IP, si visitan el sitio más de una vez con la misma IP, simplemente verán ask.com (me imagino la calentura de los pobres trabajadores de la seguridad =D). Por otra parte, la redirección hace que sea más complicado encontrar la fuente del mal. Pueden ver un dibujo abajo (créditos a websense) con este sistema de trabajo.
Ahora, también pueden estarse preguntando, y cómo es que llego hasta la página de ninetoraq sin enterarme??? Resulta que esto es especialmente fácil de hacer, sino recuerden mi anterior artículo Robando información del historial (sin usar JavaScript!). Todo es cuestión de encontrarle la vuelta, pueden usar JavaScript o el ya clásico sistema de hacking usando iframes que se oculta mucho mejor.
El código inyectado en los sites es de cierta forma random, pero la deofuscación es siempre igual. El algoritmo usa la función de JavaScript "String.fromCharCode" para convertir un grupo de valores decimales a string. El string obtenido tras la deofuscación es un iframe que eventualmente conduce a la página infectada.
El payload del código malicioso está altamente ofuscado (para que no lo pesque cualquier antivirus zapallon) e intenta explotar vulnerabilidades en Acrobat Reader, QuickTime, Microsoft Data Access Components (MDAC) y AOL SuperBuddy, entre otras posibles.

Como mencionaba al principio del post, Nine Ball es una de las inyecciones masivas que ocurrieron en el último tiempo, otras fueron Gumblar que infectó cerca de 60.000 páginas y Beladen que hizo lo propio con unas 40.000. Esto se va poniendo de moda...

Además de la citada websense, también pueden leer sobre Nine Ball en scmagazineus.com e infoworld.com.


Comentado el funcionamiento de Nine Ball, me meto de lleno con FFSearcher, tal vez el malware más interesante de los instalados por Nine Ball. FFSearcher debe su nombre a uno de los sitios utilizados en el engaño (ffsearcher.com) y es un sistema de Click fraud sobre Google Adsense for Search.
Una vez instalado en la máquina víctima, FFSearcher redirigirá de forma transparente todas las búsquedas que haga el usuario en google a través de los sitios amigos del malware, y de esta forma hacer ganar a dichos sitios grandes sumas de dinero.
Para entender mejor cómo ganan dinero, les detallo un poco mejor el mecanismo (picarones, ya los veo queriendo hacer lo mismo). Supongan que el sitio ganardinerosintrabajar.com incluye un widget Google Adsense for Search para que cuando un usuario realize una búsqueda a través de dicho textbox y clickee algún resultado, Google le pague a ganardinerosintrabajar.com una cierta suma de dinero. Ahora supongan que un usuario ignorante (nuevamente, ignorante en el sentido de que no sabe que sucede detrás) tiene instalado FFSearcher en su pc, éste abre en su browser (Firefox o Internet Explorer) la página google.com, realiza una búsqueda y clickea alguno de los resultados (hace un request sobre una página a google para entrar en ella). FFSearcher hará que ni la búsqueda en google ni el request de la página deseada vallan directamente a google.com, sino que vallan al widget de ganardinerosintrabajar.com y así darle una alegría al dueño de ganardinerosintrabajar.com, quien teniendo una página que capaz no visita ni su madre, se llena de dinero.

Lo "bueno" de FFSearcher es que logran hacer todo el fraude de forma transparente para el usuario. El usuario no ve ningún indicio de lo que está pasando dado que el browser envía y recibe los requerimientos de forma normal, y el troyano por debajo se encarga de reformarlos para desviarlos a donde desea y luego transformar lo retornado para que parezca provenir de google.com. Además los resultados no son alterados por el troyano, algo que seguramente avivaría al usuario de que algo va mal. Por otra parte, los atacantes no están desviando los pagos hacia/desde los publicistas como en el Click Fraud tradicional, simplemente fuerzan a google a pagarles por algo que de otra forma no les pagarían. Digamos, le sacan un poco de dinero a google y no perjudican a nadie, al final no son tan malos =P
Entre las páginas que se estuvieron beneficiando con el fraude, según SecureWorks, son la citada ffsearcher.com, i-web-search.com y my-web-way.com. Por supuesto que google ya les dio la baja al Adsense de dichas páginas, pero el atacante podría crear algunas nuevas.

Algunas fuentes de información son voices.washingtonpost.com y blog.trendmicro.com.