Desentra√Īar una mara√Īa de vulnerabilidades en los sitios


Despu√©s de mi primer art√≠culo publicado en codeby, que ingres√≥ en las 3 principales publicaciones de la semana, estaba muy motivado para escribir el siguiente. Pero el 11¬ļ grado impone restricciones en el tiempo libre que se prepara para el examen y las olimpiadas. Por lo tanto, escribo el segundo solo despu√©s de unos meses despu√©s de volar de todas las Olimpiadas .

Esta publicación hablará de un caso interesante cuando una vulnerabilidad encontrada en un recurso implica una cadena de encontrarlos en varios otros sitios.

Comenzando


Todo comenz√≥ con la comprobaci√≥n del sitio de un importante fabricante de productos falsificados. La cuenta personal del usuario no estaba all√≠ y el √°rea de b√ļsqueda de vulnerabilidades no era demasiado extensa.

Al probar el formulario de envío de pedidos, se descubrieron varias vulnerabilidades en él.
En primer lugar, este es un XSS almacenado bastante est√°ndar en los datos del comprador, con el que se extendi√≥ esta mara√Īa. XSS es est√°ndar, y la falta de una marca "httponly" en una cookie claramente no era est√°ndar. Muchas veces recib√≠ cookies de varios sitios, pero nunca recib√≠ autorizaci√≥n, y comenc√© a dudar de que en la naturaleza hab√≠a sitios que no usaban la bandera "httponly", porque su uso reduce significativamente el riesgo de ataques XSS. Fue a√ļn m√°s sorprendente encontrar un evento de este tipo en el sitio de una gran empresa. Pero, como result√≥, el servicio que permiti√≥ esta supervisi√≥n fue mucho mayor de lo que esperaba. Pero m√°s sobre eso despu√©s.

Sustituí las cookies recibidas e inicié sesión en la cuenta CRM del sistema del sitio (no pude resistirme, por primera vez tuve tanta suerte). Los derechos no eran administrativos, pero eran suficientes para acceder a cualquier estadística sobre pedidos, incluidos y datos del cliente.



Hice capturas de pantalla para demostrar la existencia de una vulnerabilidad y envi√© un informe. Pas√≥ m√°s de una semana y ya no estaba esperando una respuesta. Seg√ļn las estad√≠sticas, si no recibe respuesta dentro de los tres d√≠as, puede olvidarse de ellos. Pero despu√©s de 8 d√≠as, lleg√≥ una respuesta inesperada. Y a√ļn m√°s, fueron los primeros en pagarme por la vulnerabilidad encontrada.



Volviendo a probar el formulario de envío de pedidos, también encontré una vulnerabilidad de iDOR que le permite cambiar el precio del pedido editando los parámetros "json_order [0] [precio]" y "json_order [0] [total]" en la solicitud POST domain.ru/shop.php . La sustitución del enlace de orden en la misma solicitud en el campo json_order [0] [href] condujo a una RFI.

No se recibió respuesta al mensaje sobre nuevos hallazgos ...

Continuación


En ese sitio de crm, el sistema resultó no estar escrito por sí mismo, sino que fue proporcionado para el pago por un servicio conocido. Después de su error con la cookie, era lógico suponer que habría otras vulnerabilidades.

Si el script enviado por mí a través del formulario de pedido funcionó, entonces no hubo validación de campo tanto en el sitio deseado como en el sistema CRM. x2. Por lo tanto, después de recibir una cuenta de prueba, comencé buscando campos vulnerables a xss.

Despu√©s de largos viajes a trav√©s del extenso sistema de crm, se identificaron m√°s de una docena de campos con validaci√≥n insuficiente. En alg√ļn lugar, puede insertar directamente la etiqueta del script, en alg√ļn lugar debe usar scripts en l√≠nea del tipo "onmouseover = alert ()". Adem√°s, en algunos lugares fue posible incrustar un gui√≥n, pero en algunos lugares, me pregunto qu√© l√≥gica fueron guiados, agregando filtros en algunos lugares y no en otros. Desde el punto de vista del prop√≥sito l√≥gico de los campos, no vi un patr√≥n. En algunos lugares, donde casi no todos ir√°n, todo funcion√≥ bien, pero, por ejemplo, no se molestaron en agregar filtros al nombre de la contraparte.

