Apodado ProxyNotShell, un nuevo exploit utilizado en la naturaleza aprovecha la vulnerabilidad de Microsoft Server-Side Request Forgery (SSRF) recientemente publicada CVE-2022-41040 y una segunda vulnerabilidad, CVE-2022-41082 que permite la ejecuci\u00f3n remota de c\u00f3digo (RCE) cuando PowerShell est\u00e1 disponible para atacantes no identificados.<\/p>\n
Basado en ProxyShell, este nuevo riesgo de abuso de d\u00eda cero aprovecha un ataque encadenado similar al utilizado en el ataque ProxyShell de 2021 que explot\u00f3 la combinaci\u00f3n de m\u00faltiples vulnerabilidades: CVE-2021-34523, CVE-2021-34473 y CVE-2021- 31207: para permitir que un actor remoto ejecute c\u00f3digo arbitrario.<\/p>\n
A pesar de la gravedad potencial de los ataques que los utilizan, las vulnerabilidades de ProxyShell todav\u00eda se encuentran en la lista de CISA de las principales vulnerabilidades explotadas de forma rutinaria en 2021.<\/p>\n
Conoce a ProxyNotShell <\/h2>\n
Grabado el 19 de septiembre de 2022, CVE-2022-41082 es un vector de ataque dirigido a los servidores Exchange de Microsoft, lo que permite ataques de baja complejidad con pocos privilegios requeridos. Los servicios afectados, si son vulnerables, permiten que un atacante autenticado comprometa el servidor de intercambio subyacente aprovechando el PowerShell de intercambio existente, lo que podr\u00eda resultar en un compromiso total.<\/p>\n
Con la ayuda de CVE-2022-41040, otra vulnerabilidad de Microsoft tambi\u00e9n registrada el 19 de septiembre de 2022, un atacante puede activar de forma remota CVE-2022-41082 para ejecutar comandos de forma remota.<\/p>\n
Aunque un usuario debe tener el privilegio para acceder a CVE-2022-41040, lo que deber\u00eda reducir la accesibilidad de la vulnerabilidad a los atacantes, el nivel de privilegio requerido es bajo.<\/p>\n
Al momento de escribir este art\u00edculo, Microsoft a\u00fan no ha emitido un parche, pero recomienda que los usuarios a\u00f1adir una regla de bloqueo<\/a> como medida de mitigaci\u00f3n.<\/p>\n Ambas vulnerabilidades se descubrieron durante un ataque activo contra GTSC, una organizaci\u00f3n vietnamita llamada GTSC, que otorga a los atacantes acceso a algunos de sus clientes. Aunque ninguna de las vulnerabilidades por s\u00ed sola es particularmente peligrosa, los exploits que las encadenan podr\u00edan conducir potencialmente a infracciones catastr\u00f3ficas.<\/p>\n Las vulnerabilidades encadenadas podr\u00edan otorgar a un atacante externo la capacidad de leer correos electr\u00f3nicos directamente desde el servidor de una organizaci\u00f3n, la capacidad de violar la organizaci\u00f3n con CVE-2022-41040 Remote Code Execution e implantar malware en el Exchange Server de la organizaci\u00f3n con CVE-2022-41082.<\/p>\n Aunque parece que los atacantes necesitar\u00edan cierto nivel de autenticaci\u00f3n para activar el exploit de vulnerabilidades encadenadas, el nivel exacto de autenticaci\u00f3n requerido, calificado como “Bajo” por Microsoft, a\u00fan no se aclara. Sin embargo, este bajo nivel de autenticaci\u00f3n requerido deber\u00eda prevenir efectivamente un ataque masivo y automatizado dirigido a todos los servidores de Exchange en todo el mundo. Con suerte, esto evitar\u00e1 una repetici\u00f3n de la debacle de ProxyShell de 2021.<\/p>\n Sin embargo, encontrar una sola combinaci\u00f3n v\u00e1lida de direcci\u00f3n de correo electr\u00f3nico\/contrase\u00f1a en un servidor de Exchange determinado no deber\u00eda ser demasiado dif\u00edcil y, como este ataque pasa por alto la validaci\u00f3n del token MFA o FIDO para iniciar sesi\u00f3n en Outlook Web Access, una sola combinaci\u00f3n de direcci\u00f3n de correo electr\u00f3nico\/contrase\u00f1a comprometida es todo. eso es necesario<\/p>\n Al momento de escribir este art\u00edculo, Microsoft a\u00fan no ha emitido un parche, pero recomienda que los usuarios a\u00f1adir una regla de bloqueo<\/a> como medida de mitigaci\u00f3n de eficacia desconocida.<\/p>\n El bloqueo del tr\u00e1fico entrante a los servidores de Exchange que contienen afirmaciones cr\u00edticas tambi\u00e9n es una opci\u00f3n, aunque solo es factible si dicha medida no afecta las operaciones vitales e idealmente deber\u00eda percibirse como una medida temporal pendiente de la emisi\u00f3n de un parche verificado por parte de Microsoft.<\/p>\n Dado que las opciones de mitigaci\u00f3n actuales tienen una eficacia no verificada o pueden da\u00f1ar el buen funcionamiento de las operaciones, evaluar el grado de exposici\u00f3n a ProxyNotShell podr\u00eda evitar la adopci\u00f3n de medidas preventivas innecesarias potencialmente perjudiciales o indicar qu\u00e9 activos migrar de forma preventiva a servidores no expuestos.<\/p>\n Cymulate Research Lab ha desarrollado un evaluaci\u00f3n personalizada para ProxyNotShell<\/a> que permiten a las organizaciones estimar exactamente su grado de exposici\u00f3n a ProxyNotShell.<\/p>\n Se agreg\u00f3 un vector de ataque ProxyNotShell a las plantillas de escenarios avanzados, y ejecutarlo en su entorno genera la informaci\u00f3n necesaria para validar la exposici\u00f3n, o la falta de ella, a ProxyNotShell.<\/p>\n Hasta que los parches verificados est\u00e9n disponibles de Microsoft, evaluar la exposici\u00f3n a ProxyNotShell para evaluar exactamente qu\u00e9 servidores son objetivos potenciales es la forma m\u00e1s rentable de evaluar exactamente qu\u00e9 activos est\u00e1n expuestos y dise\u00f1ar medidas preventivas espec\u00edficas con el m\u00e1ximo impacto.<\/p>\n Por Laboratorios de investigaci\u00f3n de Cymulate<\/a><\/p>\n <\/p>\n<\/div>\nMitigaci\u00f3n de la exposici\u00f3n de ProxyNotShell<\/h2>\n
Evaluaci\u00f3n de la exposici\u00f3n de ProxyNotShell<\/h2>\n
![\"ProxyNotShell\"](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/10\/ProxyNotShell-\u00bfel-nuevo-infierno-de-proxy.png\" "\\"ProxyNotShell\\"")
<\/div>\n![\"ProxyNotShell\"](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2022\/10\/1664872887_743_ProxyNotShell-\u00bfel-nuevo-infierno-de-proxy.png\" "\\"ProxyNotShell\\"")
<\/div>\n