Pull the Plug: Bureaucratic Denial Of Service (2 de 4)

Para realizar un Bureaucratic Denial Of Service, la recogida de información sobre el objetivo es fundamental. Conocer quiénes son los responsables del dominio tanto a nivel legal, como a nivel técnico, ayudarán a un posible atacante a preparar las acciones necesarias.

Fase 1: Recogida de información

En esta fase es necesario conocer cuáles son los servicios que tiene contratada una empresa en un determinado proveedor. Lo más habitual es que se tenga contratado el servicio de registro de nombre de dominio, pero también puede que se haga uso del propio soporte DNS, o de hosting de espacio web o FTP.

Normalmente, cada proveedor tiene un Identificador de Servicio por cada uno de los provistos a una cuenta, que tendrá por supuesto su propio sistema de identificación. Esta cuenta, además de tener su representación en el sistema como NIC Handler, estará asociada a una persona física, identificada por su nombre, dirección de correo, número de teléfono y documento nacional de identidad, quién, en última instancia podrá tomar cualquier decisión sobre el dominio.

Por supuesto, además de recoger información y datos, será necesario conocer información táctica, como cuales los procesos burocráticos que hay que cumplimentar para solicitar el cambio o la supresión de un dominio, además de cuál es el flujo lógico de estas operaciones.

El servicio de Whois

Este servicio es una auténtica mina para la recogida de datos de un dominio. Cualquier información que solicite un proveedor de servicios de Internet para identificar a una persona está recogida en él, tal y como se puede ver en la captura siguiente, donde se ven datos parciales del dominio skytalks.info.

Figura 5: Whois parcial de Skytalks.info

Algunos registradores de dominios permiten la fortificación del sistema, haciendo que se puedan ocultar campos, como por ejemplo en el dominio .COM, donde Microsoft ha ocultado mucha de esta información. Curiosamente, muchos registradores nacionales, en pro de la transparencia, no permiten esta fortificación.

Figura 6: Información Whois de Microsoft.com

En el caso de Microsoft, nos ha llamado la atención ver cómo es víctima de un ataque hacktivista en el Whois, ya que hay dominios que han creado subdominos Microsoft.com para que aparezcan en los resultados, dejando unos mensajes muy poco "elegantes" en él.

Figura 7: Ataque hacktivista al Whois de Microsoft.com

Data Leak en los sistemas de gestión de proveedores de servicios

En el caso de algunos proveedores de servicio, esta información puede ser obtenida directamente desde su sistema de gestión. En el caso de OVH, las facturas de los servicios tienen toda la información necesaria para poder solicitar el comienzo de un proceso de modificación o supresión de un dominio. Por supuesto, acceder a una factura no es algo trivial a priori, aunque como vamos a ver, existían unos fallos que lo permitían.

Figura 8: Factura de servicio en OVH

En el caso de que se quiera acceder a los datos de una factura es necesario disponer del número de factura y la contraseña asociada a la factura, e introducirlos en el servicio: /cgi‐bin/order/bill.cgi. Este sistema está pensado para su distribución a clientes vía e-mail. La longitud de la contraseña es de cuatro caracteres, siendo estos mayúsculas/minúsculas y números por lo que se hace inviable el ataque de fuerza bruta sobre este servicio a través de la web.

Figura 9: Acceso externo a facturas de servicios en OVH

Sin embargo, también es posible acceder a un listado de las facturas emitidas a una determinada cuenta a través de la sección "administración" de la cuenta, en el apartado "facturas". Si observamos detenidamente este listado vemos que enlaza las facturas con la dirección comentada anteriormente, enlazando en algún momento, junto a la petición, la contraseña asociada a la factura.

Figura 10: Acceso a las facturas desde el panel de administración

Si se interceptan las peticiones que se producen cuando se hace clic sobre una determinada factura se puede ver que se llama a un procedimiento por POST en el que únicamente se envía el identificador de factura.

Figura 11: Petición de visualización de factura sin contraseña

Esto es así porque, para facilidad del usuario ya autenticado en el sistema, el propio procedimiento rellena la contraseña y hace un 302 Redirect al procedimiento visto en la Figura 9 con la contraseña correctamente introducida en la petición.

Figura 12: Redirect con la contraseña de la factura rellena

Ahora bien, ¿la gestión se hace de forma correcta comprobándose previamente si la factura solicitada ha sido emitida a la cuenta que realiza la petición? No. Esto permitía que, desde cualquier cuenta de OVH, fuera posible acceder a cualquier factura sabiendo su identificador.

Además, puesto que este identificador tiene un valor predecible por ser un valor incremental y en base al país en el que haya sido emitida, se pueden realizar búsquedas afinadas mediante una búsqueda binaria por fechas de facturas, sabiendo la fecha de alta del dominio a través del servicio Whois.

***************************************************************************************************
- Pull the Plug: Bureaucratic Denial Of Service (1 de 4)
- Pull the Plug: Bureaucratic Denial Of Service (2 de 4)
- Pull the Plug: Bureaucratic Denial Of Service (3 de 4)
- Pull the Plug: Bureaucratic Denial Of Service (4 de 4)


Fuente