Continuando con la Fase 1 de Búsqueda de información, en OVH fue posible encontrar otro punto interesante para la recogida de información: Las órdenes de pedido.
Data Leak en el sistema de órdenes de pedido en OVH.
Respecto a las órdenes de pedido, el problema reside en que, tras completarse satisfactoriamente el proceso de pago, las órdenes se enlazan automáticamente con la factura correspondiente - que es la que nos interesa por contener toda la información necesaria para solicitar una orden de gestión sobre el servicio, tal y como se vio en el apartado anterior -.
Cabría esperar un sistema de gestión como el que se utiliza en el sistema de facturas - con un identificador y la contraseña asociada al mismo - pero, en este caso, basta con conocer la orden de pedido y tener una cuenta en OVH, pudiéndose crear con datos falsos una cuenta temporal sin problemas para que podamos acceder al identificador y la contraseña enlazados a la misma. Además, OVH no no incorpora en su web ningún sistema que evite la creación automática de cuentas.
Como podréis observar en la petición, a pesar de que el sistema solicita una contraseña para la orden de pedido, el sistema, al recibir las credenciales válidas de una cuenta de OVH, obvia la contraseña dando acceso directamente a la orden solicitada. Como podemos observar, al final es posible obtener toda la información de cualquier persona que haya contratado alguna vez un servicio con OVH.
Fase 2: Solicitud de borrado de dominio ("Pull the Plug")
Al igual que en los sistemas de gestión de facturas comentados anteriormente, es importante controlar el proceso por el cual se realizan las solicitudes de bajas de servicios, controlando en todo momento si la cuenta que está cursando la petición tiene realmente contratado ese servicio o no. Una mala gestión de estos procesos puede provocar tanto la realización automática de un número considerable de solicitudes que ralentizen, e incluso colapsen, el sistema como, en el caso de que no se realice ninguna comprobación de la identidad de la persona que la está cursando, la eliminación directa del servicio (sin la necesidad de realizar el tercer proceso comentado en el inicio).
En el caso de OVH, cabe destacar que el sistema no gestiona correctamente el proceso de solicitud de baja de servicios, pudiendo realizar solicitudes de bajas de servicios que no están asociados a nuestra cuenta, realizando todo el proceso como si fuéramos la cuenta legítima.
Cuando se quería cursar la baja de un servicio (nombres de dominio DNS, servidores dedicados, etcétera) se tenía que acceder al apartado "Procedimientos" dentro de la sección de administración de nuestra cuenta falsa.
Como se puede observar en la imagen superior, se muestra un listado con todos los procedimientos disponibles. En este caso vamos a tratar la parte de solicitudes de baja de servicios pero, como se puede observar, también sería posible cursar una orden de cambio de propietario de un dominio y asignárselo a otra cuenta bajo nuestro control - dejando de lado aquellos dominios que sean gestionados por NICs nacionales, como es el caso de los ES que esa es "otra historia" -. A partir de ese momento obtendríamos el control del dominio pudiendo, en vez de hacer una ataque de denegación de servicio, redirigir a los usuarios a, por ejemplo, páginas de phishing.
Una vez que se accedía al procedimiento de destrucción de dominios se mostraba la información de la cuenta asociada a esos dominios, es decir, los datos de la cuenta de la sesión activa, los dominios disponibles y la opción de elegir una fecha de destrucción - en nuestro caso, inmediatamente que podremos comprobar más adelante que la solicitud será validada en unos días -.
La vulnerabilidad del sistema residía en el tratamiento de los datos de la cuenta que cursa la petición. Como podemos observar, y se ha comentado anteriormente, en la página para cursar la solicitud se mostraba la información de la cuenta que realiza el procedimiento. El problema se encuentra en que, lejos de ser un dato meramente informativo, esa información se utiliza para cursar la solicitud en vez de obtenerse del lado del servidor nuevamente a partir de la sesión que está realizando la solicitud.
De esta forma, si conocemos los datos de contacto del propietario y el identificador de la cuenta asociada al dominio - por eso es necesario el primer paso de obtención de información, porque el nombre y apellidos son muy fáciles de obtener pero el identificador no, y es imprescindible - se podría cursar una solicitud de destrucción de dominio en su nombre.
Además, puesto que estamos facilitando el e-mail de contacto - nuevamente, en vez de obtener del lado del servidor el que le corresponde a la cuenta que está cursando la solicitud -, podemos modificarlo por uno bajo nuestro control para evitar que el administrador de ese dominio reciba en ningún momento una notificación de la puesta en marcha del procedimiento. Así, todo el proceso sería oculto y en ningún momento tendría la oportunidad de bloquearlo porque todo el procedimiento se gestionaba con la cuenta que solicita la petición de baja, y no con la dueña del dominio.
Una vez lanzada la petición se recibirá un e-mail de confirmación explicando todo el proceso a realizar para que Validar la orden de borrado y que sea aceptada la solicitud. Por lo tanto, como podéis observar, de una forma tremendamente sencilla es posible crear en el sistema un expediente de destrucción de dominio y ocultar, al administrador, todo el proceso que a la semana se quedaría sin dominio sin saber por qué.
Ahora sólo quedaría validar la petición.
***************************************************************************************************
- 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)
***************************************************************************************************
Data Leak en el sistema de órdenes de pedido en OVH.
Respecto a las órdenes de pedido, el problema reside en que, tras completarse satisfactoriamente el proceso de pago, las órdenes se enlazan automáticamente con la factura correspondiente - que es la que nos interesa por contener toda la información necesaria para solicitar una orden de gestión sobre el servicio, tal y como se vio en el apartado anterior -.
Cabría esperar un sistema de gestión como el que se utiliza en el sistema de facturas - con un identificador y la contraseña asociada al mismo - pero, en este caso, basta con conocer la orden de pedido y tener una cuenta en OVH, pudiéndose crear con datos falsos una cuenta temporal sin problemas para que podamos acceder al identificador y la contraseña enlazados a la misma. Además, OVH no no incorpora en su web ningún sistema que evite la creación automática de cuentas.
 |
