Todos podemos programar: Aprende a programar para hackear tu futuro profesional #HackYourCareer

He contado muchas veces la historia, pero mi mundo y mi futuro cambió cuando con 12 años me topé con un cartel en una academia de barrio que se llamaba RUS. El cartel decía eso de "La informática es el futuro", y como cuento siempre, yo me lo creí. Comencé una andadura de switches, contadores y acumuladores aprendiendo a programar con aquellos ordenadores Dragon y Amstrad que tan importantes serían en el devenir de mi futuro profesional y, por ende, personal.

Figura 1: Todos podemos programar: Aprende a programar

para hackear tu futuro profesional #HackYourCareer

Aprender a programar me cambió la vida, y desde los 12 años me apunté a programar en todo lo que pude. Basic, Logo, Pascal, Lenguaje C, C++, Cobol, SQL, PL/SQL, Visual Basic, Visual C, Java, lo que fuera. Me encantaba programar y cuando estuve en la universidad solo quería asignaturas de programación y bases de datos, y no hice las asignaturas de seguridad informática, que eran optativas.

"¿Seguridad Informática? No, gracias, prefiero ir a Geometría Computacional que programan algoritmos gráficos de triangulación, cierres convexos y rectas de barrido y estructuras de datos complejas en memoria y en disco para resolver problemas en tiempo optimo."

Y si hay una recomendación que doy a Mi Hacker y a Mi Survivor, es que aprendan a programar. Es fundamental tener el pensamiento computacional bien desarrollado para poder generar estrategias ejecutables en un sistema informático - algo que incluso se mide en los tests de capacidades que se utilizan en Singularity Hackers para recomendarte los roles en ciberseguridad a los que mejor te adaptas -, y, además, poder extrapolarlas a todo el resto de la vida. A cualquiera que me pregunta sobre cómo entrar a trabajar en una startup, o empezar a trabajar en cualquier disciplina tecnológica, siempre le recomiendo que aprenda a programar. Hasta nuestro Presidente de Telefónica se llevó de regalo mío un Amstrad CPC 6128 y un libro de programación en BASIC para que aprendiera a programar.

Aprende a programar sí o sí

Si quieres entrar a trabajar en el mundo de la tecnología, sea la que sea la disciplina, programar te ayudará a hackear tu carrera profesional. Y tendrás que ser consciente de que te vas a adentrar en un mundo que al principio te puede parecer abstracto hasta que las piezas comienzan a encajar en tu cabeza. Una vez comprendas el proceso y lo interiorices, tu estructura de pensamiento habrá cambiado y también tu percepción sobre esta potente herramienta que permite crear prácticamente todo lo que te propongas. Verás Matrix.

Tu mente entenderá las cosas de una manera computacional que te permitirá aprender el resto de disciplinas de una formar mucho más veloz. Asumirás una nueva forma de trabajar que aplicarás a todos los ámbitos de tu vida. Formar parte del sector tecnológico no es solo una buena opción por la demanda que existe, sino por el impacto positivo que genera en todos los aspectos de tu vida. No sé donde escuché esta frase, pero me encanta: 

“Existen dos tipos de empleo, donde las personas les dicen a los ordenadores qué hacer, y dónde los ordenadores les dicen a las personas qué hacer.” 

Y a mí me gusta ser el que da las ordenes. 

Así que, si quieres que tu vida en el mundo profesional tenga que ver con la tecnología, mi recomendación es que te pongas las pilas en programación. Y después.... ya eliges bien la rama que quieres para tu vida y comienza a especializarte.

Programar va más allá que saber escribir código.

La programación es una herramienta creativa en constante evolución que te proporciona muchos caminos para llegar a un mismo sitio. Al mismo tiempo, se trata de un proceso donde buscar la forma de ser lo más eficiente y claro posible para que puedas compartirlo con otras personas el día de mañana y puedan trabajar con tu código. Y también es un proceso de ingeniera férrea que hay que entrenar, para conseguir que tu código sea de mejor calidad cada vez. Conocer el proceso de desarrollo te permitirá trabajar en equipo con gente del sector de una forma más estrecha, entenderás cómo ayudarles desde la disciplina en la que trabajes.

La programación te ayuda a pensar de una forma lógica, acotar los problemas y resolverlos uno a uno, te enseña a ser, además de creativo, ordenado y metódico. Desarrollar tus primeros algoritmos hará que poco a poco sientas que la programación no es algo inaccesible, verás que todo encaja dando los pasos adecuados para resolver problemas complejos.

Ya sabéis que yo siempre, en las entrevistas de trabajo hago pruebas como la resolver el factorial de 100 solventado las limitaciones de las estructuras de datos, que no tiene nada que ver con picar código, o pedir que me pinten una recta píxel a píxel para ver cómo programa esa persona, cómo piensa, cómo razona en la resolución de problemas.

Por dónde empezar: Python o JavaScript

Programar es para todo el mundo. No solo para los que hemos ido a formación específica de informática. Mi Hacker y Mi Survivor no sé lo que serán de mayores, pero ya están haciendo sus cursos de programación este verano en el colegio. Y si quieres meterte en este mundo de forma profesional, ya puedes empezar a tomártelo en serio y comenzar a programar desde ya. 

Y si quieres una recomendación personal, pues tienes dos lenguajes que son muy fáciles para comenzar a programar cosas, y los dos son muy potentes y te servirán tanto para construir tecnología, como para desarrollar el pensamiento computacional. Y a ambos, además, les vas a poder sacar partido en seguridad informática.

