Vulnerabilidad que permitía comprometer Arc sin visitar un sitio web

 (kibty.town)
2 puntos por GN⁺ 2024-09-20 | 1 comentarios | Compartir por WhatsApp
  • Una combinación de Boosts de Arc y problemas en las reglas de Firestore permitía que un atacante asociara a la cuenta de una víctima un Boost con JavaScript arbitrario
  • El uso de Firebase Auth y Firestore se confirmó mediante hooking con Frida, lo que reveló el flujo de acceso a las colecciones preferences, users, user_referrals y boosts
  • La vulnerabilidad surgía porque el objetivo de aplicación de los Boost se determinaba con creatorID, pero el atacante podía cambiar el creatorID de su propio documento Boost por el ID de otro usuario
  • El ID de la víctima podía obtenerse desde user_referrals, boostSnapshots de Boosts públicos, Easels compartidos y otras fuentes; cuando la víctima visitaba el sitio objetivo, el Boost malicioso podía ejecutarse
  • The Browser Company aplicó un parche y pagó una recompensa de $2,000; tras la asignación de CVE-2024-45489, decidió reducir su dependencia de Firebase, realizar auditorías de seguridad e impulsar un programa de bug bounty

Funciones en la nube de Arc y uso de Firestore

  • Arc requería una cuenta para usarse, y se confirmó que durante el registro utilizaba autenticación de Firebase
  • En la observación inicial de red no se veían otras solicitudes, pero al revisar la función para compartir Easels surgió la posibilidad de que estuviera usando Firestore
  • Easels es una interfaz tipo pizarra que puede compartirse con otras personas y verse en la web
  • Firestore es un servicio database-as-a-backend que permite construir funciones sin un backend propio, usando reglas de seguridad de la base de datos y acceso directo desde el cliente
  • Como caso previo de reglas de seguridad deficientes en Firestore, se enlaza Firewreck

Cómo se confirmó la llamada a Firebase

  • Como el SDK de Swift de Firebase tiende a no respetar la configuración del proxy del sistema, en vez de mitmproxy se usó un script de Frida para volcar las llamadas relacionadas
  • El script hacía hooking de llamadas de Firestore en clases Objective-C
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • métodos de ejecución como getDocuments, addSnapshotListener:, getDocument
    • métodos de escritura de documentos de la familia updateData, setData
  • Durante la ejecución de Arc se observaron los siguientes tipos de rutas y consultas de Firestore
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • consulta en user_referrals con inviter_id == {userID}
    • consulta en boosts con creatorID == {userID}
  • En esta estructura, Arc almacenaba en Firestore algunas preferencias, el objeto base del usuario, información de referidos y los Boosts

Por qué Boosts se convirtió en la ruta de ataque

  • Arc Boosts es una función con la que el usuario puede personalizar sitios web
    • bloqueo de elementos
    • cambio de fuente
    • cambio de colores
    • CSS personalizado
    • JavaScript personalizado
  • Los Boosts se almacenan en Firestore, y el navegador Arc consulta qué Boost aplicar usando el campo creatorID
  • El atacante creó en su propia cuenta un Boost para Google.com y luego probó modificando algunos parámetros del documento en Firestore
  • Debido a la consulta basada en creatorID, no podía consultar directamente los Boosts de otros usuarios, pero sí podía cambiar el creatorID de su propio documento Boost por el ID de usuario de otra cuenta
  • Al probarlo con otra cuenta, el Boost creado por el atacante se aplicó en la computadora de la víctima cuando esta accedió a Google.com

Cadena de ataque y obtención del ID de usuario

  • El flujo final del ataque era el siguiente
    • obtener el ID de usuario de la víctima
    • crear en la cuenta del atacante un Boost malicioso con el payload deseado
    • cambiar el campo creatorID del documento Boost por el ID de la víctima
    • cuando la víctima visitara el sitio web objetivo, el Boost malicioso se ejecutaría
  • Esta vulnerabilidad era posible porque Arc Boosts puede incluir JavaScript arbitrario, se almacena en Firestore y el destino de aplicación se decide por el campo creatorID
  • Había varias formas de obtener el ID de usuario de la víctima
    • user_referrals: si alguien invitaba a otra persona a Arc o era referido, se podía obtener el ID de usuario de la contraparte desde la tabla user_referrals
    • Boosts públicos: los Boosts sin JavaScript pueden compartirse, y en boostSnapshots del sitio público de Arc Boosts aparece incluido el ID de usuario del creador
    • Easels: la función de pizarra compartible también permitía obtener el ID de usuario