| Figura 13: Acceso a una orden de pedido sin contraseña |
Como podréis observar en la petición, a pesar de que el sistema solicita una contraseña para la orden de pedido, el sistema, al recibir las credenciales válidas de una cuenta de OVH, obvia la contraseña dando acceso directamente a la orden solicitada. Como podemos observar, al final es posible obtener toda la información de cualquier persona que haya contratado alguna vez un servicio con OVH.
Fase 2: Solicitud de borrado de dominio ("Pull the Plug")
Al igual que en los sistemas de gestión de facturas comentados anteriormente, es importante controlar el proceso por el cual se realizan las solicitudes de bajas de servicios, controlando en todo momento si la cuenta que está cursando la petición tiene realmente contratado ese servicio o no. Una mala gestión de estos procesos puede provocar tanto la realización automática de un número considerable de solicitudes que ralentizen, e incluso colapsen, el sistema como, en el caso de que no se realice ninguna comprobación de la identidad de la persona que la está cursando, la eliminación directa del servicio (sin la necesidad de realizar el tercer proceso comentado en el inicio).
En el caso de OVH, cabe destacar que el sistema no gestiona correctamente el proceso de solicitud de baja de servicios, pudiendo realizar solicitudes de bajas de servicios que no están asociados a nuestra cuenta, realizando todo el proceso como si fuéramos la cuenta legítima.
Cuando se quería cursar la baja de un servicio (nombres de dominio DNS, servidores dedicados, etcétera) se tenía que acceder al apartado "Procedimientos" dentro de la sección de administración de nuestra cuenta falsa.
 |
| Figura 14: Procedimientos que pueden solicitarse desde el panel de administración de OVH |
Como se puede observar en la imagen superior, se muestra un listado con todos los procedimientos disponibles. En este caso vamos a tratar la parte de solicitudes de baja de servicios pero, como se puede observar, también sería posible cursar una orden de cambio de propietario de un dominio y asignárselo a otra cuenta bajo nuestro control - dejando de lado aquellos dominios que sean gestionados por NICs nacionales, como es el caso de los ES que esa es "otra historia" -. A partir de ese momento obtendríamos el control del dominio pudiendo, en vez de hacer una ataque de denegación de servicio, redirigir a los usuarios a, por ejemplo, páginas de phishing.
Una vez que se accedía al procedimiento de destrucción de dominios se mostraba la información de la cuenta asociada a esos dominios, es decir, los datos de la cuenta de la sesión activa, los dominios disponibles y la opción de elegir una fecha de destrucción - en nuestro caso, inmediatamente que podremos comprobar más adelante que la solicitud será validada en unos días -.
 |
| Figura 15: Listado de servicios que pueden gestionarse |
La vulnerabilidad del sistema residía en el tratamiento de los datos de la cuenta que cursa la petición. Como podemos observar, y se ha comentado anteriormente, en la página para cursar la solicitud se mostraba la información de la cuenta que realiza el procedimiento. El problema se encuentra en que, lejos de ser un dato meramente informativo, esa información se utiliza para cursar la solicitud en vez de obtenerse del lado del servidor nuevamente a partir de la sesión que está realizando la solicitud.
De esta forma, si conocemos los datos de contacto del propietario y el identificador de la cuenta asociada al dominio - por eso es necesario el primer paso de obtención de información, porque el nombre y apellidos son muy fáciles de obtener pero el identificador no, y es imprescindible - se podría cursar una solicitud de destrucción de dominio en su nombre.
 |
| Figura 16: Tampering de datos, para cambiar los datos del domino a solicitar la baja |
Además, puesto que estamos facilitando el e-mail de contacto - nuevamente, en vez de obtener del lado del servidor el que le corresponde a la cuenta que está cursando la solicitud -, podemos modificarlo por uno bajo nuestro control para evitar que el administrador de ese dominio reciba en ningún momento una notificación de la puesta en marcha del procedimiento. Así, todo el proceso sería oculto y en ningún momento tendría la oportunidad de bloquearlo porque todo el procedimiento se gestionaba con la cuenta que solicita la petición de baja, y no con la dueña del dominio.
Una vez lanzada la petición se recibirá un e-mail de confirmación explicando todo el proceso a realizar para que Validar la orden de borrado y que sea aceptada la solicitud. Por lo tanto, como podéis observar, de una forma tremendamente sencilla es posible crear en el sistema un expediente de destrucción de dominio y ocultar, al administrador, todo el proceso que a la semana se quedaría sin dominio sin saber por qué.
Ahora sólo quedaría validar la petición.
***************************************************************************************************
- 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)
***************************************************************************************************
No hay comentarios:
Publicar un comentario