El primero de ellos es Python, que como sabéis es un lenguaje que utilizamos mucho en seguridad informática. Es fácil comenzar con él, y tienes muchas librerías y herramientas creadas que puedes utilizar para acelerar tus proyectos. En GitHub tienes un cantidad ingente de proyectos en Python que puedes observar, y tienes dos libros en 0xWord que te pueden ayudar, como son Python para pentesters y Hacking con Python.

Figura 2: Python para Pentesters & Hacking con Python
de Daniel Echeverry en 0xWord

Mi segunda recomendación, especialmente si quieres aprender técnicas de programación que luego puedas utilizar para ser un Full-Stack Developer, Back-End Developer, o un Front-End Developer o quieres hacer ataques complejos de Ethical Hacking en entornos Web, como los Client-Side Attacks en técnicas como Cross-Site Scripting, ClickJacking, Javascript Botnets, etcétera, te recomiendo que le metas caña a Javascript, que no necesitas mucho para comenzar, y te va a servir para todo en tu vida. Aquí estoy yo contando en DefCON el trabajo de Owning Bad Guys {and Mafia} using Javascript Botnets.


Figura 3: Ownling bad guys {and mafia} using Javascript Botnets

Javascript te permitirá desarrollar tus primeras aplicaciones web de principio a fin, siendo un lenguaje que puedes emplear tanto para la parte visual como en las tripas de tu aplicación, cuenta con una gran comunidad y tiene una curva de aprendizaje amable porque desde el primer Hello World! hasta un sistema completo el camino es directo. Si quieres empezar desde cero, esta es una muy buena opción.

Figura 4: BootCamp Online de Programación desde cero con Javascript

Si quieres tomarte en serio esto de aprender a programar desde cero, lo mejor es que comiences con algún curso que te ponga las pilas. Yo tuve la suerte de tener a mi profesor Teo en la Academia RUS, que estuvo encima de mí al principio, para explicarme las cosas con las que me quedaba bloqueado. Liberó las bloqueos mentales que tenía y me ayudó a que amara programar. Hoy ya no existe esa academia de barrio, pero tenemos cosas mejores, como Coding Schools como GeeksHubs Academy, y una buena recomendación para empezar a tope desde cero con un lenguaje como Javascript es hacerte un Bootcamp de programación desde cero, como el que tienen nuestros compañeros de GeeksHubs Academy que te pone las pilas en 100 horas.

Figura 5: Contenidos del Bootcamp Online de Programación desde cero con Javascript

En un Bootcamp Online de Programación desde cero con JavaScript como éste empezarás por interiorizar conceptos teóricos básicos e imprescindibles para entender el maravilloso mundo de la programación en el que vas a introducirte. Estos bootcamps están geniales, porque mezclan los dos conceptos que son tan necesarios: Aprender haciendo y Aprender Aprendiendo. 

Figura 6: Todos podemos programar.

Para ello, en estos campos de entrenamiento militar - casi - se aplican de forma alterna píldoras teóricas y conceptuales, investigaciones propuestas que tendrás que realizar, ejercicios prácticos guiados y retos personales que tendrás que resolver para asentar tu conocimiento. Por supuesto, en este bootcamp, aprendes por motivos obvios HTML y CSS que te van a poner las pilas y los vas a utilizar siempre.

Si tras tu primer contacto con la programación tu curiosidad ha aumentado, te espera un camino lleno de experiencias en un mundo del que, después de 34 años desde el primer día, no he podido dejar de enamorarme. A pesar de que mi día a día no sea programar, saber programar sigue siendo parte de todos los días hasta en los puestos profesionales que he desempeñado en los últimos años.

¡Saludos Malignos!

Autor: Chema Alonso, Microsoft MVP en Ciberseguridad del año 2004 al año 2017

Contactar con Chema Alonso

Algunos consejos de seguridad para desarrollar un frontend web (Y son muchos los que se necesitan)

El mundo de las aplicaciones web está en constante renovación, se desarrollan nuevos frameworks y herramientas, se implementan nuevos patrones arquitectónicos como los MicroFrontEnds, de los que hemos hablado en un artículo anterior. Además, el usuario está tomando una interacción mayor y más compleja con la parte frontal, esta complejidad puede llegar a suponer una brecha de seguridad si no se tiene el suficiente cuidado al desarrollar los proyectos.

Figura 1: Algunos consejos de seguridad para desarrollar un frontend web
(Y son muchos los que se necesitan)

En este artículo os hablaré de las distintas amenazas que se pueden dar en nuestra estructura frontal y de cómo prevenirlas. Es decir, vamos a ver un resumen de cuáles son las técnicas de Hacking Web Applications desde el punto de vista de los Client-Side Attacks: XSS, CSRF, SSRF, XSPA o SSJS - para lo que os recomiendo que leáis el libro de Enrique Rando - y también contaré algunos consejos para desarrollar FrontEnds de forma segura para evitarlos.

Figura 2: Libro de "Hacking Web Applications: Client-Side Attacks"
de Enrique Rando en la editorial 0xWord.

En primer lugar, para conocer los puntos débiles más comunes que se pueden dar en nuestra aplicación, debemos conocer los tipos de ataques que se realizan sobre estas y como prevenirlos.

Resumen ligero de Client-Side Attacks