Los campos más vulnerables no pueden ser influenciados externamente. Solo podrían ser utilizados por los empleados para mejorar sus derechos en el sistema, lo que también es importante.

Con xss se acabó, fue posible pasar a cosas más interesantes.

Nunca he buscado vulnerabilidades CSRF antes, los sitios que he probado no estaban en la clase contra la cual usar√≠an phishing. Por lo tanto, no quer√≠a molestarme a m√≠ mismo ni a los propietarios de sitios con vulnerabilidades que nunca se usar√≠an contra ellos. Fue un caso radicalmente diferente. Este sistema de crm era popular, tambi√©n lo usaban las grandes tiendas en l√≠nea, adem√°s, exist√≠a la posibilidad de conectar cajas de efectivo de puntos de venta minoristas, lo que hac√≠a que el problema de seguridad fuera a√ļn m√°s importante.

Sorprendentemente, no hab√≠a protecci√≥n contra CSRF. Fue posible enviar cualquier solicitud, los controles no se llevaron a cabo en ning√ļn lado.
- ¬ŅCambiar la informaci√≥n de la cuenta? por favor
- Cambiar el nombre y el precio de los bienes? - no hay duda

Al mismo tiempo, las cookies contenían algo llamado "csrftoken".

Entonces a√ļn pens√©, ¬Ņcu√°l es el punto de poner el token csrf en las cookies? Buscando en Google, descubr√≠ que hay una forma bastante conveniente de protegerse contra csrf con un token en cookies y duplicarlo en una solicitud posterior, en la que no es necesario almacenar el token en el servidor. M√°s detalles aqu√≠ .

Pero en nuestro caso, solo se realiz√≥ la mitad del trabajo, el token se coloc√≥ en cookies y estuvo ausente en las solicitudes al servidor. Y a√ļn m√°s, su eliminaci√≥n completa de las cookies no cambi√≥ nada. ¬ŅPor qu√© fue agregado?

En conjunción con el csrf descubierto, nuestro xss, que no era accesible previamente desde el exterior, obtiene una segunda vida. Después de todo, no necesitamos ingresar a nuestra cuenta para editar campos vulnerables.

Además, mediante la sustitución del tipo mime del archivo, se pueden cargar archivos arbitrarios en el servidor. Pero el servidor se configuró correctamente y los scripts php no se ejecutaron allí.

Además más interesante. Todos los datos sobre bienes que la tienda en línea tomó de crm. Es decir nombre, descripción, foto. El enlace a la imagen del producto era "aaaa.domain.ru/file/get/id=xxx". Para que la tienda en línea pueda tomar imágenes, deben tener derechos de lectura para todos. 122)

Después de comprobar las rutas a lo largo de las cuales se almacenan otros archivos más privados, vi la misma URL. No parece nada sorprendente, probablemente tengan otros derechos de acceso. No inferior a 022 definitivamente. Pero, la realidad resultó ser ligeramente diferente, también tenían acceso gratuito para usuarios no autorizados.

- ¬ŅHa solicitado importar datos de pedido en un archivo exel? - Genial, ahora cualquiera puede descargarlo.

¬ŅQuiz√°s la identificaci√≥n parec√≠a "yt5bjFb54hb # HJ% $ p" y no cedi√≥ ante la fuerza bruta? No tampoco. Todos los archivos de identificaci√≥n ten√≠an un formato num√©rico y estaban en el rango de varios miles. Protecci√≥n contra brutus, tampoco me di cuenta. Habiendo escaneado todas las identificaciones de 1 a 10000 obst√°culos no se encontraron. Repetido varias veces m√°s, nadie estaba interesado en tal actividad.

Respondieron mi informe en 3 días.

Con respecto a la falta de una bandera, httponly dijo que faltaba "Aparentemente hace mucho tiempo, desde que se actualizó la versión de php". Encendido el mismo día.