Parche y cronograma de divulgación

  • The Browser Company normalmente no hacía bug bounty, pero por esta vulnerabilidad pagó $2,000 USD
  • La línea de tiempo de la vulnerabilidad fue la siguiente
    • 25 de agosto, 5:48pm: primer contacto por Signal con Hursh, cofundador de Arc
    • 25 de agosto, 6:02pm: ejecución de la PoC de la vulnerabilidad en la cuenta de Arc de Hursh
    • 25 de agosto, 6:13pm: tras compartir los detalles en formato cifrado, se añadió al investigador a un canal de Slack
    • 26 de agosto, 9:41pm: parche de la vulnerabilidad y pago de la recompensa
    • 6 de septiembre, 7:49pm: asignación de CVE-2024-45489
  • Después, Arc publicó su propio artículo sobre el problema: CVE-2024-45489 incident response

Ejecución en páginas privilegiadas y conflicto con la privacidad

  • Aunque los Boosts no podían crearse desde el cliente, sí podían ejecutarse en otros protocolos
  • Si se creaba un Boost dirigido a la página settings, este se ejecutaba en chrome://settings, lo que podía derivar en elevación de privilegios
  • Al visitar un sitio se producía la siguiente consulta a Firestore
    • búsqueda en la colección boosts con las condiciones creatorID == {userID} y hostPattern == "www.google.com";
  • Aquí, hostPattern representa el sitio visitado, lo que entra en conflicto con la política de privacidad de Arc, donde se afirma que Arc no sabe qué sitios visita el usuario

