Búsquedas avanzadas en Google y Google Dorks

Hoy voy a describiros algún fundamento básico de búsqueda avanzada en Google mediante filtros básicos y avanzados, terminando en los llamados Google Dorks.

Google se ha convertido actualmente en una de las multinacionales que más tráfico generan dentro de la red, ofreciendo una cantidad desorbitada de servicios, recientemente realizando intentos de centralizar todos ellos mediante herramientas como las cuentas de Google o Google+. Sin embargo, todos podemos identificar Google con su uso más "clásico": un motor de búsqueda.

Pese a ser el más utilizado, el motor tiene una serie de herramientas y filtros que no suelen utilizarse pese a ser bastante sencillos de utilizar. Intentaré hacer un breve recorrido por ellos a modo de introducción. Intentad practicar un poco y quedaos con un par de ellos, ya que realmente agilizan mucho la búsqueda de información.

Podemos empezar por un par de operadores básicos para hacer las búsquedas más concretas:

• Comillas (""): Sirven para buscar exactamente las palabras que se indican dentro, en ese mismo orden tal cual. Es decir, la frase exacta. Por ejemplo, buscar páginas que contengan exactamente la frase "Hola mundo" (¡Entre comillas de verdad!).

Búsqueda literal de una frase en Google usando comillas

• Símbolo menos (-): Se utiliza para excluir una palabra de una búsqueda. Por ejemplo, buscar páginas que NO contengan la palabra "hola". 
• Asterisco (*): Se puede utilizar como palabra comodín, en caso de que no se conozca o no se recuerde una palabra dentro de una frase. Por ejemplo, "Más vale * en mano" debería arrojar resultados donde * es "pájaro". 
• Símbolos monetarios ($, €...): Se utilizan para indicar búsquedas de cantidades de dinero. Tiene mucha utilidad junto al siguiente. 
• Dos puntos seguidos (..): Utilizados para separar cifras, sirve para indicar un rango numérico. Por ejemplo, la búsqueda "toshiba laptop $300..400" debería darnos como resultado portátiles marca Toshiba de entre 300 y 400 dólares.
• OR: El uso de esta palabra clave indica que buscamos páginas que puedan contener una u otra palabra que indicamos. Por ejemplo, "maratón OR triatlón" buscará páginas que contentan una o las dos palabras. 

Esos son los filtros más sencillos de utilizar. Acercándonos un poco más a los filtros avanzados tenemos una nueva sintaxis; se debe indicar el nombre del filtro (por ejemplo, intitle) seguido de dos puntos y las palabras a filtrar, separadas por una coma si pueden ser varias. ¡Cuidado con los espacios, ya que "rompen" el filtro!

Estos son algunos de los operadores avanzados para Google Dorks más interesantes:

• intitle: Busca palabras en el título de la página. Por ejemplo, "intitle:google,plus" arrojaría páginas cuyo título contenga las palabras "google" o "plus". 
• related: Busca páginas relacionadas con aquella que se le proporciona. Por ejemplo, "related:google.com" buscaría páginas relacionadas con el motor de búsqueda. 

Búsqueda de páginas relacionadas con google.com... ¡Otros motores de búsqueda!

• info: Información acerca de la página indicada, como páginas que la enlazan, páginas similares o versiones almacenadas de la página (caché). Por ejemplo, "info:thesecuritysentinel.es" arroja información acerca de dicha página. 

Búsqueda de información de una página

• cache: Muestra la página tal y como la observó Google la última vez que la visitó. Tiene una gran utilidad cuando se necesita consultar una página pero no está disponible en ese momento. Por ejemplo, podríamos acceder a una versión en caché de esta página mediante "cache:hazardproject.blogspot.com". 

Moviéndonos a un uso un poco más avanzado, los Google Dorks, también llamados Google Hacking, son una serie de parámetros de búsqueda que podemos introducir de forma manual en la clásica página de búsqueda de Google. De esta forma, podemos filtrar muchísimo nuestra búsqueda. ¿Qué clase de filtros podremos introducir? Más abajo describiré unos cuantos, pero como introducción, podremos buscar palabras en el título de la página, tipos de fichero, excluir palabras...