- XSS Cross-Site Scripting: Es un vector de ataque dirigido a una aplicación web o página web que puede permitir a un atacante inyectar código sin que este sea validado y así, conseguir acceso a información sensible, secuestro de sesiones de usuario o subyugar la integridad del sistema. Gracias a ataques XSS se pueden hacer ataques de Session Hijacking, ataques de Click-Jacking, Cross-Site Request Forgery, etcétera, todos aprovechándose de la posibilidad de inyectar código que se va a ejecutar en el cliente. Si dejamos de lado los XSS Google-Persistentes, existen tres tipos de XSS.

Figura 3: Conferencia de "Ataques XSS Google Persistentes" por Chema Alonso

- XSS Directo: Es conocido como XSS Persistente, se da en los formularios y se ejecuta cuando un usuario accede a la ruta donde se ha inyectado el código. Estos XSS Persistentes o Stored-XSS son muy peligrosos y aparecen periódicamente en plataformas de eCommerce, CMS, LMS, etcétera, sobre todo en plugins.

Figura 4: Esquema de una ataque XSS Directo

- XSS Indirecto: Es conocido como XXS Reflejado, la inyección de código se da en formularios, URLs o vídeos, entre otros. Su objetivo radica en modificar los valores que la aplicación web utiliza para comunicarse a nivel interno con dos de sus rutas.

Figura 5: Esquema de una ataque XSS Indirecto o XSS Reflejado

 

Evidentemente, para prevenir estos dos tipos de ataques de Cross-Site Scripting, al igual que para prevenir cualquier tipo de ataque de inyección, como son también los ataque de SQL Injection, se debe aplicar un filtro para validar todos los campos que utilicemos como input, ya sean por GET o por POST.  Como dijo Michael Howard en su libro de Writing Secure Code:

"All input is evil until it proves otherwise"

Para evitar estos ataques es importante que tu servidor web también haga uso de los Security Headers para utilizar todas las capacidades de los navegadores de hoy en día en la fortificación contra ataques XSS, para ello hay que configurar:

- X-XSS-Protection

- Content-Type

- X-Content-Type-Options

- X-FrameOptions

- Acces-Control-Allow-Origin

Para verificar las políticas de fortificación de tu web, y cómo están configurados los HTTP Security Headers, puedes usar la web de SecurityHeaders.io que te dará un informe de cómo está de bien configurada tu aplicación web.

- XSS DOM Based: Este tipo de XSS, en vez de darse en la parte HTML se da en el Document Object Model. En los dos tipos anteriores el payload se puede observar en la respuesta de la página o ruta. Sin embargo, en este tipo de XSS el código HTML y la respuesta serán exactamente iguales. El payload solo se podrá observar en tiempo de ejecución o investigando el DOM de la página. 

Figura 6: Esquema de ataque XSS DOM-Based

Para evitar los ataques XSS DOM Based en nuestra aplicación es recomendable utilizar un método de salida adecuado. Es decir, imagina que quieres que el usuario escriba un input en una etiqueta <Div>. En este caso en vez de utilizar innerHTML, utiliza innerText o textContent. De esta forma el usuario puede ejecutar la misma acción, pero evitando una vulnerabilidad XSS DOM Based.

- Ataques DoS/DDoS: Uno de los ataques de XSS, además de los citados en los párrafos anteriores, se basa en la capacidad de forzar al navegador a pedir una determinada URL si somos capaces de inyectar código en la página de respuesta. Esto se puede utilizar para llevar a un cliente con un navegador vulnerable a una web con un Kit de Exploits en un ataque de Watering Hole, o para hacer un ataque de DoS (Denial of Service). 

En este último caso el objetivo es dejar sin recursos el servidor para evitar que los usuarios se conecten a este. Funciona sobrecargando el servidor con un gran número de peticiones en intervalos muy pequeños gracias a que muchos clientes le van a pedir recursos pesados de manera involuntaria desde sitios vulnerables a XSS.

Figura 7: Esquema de ataque DDoS. El atacante inyecta el XSS en el servidor web vulnerable y conecta los visitantes a su XSS-Botnet o JavaScript Botnet para hacer un DDoS. 

Estos ataques, cuando se basan en exploits XSS almacenados en sitios de gran cantidad de usuarios a los que se fuerza a pedir recursos pesados en el servidor de la víctima, da como consecuencia ataques DDoS (Distributed Denial of Service). Para el servidor atacado por las peticiones masivas es un problema, y por eso se utilizan soluciones como Cloudflare, AntiDDOS o captchas para proteger los recursos "pesados" para evitar estos ataques. Cada visitante del sitio con el exploit XSS se convierte en un bot de una XSS-Botnet, que funcionan de forma similar a las Javascript Botnets.

Figura 8: Owning bad guys {and mafia} with Javascript Botnets

- Ataques Cross-Site Request Forgery (CSRF): Este ataque se suele utilizar para realizar estafas. Consiste en intentar engañar a la víctima para envíe una solicitud HTTP maliciosa que el cliente no controla. Esto se puede hacer con un simple ataque de Phishing con un e-mail o haciendo un ataque de XSS. En cualquier caso, cuando esto ocurre, el atacante consigue que la víctima haga algo involuntario a ella en una plataforma a la que el atacante no tiene acceso.  Las posibilidades de estos ataques son muchas. Desde crearse un usuario, hasta borrar un contenido, forzar el cierre de sesión en una red social como Facebook o darse permisos desde la sesión de un administrador, o, como hemos visto muchas veces, conseguir votos involuntarios en concursos vulnerables a CSRF.

