Seguridad en navegadores

Hola,

El amigo Chema se ha currado una presentación sobre seguridad en navegadores. En su día me comprometí a hacer referencia al mismo, y que haría los oportunos comentarios al respecto.

Yo no voy a comentar la totalidad de las secciones del informe porque hace tiempo que tengo interés en otro tipo de factores asociados a la seguridad que no suelen aparecer en las comparativas técnicas de productos, y que pueden hacer que en un despliegue empresarial las condiciones de seguridad sean tremendamente variables y dispares. Que nadie entienda que con este razonamiento resto validez al informe, o que lo menosprecio en algún modo: nada más lejos de la realidad. Este informe muestra información que puede ser interesante para los lectores, como el recuento de vulnerabilidades (aunque prefiero métricas como la correlación de costes por incidente y por vulnerabilidad en función al tiempo de exposición), comparativas de distintas funcionalidades y otros detalles de índole técnica que pueden y de hecho a buen seguro permiten adquirir al lector un conocimiento más profundo sobre cada producto analizado y de las diferencias que existen entre ellos. Sin embargo, tal y como decía, considero que este informe no contiene información relacionada con la seguridad que entiendo que es necesaria conocer para poder escoger un producto de navegación. Por poner algunos ejemplos:

  • No se habla sobre la problemática que tienen muchísimas corporaciones con la presencia de legacy (Oracle, SAP, un buen numero de CRMs y otros ERPs, por poner algunos ejemplos). Son muchos los que por motivos de dependencias históricas y mala praxis de los vendedores están ligados a Internet Explorer 6 sin posibilidad real de usar Internet Explorer 7 y 8. Este es un problema real de la seguridad empresarial al cual ningún informe pone solución y que lógicamente resta valor a las comparativas que sólo hablan de las versiones más recientes de un producto determinado. Si el documento habla sólo de las versiones recientes, se pierde la perspectiva de un problema crucial como el que citamos.
  • El informe tampoco habla sobre datos reales de impacto de malware sobre navegadores. Como usuario, y decisor quiero tener claro si el malware real puede pegarle más fuerte a IE8, Firefox, Chrome u Opera. Aunque tengo claro que el malware tiene mayor apetencia por los productos de mayor cuota de mercado, no veo referencias a qué navegador se orientan las muestras reales de troyanos financieros y sobre todo, en qué porcentajes y proporciones económicas. ¿Cuál de los productos atrae a más diseñadores de malware? ¿Cómo podemos cuantificar esa apetencia? ¿Facilita alguno de los productos más que otro el uso de inyecciones y modificaciones de HTML por parte de troyanos financieros? ¿Cuál ofrece mejor acceso a un troyano al sistema operativo? En definitiva, ¿para que navegador se diseñan más amenazas y que consecuencias tiene en cada caso la elección de un navegador distinto?
  • ¿Qué navegador facilita la optimización en costes a la hora de desplegar un parche de seguridad? Aunque esto parezca trivial, conviene recordar que un parche se despliega una vez hayamos realizado las pruebas correspondientes, a no ser que seamos unos temerarios que no probamos las cosas antes de lanzarlas a producción. Las pruebas son una fuente de consumo de recursos muy representativa, especialmente agravada por la presencia de múltiples versiones y variantes de aquello que se quiere probar a lo largo del tiempo. Una vez probado y validado el cambio, lo distribuimos a la red corporativa. ¿Que navegador promedia mejores tiempos en función al tamaño y frecuencia de los parches? ¿Cuál promedia mejores consumos de ancho de banda? ¿Qué modificaciones, parches y nuevas funcionalidades son más sencillas (y por ende, económicas) de probar? ¿Qué productos proyectan en el medio y largo plazo mejores ahorros en pruebas y validaciones?
  • ¿Cómo resolver los bloqueos y la gestión de listas de Javascript? Ya hemos visto que los navegadores suelen hacer aguas cuando los exploits permiten la ejecución de código arbitrario basado en la permisividad Javascript. En no pocas ocasiones este no es un problema técnico, sino de gestión de personas. Por mucho que un navegador soporte la configuración por zonas (IE) o la gestión de scripting activo peligroso Javascript mediante addons (NoScript y similares), en muchos casos el filtrado de contenidos choca con aspectos no técnicos, como las condiciones legales o laborales que pueden dificultar o imposibilitar el bloqueo de ciertos contenidos. Y aunque podamos configurar por zonas o emplear addons, ¿Quién mantendrá esas listas blancas/negras? ¿Qué costes tiene asociada una medida como esa? ¿Que pasa si no tenemos un 24×7 y hay que actuar sobre esa lista con urgencia? ¿Es rentable echarle encima a nuestro 24×7 este tipo de responsabilidades? ¿Es más barato mantener un addon o unas listas vía GPO? ¿Si optamos por el addon, hay que empaquetar cualquier cambio para distribuir o existen métodos más económicos para cambios incrementales?

Son sólo algunos ejemplos de las cosas que normalmente no aparecen en los informes y comparativas. Y es normal que no aparezcan, porque es información difícil de recopilar y que no suele estar disponible de un modo genérico para ser utilizada en cualquier entorno. Sin embargo, al menos para mí, la respuesta a estas preguntas es crucial para saber, en un despliegue determinado y bajo unas condiciones de contorno determinadas, que producto o productos de navegación son más aconsejables. Yo soy incapaz de emitir un juicio basándome sólo en las características de cada producto consideradas de modo estático e individual, igual que soy incapaz de elegir un coche en función unicamente a lo que dicen las fichas de vehículo: necesito respuesta a esas y otras preguntas. Quizás ese sea el punto flaco de las comparativas, y no sólo a las de navegadores (las de antivirus son un buen ejemplo de escasa utilidad por norma general)