La utilidad de los Google Dorks dentro del proceso de pentesting está sobre todo dentro de la fase de recolección de información del objetivo; cuentas de correo electrónico, datos personales de un empleado, posibles fallos de seguridad en una página... El abanico de posibilidades es muy amplio.

La fase de recolección de información es aquella en la que intentamos descubrir la mayor cantidad posible de información acerca del objetivo del ataque, ya sea una empresa, un empleado en concreto, un usuario en una web, un servidor de correo... Toda información es buena y útil, pudiendo darnos datos que faciliten otro tipo de ataques, como la suplantación de identidad o la fuerza bruta.

La información que nos brinda Google es toda aquella que aparece de forma pública relacionada con nuestra búsqueda, que ha sido indexada por dicho buscador. Aquí es donde radica la importancia de proteger y ocultar la información por parte de los propietarios de dichas páginas. Si no, podemos encontrarnos con dorks bastante simples que nos arrojan un gran número de ficheros de texto que contienen usuarios y contraseñas.

Veamos algunos de estos filtros más avanzados, sin entrar de momento en mayores detalles:

• inurl: Sirve para realizar búsquedas cuyos resultados tengan ciertas palabras en su URL. Por ejemplo, "inur:security,sentinel" podría dar como resultado páginas de dicha empresa. 
• filetype: Busca tipos de fichero en concreto, como puede ser un documento PDF, documentos de Microsoft Word, ficheros de texto plano... En la recolección de información cobra gran importancia junto al siguiente. 
• site: Busca resultados dentro de una sitio web en concreto. Por ejemplo, el dork "filetype:doc OR filetype:pdf site:uva.es" arroja resultados que contengan ficheros .pdf o .doc dentro de la página de la Universidad de Valladolid. 

Búsqueda de ficheros en una página mediante un dork

• link: Busca páginas que contengan links a la página indicada. Por ejemplo, "link:uva.es" busca páginas que enlacen a la Universidad de Valladolid. 

Terminaremos aquí, de momento, el recorrido de las búsquedas avanzadas y los dorks. Es un tema muy amplio y aún me he dejado en el tintero bastantes palabras claves y filtros que dejaré para una entrada algo más avanzada junto a ejemplos de recolección de información. 

Un saludo hackers!

hartek

Gestor Unificado de Amenazas (UTM)

 Existen actualmente en el mercado varias opciones a la hora de realizar la monitorización control de acceso a nuestras diferentes subredes, tanto a nivel particular como empresarial. La opción más escogida por las empresas y la industria en general pasa por colocar un Firewall o un UTM (Unified Threat Manager) entre Internet (parte WAN) y la red local (parte LAN). La diferencia conceptual entre estas dos opciones reside en que el Firewall suele estar orientado al control de acceso y el bloqueo de conexiones entrantes y salientes no deseadas; el UTM contiene muchas más opciones de seguridad, como por ejemplo la detección de intrusiones, la instalación de un proxy web o el control avanzado de acceso entre diferentes interfaces de red conectadas.


Entre los UTM más utilizados actualmente se encuentra IPCop, una distribución Linux que implementa tanto un Firewall como otras muchas funcionalidades de seguridad y gestión centralizada de redes. Puede instalarse en cualquier dispositivo compatible con arquitectura Intel de 32 bits, y cuenta con un gran número de extensiones o addons para ampliar sus funciones.

Además de contar con una interfaz directa mediante consola, cuenta también con una interfaz web desde la que podremos realizar cualquier configuración necesaria, además de actualizar el sistema e instalar extensiones.

IPCop de forma predeterminada divide la red en varias “zonas”, diferenciadas por un código claro de colores. Cada una de estas zonas tendrá unas políticas de seguridad especiales, que pueden sobreescribirse posteriormente con reglas explícitas más personalizadas.

