T3 Ep102.5: Errores de intercambio “ProxyNotShell” – habla un experto [Audio + Texto] PlatoBlockchain Data Intelligence. Búsqueda vertical. Ai.

S3 Ep102.5: Errores de intercambio "ProxyNotShell": habla un experto [Audio + Texto]

Marca de tiempo: 1 de octubre de 2022 10:05 a. M.

by
Paul patito

NO ENTRE EN PÁNICO… PERO PREPÁRESE PARA ACTUAR

Con Paul Ducklin y Chester Wisniewski

Música de introducción y final de Edith Mudge.

Haga clic y arrastre en las ondas sonoras de abajo para saltar a cualquier punto. Tú también puedes escuchar directamente en Soundcloud.

Puedes escucharnos en SoundCloud, Podcasts de Apple, Podcasts de Google, Spotify, Stitcher y en cualquier lugar donde se encuentren buenos podcasts. O simplemente suelta el URL de nuestro feed RSS en tu cazador de vainas favorito.

LEER LA TRANSCRIPCIÓN

[MÓDEM MUSICAL]

PATO.  Hola a todos.

Bienvenidos a otro miniepisodio especial del podcast Naked Security.

Soy Paul Ducklin, acompañado nuevamente por mi amigo y colega Chester Wisniewski.

Hola Chet.

CHET.  [FALSO ACENTO AUSSIE] Buenos días, Duck.

PATO.  Bueno, Chet, estoy seguro de que todos escuchan. si están escuchando poco después de que salió el podcast, ¡saben de lo que vamos a estar hablando!

Y tiene que ser este doble cañón Microsoft Exchange de día cero que salió en el lavado prácticamente el último día de septiembre de 2022:

Nuestros amigos de ventas dicen: "Oh, es fin de mes, es fin de trimestre, es un momento frenético... pero mañana todos tendrán un reinicio a $0".

¡No va a ser así este fin de semana para los administradores de sistemas y los administradores de TI!

CHET.  Pato, creo, en las inmortales palabras del difunto Douglas Adams, "NO ENTRAR EN PÁNICO" podría estar en orden.

Muchas organizaciones ya no alojan su propio correo electrónico en las instalaciones de los servidores de Exchange, por lo que una buena parte de la gente puede respirar hondo y dejar pasar un poco de tiempo este fin de semana, sin estresarse demasiado por eso.

Pero si está ejecutando Exchange en las instalaciones...

…si fuera yo, podría estar trabajando algunas horas extra solo para implementar algunas mitigaciones, para asegurarme de no tener una sorpresa desagradable el lunes o el martes cuando esto, con toda probabilidad, se convierta en algo más dramático.

PATO.  Entonces, es CVE-2022-41040 y CVE-2022-41042… eso es todo un bocado.

He visto que se hace referencia en Twitter como ProxyNotShell, porque tiene algunas similitudes con el ProxyShell vulnerabilidad que fue la gran noticia hace poco más de un año,

Pero aunque tiene esas similitudes, es un par completamente nuevo de exploits que se encadenan, lo que potencialmente brinda una ejecución remota de código, ¿es correcto?

CHET.  Eso es lo que parece.

Esas vulnerabilidades se descubrieron durante un ataque activo contra una víctima, y ​​una organización vietnamita llamada GTSC desentrañó estas dos nuevas vulnerabilidades que permitieron a los adversarios obtener acceso a algunos de sus clientes.

Parece que divulgaron responsablemente esas vulnerabilidades a la Zero Day Initiative [ZDI] que está a cargo de Trend Micro para informar las vulnerabilidades de día cero de manera responsable.

Y, por supuesto, ZDI luego, a su vez, compartió toda esa inteligencia con Microsoft, hace poco más de tres semanas.

Y la razón por la que sale hoy es que creo que el grupo vietnamita...

…parece que se están impacientando un poco y preocupados porque han pasado tres semanas y no se han enviado alertas ni consejos para ayudar a proteger a las personas contra estos presuntos actores del estado-nación.

Entonces decidieron hacer sonar las alarmas y hacerles saber a todos que deben hacer algo para protegerse.

PATO.  Y, para ser justos, cuidadosamente dijeron: “No vamos a revelar exactamente cómo explotar estas vulnerabilidades, pero le daremos mitigaciones que encontramos efectivas”.