No existe navegador perfecto, y ninguno de los productos que hay ahí fuera esta exento de sufrir un 0-day. Vulnerabilidades tienen todos los productos, y te puedes zampar un drive-by uses Firefox o uses Explorer (por hablar de los dos más habituales) y por mucha filigrana que tengan ambos, como las barras antiphishing, el resalte de dominios (que no tiene Firefox) o por más flexibilidad que permitan uno u otro a la hora de administrar el funcionamiento de Javascript. Creo que los que nos dedicamos a la seguridad debemos hacer hincapié en un mensaje que debe quedar claro para los usuarios que buscan respuestas rápidas a problemas que tienen infinidad de dependencias. NINGÚN NAVEGADOR GARANTIZA TU SEGURIDAD. La seguridad la proporciona una combinación de condiciones mucho más compleja que el uso de un navegador u otro, y no hay que tener miedo a aparcar temporalmente nuestro navegador favorito mientras sea vulnerable y no exista una solución fiable para evitar los riesgos.

En el mundo empresarial, así como en el personal, creo que es buena práctica tener instalados al menos dos productos distintos, de modo que cuando se presentan problemas para uno de ellos, sea posible usar sin riesgos el otro. Implementar una estrategia dual no es tan complicado, sobre todo teniendo en cuenta que la mayoría de las infraestructuras corporativas emplean soluciones Microsoft para el escritorio, y por tanto, es frecuente encontrar soluciones Microsoft para el mantenimiento y distribución de software (Systems Management Server/System Center Configuration Manager). Es perfectamente viable emplear GPOs para actualizar el navegador que deben usar por defecto los usuarios, con lo que técnicamente es perfectamente posible que la dualidad exista sin que sea necesaria la intervención del usuario. También es perfectamente posible disponer de los dos navegadores e ir informando a los usuarios sobre la necesidad de emplear el navegador por defecto o el alternativo. Como poder se puede hasta automatizar que los enlaces de Internet se abran con un producto y los Intranet con otro distinto.

Lo que es absurdo es insistir una y otra vez en que sólo debemos confiar en un sólo producto, sea IE, Firefox o cualquier otro. Creo que la trayectoria mostrada por todos los productos, que deja mucho que desear en todos y cada uno de los casos, la especialización del crimen organizado, la existencia de un industria consolidada dedicada al diseño y descubrimiento de exploits para productos software y los más que patentes riesgos de sufrir quebrantos económicos y no económicos en casa y en la empresa justifican el uso de una estrategia dual de productos de navegación cuando sea necesaria, que debe ir ineludiblemente acompañada de un esfuerzo importante en la formación y concienciación del usuario.

Un saludo,

Obtención de líneas temporales para análisis forense mediante log2timeline

Hola,

En cualquier investigación forense es vital la obtención de una línea temporal que permita recrear la sucesión de eventos. Cuando los eventos son numerosos, complejos y concurrentes, tener una representación gráfica de dicha sucesión puede ayudar al investigador a plantear y resolver el caso.

Os dejo una reseña sobre log2timeline, una útil aplicación que nos permitirá generar ficheros compatibles con, entre otros, líneas temporales SIMILE. La aplicación permite igualmente generar líneas temporales compatibles con ArcSight Commen Event Format (CEF), XML estándar para procesar con CyberForensics TimeLab (CFTL), CSV, mactime, SQLite y TLN.

Log2timeline puede leer datos de ficheros de eventos de Windows, exif, favoritos e historia en los principales navegadores (Firefox, Opera, IE, Chrome), logs IIS, pcap, pdf y otros tipos de ficheros que están descritos en la documentación. Se pueden enumerar ejecutando log2timeline -f list.

log2timeline

A modo de prueba, aquí tenéis el código que se genera a partir de un histórico de navegación de Google Chrome, una vez exportado para ser procesado con SIMILE. En este caso en concreto se muestra el total de la actividad de mi navegador Chrome en una corta sesión de ejemplo. Nótese la utilidad que puede tener para el investigador la presencia de datos relacionados con el comportamiento del usuario, como por ejemplo

  • type: [START_PAGE – The start page of the browser] (URL not typed directly)
  • type: [TYPED – User typed the URL in the URL bar] (directly typed)
  • type: [LINK – User clicked a link] (URL not typed directly)

Instalación de log2timeline

El proceso es bastante simple, ya que tiene únicamente tres pasos: perl Makefile.PL, make y make install (como root). No obstante, y dependiendo de lo que tengas instalado en tu máquina, es frecuente que al crearse el fichero make se presenten algunos warnings con aquellos módulos que no han sido encontrados. La mayoría son prerrequisitos para poder parsear distintos tipos de fichero, en mi caso faltaban File::Mork, HTML::Scrubber, Image::ExifTool, Net::Pcap y XML::LibXML. Aunque puedan parecer simples avisos, y aunque no vayamos a usar el soporte para los ficheros afectados, es conveniente instalar los módulos para prevenir fallos en el funcionamiento de log2timeline (lo que incluye operativas básicas como listar los tipos de logs procesables, los tipos de salida generables, etc)

Un saludo,