• La zona verde es nuestra zona LAN local. IPCop confía plenamente en esta zona, permitiendo las conexiones desde ella a cualquier otra zona de red sin restricciones.
• La zona roja es la zona WAN, normalmente Internet. IPCop desconfía completamente de esta zona, y no permite ninguna conexión desde la zona roja a cualquiera de las otras zonas, si no es por medio de NAT o una VPN.
• La zona azul es nuestra zona WiFi, la que realmente interesa en el caso que nos ocupa. Esta zona, opcional, permite la gestión de una red inalámbrica. De forma predeterminada no se permite el acceso a ninguna de las otras zonas, a no ser que se configuren reglas de tráfico interno en el Firewall permitiendo esto. Además proporciona filtrado por MAC y dirección IP.
• La zona naranja es la zona desmilitarizada o DMZ de nuestra red. IPCop permite establecer conexiones desde aquí solamente hacia la zona roja, la cual tendrá que conectarse a la naranja mediante NAT. El objetivo de esta zona es colocar los servidores y otros dispositivos que tengan que ser accedidos tanto desde el exterior como desde el interior.

Podemos observar aquí una tabla resumen de estas reglas predeterminadas:

Resumen de las reglas d IPCop

 Como ya hemos dicho, IPCop dispone de una interfaz web desde la que podremos manejar toda la configuración una vez hayamos instalado el sistema de forma correcta mediante consola. En el proceso de instalación es cuando se pedirá la configuración inicial de la red, seleccionando las zonas que será necesario gestionar y su tipo, además de otros detalles como el direccionamiento IP y algunos servicios predeterminados.

Como ejemplo a la hora de securizar un segmento de red, podemos configurar la zona azul o zona Wifi. En el apartado del Firewall, podemos agregar cualquier tipo de regla que permita la entrada/salida de conexiones entre la zona azul y cualquier otra zona. Recordemos que las reglas predeterminadas pueden, de esta manera, sobreescribirse. Sin embargo, no es habitual que un servidor u otro host al que haya que conectarse esté dentro de esta zona, y hay que tener en cuenta que podría haber intrusos en ella; ninguna red es segura. Por tanto habrá que tratar estas reglas con sumo cuidado.

Configurando una regla de Firewall

Además del origen y destino, podemos especificar el protocolo de red o el puerto que queramos gestionar, permitiendo o denegando la ejecución de ciertas aplicaciones.

Otro servicio muy útil es el control de acceso a páginas web mediante el uso de un proxy web y filtros de URLs. Ésto permite denegar o permitir ciertas páginas, siguiendo políticas de lista blanca o negra.

Activando el servicio de proxy web

Y por supuesto, un UTM no estaría completo sin un sistema de logs que controle todos los eventos posibles en las interfaces de red. IPCop dispone de forma predeterminada de un log de sistema y de un log de Firewall; éste último es el que registrará todos los eventos en cuanto a intentos de conexión a cualquiera de las interfaces, entre ellas la de zona azul.

Vista de los logs del UTM

Concluimos diciendo que éste es solamente un ejemplo de las opciones empresariales que podemos incorporar a una compañía en materia de control de acceso y monitorización de una red inalámbrica. De hecho, si solamente quiere monitorizar dicha interfaz inalámbrica, tal vez un UTM completo sea excesivo, y queramos instalar una solución más limitada y enfocada al control mediante Firewall. Muchas empresas,de todos modos, y sobre todo pequeñas y medianas, apuestan por este tipo de soluciones para mantener centralizada la gestión de amenazas.

Espero que la entrada os guste y os haya servido para aprender algo. Un saludo!!
hartek

Referencias:
http://www.ipcop.org/docs.php
http://www.ipcop.org/1.4.0/en/admin/html/section-firewall.html
http://www.ipcop.org/2.0.0/es/admin/html/firewall-blue-access.html

PoC: Inyección SQL simple (I)

La inyección SQL se mantiene como Top 1 en el Top 10 de OWASP de los riesgos de seguridad más explotados en el año 2013. Actualmente, la cifra no debería ser muy diferente.

Aunque la mayoría de los frameworks utilizados para el desarrollo web incorporan ya herramientas para evitar este tipo de filtraciones mediante el uso de funciones propias para el tratamiento de los formularios y las solicitudes, podemos aún encontrar una gran cantidad de páginas web vulnerables a este tipo de explotación. La inyección SQL no pasa de moda.