Figura 9: Esquema de ataque CSRF

La forma de prevenir un ataque CSRF es que la URL solo pueda ser llamada desde una web previa que tiene unos tokens que le autorizan como punto de llamada válido. Es decir, el servidor web protege la URL2 enviándole a la URL1 un token aleatorio Anti-CSRF. Cuando el usuario hace clic en un enlace de la web en la URL1 para navegar a la URL2 debe enviar los tokens AntiCSRF. La URL2 comprueba que son correctos y permite que se ejecute. Como el atacante no puede saber cuáles son los tokens AntiCSRF que genera el servidor web, entonces no puede hacer "a ciegas" que la víctima haga algo mediante una inyección de un exploit XSS o de un e-mail de phishing. 

Además de todo esto, hay que tener en cuenta que, al forzar una petición HTTP contra un servidor, se podrían enviar cookies asociadas en las peticiones HTTP al nuevo servidor, así que hay que fortificar las cookies para que el acceso solo sea Same-Site:Strict o Same-Site-Lax, como se explica en este artículo.

Algunos consejos para evitar los Client-Side Attacks

Ahora que ya hemos hablado de algunos de los tipos de vulnerabilidades y ataques más comunes, vamos a ver unos consejos importantes para tener en cuenta a la hora de realizar nuestro desarrollo. 

• Desarrollo Seguro: En primer lugar, desarrollar de forma segura siempre debe formar parte del proceso de desarrollo ya que solventar un problema de seguridad cuando una aplicación está desplegada, es mucho más costoso y dañino para el usuario final, que analizar el código y realizar los cambios a priori. Para ello, es mejor trabajar con patrones de diseños conocidos y estudiados que resuelven problemas concretos, en lugar de reinventar la rueda constantemente, y usar soluciones lo más estandarizadas posibles.

 

Figura 10: Desarrollo de WebApps Seguras con Angular y

Desarrollo de WebApps Seguras con Spring Boot

• Despliegue Seguro:No solo hay que hacer que la seguridad esté dentro del ciclo de vida de creación del software, así como en el despliegue de las nuevas releases, así que no solo la seguridad debe estar en el código, sino en los procesos de DevOps, pasando a ser SecDevOps.

Figura 11: Docker "SecDevOps"

• Fortificación: Las reglas de la fortiticación son Mínimo Privilegio Posible, Mínima Superficie de Exposición y Defensa en Profundidad. Si aplicamos la segunda regla al desarrollo de fontends de aplicaciones web, compartimentar una aplicación, puede ser una buena forma de mitigar el impacto de una vulnerabilidad por lo que se de be optar por patrones como los MicroFrontEnds como una alternativa.

• Contenido de Terceros Controlado: En caso de utilizar librerías de terceros, hemos de ser selectivos a la hora de elegir cual implementar ya que esto puede prevenir una o varias brechas de seguridad en nuestra aplicación. Se aconseja buscar librerías respaldadas por la comunidad y en las que se realice un mantenimiento habitual. También, si utilizamos recursos almacenados en servidores CDN, es muy recomendable utilizar el Tag Integrity que nos asegura la no alteración y la integridad del recurso que estamos utilizando. 

Figura 12: Ejemplo de uso de la Tag Integrity

• Librerías vulnerables: Auditar las dependencias de nuestros proyectos es una buena práctica. Con el comando npm audit se mostrará una lista de los paquetes vulnerables que existen en nuestro proyecto y podremos ver cual de estas dependencias requieren una actualización.

• Content Security Policies: Por último y no menos importante, recomendaros encarecidamente el uso de Content Security Policy. Es el nombre de la HTTP Header que utilizan los servidores web para sacar el máximo de partido de las opciones de fortificación que tienen los navegadores para mejorar la seguridad de una aplicación o página web.

Figura 13: CSP en la web de Facebook 

También se puede implementar vía meta tag. Las CSP suelen ser difíciles de configurar para que se ajusten a todos los comportamientos de todas las webapps en todos los navegadores, pero desde luego son la mejor opción para desplegar de forma fortificada una aplicación web, aunque sea en modo Reporting como hizo Google.

Figura 14: Etiqueta CSP como meta HTTP

Conclusiones

Fortificar una WebApp implica fortificar el end-point, así que desde el servidor web debemos utilizar todas las opciones no solo para fortificar nuestro código y las aplicaciones o frameworks server-side que utilicemos para soportar nuestra arquitectura, sino que deberemos también preocuparnos de todas las opciones de fortificación de los navegadores. Estos son solo algunos ejemplos de algunos ataques que se pueden dar client-side, y el número de cosas que hay que mirar en una aplicación web para tener la fortificación mejor posible es muy alta. 

Figura 15: XSS detectado por Faast de ElevenPaths en Apple.com

Como podéis ver, un XSS se le puede escapar hasta a la propia Apple en Apple.com. Por eso, se recomienda tener cualquier WebApp expuesta en Internet, bajo un servicio de Pentesting Persistente, como el que hacemos desde ElevenPaths con el servicio Faast, donde miramos constantemente no solo las vulnerabilidades, sino también las debilidades en la fortificación del servidor y el cliente. Recuerda, si tú no auditas tu web, otro lo hará por ti... gratis.

Autor: Luis E. Álvarez, desarrollador y miembro del equipo Ideas Locas CDCO de Telefónica.

