Se está formando otro alboroto en Twitter, pero esta vez es un investigador de seguridad haciendo ruido en lugar de un excéntrico multimillonario. [Peiter Zatko] trabajó como jefe de seguridad de Twitter durante poco más de un año, desde noviembre de 2020 hasta enero de 2022. Es posible que conozca mejor a Zatko como [Mudge], un reconocido investigador de seguridad que literalmente escribió el libro sobre desbordamientos de búfer. Fue miembro en Industrias pesadas L0pht, trabajó en DARPA y Google, y se incorporó a Twitter en respuesta al hackeo de julio de 2020 que vio a muchas cuentas de marca ejecutando escaneos de Bitcoin.
Mudge fue despedido en Twitter en enero de 2022, y parece que inmediatamente comenzó a armar una denuncia de denunciante. Puedes acceder su paquete de quejas en archive.org, con las denunciante_divulgación.pdf (PDF, y espejo) siendo el documento principal. Aquí hay algunos datos interesantes, como la respuesta real a cuántos robots de spam hay en Twitter: "Realmente no lo sabemos". La afirmación muy pública de que “…<5% de mDAU informados para el trimestre son cuentas de spam” es un poco manual, ya que el recuento de usuarios activos diarios monetizables se define esencialmente como cuentas activas que no son bots. Quizás el Sr. Musk tenga una queja más legítima de lo que se pensaba anteriormente.
Más del 30% de las computadoras de los empleados de Twitter tenían actualizaciones de seguridad deshabilitadas en algún nivel, y aproximadamente la mitad del personal de Twitter tenía acceso a los sistemas de producción. En un momento, [Mudge] sintió la necesidad de "sellar el entorno de producción", temiendo el vandalismo de un ingeniero interno en respuesta a la agitación política. Para su asombro, no había nada para prevenir, o incluso rastrear, ese tipo de ataque. Otro descubrimiento preocupante fue la falta de un plan de desastres en torno a una falla de varios nodos. Los detalles están redactados, pero una cierta cantidad de centros de datos que se caen con gracia al mismo tiempo paralizarían la infraestructura de Twitter durante semanas o más, con la nota de que volver al servicio sería un desafío de dificultad desconocida. Curiosamente, este escenario exacto casi eliminó a Twitter de forma permanente en la primavera de 2021. Señalaré aquí que esto también implica que Twitter podría sufrir un escenario de cerebro dividido si se interrumpiera la conectividad de red entre sus centros de datos. Este es un efecto en los sistemas de alta disponibilidad donde varios sistemas se ejecutan en modo maestro y el conjunto de datos compartido converge.
Hubo un extraño rechazo, como la solicitud de que [Mudge] diera oralmente su descripción general inicial de los problemas y que no enviara el informe escrito a los miembros de la junta. Nunca es una buena señal cuando recibes una solicitud no poner algo por escrito. Más tarde, [Mudge] contrató a una empresa externa para preparar informes sobre qué tan bien estaba Twitter combatiendo el problema del spam y los bots. Los ejecutivos de Twitter contrataron a un bufete de abogados, dirigiendo los informes primero al bufete, donde se eliminaron los detalles más vergonzosos y solo luego se los entregaron a [Mudge]. Asombroso.
Un sistema de cara interna para los ingenieros de Twitter estaba viendo casi 3,000 inicios de sesión fallidos diarios. Nadie sabía por qué, y nunca se abordó. Las estaciones de trabajo de los empleados no tenían copias de seguridad en funcionamiento, y la respuesta de los ejecutivos fue que al menos esto les daba una excusa razonable para no cumplir con las solicitudes oficiales de registros. A principios de este año, Twitter tenía aproximadamente 10,000 4 servicios que pueden tener vulnerabilidades de LogXNUMXj y ningún plan viable para abordar las posibles vulnerabilidades. Si querías una recompensa por error de Twitter, este parece un gran lugar para comenzar.
Las cosas no mejoraron. [Mudge] trató de hacer sonar el silbato internamente, sobre lo que consideró un informe fraudulento presentado el 16 de diciembre a la junta directiva de Twitter. Este esfuerzo se filtró a través de la estructura interna de Twitter durante un mes, y el 18 de enero declaró que había un informe preciso (PDF, y Espejo PDF) casi listo para presentar a la junta. En un aparente intento desesperado de evitar que se entregue este informe, [Mudge] fue despedido al día siguiente, 19 de enero.
Mi respuesta inicial está bien resumida por Martin McKeay, irónicamente en Twitter.
Dada la posibilidad de elegir entre creer en Mudge y en casi cualquier director ejecutivo de los EE. UU., voy a elegir a Mudge.
— Martín McKeay (@mckeay) 23 de agosto de 2022
Y cuando busca una disidencia bien razonada, Robert Graham suele ser una buena fuente. No decepciona en este tema., argumentando que, si bien muchas de las preocupaciones de [Mudge] son válidas, el paquete general es exagerado. Señala varias secciones de la denuncia que son declaraciones de opinión en lugar de declaraciones de hechos, y afirma: "Lo hace parecer un Santo Cruzado que lucha por una causa, en lugar de una parte neutral que brinda su experiencia profesional".
Navegador en la aplicación
Las aplicaciones de iOS y Android han adquirido un nuevo hábito: abrir enlaces en la propia aplicación en lugar de abrirlos en su navegador principal. Puede que no hayas pensado nada sobre el navegador integrado en la aplicación, pero [Felix Krause] seguro que tiene. Mira, cuando una aplicación ejecuta su propio navegador, esa aplicación es la que manda ahora. ¿El desarrollador quiere inyectar algo de CSS o JS en un sitio, o en todos los sitios? No hay problema. Y aquí, HTTPS no te salvará. Pero seguramente ninguna de las aplicaciones populares aprovecharía esto, ¿verdad?
Eso nos lleva a inappbrowser.com. Envía ese enlace a ti mismo y ábrelo en la aplicación. Busca objetos JS extraños o peligrosos conocidos y enumera todo lo que encuentra. Tenga en cuenta que no todo el código inyectado es malicioso, podría ser simplemente crear un tema en una página o agregar funcionalidad al contenido ya existente. Hay algunas aplicaciones que parecen particularmente problemáticas, como Instagram, Facebook y TikTok. TikTok, para sorpresa de nadie, captura cada toque de pantalla y cada pulsación de teclado mientras usa el navegador de la aplicación Inn. Y aunque la mayoría de los demás navegadores integrados en la aplicación tienen un botón para abrir en su navegador principal, TikTok lo deja fuera, lo que hace que sea aún más difícil escapar de su jardín. Estos problemas se observaron específicamente en iOS, pero es muy probable que existan problemas similares en las aplicaciones de Android.
Firefox en Pwn2Own
Esta historia nos llega a través de Pwn2Own Vancouver 2022, donde [Manfred Paul] demostró un ataque novedoso al navegador Firefox de Mozilla. Al encadenar múltiples vulnerabilidades de corrupción de prototipos, un ataque va desde la ejecución de código JavaScript en un sitio web hasta la ejecución de código arbitrario en la computadora host. Es un exploit de un solo clic, realmente desagradable, pero afortunadamente se demostró en Pwn2Own y se solucionó en Firefox 100.0.2. Zero Day Initiative tiene el informe para nosotros, y la primera parte detalla el primer exploit, saltando de la ejecución de JavaScript a la ejecución de código arbitrario, pero aún dentro de la zona de pruebas de procesamiento.
El punto de partida aquí es comprender que Firefox implementa algunas de sus funciones completamente dentro de JavaScript, y todo el Javascript que se ejecuta dentro del entorno limitado del renderizador se ejecuta en el mismo contexto. Una de esas funciones que se implementa en JavaScript es la espera de nivel superior, una forma de cargar un módulo de JavaScript en segundo plano. Si el módulo cargado anula el prototipo de matriz de una manera particular, se llama a esa anulación en el código de función. Una vez llamado, se filtra un identificador del módulo al código que no es de confianza. Este identificador no está diseñado para estar expuesto y las llamadas a sus funciones pueden no ser seguras. Esto permite salir del motor de JavaScript y escribir valores en ubicaciones de memoria arbitrarias, aunque todo dentro de la zona de pruebas del navegador. Otro truco inteligente se usa para ejecutar código arbitrario. Las constantes de coma flotante se almacenan en línea en los métodos de WebAssembly y son secciones ejecutables de la memoria. Por lo tanto, los fragmentos de código para ejecutar se pueden codificar como números de punto flotante y el puntero de retorno se sobrescribe para saltar al código. Esto no es práctico para una carga útil más grande, por lo que esta técnica se usa para marcar un objeto ArrayBuffer más grande como ejecutable y luego saltar a eso, lo que proporciona una ejecución arbitraria de bits de código mucho más grandes.
Segunda parte de la publicación. se trata de cómo escapar de la zona de pruebas y hacer que el código se ejecute en el sistema. Y en esta historia, se trata de la contaminación de prototipos de JavaScript hasta el final. Incluso fuera de la zona de pruebas, varios bits del navegador Firefox se implementan en JS, y hay varias interfaces a través de las cuales el código de la zona de pruebas se comunica con el proceso principal. Entonces, el código de ataque juega con el prototipo del objeto y luego necesita obtener el tab.setAttribute() función para ejecutar, donde el prototipo manipulado inyectará un atributo. La forma más fácil de lograr esto es bloquear la pestaña en cuestión y, dado que tenemos acceso arbitrario a la memoria, es trivial. El atributo que se agrega es cómo manejar un desbordamiento de texto de título, y la acción a tomar es establecer el nivel de espacio aislado de la pestaña en 0. Disimulado.
Google ha entrado en la lucha DDoS
Google tiene bastante ventaja en su límite de mitigación de DDoS, ya que detuvo con éxito el ataque HTTPS DDoS más grande registrado, manejando 46 millones de solicitudes por segundo contra uno de sus clientes. La idea de este ataque es que es computacionalmente costoso realizar un protocolo de enlace HTTPS, y si llegan suficientes conexiones nuevas al mismo tiempo, los servidores que respaldan el servicio no pueden mantenerse al día. Mantenga la presión y el servicio es totalmente inaccesible.
El verdadero desafío al tratar de detener este ataque en particular es discernir el tráfico malicioso de los usuarios legítimos. Este cliente ya había estado usando la Protección adaptativa de Google, por lo que se recopiló una huella digital del tráfico legítimo. No se han publicado los detalles exactos sobre cómo se comparó el tráfico malicioso, pero uno podría suponer que varias conexiones nuevas desde la misma dirección IP y las IP comprometidas conocidas podrían ser parte de esa solución. De todos modos, es una hazaña impresionante.
¿Qué puede salir mal? Este.
Y finalmente, señalado por el usuario [Hecker] en el Servidor Hackaday Discord, vemos el feo efecto secundario no deseado de escanear las fotos de los usuarios en busca de material ilegal. Parece que el mero hecho de hacer una copia de seguridad de las fotos en Google Photos desencadena un escaneo de este tipo, y esto se convirtió en una pesadilla para un usuario. Una fotografía tomada para un diagnóstico médico llevó a la cancelación de la cuenta y a una investigación policial, aunque el detective asignado al caso determinó que toda la situación era ridícula y que no había ocurrido ningún delito. La privacidad realmente importa, especialmente para los inocentes.
Ultimo pase
Y algunas noticias de última hora, LastPass ha publicado un aviso que detectaron un acceso no autorizado a su código fuente a través de una cuenta de desarrollador comprometida. Parece que están haciendo una investigación exhaustiva del incidente. LastPass está diseñado para que todos los secretos se almacenen en la computadora del usuario, por lo que es poco probable que los datos del usuario se hayan visto comprometidos. Aún. El único ataque al que LastPass podría ser vulnerable es la introducción de código malicioso en el complemento del navegador y las aplicaciones móviles, y una cuenta de desarrollador comprometida es, en cierto sentido, el peor de los casos, por lo que es bueno que lo hayan detectado. Estoy bastante seguro de que sus expertos están revisando su entorno de desarrollo y código base con peines de dientes finos en este mismo momento. Más la próxima semana si hay actualizaciones disponibles.