Seg√ļn xss, dijeron que todo el mundo sabe que el filtro se apag√≥ a principios de verano (en ese momento ya era agosto), por supuesto, esto no explica por qu√© se estaba filtrando en alg√ļn lugar, pero no en alg√ļn lugar, pero supongamos que no nos dimos cuenta de esto. inconsistencia Tambi√©n aseguraron que el filtro se lanzar√° en un par de d√≠as. De hecho, result√≥ que en un par de meses. Pero, aqu√≠ los entiendo perfectamente: tambi√©n plane√© comenzar a prepararme para los ex√°menes en un par de d√≠as ...

Subir archivos arbitrarios al servidor les preocupaba poco, ya que no se ejecutan en el servidor, lo que significa que no hay nada de qu√© preocuparse. Solo al momento de escribir el art√≠culo tuve una idea de si un sitio que ya se encuentra en un hosting que no sea CRM est√° tratando de tomar una imagen del producto para el escaparate, pero recibe un script php, ¬Ņlo ejecutar√°? O debido al hecho de que est√° destinado a la etiqueta img, ¬Ņse procesar√° solo como una imagen? ¬ŅO depende de la configuraci√≥n del servidor? Por favor responda a personas con conocimiento.

La respuesta al informe csrf result√≥ ser bastante interesante. Respondieron con una pregunta: "¬ŅQu√© consideras un token para protecci√≥n contra ataques csrf?" Realmente, ¬Ņde qu√© estoy hablando?



Dijeron sobre el libre acceso a cualquier archivo que no tuvieron en cuenta este momento. Cerrado de inmediato.

Debo decir que este fue el √ļnico momento en que realmente esperaba recibir una recompensa en efectivo. El sitio es grande, excepto que a√ļn no hay un proyecto pagado. Revista popular en l√≠nea. Pero solo recibi√≥ gratitud verbal.
Debo agradecerles, me tranquilic√© a√ļn m√°s sobre el tema del pago. Trabajar por el bien de la gratitud en cualquier forma finalmente no conducir√° a nada. Te acostumbrar√°s a cualquier elogio y otros honores, y dejar√°n de brindar satisfacci√≥n. Y si hiciste todo por ellos, entonces se perder√° el significado de hacer algo. Y no puede perder el placer del proceso de su actividad, resolver nuevos problemas, crear algo nuevo. Trabaja por el bien del trabajo, no importa lo trivial que pueda sonar. El trabajo durante el cual no te das cuenta de c√≥mo pasan las horas, c√≥mo el sol logr√≥ no solo ir m√°s all√° del horizonte, sino tambi√©n salir nuevamente a causa de √©l.

'' '
Estamos satisfechos con lo peque√Īo, la felicidad no est√° en mucho dinero
"Haz lo que amas" - apreciado en nuestros círculos
'' '© Kolya Manyu - Todos los días

Final


En el soporte t√©cnico del sitio anterior, se utiliz√≥ el sistema de recepci√≥n de tickets de terceros UserEcho. No fall√© en comprobarlo. En sue√Īos, por supuesto, era posible tener la oportunidad de leer cualquier boleto privado. Naturalmente, no tuve √©xito. Ten√≠a que contentarme con poco.



Al probar la API que funcionaba con tickets, inicialmente no se notaron anomal√≠as, el derecho de no mirar a alguien m√°s, de no suscribirse no era posible. Pero, al seguir estudiando el sitio, result√≥ que los desarrolladores hicieron una peque√Īa falla.
En el perfil, puede encontrar una sección sobre la administración de sus boletos, indicando aquellos a los que se suscribió o a los que se suscribió anteriormente.



Si enviamos una solicitud para cancelar la suscripci√≥n del boleto de otra persona, se nos informa, como se esperaba, que no tenemos derechos para esta acci√≥n. Pero al mismo tiempo, est√° incluido en nuestra lista de boletos, como uno de los que nos suscribimos anteriormente. Por lo tanto, tenemos la oportunidad de averiguar su nombre y url con el formato "ticket_name_name_in_translate". Este da√Īo, por supuesto, no llev√≥ a ninguno. En casos muy raros, ser√° posible aprender algo importante y valioso del nombre. Pero era mejor que quedarse sin nada en absoluto.

Después de un par de semanas, se solucionó el error.

¬°Agradezco a todos los que leyeron hasta el final!

Source: https://habr.com/ru/post/445112/


All Articles