Medidas posteriores de Arc

  • A raíz de la vulnerabilidad y de la incorporación de nuevas funciones, Arc comenzó a alejarse de Firebase
  • El resumen propio de Arc incluye las siguientes medidas
    • confirmación de la corrección del problema
    • incorporación de una función para desactivar Boosts desde el cliente
    • auditoría interna de las reglas ACL actuales de Firebase
    • establecimiento de un protocolo de respuesta a incidentes de seguridad
  • Las medidas adicionales compartidas en discusiones internas de Arc fueron las siguientes
    • corrección del problema de privacidad en la actualización v1.61.1
    • dejar de usar Firebase en nuevas funciones y productos
    • auditoría de seguridad externa para esa versión
    • inicio de un programa de bug bounty para futuras vulnerabilidades

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-20
Opiniones en Hacker News

  • Soy Hursh, cofundador y CTO de The Browser Company, la empresa que hace Arc. No hubo usuarios afectados en la práctica y lo parcheamos de inmediato, pero considero que la gravedad potencial de esta vulnerabilidad es inaceptable.
    Aquí resumimos los detalles técnicos, los planes de mejora a futuro, la salida de Firebase y la creación de un programa formal de bug bounty: https://arc.net/blog/CVE-2024-45489-incident-response
    Lamento mucho tanto la vulnerabilidad en sí como la comunicación tardía, y los comentarios —incluyendo decepción, enojo y aliento— nos hacen asumir la responsabilidad de mejorar.

    • Me pregunto si este texto fue escrito solo para que lo vean los usuarios de HN. No aparece en la lista del blog (https://arc.net/blog) ni fue publicado en Twitter.
      Toda la respuesta parece ser del tipo “solo reaccionamos cuando el ruido es suficiente”.
    • A varios amigos les gusta Arc y yo mismo estaba considerando cambiarme, pero ahora pienso no usarlo. No tanto por la vulnerabilidad en sí, sino porque pagaron apenas USD 2.000 de recompensa por un bug que podía comprometer peligrosamente a todos los usuarios.
      No quiero usar un navegador hecho por una empresa que se toma tan a la ligera la seguridad de sus usuarios. No puedo asegurarlo, pero con este nivel de gravedad probablemente se habría vendido por mucho más en el mercado negro.
    • En los comentarios de abajo hay preocupación de que, en cada carga de página, se esté enviando a TBC la URL junto con un ID de usuario identificable. Quienes usan navegadores que no son Chrome suelen ser bastante sensibles a la privacidad, así que convendría responder a este punto.
      Las vulnerabilidades pueden ocurrir, pero enviar datos de navegación parece una decisión de diseño intencional.
    • Después de ver esto, no parece haber forma de convencerme de que el equipo tenga la experiencia necesaria para mantener un navegador. Más allá de que lo hayan corregido, no parecen tener ahora ni a futuro la capacidad de crear un navegador seguro.
      Creo que es un caso en el que el CTO debería renunciar.
    • Me pregunto si planean aumentar los montos de las recompensas. USD 2.000 es muy poco comparado con el valor de este bug, y espero que le paguen al descubridor una compensación adecuada.
      Se les presentó una oportunidad excelente para encaminarse en la dirección correcta.

  • En estos comentarios muchos culpan a Firebase, pero parece que repiten cosas que en realidad no conocen bien. No uso Firebase, pero por lo que probé antes, esto no es un caso extremo ni un problema difícil de resolver: es lo más básico de lo básico.
    El verdadero problema fue diseñar la API para que confiara en un valor que el cliente envía diciendo “quién soy”. Al final es un error de principiante y probablemente podía arreglarse con un cambio de una línea. Solo con ver la documentación, en https://firebase.google.com/docs/rules/rules-and-auth#cloud-... request.auth entrega el ID de usuario necesario (request.auth.uid).

    • Como alguien que opera una app hecha con Firebase, estoy de acuerdo. Tal como señaló quien escribió el post, es muy fácil equivocarse en la configuración, pero estas prácticas básicas de seguridad están resaltadas en la documentación de Firebase con advertencias grandes y visibles.
      Las reglas de seguridad deben tomarse en serio y, en la práctica, son la única línea de defensa.
    • Es interesante ver cómo los ingenieros de software pasaron de crear su propia autenticación, a dejar de crearla por su cuenta, y ahora a no darse cuenta ni siquiera de problemas de seguridad tan obvios como este.
      Ya sea que crees tu propia autenticación o no, la clave es una sola: nunca confíes en el cliente.
    • Si “al final es un error de principiante”, ojalá fuera así. Mis compañeros también cometieron exactamente el mismo error varias veces en apps frontend internas.
    • Un plan de seguridad que depende de asumir que nadie cometerá jamás un error de principiante es, en sí mismo, un error de principiante.
    • Si entendí bien, la corrección de este problema habría sido algo como poner las siguientes reglas dentro de la instrucción match de firestore.rules. Es contenido que aparece tal cual en la documentación introductoria de seguridad de Firebase Firestore. 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • Me encantó el pequeño gato de pixel art que corría hacia donde hacías clic. Era un detalle divertido e ingenioso de esos que hoy casi no se ven, y se sentía como un recordatorio de que internet también puede ser un lugar así de alegre si queremos.

    • De mi lado no lo vi; parece que el desarrollador respeta prefers-reduced-motion y no lo muestra si esa opción está activada. Excelente manejo: le da diversión a quien la quiere y evita molestias a quien no.
    • Para ser un gato de 35 años, se mueve muy bien.
      https://en.wikipedia.org/wiki/Neko_(software)
    • En Debian se puede instalar y ejecutar el gato con lo siguiente:
      sudo apt install oneko
      oneko &
      Es un buen regalo para la computadora de un compañero que se ausentó.
    • Es lindo, pero como sabía que el gato se movería cada vez que moviera el mouse o hiciera scroll, no podía concentrarme en el texto. Abrí la consola y lo eliminé. Perdón, gatito.
    • En el teléfono seguía tapando el texto, así que estaba buscando cómo quitarlo. Lo resolví con el modo lectura de Firefox.

  • Según este artículo, Arc exige una cuenta y envía a Google Firebase el nombre de host de cada página que visitas junto con tu ID de usuario. Entonces me pregunto si Arc no será el navegador con peor privacidad entre los que se usan hoy

    • Apenas lo instalé y vi que la cuenta era obligatoria, borré Arc de inmediato. Me pareció tan absurdo como un cepillo de dientes que necesita Wi-Fi, pero ahora veo que es más grave
    • Creo que ese premio se lo llevaría OperaGX
    • También me da curiosidad saber qué tan roto quedaría Arc si Firebase se cae
    • Cuando lo descargué hace unos meses y vi que necesitaba una cuenta para usarlo, tuve la intuición de que era mejor seguir usando Firefox
    • ¿No cifran los datos que envían a Firebase? Si son datos sensibles, hasta Google recomendaría hacerlo

  • Es un bug realmente genial. Las reglas de seguridad de servicios de backend como Firebase tienen valores predeterminados raros y difíciles de explicar. Si uno construyera su propia API, el userId de un registro como el boost de este caso no se recibiría desde el payload de la solicitud, sino que se establecería con el ID de usuario de la sesión
    Cualquier desarrollador por encima de cierto nivel difícilmente pensaría en permitir que el cliente envíe a una ruta de API protegida un valor que dice ser su propio userId. En cambio, con las reglas de seguridad hay que imaginar todas las formas en que el sistema puede ser mal usado, independientemente de la manera en que realmente se programó para usarse

    • Si lo planteas así, sinceramente lo estás haciendo mal. Si empiezas con denegar por defecto, solo tienes que imaginar las formas legítimas de uso
    • Para inserciones es cierto, pero en actualizaciones he visto muchas veces que se mete toda la solicitud directamente en un ORM o en un almacén de documentos. Es fácil pensar “el propietario puede actualizar el documento”, pero también es fácil pasar por alto que algunos campos que el cliente oficial no establece, como el propietario o la hora de creación, no deberían poder cambiarse
      La solución correcta probablemente sea tener permisos de denegación por defecto para todos los campos. Así, como mínimo, tendrías que declarar explícitamente que el campo de propietario es escribible, y eso te obligaría a pensar en las implicaciones de transferir este objeto a otro usuario

  • Me sorprende lo ridículamente tonta que es esta vulnerabilidad. Para ejecutar código arbitrario, literalmente solo hacía falta enviar el ID de usuario de otra persona, y ese ID además era bastante fácil de obtener
    No trabajo en FAANG ni nada parecido, sino en una empresa que hace un producto mediocre que ni siquiera es realmente necesario, pero aun así yo no cometería un bug así. Y esta gente pretende hacer un navegador y asumir la experiencia de seguridad y la responsabilidad moral que eso conlleva

    • ¿Podrías explicar cómo se podía obtener el ID de usuario de otra persona? Entiendo que es una vulnerabilidad grande, pero quiero entender cómo ocurría esa parte

  • Me gustaría que el título del post incluyera Arc para que lo reconozcan mejor quienes usan Arc o tienen conocidos que lo usan

    • Totalmente de acuerdo. La primera vez que lo vi ayer no me di cuenta de que me afectaba, y solo hice clic después de que cambiaron el título
      Sinceramente, creo firmemente que el título debería ser algo como “Bug fundamental en el navegador Arc (CVE 123-4567)”

  • En el mundo hay muchas vulnerabilidades de seguridad graves que son comprensibles, y si se manejan y corrigen responsablemente, se pueden perdonar
    Pero este no es uno de esos casos. Para mí muestra una incompetencia capaz de destruir su reputación, al punto de convencerme de no volver a usar Arc

    • Por otro lado, la velocidad de respuesta en sí fue bastante impresionante
      aug 25 5:48pm: primer contacto con Hursh, cofundador de Arc, por un canal cifrado de Signal
      aug 25 6:02pm: ejecución de la prueba de concepto de la vulnerabilidad en la cuenta de Arc de Hursh
      aug 25 6:13pm: divulgación de los detalles en formato cifrado y agregado a un canal de Slack
      aug 26 9:41pm: vulnerabilidad parcheada, recompensa pagada
      Cuatro horas desde el primer contacto inesperado hasta desplegar la corrección es bastante bueno, incluso considerando que quizá el arreglo era simple. Corrección: cambió la fecha, así que en realidad fueron 28 horas. Aun así es aceptable, y que 30 minutos después del primer contacto la respuesta fuera “entra a nuestro canal de Slack” es muy rápido
    • Que se necesitara una cuenta obligatoria incluso para probar Arc una vez ya era una gran señal de alerta desde el principio, así que ni siquiera lo probé. Ahora me alegra no haberlo usado
    • Sinceramente, siempre vi a Arc, sobre todo en términos de privacidad, como un lobo con piel de oveja
      En un producto tan importante y personal como un navegador, recibir entre 50 y 60 millones de dólares en efectivo y una valuación de 500 millones sin tener modelo de negocio es una gran señal de alerta. No es una obra de caridad, así que alguien terminará pagando de alguna forma
    • Uno tiende a pensar que una empresa que distribuye un navegador pondría algo más de atención en sus reglas de seguridad
      También es una lástima que Firebase no haya logrado hacer esto más a prueba de tontos. ¿Y de verdad solo $2,500? Literalmente se podía tomar control de todos los usuarios de Arc; la NSA le habría agregado varios ceros más
    • Y encima Firebase, en serio. Una empresa que incluso contrata ingenieros de software de bajo nivel está usando un backend CRUD empaquetado. Habrá sido eficiente en costos, pero si yo diseñara algo así, Firebase ni siquiera estaría en una larga lista de candidatos para el backend
      Sobre todo cuando competidores funcionales como Supabase envuelven un DBMS común y un modelo de autenticación

  • Gracias por compartirlo. Uso Arc desde la primera semana de la beta
    Pero me preocupa bastante que no hayan mencionado este bug ni su corrección en ninguna red social. Disfruté el tiempo usando Arc, pero viendo esta forma de manejarlo, no creo que pueda seguir usándolo

    • ¿No es suficiente que reconocieran el problema y lo arreglaran en 28 horas? Con una respuesta así me dan ganas de seguir usando Arc

  • $2,000 por una vulnerabilidad tan grande es una cantidad insultante

    • Por los posts de HN, parece que muchas vulnerabilidades de este tipo no reciben recompensa alguna o reciben montos muy bajos. Da la impresión de que las empresas les están rogando a los hackers que vendan los exploits
      Quizá sea porque los reguladores no las castigan por los incidentes de seguridad
    • Sí, esa también fue mi primera reacción. Me sorprendió muchísimo que fueran tan tacaños
    • Hace falta una conciencia bastante firme para no vendérselo a alguien malicioso que pagaría entre 20 y 50 veces esa cantidad