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!