Si hace poco en Hacktimes.com se analizaban los certificados SSL/TLS de diferentes entidades bancarias españolas, hoy le toca el turno a la seguridad de las páginas de las que dispone el Gobierno de España que, desgraciadamente, tan de moda está en la actualidad. Utilizando herramientas para obtener todo tipo de información relativa a las páginas Web del dominio GOB.ES tales como theHarvester o extensiones para Google Chrome como Recx Security Analyzer se ha revisado la seguridad de 150 páginas Web como, por ejemplo, Agencia tributaria (www.agenciatributaria.gob.es), la página del Palacio de la Moncloa (www.lamoncloa.gob.es), las sedes y subsedes de los diferentes Ministerios, etc.
En concreto, se ha analizado la presencia de certificados SSL (Secure Socket Layer) en las diferentes páginas, la protección de los servidores Web contra ataques de Cross Site Scripting (XSS), el tipo de Servidor Web utilizado (Apache, Internet Information Server, etc.), la privacidad ofrecida a los usuarios con opciones como Caché-Control y diversas cabeceras HTTP que ayudan a mejorar la seguridad de las aplicaciones Web en general desde el punto de vista del usuario.
El procedimiento a seguir ha sido sencillo, con la herramienta theHarvester de la gente de Edge-Security (http://www.edge-security.com/) se buscaron e identificaron todas las páginas y subdominios que tiene indexados Google bajo el dominio GOB.ES, aproximadamente 150. Se filtraron las páginas repetidas y se analizó la seguridad a nivel HTTP de cada una de ellas:
./theHarvester.py -d gob.es -b google -l 500
...
[-] Searching in Google:
Searching 0 results...
Searching 100 results...
Searching 200 results...
Searching 300 results...
Searching 400 results...
Searching 500 results...
[+] Emails found:
------------------
No emails found
[+] Hosts found in search engines:
------------------------------------
194.69.254.170:datos.gob.es
194.69.254.170:Datos.gob.es
193.147.0.87:sede.educacion.gob.es
194.224.66.10:www.educacion.gob.es
195.76.37.29:www.secegsa.gob.es
195.235.106.207:www.agenciatributaria.gob.es
195.66.151.69:www.sedecatastro.gob.es
193.146.141.234:www.lamoncloa.gob.es
193.146.141.234:www.leydetransparencia.gob.es
92.54.16.73:www.economiasostenible.gob.es
193.147.0.49:www.csd.gob.es
193.147.0.101:sede.csd.gob.es
...
Después, utilizando la extensión de Google Chrome antes comentada, se ha procedido al análisis de las cabeceras HTTP de cada servidor Web. También se han realizado diversas pruebas manuales sobretodo con NMAP, a modo de comprobación para verificar los datos encontrados de forma automática.
Las principales conclusiones del análisis son las siguientes:
1) Los servidores Web utilizados se reparten tal y como se puede observar en el siguiente gráfico. 64 Servidores (43%), se corresponden con alguna versión de Apache, 41 Servidores (28%) son Internet Information Server versión 6.0 bajo Windows 2003 principalmente. Sólo se han detectado 10 equipos con IIS v7.0 o IIS v7.5 en equipos MS Windows Server 2008 y MS Windows Server 2008 R2, respectivamente. En 25 equipos no fue posible identificar el Servidor Web utilizado o se obtuvieron datos confusos debido, sobre todo, al uso de balanceadores de carga, o por tratarse páginas obsoletas y sin servicio pero aún indexadas en Google.
Fig 1. Listado de los Servidores Web encontrados
2) Sólo 47 de las páginas analizadas utilizan certificados SSL para cifrar la comunicación entre el servidor y el equipo del usuario que visita la página Web.
3) Ninguna de las páginas analizadas utiliza las cabeceras HTTP "X-Content-Type-Options", "X-XSS-Proteccion", "X-Frame-Options", "Access-Control-Allow-Origin", "X-Content-Security-Policy" ni "Strict-Transport-Security".
Las cabeceras X-Content-Type-Options y X-XSS-Proteccion se utilizan principalmente para reducir el riesgo de sufrir algún ataque de Cross Site Scripting (XSS). En Internet Explorer 8 y superiores se puede activar X-XSS-Protection en el servidor Web y se dispone de un filtro anti-cross-site-sctipting. La cabecera X-Content-Security-Policy también se utiliza como defensa contra los ataques de inyección de contenido Web como, por ejemplo, la vulnerabilidad vista de Cross Site Scripting del tipo persistente y del reflejado o no persistente (reflected).
Con la cabecera X-Frame-Options se delimita la posibilidad de cargar páginas dentro de marcos (tags HTML iframe y frame) y así evitar ataques del tipo click-jacking.
Access-Control-Allow-Origin se emplea con navegadores Firefox y Google Chrome para controlar a qué sitios se permite pasar por alto las políticas que controlan el origen del servidor Web y que están autorizados a enviar peticiones del tipo "cross-origin" para impedir que se carguen datos desde otra página diferente a la que se está visitando.
La cabecera Strict-Transport-Security se utiliza para controlar si se permite el acceso al servidor únicamente mediante conexiones seguras desde navegadores Firefox y Google Chrome.
4) En 43 páginas se ha detectado el uso de Cache-Control. Esta cabecera controla la cantidad de páginas que se pueden almacenar en la memoria caché del navegador Web del usuario o en los sistemas de proxy-web que puedan existir en el entorno de navegación de dicho usuario. Configurando la cabecera en el servidor como "no-store, no-cache" se consigue mayor privacidad y mejoras en el rendimiento del equipo del usuario al no tener que guardarse la página visitada.
Es recomendable utilizar Cache-Control sobretodo en páginas con contenido más sensible y confidencial para evitar que sean guardadas en la cache. Es sufciente con añadir la siguiente directiva en la configuración del Servidor Web para indicar a los navegadores que el contenido de la página que se está visitando no debe almacenarse:
Cache-Control: no-cache, no-store
Fig 2. Captura del uso de la Extensión para Google Chrome “Recx Security Analyzer”
Conclusión
Salvo el uso de certificados SSL en sólo un 31% del total de las páginas analizadas, no se están utilizando las últimas técnicas de seguridad que, además, son sencillas de implementar, para mejorar la seguridad de los usuarios y los visitantes de las Webs del Gobierno de España.
Todo esto coincide con la poca importancia que se da a la seguridad en los organismos gubernamentales tal y como se puede comprobar con los ataques que sufrieron las páginas Web de los candidatos y los diferentes partidos políticos a la presidencia en las últimas elecciones estatales o los repetidos ataques que sufren este tipo de páginas según datos de páginas como Zone-h (http://www.zone-h.org/) y similares.
Por cierto, en Hacktimes.com tampoco están activadas la mayoría de las cabeceras HTTP comentadas anteriormente pero el contenido no es ni de lejos tan sensible o confidencial como sucede con las páginas GOB.ES. Tampoco tenemos tantas visitas como puede llegar a tener una página gubernamental (ya nos gustaría) por lo que la repercusión de un posible error provocado por el tipo de vulnerabilidades tratadas en este artículo es mínima.
Comentarios
En primer lugar, agradecerte el comentario no solo por la crítica constructiva sino por como argumentas tus puntos ya que ayuda a mejorar el contenido del blog. Simplemente quería recalcar que el articulo se pensó como un análisis superficial y en ningún momento se pretendió sacar una conclusión firme y de valor que pudieran servir para evaluar de forma objetiva la seguridad de una muestra de las aplicaciones, de naturaleza tan dispar, que se alojan en el TLD gob.es. De todos modos, al realizar cualquier test de seguridad, el hecho de que algunas cabeceras estén implementadas puede dar una idea de si al desarrollar la aplicación se han tenido en cuenta criterios de seguridad. Evidentemente, el hecho de que la aplicación tenga implementados dichos controles tampoco asegura que luego fallen otros por lo como bien dices un análisis exhaustivo debe ser siempre realizado. Entiendo que el contenido no te haya satisfecho ni agradado aunque espero que en general el artículo pueda servir para dar una idea de algunas cabeceras que pueden ayudan a mejorar la seguridad de los usuarios. Saludos.
Alpha: me quito el sombrero ante tu comentario. Me parece de lo más acertado y adecuado y desde hacktimes te lo agradecemos sinceramente. Sin que sirva de disculpa este artículo pretendía dar a conocer la extensión para Google Chrome y sacar algún dato y estadística útil acerca de las páginas GOB.ES. En ningún momento se ha hecho un análisis en profuncidad de la seguridad de dichas páginas (ni se ha pretendido) y sólo se han mirado ciertos datos que se podían obtener con un simple GET. Lamentamos que no te resulte interesante este artículo y te animamos a ver el siguiente y a colaborar con nosotros cuando quieras.
Hola, por lo general sigo con gusto las publicaciones de HackTimes.es, creo que es material de calidad y esa calidad está muy cuidado, pero creo que este artículo es la excepción. Sin saber cuál es el estado de las páginas gubernamentales españolas, creo aún así que una vista previa sobre SOs, SSL y HTTP headers no representa un análisis de seguridad y no son dignos de obtener conclusiones seguras. 1. El uso de SSL es discutible, por supuesto que recomendado, pero inútil cuando no se trata de transmisión de datos sensibles. Muchas páginas suelen tener una sección privada en la cual se aplica este tipo de seguridad, pero en las páginas públicas se permite HTTP sin encriptación. (No sé si este es el caso aquí, pero esta consideración tampoco fue parte del análisis.) 2. El uso de headers no-estándar no son buenas prácticas para recaer en la seguridad, y muchas de esas cabeceras pueden ser reemplazadas por otros mecanismos de seguridad que responden a la misma característica. Consideremos además que el público es no-homogéneo, con lo que no se puede considerar que la mayoría de los usuarios utilice Internet Explorer. (Ni tampoco una versión actualizada.) Independientemente de eso, Strict-Transport-Security se debería utilizar sólo en conexiones HTTPS, lo que nos devuelve al punto 1. 3. Estoy de acuerdo con el análisis del uso del caché, pero no se identificó su relación real con la seguridad. Coincido en que no hay una relación demasiado marcada (excepto que queramos considerar ataques de browser caché poisoning o HTTP hijacking, pero estaríamos estirando el análisis a casos extremos). En fin, creo que para haber sido más útiles, estos análisis deberían indagar un poco más a fondo. Si es que hay cuestiones legales que impiden hacer esto, lo comprendo totalmente, pero debería ser indicado públicamente. Nuevamente, creo que un análisis de seguridad debe ser más profundo de lo que hemos visto aquí para poder sacar conclusiones significativas.
Añadir comentario