Figura 16: Contactar con Luis Eduardo Álvarez en MyPublicInbox

Nuevo Libro: "Hacking Web Applications: Client-Side Attacks" de @0xWord

Ayer ya se puso a la venta el nuevo libro de 0xWord, titulado "Hacking Web Applications: Client-Side Attacks" y escrito por el gran Enrique Rando, que ya tiene en su haber la participación en los libros de "Hacking con Buscadores", "Hacking Web Applications: SQL Injection" y "Hacking Web Technologies", además de decenas de artículos escritos por aquí.

Figura 1: Nuevo libro de 0xWord "Hacking Web Applications: Client-Side Attacks"

El texto se centra en algo fundamental en los test de intrusión, como son los Client-Side Attacks, y que tantas veces hemos visto como primera fase de un APT de muchos de los grandes incidentes de seguridad que llegan a los medios de comunicación.

Figura 2: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

En palabras del propio autor, el libro tiene la siguiente descripción:

"Usuarios, navegadores y aplicaciones web. Cada cual con sus propios problemas, formando un curioso triángulo. Personas que, como suele decirse, son el eslabón más débil de la ya de por sí frágil cadena de la seguridad. Navegadores cuya complejidad, siempre en aumento, los convierte en poco menos que nuevos sistemas operativos con fallos y características susceptibles de ser usadas con fines ilegítimos. Y programas que, de forma casi inevitable, presentan fallos. 

Por si fuera preciso empeorar las cosas, todo esto ocurre no en el Centro de Proceso de Datos, donde todo es más fácil de gestionar, sino en los puestos de usuario. Lejos del confortable control del personal informático, quizá a cientos de kilómetros gracias a la conectividad que Internet proporciona. Lejos del servidor de aplicaciones, sí, pero interactuando con la parte cliente de éstas. Lejos del servidor de bases de datos, pero cerca, muy cerca, de los datos y de la gestión que de ellos se realiza. 

Este escenario presenta sus propias vulnerabilidades y sus ataques característicos. Quizá los más conocidos sean los de Cross Site Scripting, sobre los que tanto se ha hablado y cuyas repercusiones no siempre se ha sabido explicar. Pero hay otros, menos populares pero igual de devastadores, como Cross Site Request Forgery o Clickjacking. O técnicas como las de Typosquatting, abuso de nombres de dominio internacionalizados o Tabnabbing. O manipulaciones de la interfaz de usuario de los navegadores y de las características, cada vez más avanzadas, que éstos ofrecen gracias a las APIs asociadas a HTML 5. O prácticas habituales en el desarrollo de aplicaciones web que pueden tener consecuencias inesperadas. 

Este libro trata de esos “enemigos olvidados”, presentándolos a través una serie de pruebas de concepto que ponen en evidencia no sólo lo fácil que puede llegar a ser explotarlos sino también cuán graves que pueden ser sus efectos."

Pero para que veas los detalles completos, tienes el índice del libro subido a SlideShare.

Figura 3: Índice el Libro "Hacking Web Applications: Client-Side Attacks"

Éste es el libro número 50 de 0xWord, un hito para nosotros, así que probablemente hagamos algún acto en Madrid (o en Móstoles) para celebrarlo, en el que podáis estar con muchos de los escritores para compartir experiencias y charlas.

Saludos Malignos!

Security Headers & SRI Test: Para los bookmarks

Cuando estas revisando la seguridad de la infraestructura expuesta en Internet de una organización, como hacemos nosotros con Faast, se deben revisar todos los detalles. Fugas de información, configuraciones inseguras, vulnerabilidades o cualquier otra debilidad que pueda ser utilizada por un atacante para afectar la seguridad de la organización, ya sea de forma directa o encadenando varios fallos. Como sabéis, miramos cosas como los leaks de información por culpa de los metadatos, los fallos OWASP, la calidad de los certificados digitales, las versiones de software, etc...

Figura 1: Security Headers & SRI Test. Para los favoritos

Para hacer tests puntuales de seguridad en la web, existen muchas utilidades que puntualmente puedes utilizar para ello. Desde revisar los archivos que tiene una web enviándolos a Virus Total, revisar la configuración de los certificados digitales con SSL Server Test de Qualys o usar nuestro MetaShield Analyzer para revisar los metadatos de los documentos públicos de una web. Son útiles para pruebas puntuales porque se ofrecen desde la nube y te permiten ver rápidamente la información relevante de un determinado aspecto.

Security Headers para comprobar tus HTTP Headers

Hoy os traigo un par de webs que sirven para revisar algo de forma rápida. La primera de ellas es Security Headers, que revisa algo que es muy útil en la configuración de un sitio web que quiere ser robusto frente a todo tipo de ataques. Son los HTTP Headers que un servidor envía a un navegador para fortificar la plataforma. 

Figura 2: Revisión de Security HTTP Headers en Google.com

Basta con poner el nombre del sitio y obtener información de cómo están configurados los HTTP Headers relativos a la seguridad del sitio. Algunos de los más importantes ya los hemos tratado en multitud de artículos, por lo que os dejo algunas referencias:

- Server: Este header puede ser muy "verbose" y llegar a dar la información de la versión exacta del servidor, así que su revisión es más para evitar fugas de información que para configurar algo robusto en el cliente. 

- X-Powered-By: Normalmente este campo también puede ser una fuente de información de leaks que informe al visitante del framework con que se construye una web.  