La razón de que este riesgo de seguridad esté tan extendido es, en primer lugar, la relativa facilidad con la que puede explotarse una vulnerabilidad de este tipo. Mediante unos conocimientos mínimos de SQL y algunos lenguajes de programación web puede deducirse a priori algunas características de la aplicación víctima que nos puede llevar a la explotación tras nos pocos intentos; sin hablar de herramientas automatizadas que realizan el trabajo de forma fácil y rápida.

En primer lugar, os recomiendo explorar un poco los fundamentos importantes de las bases de datos relacionales y el lenguaje SQL, utilizado para realizar consultas sobre ellas. A grandes rasgos, es un tipo de base de datos que almacena y organiza la información en entradas sobre diversas tablas, sobre las que se pueden realizar posteriormente consultas que permiten añadir, recuperar o modificar información sobre estas tablas. Estas consultas se realizan mediante lenguaje SQL.

Por la facilidad en el manejo y la velocidad que ofrecen estas bases de datos, son el recurso más utilizado para almacenar la información de aplicaciones y servicios web. Entre ellas, las más utilizadas son Oracle, MySQL y Microsoft SQL Server.

En esta pequeña prueba de concepto pretendo mostrar el fundamento básico de una vulnerabilidad web explotable de forma sencilla mediante inyección SQL. Para ello será necesario tener instalado tanto un servidor web y un sistema gestor de base de datos, que alojarán la aplicación vulnerable. Como consejo, una máquina virtual Linux con Apache2 y MySQL no tarda mucho tiempo en configurarse para estar operativa.

Por cierto, incluiré enlaces a GitHub para cada fragmento de código para que podáis verlo y copiarlo de manera más sencilla.

El primer paso será crear el formulario vulnerable. Es tan simple como crear un formulario HTML con campos para el usuario y la contraseña. Lo mantendremos simple y sin adornos para la prueba.

No se puede crear más simple

Asimismo, necesitamos un fichero PHP que recibirá los datos del formulario, conectará con la base de datos y ejecutará la consulta que nos permitirá identificarnos como un usuario del sistema. Atención a esta parte del código, que realiza la consulta a la base de datos:

Consulta a la base de datos

En la consulta, guardada en la variable llamada $sql, indicamos que queremos que se nos devuelvan todos los datos (a modo de ejemplo) de aquel usuario identificado con las credenciales recogidas por el formulario anterior, que están almacenados en la tabla login_table. Por último, se mostrará un mensaje de bienvenida para el usuario cuyos datos hemos recuperado, como puede verse en el código más adelante.

Aunque no es un login como tal, dado que no creamos o mantenemos una sesión, sirve para ejemplificar un tratamiento de formularios y una consulta en la base de datos para realizar la autenticación.

Supongamos que los usuarios almacenados son solamente dos: admin, que puede ser fácilmente el mismo administrador de la aplicación y cuya contraseña a modo de ejemplo será adminPass, y pepe, un usuario cualquiera, cuya contraseña será userPass (¡malas elecciones en el mundo real!). Podemos identificarnos correctamente como cualquiera de los dos usuarios.

Ahora empecemos con las pruebas de verdad. Una de las formas de inyección más extendidas es introducir una condición no prevista en la consulta SQL. ¿Cómo podemos hacerlo? Mediante la manipulación de la entrada que introducimos en el formulario.

De forma "normal", la query o consulta a la base de datos con el usuario pepe y su contraseña sería:

select * from login_table where usuario='pepe' and contraseña='userPass';

A grosso modo, lo que hace es preguntar a la base de datos por los datos de un usuario cuyo nombre es pepe y su contraseña es userPass; amablemente, la base de datos nos los devuelve. Tenemos por tanto dos condiciones en la búsqueda: que el usuario sea pepe Y que la contraseña sea userPass.