Parece que cualquiera de los dos exploits por sí solo no es especialmente peligroso...

… pero encadenados, significa que alguien fuera de la organización que tiene la capacidad de leer el correo electrónico de su servidor podría usar el primer error para abrir la puerta y el segundo error para implantar malware en su servidor de Exchange.

CHET.  Y ese es un punto muy importante que destacar, Duck, que dijiste, “Alguien que pueda leer el correo electrónico en su servidor”.

Este no es un ataque *no autenticado*, por lo que los atacantes necesitan tener algo de inteligencia en su organización para poder ejecutar estos ataques con éxito.

PATO.  Ahora, no sabemos exactamente qué tipo de credenciales necesitan, porque en el momento en que estamos grabando esto [2022-09-30T23:00:00Z], todo sigue siendo en gran parte secreto.

Pero por lo que he leído (de personas a las que me inclino a creer), parece que las cookies de sesión o los tokens de autenticación no son lo suficientemente buenos y que en realidad necesitaría una contraseña de usuario.

Sin embargo, después de haber proporcionado la contraseña, si hubo autenticación de dos factores [2FA], se activa el primer error (el que abre la puerta) *entre el punto en el que se proporciona la contraseña y el punto en el que se colocarían los códigos 2FA solicitado*.

Así que necesitas la contraseña, pero no necesitas el código 2FA...

CHET.  Parece que es una "vulnerabilidad de autenticación media", si quieres llamarlo así.

Esa es una bendición mixta.

Significa que un script de Python automatizado no puede simplemente escanear todo Internet y potencialmente explotar todos los servidores de Exchange en el mundo en cuestión de minutos u horas, como vimos que sucedió con ProxyLogon y ProxyShell en 2021.

Vimos el regreso de gusanos en los últimos 18 meses, en detrimento de muchas organizaciones.

PATO.  ¿“Gusano”?

CHET.  ¡Lombrices, sí! [RISAS]

PATO.  ¿Es eso una palabra?

Bueno, si no lo es, ¡lo es ahora!

Me gusta eso... Podría tomarlo prestado, Chester. [RISAS]

CHET.  Creo que esto es levemente gusanoable, ¿verdad?

Necesita una contraseña, pero encontrar una dirección de correo electrónico y una combinación de contraseña válidas en cualquier servidor de Exchange probablemente no sea demasiado difícil, desafortunadamente.

Cuando habla de cientos o miles de usuarios... en muchas organizaciones, es probable que uno o dos de ellos tengan contraseñas deficientes.

Y es posible que no haya sido explotado hasta la fecha, porque para iniciar sesión con éxito en Outlook Web Access [OWA] se requiere su token FIDO, o su autenticador, o cualquier segundo factor que pueda estar usando.

Pero este ataque no requiere ese segundo factor.

Entonces, solo adquirir una combinación de nombre de usuario y contraseña es una barrera bastante baja...

PATO.  Ahora hay otra complejidad aquí, ¿no es así?

Es decir que aunque directriz de Microsoft dice oficialmente que los clientes de Microsoft Exchange Online pueden retirarse de Blue Alert, solo es peligroso si tiene Exchange en las instalaciones...

… hay un número sorprendente de personas que cambiaron a la nube, posiblemente hace varios años, que estaban ejecutando tanto su servicio local como su servicio en la nube al mismo tiempo durante el cambio, que nunca tuvieron la oportunidad de apagar el local Servidor de intercambio.

CHET.  ¡Precisamente!

Vimos esto volviendo a ProxyLogin y ProxyShell.

En muchos casos, los delincuentes accedieron a su red a través de servidores Exchange que creían no tener.

Por ejemplo, alguien no revisó la lista de máquinas virtuales que se ejecutan en su servidor VMware para darse cuenta de que sus servidores de Exchange migratorios los estaban ayudando durante el transporte de datos entre su red local y la red en la nube...

…todavía estaban, de hecho, encendidos, habilitados y expuestos a Internet.

Y lo que es peor, cuando no se sabe que están allí, es aún menos probable que hayan sido reparados.

Es decir, las organizaciones que tienen Exchange, al menos, probablemente se esfuerzan por programar el mantenimiento de forma regular.