- X-Frame-Options: Este header es para fortificar el navegador frente a ataques de ClickJacking. 

- X-XSS-Protection: Esta cabecera sirve para que el servidor fuerce el uso del filtro AntiXSS en el navegador. También, por supuesto, para deshabilitarlo. 

- X-Content-Type-Options: Los navegadores, sobre todo al principio, intentaban averiguar el tipo del documento que estaban cargando independientemente de su extensión. Esto era un problema con sistemas de correo electrónico donde archivos HTML enviados como TXT se acababan ejecuntando en el navegador. Con este header el servidor le puede decir al navegador que no intente averiguar el MIME Type del documento. 

- Strict-Transport-Policy: Es la cabecera que se utiliza para configurar las funcionalidades de Certificate Pinning disponibles en el protocolo HSTS. 

- Access-Control-Allow-Origin: Es el header que configurar la política CORS (Cross-Origin Resource Sharing) que indica de qué puntos se puede cargar o no cierto contenido. 

- CSP (Content Security Policies): Son los headers que se usan para configurar de forma completa cómo debe ser la ejecución de los contenidos de una web. Desde carga de contenido script, plugins o servidores a utilizar.

SRI Test para comprobar SubResource Integrity

La segunda de las webs que os dejo, de diseño similar, se encarga de revisar la política SRI (SubResource Integrity) de la que os hablé hace no mucho. En esta web - SRI Test - se comprueba si hay algún archivo de un servidor tercero que tenga o no configurada los hashes de integridad para evitar cargar contenido manipulado por un atacante.

Figura 3: SRI Test en Apple.com. Ninguna protección SRI pero ninguna
carga de contenido de fuera del dominio apple.com

Al final, son dos pequeñas utilidades que te pueden ayudar a revisar la configuración de tus sitios web expuestos a Internet y recibir algunas recomendaciones de fortificación que son útiles y que si no las conoces te pueden ayudar.

Saludos Malignos!

El IronFrame para luchar contra ataques de ClickJacking

En una entrevista concedida antes de DefCon, el hacker Dan Kaminisky ha dejado entrever una idea para luchar contra los ataques de ClickJacking que me ha gustado. Aunque no he visto los detalles de la misma, la poca información que hay sobre el IronFrame, que así se llama la medida de protección, me ha parecido digna de investigar y ha hecho que mi mente juegue un poco con los detalles. 

Figura 1: El IronFrame para luchar contra los ataques de ClickJacking

Los ataques de ClickJacking se basan en conseguir superponer un iframe transparente sobre la página que está viendo la víctima. En ese iframe transparente se coloca la web con la que se quiere que la víctima interactúe para así conseguir mediante engaños que la víctima configure cosas inseguras en su equipo sin darse cuenta.

Figura 2: Ejemplo en Hacker9 de ataque de ClickJacking para robar cuentas bancarias

Para conseguir que el usuario haga clic en las zonas de la capa transparente, el atacante utiliza trucos de ingeniería social que engañan a la víctima. En este vídeo se puede ver cómo un atacante podría utilizar una ataque de ClickJacking para cargar la página de configuración de Adobe y activar la webcam a la víctima con solo robar unos clics.

Figura 3: Ataque de ClickJacking para activar la webcam de la víctima

Si un atacante consigue inyectar un código en el cliente y poner un iframe, se podrían hacer infinidad de cosas. Una de las que más me gustó - abusando de nuevo de la gran potencia que tiene HTML 5 - fue la de aprovechar las funciones de Speech to Text para grabar lo que una persona diga en frente del navegador. En este artículo os conté cómo se podría hacer que una web te escuche y grabe lo que digas.

Figura 4: Cómo conseguir que una web te oiga inyectando un iframe malicioso

Al final, todos los ataques de ClickJacking se basan en poder superponer una capa sobre lo que está viendo el usuario, para conseguir el robo de los comandos que emite la víctima, que podrán ser clics, acciones de drag&drop, introducciones de teclado y hasta comandos de voz.

Protecciones contra ataques de ClickJacking

Para evitar que esta inyección se produzca, debe fortificarse al máximo la conexión entre el cliente y el servidor, para lo que se toman distintas medidas paliativas de fortificación desde el servidor, y en en los navegadores que puedan ser atacados. Las principales son:

- Evitar la inyección de código en ataques man in the middle: Si alguien es capaz de manipular la página en tránsito, entonces podría inyectar código directamente por la red. El uso de conexiones HTTPs y el forzado de estas conexiones HTTPs con el protocolo HSTS (HTTP Strict Transport Security) ayuda a mitigar estas posibilidades.

- Evitar la inyección de código en el cliente: El gran esfuerzo se pone siempre en evitar que se pueda hacer una inyección de código en el lado del cliente por medio de un ataque de XSS o HTML Injection. Para ello, se toman las siguientes protecciones:

- Filtros Anti-XSS: Los navegadores se fortifican con filtros Anti-XSS que los investigadores de seguridad constantemente tratan de saltarse. Debido la complejidad de las tecnologías web, conseguir que un filtro Anti-XSS sea perfecto es casi imposible, por lo que de cuando en cuando van apareciendo bugs para saltarse el filtro Anti-XSS en todos los navegadores. Algunos ejemplos tenéis en estos artículos:

- El 0day del filtro Anti-XSS de Google Chrome que duró 24 horas
- Saltarse el filtro Anti-XSS de Google Chrome 11
- Unos trucos para saltarse el filtro Anti-XSS de Google Chrome y Apple Safari

