Recientemente, comencé a recibir una propuesta para verificar el funcionamiento de varios servicios en busca de errores y vulnerabilidades. Y en tales propuestas trato de trabajar en el resultado y obtener el máximo placer del proceso. Pero el resultado del último "proyecto" me sorprendió por decir lo menos.
Me pidieron que probara el proveedor de alojamiento.
No revelaré el nombre. Y en mi historia usaré el nombre de Hoster. Con el sitio en sí, el servicio de alojamiento era todo estándar. Ofertas para comprar VDS, Dominios, certificados SSL.
En primer lugar, me sorprendió la forma en que se implementó la cuenta personal del usuario. No se requería prueba de propiedad de la dirección de correo electrónico durante el registro. Es decir, puede registrarse con la dirección de correo electrónico steve.jobs@apple.com. O mejor aún, support@hoster.com.
Pero afortunadamente, por analogía con
esta historia , la divulgación de información confidencial del servicio de asistencia técnica no se realizó.
Sin embargo, sucedió cuando creé una solicitud de soporte de prueba e inmediatamente verifiqué la disponibilidad de solicitudes de ID vecinas para otras solicitudes de soporte. Sorprendentemente estaban disponibles. Y fue posible observar quién y qué se registra con el hoster. ¿Y qué problemas enfrentan los usuarios? En general, la vulnerabilidad IDOR estándar, que ahora no sorprenderá a nadie. Por supuesto, ella fue corregida al instante.
También hubo varios lugares con Stored XSS. También hubo Blind XSS que me devolvió la Cookie del administrador del servicio. Gracias a este XSS, pude averiguar dónde se encuentra la interfaz del administrador y, en general, reveló mucha información interesante.
- Cuantos usuarios activos.
- Cuántos dominios están en control.
- Cuántos VDS se implementan.
Y mucho mas ...
Hubo varios errores con los tokens CSRF, que permitieron en nombre del usuario hacer muchas cosas peligrosas en su cuenta. Y si hubo lugares donde se transfirieron tokens CSRF, entonces simplemente se transfirieron. Nadie planeó revisarlos en el backend. Como resultado de mis hallazgos, parte de la funcionalidad se deshabilitó por completo. Por ejemplo, se decidió eliminar temporalmente la autenticación 2FA, ya que no tuvo lugar en la implementación.
En el curso de mi trabajo, presté atención no solo a los problemas de seguridad, sino también a los errores de implementación o problemas en el funcionamiento de algunas funciones. Me gusta QA no podría pasar así. Como resultado, mi rastreador de problemas alcanzó la cifra: 22. Tantos problemas en conjunto que encontré y solucioné (extremadamente notable).
Los resultados fueron más que convincentes. Y ya planeé completar este proyecto. Pero por alguna razón, nuevamente recordé el problema de la falta de confirmación del propietario de la dirección de correo electrónico durante el registro. Y comenzó a pensar en situaciones en las que esto puede crear problemas máximos para el alojamiento y sus propietarios. En algún momento, comencé a pensar en las relaciones de los propietarios de este servicio de alojamiento con otros proyectos de la misma compañía que conocía. Después de un par de minutos, registré una cuenta con la dirección de correo electrónico de otro proyecto de la misma compañía (deje que sea support@example.com). Luego logré vincular el dominio example.com a mi cuenta creada suppot@example.com. Pero todavía no podía controlar el contenido del dominio vinculado.
Pero podría pescar perfectamente con correos electrónicos en nombre del servicio example.com.
No está claro a dónde llegaron las cartas de respuesta. Porque me respondí una de esas cartas de prueba. Pero no recibí la respuesta en sí. Probablemente desapareció en respuesta al verdadero propietario de la cuenta de correo electrónico support@example.com.
Y luego sucedió algo para lo que decidí escribir este artículo.
Logré resolver el subdominio olvidado. Vulnerabilidad de adquisición de subdominio clásico. Puedes leer más sobre esto
aquí .
No sé por qué, pero intenté agregar un enlace a un dominio inexistente. Y lo hice
El subdominio se agregó con éxito y pude controlar el contenido de este subdominio. Y se mostró el contenido.
¡Pero esto no puede ser lo mismo! ¿Cómo es eso? Después de todo, la vulnerabilidad de adquisición de subdominios clásica solo funciona con subdominios existentes.
Esta situación no cabía en mi cabeza. Es decir, está bien, pude omitir los niveles de validación de mi actitud hacia example.com, que nunca es mía (probablemente gracias a
example .com en el nombre de mi cuenta). Pero, ¿cómo es posible agregar subdominios y controlarlos sin ningún componente de verificación en los registros A, TXT, CNAME ...?
Por lo general, veo esto: le agregaremos un subdominio, solo usted demuestra que puede hacerlo. Vaya y agregue a TXT este hash
ololopyshpyshpyshbdysh123 .
Pero no había tal cosa. ¿Quieres el subdominio admin.example.com? No hay problema!
Como si una vulnerabilidad de Subdominio Takeover V2.
Debido a la capacidad de comunicarse rápidamente con los propietarios del servicio de alojamiento probado, Pandora me abrió este cuadro.
Resultó lo siguiente. El alojamiento funcionó a través de CloudFlare. Y trabajó de una manera muy astuta.
Trataré de explicar en palabras simples.
En términos generales, te digo, ven a mí, te alojaré. Delega tus dominios a mí.
Y luego envío todas las llamadas entrantes indiscriminadamente a CloudFlare, considerándolas correctas.
Y si se me confió el dominio vasya.ru, y un vecino vino y amordazó el sitio con test.vasya.ru y también me lo dio para alojar, entonces mi servidor, que tenía acceso a CloudFlare y que ya tenía derechos para vasya.ru, agregaba el tercer nivel sin problemas dominio para un vecino y todas las reglas, de forma rápida y sin dudas. Para todos los DNS, ha llegado la información correcta de CloudFlare. Y CloudFlare confía en mí.
Por lo general, por supuesto, los proveedores de alojamiento configuran sus servicios de DNS. Pero aquí resulta que hicieron trampa y simplemente transfirieron todo a CloudFlare de un usuario.
Entonces tenemos una adquisición de subdominio god_mode. Es cierto, esto funcionó solo con aquellas direcciones que el hosting ya controla. Pero en conjunto con el panel de administración del servicio descubierto anteriormente, esto podría ser un truco tanto para el cliente de hosting como para el cliente de hosting.
Por el momento, casi todas las vulnerabilidades y errores críticos han sido reparados. Y espero que nadie decida sobre esas delicias arquitectónicas después de leer esta historia.
PD: comentarios y sugerencias sobre el artículo son bienvenidos. ¡Un agradecimiento especial a
Patriot2k por su asesoramiento técnico! También estoy abierto a sugerencias para probar algo interesante.