{"id":1691545,"date":"2025-04-28T13:05:09","date_gmt":"2025-04-28T13:05:09","guid":{"rendered":"https:\/\/teknomers.com\/es\/como-comienzan-las-violaciones-desglosar-5-vulns-reales\/"},"modified":"2025-04-28T13:05:13","modified_gmt":"2025-04-28T13:05:13","slug":"como-comienzan-las-violaciones-desglosar-5-vulns-reales","status":"publish","type":"post","link":"https:\/\/teknomers.com\/es\/como-comienzan-las-violaciones-desglosar-5-vulns-reales\/","title":{"rendered":"C\u00f3mo comienzan las violaciones: desglosar 5 vulns reales"},"content":{"rendered":"


\n<\/p>\n

\n
<\/a><\/div>\n

No todas las vulnerabilidad de seguridad tienen un alto riesgo por s\u00ed solo, pero en manos de un atacante avanzado, incluso peque\u00f1as debilidades pueden aumentar en grandes infracciones. Estas cinco vulnerabilidades reales, descubiertas por Intruso<\/a> Equipo de caza de errores, revela c\u00f3mo los atacantes se convierten en fallas en graves incidentes de seguridad.<\/p>\n

1. Robando credenciales de AWS con una redirecci\u00f3n<\/strong><\/h2>\n
    \n<\/ol>\n

    La falsificaci\u00f3n de solicitudes del lado del servidor (SSRF) es una vulnerabilidad com\u00fan que puede tener un impacto significativo, especialmente en aplicaciones alojadas en la nube. Si una aplicaci\u00f3n web obtiene recursos de URL proporcionadas por el usuario, se debe tener cuidado para garantizar que los atacantes no puedan manipular las solicitudes para acceder a recursos no deseados.<\/p>\n

    Mientras evaluaba una aplicaci\u00f3n para mover el hogar en AWS, nuestro equipo prob\u00f3 t\u00e9cnicas de derivaci\u00f3n SSRF comunes.<\/p>\n

    La cadena de ataque fue la siguiente: la aplicaci\u00f3n envi\u00f3 una solicitud de webhook al servidor web del atacante, que respondi\u00f3 con una redirecci\u00f3n 302 al servicio de metadatos de AWS. La aplicaci\u00f3n sigui\u00f3 la redirecci\u00f3n y registr\u00f3 la respuesta, que expuso metadatos sensibles, incluidas las credenciales de AWS.<\/p>\n

    Con estas credenciales, un atacante podr\u00eda enumerar los permisos de IAM e intentar girar m\u00e1s profundamente en el entorno de la nube.<\/p>\n

    Este ataque no hubiera sido posible si el servicio de metadatos fuera Hacer cumplir IMDSV2<\/a> – Una mejor pr\u00e1ctica que un buen esc\u00e1ner de seguridad en la nube<\/a> habr\u00eda marcado. Si bien las herramientas automatizadas podr\u00edan no haber detectado la cadena de ataque completo, romper solo esta parte de la cadena podr\u00eda haber evitado la explotaci\u00f3n.<\/p>\n

    2. Desde el repositorio .Git expuesto al acceso completo a la base de datos<\/strong><\/h2>\n
      \n<\/ol>\n

      Mientras investigaba un repositorio .GIT involuntariamente expuesto marcado por un escaneo de vulnerabilidad, nuestro equipo descubri\u00f3 que pertenec\u00eda a una aplicaci\u00f3n web de acceso p\u00fablico.<\/p>\n

      Al revisar el c\u00f3digo fuente de la aplicaci\u00f3n, descubrimos un bypass de autenticaci\u00f3n: se podr\u00eda acceder a la p\u00e1gina de inicio de sesi\u00f3n proporcionando un par\u00e1metro oculto.<\/p>\n

      Nuestro equipo obtuvo acceso a una herramienta de gesti\u00f3n, donde un an\u00e1lisis posterior revel\u00f3 una vulnerabilidad de inyecci\u00f3n SQL ciega en una p\u00e1gina autenticada.<\/p>\n

      Explotando esta vulnerabilidad otorg\u00f3 acceso a la base de datos de una universidad, que, si un atacante aprovecha, podr\u00eda haber expuesto informaci\u00f3n personal confidencial de los estudiantes y el personal, que muestra c\u00f3mo una peque\u00f1a configuraci\u00f3n err\u00f3nea puede aumentar r\u00e1pidamente a un riesgo de seguridad importante.<\/p>\n

      3. C\u00f3mo un peque\u00f1o detalle condujo a la ejecuci\u00f3n de c\u00f3digo remoto<\/strong><\/h2>\n
        \n<\/ol>\n

        Mientras buscaba errores en una aplicaci\u00f3n de firma de documentos, nuestro equipo not\u00f3 que, despu\u00e9s de firmar un PDF, los metadatos enumeraron “ExifTool” como creador de documentos. Dada la historia de vulnerabilidades cr\u00edticas de Exiftool, cavamos m\u00e1s profundo.<\/p>\n

        Aunque la aplicaci\u00f3n no revel\u00f3 la versi\u00f3n de la herramienta, las pruebas de vulnerabilidades conocidas recientes confirmaron que era vulnerable a CVE-2021-22204<\/a>. Al crear y cargar un PDF malicioso, nuestro equipo obtuvo con \u00e9xito la ejecuci\u00f3n de comandos remotos como usuario de datos www.<\/p>\n

        Este punto de apoyo podr\u00eda haber permitido que un atacante aproveche vulnerabilidades adicionales en el servidor afectado, lo que les permite obtener acceso a la ra\u00edz y un pivote a otras m\u00e1quinas en la red, causando da\u00f1os extensos.<\/p>\n

        4. Desde el autoxss hasta la adquisici\u00f3n de la cuenta en todo el sitio<\/strong><\/h2>\n
          \n<\/ol>\n

          La secuencia de comandos entre sitios (XSS) es un poderoso vector de ataque para ataques de secuestro de sesi\u00f3n, especialmente cuando no se requiere interacci\u00f3n de usuario. Si bien una vulnerabilidad de ‘AutoXSS’ suele ser de bajo riesgo, puede volverse peligroso cuando se combina con otra vulnerabilidad.<\/p>\n

          Nuestro equipo descubri\u00f3 este escenario exacto al evaluar una aplicaci\u00f3n de subasta. Se descubri\u00f3 una vulnerabilidad de AutoXSS cuando se reflej\u00f3 un encabezado de solicitud HTTP suministrado por el usuario en la respuesta de la aplicaci\u00f3n.<\/p>\n

          Normalmente, esto ser\u00eda inofensivo ya que un atacante no puede obligar al navegador de una v\u00edctima a enviar un encabezado malicioso, pero las pruebas adicionales descubrieron una vulnerabilidad de recolecci\u00f3n de cach\u00e9.<\/p>\n

          Al encadenar estas dos debilidades, nuestro equipo enga\u00f1\u00f3 a la aplicaci\u00f3n para almacenar en cach\u00e9 y servir la carga \u00fatil de AutoXSS a todos los visitantes del sitio, escal\u00e1ndola a un ataque XSS persistente en todo el sitio.<\/p>\n

          Esto habr\u00eda permitido a un atacante secuestrar cualquier cuenta de usuario, incluidas las cuentas de administraci\u00f3n.<\/p>\n

          5. Cambiar un n\u00famero para exponer datos confidenciales<\/strong><\/h2>\n
            \n<\/ol>\n

            Las debilidades de API son m\u00e1s comunes de lo que piensas. Entre ellos, las vulnerabilidades de IDOR requieren poco esfuerzo para explotar m\u00e1s all\u00e1 de modificar un identificador en una solicitud.<\/p>\n

            El verdadero desaf\u00edo para un atacante no es la ejecuci\u00f3n, sino el descubrimiento: encontrar un punto final vulnerable que se pueda usar sin la autenticaci\u00f3n o autorizaci\u00f3n adecuada, y reconociendo que expone datos confidenciales. Una vez encontrado, la explotaci\u00f3n puede ser tan simple como cambiar el identificador a un recurso que el usuario no posee, o simplemente hacer una solicitud a un punto final que debe reservarse para los administradores.<\/p>\n

            Nuestro equipo frecuentemente identifica IDOR, falta de autenticaci\u00f3n y debilidades de autorizaci\u00f3n rotas en API. Aqu\u00ed hay algunos fragmentos de solicitudes y rutas HTTP reales que encontramos que los datos altamente sensibles expuestos:<\/p>\n