- Forzado de filtros Anti-XSS con HTTP Headers: Estos filtros pueden ser anulados desde el cliente. Es decir, el usuario podría configurar su navegador para quitar esta protección, pero aún así pueden ser forzados desde el servidor web por medio de los HTTP headers de servidor X-XSS-Protection. Aunque el cliente lo hubiera deshabilitado, el servidor lo puede volver a habilitar.

Figura 5: Servidores de Google activando el filtro con X-XSS-Protection: 1

- Content-Security Policies: La última de las medidas que un servidor web puede aplicar para evitar la inyección de código en su web es el uso de las CSP. Con la configuración de una CSP, el administrador de un sitio podría anular la ejecución de código JavaScript en toda una parte de la web, lo que evitaría que se ejecutara cualquier código inyectado vía un bug de XSS en esa web.

Figura 6: Configuración CSP en la web de Facebook

- Evitar la inclusión de un web en un iframe: La última de las protecciones que se aplican generalmente es la de evitar que una web pueda ser incluida dentro de un iframe. Al final, cuando el atacante quiere hacer un esquema de ClickJacking, inyecta un iframe en una web vulnerable y en ese iframe incluye la web de la que quiere robar los clics a la víctima. Por ello, para evitar que roben los clics de tu web, se introducen protecciones por medio de HTTP Headers X-Frame-Options, además de comprobaciones en JavaScript para ver si una web está en la ventana principal o no del navegador.

Todas estas medidas, cuando se hace una auditoría de seguridad a una web, se revisan una a una. Nosotros en nuestro servicio de pentesting persistente Faast miramos a ver si están todos los HTTP Headers en su sitio y la robustez de la conexión HTTPs, pero aún así, no hay garantía de que no se pueda llegar a encontrar un resquicio para un ataque de ClickJacking

La propuesta del IronFrame para luchar contra el ClickJacking

Vaya por delante que de la propuesta de Dan Kaminisky conozco lo que he leído, entre otros sitios en Dark Reading, pero me gusta desde el principio. La idea se basa en que los navegadores tengan un IronFrame que siempre sea la capa más cercana al usuario, es decir, que sobre ese IronFrame no pueda situarse ningún iframe. De esta forma, la aplicación web se aseguraría que ninguna capa pudiera superponerse y engañar la visión que tiene el usuario de la web.

Figura 7: Entrevista a Dan Kaminisky sobre el IronFrame

Quedan muchas cosas por definir sobre cómo gestionar ese IronFrame, pero de base es un buen punto de partida. Añadir la política de gestión de ese IronFrame desde las Content-Security Policies, usar HTTP Headers para manejarlo que solo puedan incluirse en conexiones HTTPs para evitar que nadie pueda incluir un IronFrame malicioso vía bugs de XSS o HTML Injection, o mediante ataques de man in the middle, usar HSTS para evitar que alguien, con esquemas similares al de Evil Foca pueda hacer ataques de Bridging HTTPs(IPv4)-HTTP(IPv6) o directamente SSLStrip, son detalles que quedarían por limar y ver cómo se podrían definir en un estándar, pero a mí el concepto me gusta.

Figura 8: Ningún iFrame podría estar por encima del IronFrame

Además, se podrían añadir opciones para que desde el lado del servidor se pudiera acceder a imágenes rasterizadas de qué es lo que se está pintando en el IronFrame, lo que daría grandes posibilidades de testing e incluso de detectar ataques man in the browser - que o de mitigarlos, ya que si hay un troyano en cliente estaríamos hablando de otros ataques y no de ClickJacking -. ¿Qué os parece a vosotros la idea de construir este IronFrame en los navegadores?

Saludos Malignos!

Google Chrome: Bug para esconder el Path en una URL

Supongamos que en una página web existe una vulnerabilidad de HTML Injection o de XSS que permite a un atacante manipular el contenido que ve un usuario a la hora de pulsar un enlace malicioso. Supongamos que el atacante, con ese HTML Injection, o ese bug de XSS quiere hacer un ataque de Phishing para robar las credenciasles, de ClickJacking para robar acciones, o conseguir ejecutar un ataque que lance un SQL Injection a un servidor de la Intranet desde un enlace malicioso en una web.  En esos entornos, ver toda la URL a la que nos estamos conectando puede ayudar a tener la máxima información posible para saber si algo ha pasado.

Bugs de Address Bar Spoofing

Así, los investigadores de seguridad catalogan como bugs todos los ataques que permiten ocultar, cambiar o engañar al usuario jugando con la barra de direcciones. En el caso de los dispositivos móviles, se han visto muchos bugs de Address Bar Spoofing que han sido corregidos en el pasado, pero a día de hoy ya no parece tan importante.

De hecho, en los navegadores se empieza a eliminar incluso el Path de la URL, dejando sólo como información útil el nombre de dominio. Se supone que si alguien es capaz de inyectar código HTML o un XSS en la URL, el problema no es que se juegue con el Path, sino que existe un bug de HTML Injection o XSS en la web. En el caso de Google Chrome es posible manipular desde un enlace el Path que se muestra en la barra de direcciones. Para tratar de comprender esta característica, debemos tener claro las partes que componen una URL:

Figura 1: Estructura de una URL 