Pero cuando no sabe que tiene algo en su red “porque lo olvidó”, lo cual es realmente fácil con las máquinas virtuales, se encuentra en una situación aún peor, porque probablemente no ha estado aplicando actualizaciones de Windows o de Exchange.

PATO.  Y la ley de Murphy dice que si realmente confías en ese servidor y no lo cuidas adecuadamente, colapsará justo el día antes de que realmente lo necesites.

Pero si no sabe que está ahí y podría usarse para mal, las posibilidades de que funcione durante años y años y años sin ningún problema son probablemente bastante altas. [RISAS]

CHET.  Sí, desafortunadamente, esa ha sido ciertamente mi experiencia.

Suena tonto, pero escanear su propia red para averiguar qué tiene es algo que le recomendamos que haga regularmente de todos modos.

Pero sin duda, cuando se entera de un boletín como este, si es un producto que sabe que ha usado en el pasado, como Microsoft Exchange, es un buen momento para ejecutar ese Escaneo Nmap...

…y tal vez incluso iniciar sesión shodan.io y verifique sus servicios externos, solo para asegurarse de que todas esas cosas se apagaron.

PATO.  Ahora sabemos por la propia respuesta de Microsoft que están trabajando frenéticamente para sacar parches.

Cuando aparezcan esos parches, será mejor que los aplique muy rápido, ¿no es así?

Porque si algún parche va a ser objeto de ingeniería inversa para descubrir el exploit, será algo de este tipo.

CHET.  ¡Sí, absolutamente, Pato!

Incluso una vez que aplique el parche, habrá una ventana de tiempo, ¿verdad?

Quiero decir, normalmente Microsoft, para los martes de parches de todos modos, lanza sus parches a las 10.00:XNUMX a.m., hora del Pacífico.

En este momento estamos en el horario de verano, por lo que es UTC-7... Entonces, alrededor de las 17:00 UTC suele ser cuando Microsoft lanza parches, por lo que la mayoría de su personal tiene todo el día para responder a las consultas entrantes en Seattle. [Microsoft HQ está en Bellevue, Seattle, WA.]

La clave aquí es que hay una especie de "carrera" de horas, tal vez minutos, dependiendo de qué tan fácil sea explotar esto, antes de que comience a suceder.

Y nuevamente, volviendo a esas explotaciones anteriores de Exchange con ProxyShell y ProxyLogon, a menudo descubrimos que incluso los clientes que habían parcheado en tres, cuatro, cinco días...

…que, para ser honesto, es un poco rápido para un servidor de Exchange, son muy difíciles de parchear, con muchas pruebas involucradas para asegurarse de que sea confiable antes de interrumpir sus servidores de correo electrónico.

Eso fue suficiente tiempo para que esos servidores obtuvieran conchas web, criptominers, todo tipo de backdoors instalado en ellos.

Y así, cuando sale el parche oficial, no solo necesitas actuar rápido...

…*después* de que actúes, vale la pena volver atrás y revisar minuciosamente esos sistemas en busca de pruebas de que tal vez hayan sido atacados en el intervalo entre el momento en que el parche estuvo disponible y el momento en que pudiste aplicarlo.

Estoy seguro de que habrá muchas conversaciones sobre Naked Security y sobre Twitter y otros lugares, hablando sobre los tipos de ataques que estamos viendo para que sepa qué buscar.

PATO.  Si bien puede ir y buscar un montón de hashes de malware conocido que ya se ha distribuido en un número limitado de ataques...

…realmente, la conclusión es que todo tipo de malware es una posibilidad.

Y así, como creo que dijiste en el último mini-episodio que hicimos, ya no es suficiente esperar a que aparezcan alertas de algo malo que haya sucedido en su tablero:

Tienes que salir de forma proactiva y buscar, en caso de que los delincuentes ya hayan estado en tu red y hayan dejado algo atrás (¡que podría haber estado allí durante mucho tiempo!) que aún no hayas notado.

CHET.  Así que creo que eso nos lleva hacia, “¿Qué hacemos ahora, mientras esperamos el parche?”

Publicado el blog del Microsoft Security Research Center (MSRC) algunos consejos de mitigación y detalles... todo lo que Microsoft esté dispuesto a revelar en este momento.