¿Qué pasa si manipulamos un poco la entrada de la contraseña, jugando con las comillas simples que suelen utilizarse para introducir los campos de la consulta? Que podemos introducir una condición extra, ya que el código en este caso lo permite. Introduzcamos en el campo de contraseña el valor 'or'1'='1. De esta manera, la consulta a ejecutar quedaría de la siguiente manera:

select * from login_table where usuario='pepe' and contraseña='userPass' or '1'='1'; 

¡¡Boom!!

El resultado es que hemos sido identificados como administrador. ¿Qué ha pasado aquí?

La explicación es simple: con el código introducido en el campo de contraseña, la consulta busca los datos de un usuario cuyo nombre es pepe Y cuya contraseña es userpass O 1 es igual a 1. Dado que 1 siempre es igual a 1, la primera entrada de la tabla es verdadera, y son sus datos los que se devuelven como resultado. Como la primera entrada es la del administrador... ¡nos hemos identificado como el mismo!

Para entender la lógica de esta consulta es necesario conocer una ley básica del álgebra de Boole, en la que se basan las operaciones lógicas como esta. La operación AND tiene precedencia sobre OR; es decir, se evalúa antes. En este caso, ello implica que  al comprobar si una entrada de la tabla concuerda con los criterios, se dan como correctos los casos en los que o tanto el usuario como la contraseña coinciden, o 1 es igual a 1 (o ambas). Por tanto, siempre se devolverá la primera entrada que se encuentre, dado que será correcta.

Esta forma de inyectar SQL es la más básica y comúnmente probada, pese a que a estas alturas debería estar prácticamente erradicada; la realidad, por desgracia, no es tan ideal. Muchas aplicaciones web son aún, por desgracia, débiles a este tipo de ataques.

Más adelante intentaré ampliar el ejemplo con otras sentencias de inyección que funcionarían, e intentaré ampliar un poco la explicación teórica. Espero que hasta el momento os sirva para conocer de forma muy básica la inyección SQL.

Un saludo!!
hartek

The Hazard Project, la razón de ser

Tras unas horas probando nombres que no estuviesen ya cogidos en Blogspot, queda inaugurado por fin el blog.

Llevaba ya un tiempo dándole vueltas a la idea de crear un blog para recoger las pruebas que realizo en materias de seguridad, así como las pruebas y experimentos que suelo llevar a cabo al respecto. La razón es tanto el llevar un diario en el que recoger toda esa información como el simple hecho de devolver a la comunidad un poco de ese conocimiento que todos robamos de aquí y allá.

¿Por qué seguridad? De todas las materias que toca la informática, esta rama es una de las menos valoradas, a la par que seguramente una de las más importantes. La seguridad de la información y las comunicaciones debe ser una prioridad tanto a nivel de usuario como empresarial, y no es sino en estos últimos meses y años cuando se ha hecho un eco real de los ataques que sufre la industria y, en extensión, los usuarios.

Cuando empiezas a formarte en materias de seguridad es cuando te das cuenta de las consecuencias de no hacer bien las cosas. Cuando comienzas a explotar un buffer overflow de un sistema conocido, te acuerdas de lo fácil que es que te salga un error similar programando en C. Cuando ejecutas un man in the middle, te acuerdas de aquella vez que programaste una aplicación cliente-servidor para una tontería y enviabas credeciales en plano.

Y te acojonas, porque tú lo corregiste, pero alguien puede no hacerlo. Y has visto que es bastante fácil de explotar.

En lo sucesivo intentaré publicar de forma más o menos regular pruebas de concepto, experimentos y otro tipo de entradas y tutoriales relacionados con la seguridad, el hacking (¡ético, hombre!) y el pentesting. Todos los comentarios son bienvenidos, sobre todo si ves que he cometido algún pecado capital en el código, en un concepto o similar (es probable que llegue a ocurrir).

Creo que pronto empezaré a redactar una PoC sobre SQL Injection, bastante sencillita, pero que sirve para ver un ejemplo muy sencillo de inyección, pudiendo ver tanto el código HTML de un formulario web víctima como la ejecución de la consulta vulnerable en PHP en el servidor. Espero que os guste y que os sirva para aprender.

Un saludo a todos!!
hartek