Normalmente cuando los que estamos en el campo de la seguridad informatica nos encontramos con un enlace que explota una vulnerabilidad de XSS reflejada que está siendo explotada, podemos reconocerla fácilmente mirando el Pathname de la URL o viendo que en la URL hay código HTML/Javascript/CSS/* inyectado. La mayoría de las personas, por el contrario, ignoran lo que hay en el Path de la URL y simplemente les basta con saber que el sitio en el que están navegando es legitimo, fijándose en el dominio del sitio web pudiendo ser engañadas más fácilmente.

Figura 2: Código inyectado en una URL

Si un sitio tiene una vulnerabilidad de HTML Injection o XSS y si se puede de alguna manera ocultar el Path de la URL a todos, - con o sin conocimientos en seguridad - tal vez nos pase desapercibido que el sitio en el que estamos conectados tiene código inyectado por un tercero. Si así fuere, en la barra de navegación del navegador solo veríamos el dominio del sitio sin más, o bien el dominio del sitio con un Path cambiado por el atacante.

Ocultar el Path de una URL en Google Chrome con XSS [Conocido]

Ocultar el Path de una URL es posible en Google Chrome si somos capaces de inyectar un código script en la página vulnerable. Así, inicialmente se vería la URL con todo el Path, pero luego, tras la ejecución del código script inyectado se podría cambiar. Para ello es necesario inyectar un código script como el siguiente que "abuse" de las funciones de HTML5.

<script>window.history.pushState("change", "title", "/nuevo-path");</script>

Figura 3: Ejemplo de cambio de Path por medio de inyección XSS

Ahora bien, esto no es nada nuevo y está contemplado ya que al instalar el navegador,viene por defecto activado el Google Chrome XSS Auditor, por lo que para poder inyectar un script en la URL hay que tenerlo desactivado, o bien lograr saltarse el filtro de seguridad con algunos de los casos que van saliendo y que el equipo de seguridad corrige, como hemos visto en el pasado. Aquí hay algunos ejemplos:

- El 0day del Anti XSS de Google Chrome que duró 24 horas
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11

Hacer un bypass y conseguir ejecutar un XSS, por consiguiente, implicaría tener un bug XSS en la web objetivo y un bug en Google Chrome XSS Auditor.

Figura 4: Ocultando la URL en la barra de estado

Junto a este efecto, un atacante podría valerse del viejo truco de cambiar el href de un hipervínculo cuando pasa el ratón por encima para engañar a la barra de estado cuando alguien lo quiere comprobar.

<a target="_blank" onmouseup="this.href='http://www.sitioalqueseredireccionara.com' "href="http://www.facebook.com">http://www.facebook.com</a>

Un ejemplo el truco del hipervínculo que cierra todas las sesiones en Facebook, podemos hacer que cualquiera que ingrese a un cierto enlace http://www.facebook.com/ se le cierre la sesión en Facebook, y ¿quién podría sospechar?.

Ocultar el Path de una URL en Google Chrome un URL overflow [new]

Pero, ¿y si de alguna manera pudieramos ocultar el Path teniendo activado Google Chrome XSS Auditor sin saltarnos ningún filtro? Resulta ser que - teniendo activado el Auditor XSS de Google Chrome - he encontrado la manera en la cual puedo ocultar el Path de cualquier URL, con o sin vector XSS, con o sin parámetros en la URL. Esto es aplicable a cualquier URL. Aquí tendríamos un hipervínculo que ocultaría el Path al explotar el enlace

Figura 5: Explotación del "bug" con un enlace con XSS en la web de autodesk. Código en Pastebin.

El bug - o "feature" según el equipo de seguridad de Google ya que no lo consideran un bug - es que si hacemos que la cantidad de caracteres de la URL sea mayor a 32.760 caracteres, por alguna razón, el navegador limpia de la barra de direcciones todo el Pathname de la URL, y deja únicamente el dominio del sitio, algo bastante curioso. En este ejemplo, con el truco de cerrar las sesiones de Facebook.

Figura 6: El ejemplo del truco de Facebook sería así. Código en Pastebin.

Por lo que si alguien se estuviese aprovechando de un XSS, HTML Injection o hiciese un ataque CSRF con un SQL Injection, o similar, bastaría con agregarle ese trozo de código para ocultar el vector. Como se puede ver, usando comentarios o el carácter sharp es posible añadir tantos caracteres como sea necesario sin que deje de funcionar el hipervínculo.

Ideas finales

Básicamente este fallo abre una gran puerta a los ciberdelincuentes para hacer más efectivos sus ataques y así engañar mucho más fácilmente a los usuarios. A continuación les muestro en un vídeo este “bug” o al menos a mi me parece así, ya que los de Google no piensan de la misma manera, tal vez sea un nuevo “feature” para ellos.

Figura 7: Vídeo con la PoC de este ataque

Realmente es peligroso para cualquier tipo de usuario porque en general, la mayoria de las personas confían en la barra del navegador y la barra de estado para comprobar la veracidad de un sitio, y si el sitio es un sitio confiable, ¿Qué podemos sospechar? En Chrome Canary este bug se vuelve tal vez más peligroso, si el usuario tiene activada la bandera: chrome://flags/#origin-chip-in-omnibox

Este bug fue reportado a Google, pero sin embargo no lo consideran como un fallo de seguridad, y sí una feature, como en el caso de saltarse el filtro de contenido JavaScript con un iframe. ¿Tú qué piensas?


Autor: Ariel Ignacio La Cono
e-mail: msignataur@hotmail.com
Twitter: @IgnacioLaCono