Yo diría, si eres un puro Microsoft Exchange en línea cliente, usted está más o menos limpio y debe prestar atención en caso de que las cosas cambien.

Pero si se encuentra en una situación híbrida, o si aún está ejecutando Microsoft Exchange localmente, creo que probablemente haya algún trabajo que valga la pena hacer esta tarde o mañana por la mañana, si nada más.

Por supuesto, en el momento de la grabación, esto es viernes por la tarde... así que, en realidad, cuando estés escuchando esto, "inmediatamente, cada vez que lo estés escuchando, si aún no lo has hecho".

¿Cuáles son las mejores prácticas aquí, Duck?

Obviamente, una cosa que puede hacer es desactivar el acceso web externo hasta que haya un parche disponible.

¡Simplemente podría apagar su servidor IIS y luego eso lo hará!

PATO.  Sospecho que muchas empresas no estarán en esa posición.

Y Microsoft enumera dos cosas que dicen... bueno, no dicen, "Esto definitivamente funcionará".

Sugieren que limitará en gran medida su riesgo.

Una es que existe una regla de reescritura de URL que puede aplicar a su servidor IIS. (Tengo entendido que es IIS el que acepta la conexión entrante que se convierte en el acceso a Exchange Web Services [EWS]).

Entonces, hay una configuración de IIS que puede hacer que buscará posibles explotaciones del primer agujero, lo que evitará que se inicie la activación de PowerShell.

Y hay algunos puertos TCP que puede bloquear en su Exchange Server.

Creo que es el puerto 5985 y 5986, que detendrá lo que se llama PowerShell Remoting… evitará que estos comandos de ejecución remota de PowerShell no autorizados se inserten en el servidor de Exchange.

Tenga en cuenta, sin embargo, que Microsoft dice que esto "limitará" su exposición, en lugar de prometer que saben que soluciona todo.

Y eso puede deberse a que sospechan que hay otras formas en que esto podría desencadenarse, pero aún no han descubierto cuáles son. [RISAS]

Ninguna configuración es algo que usted hace en Exchange.

Uno de ellos está en IIS y el otro es algún tipo de regla de filtrado de red.

CHET.  Bueno, eso es útil para ayudarnos a pasar los próximos días mientras Microsoft nos brinda una solución permanente.

La buena noticia es que creo que una gran cantidad de software de seguridad, ya sea un IPS que puede integrarse en su firewall, o productos de seguridad de punto final que tiene para proteger su infraestructura de Microsoft Windows Server...

…los ataques para esto, en muchos casos (al menos en los primeros informes), se parecen mucho a ProxyLogon y, como resultado, no está claro si las reglas existentes protegerán contra estos ataques.

Es posible, pero además de eso, la mayoría de los proveedores parecen estar tratando de ajustarlos un poco, para asegurarse de que estén lo más preparados posible, en función de todos los indicadores que se han compartido públicamente actualmente, para que detecten y enviarle alertas si esto ocurriera en sus servidores de Exchange.

PATO.  Eso es correcto, Chester.

Y la buena noticia para los clientes de Sophos es que puede realizar un seguimiento de las detecciones específicas de Sophos si desea revisar sus registros.

No solo para IPS, ya sea el IPS en el firewall o el punto final, sino que también tenemos un montón de reglas de comportamiento.

Puede rastrear esos nombres de detección si quiere ir a buscarlos... siga eso en el @SophosXops Feed de Twitter.

A medida que obtengamos nuevos nombres de detección que puede usar para la búsqueda de amenazas, los publicaremos allí para que pueda buscarlos fácilmente:

CHET.  Estoy seguro de que tendremos más que decir en el podcast de la próxima semana, ya sea que Doug se reúna con ustedes o que yo esté en el asiento de invitados una vez más.

Pero estoy bastante seguro de que no podremos poner esto a la cama por un tiempo ahora...

PATO.  Creo que, como ProxyShell, como Log4Shell, va a haber un eco que reverberará durante bastante tiempo.

Así que tal vez sea mejor que digamos, como siempre lo hacemos, Chester:

Hasta la proxima vez…

AMBAS COSAS.  Mantente seguro.

[MÓDEM MUSICAL]

Sello de tiempo:

Mas de Seguridad desnuda