Investigador descubre que una falla en el sitio web de a16z expuso algunos datos de la empresa

 (kibty.town)
1 puntos por GN⁺ 2024-07-21 | 1 comentarios | Compartir por WhatsApp
  • Un investigador de seguridad descubrió que, en el subdominio relacionado con a16z portfolio.a16z.com, todo el process.env de una instancia de Heroku estaba incluido dinámicamente en JavaScript
  • Los valores expuestos incluían varias credenciales de servicios, como DATABASE_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, MAILGUN_API_KEY, entre otras
  • El investigador dijo que, durante una revisión general con lunchcat para encontrar secretos en archivos JS, detectó una referencia a claves de AWS y que era posible confirmarlo solo con la pestaña Sources de las herramientas de desarrollo del navegador
  • El alcance del impacto incluía una base de datos con PII, AWS, Salesforce y Mailgun; además, afirmó que Mailgun permitía enviar correos arbitrarios desde el dominio de a16z y leer correos anteriores
  • a16z no pagó la recompensa del bug bounty argumentando que el investigador intentó contactarlos públicamente; el investigador dijo que el sitio principal no tenía datos de contacto y que el correo que encontró rebotó

Variables de entorno reveladas durante una revisión de subdominios

  • El investigador dijo que encontraba objetivos buscando empresas en Twitter y haciendo pruebas de penetración rápidas, y que usa con frecuencia la pestaña Relevant People
    • En este caso, la ruta fue: empresa relacionada con crypto → firma de capital de riesgo crypto → a16z crypto → a16z
  • Durante la investigación de a16z, realizó un escaneo de subdominios general y usó la herramienta lunchcat para revisar dominios y detectar secretos en archivos JS
  • portfolio.a16z.com parecía ser una herramienta de gestión de portafolio para empresas pertenecientes a a16z, y durante la revisión se detectó una referencia a claves de AWS en alguna parte del sitio web
  • Dentro del JS había valores que parecían corresponder a todo el process.env de la instancia de Heroku, incluidos de forma dinámica
    • Entre los elementos incluidos estaban MARKETPLACE_URL, DATABASE_URL, SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, SESSION_SECRET, MAILGUN_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, COOKIE_SECRET, HEROKU_POSTGRESQL_CRIMSON_URL, entre otros
    • El investigador verificó rápidamente las credenciales y dijo que no parecían falsas, sino credenciales reales
    • Explicó que el acceso consistía simplemente en abrir la pestaña Sources en las herramientas de desarrollo del navegador

Alcance potencial de la exposición y polémica por el bug bounty

  • Los servicios que el investigador enumeró como potencialmente comprometidos fueron los siguientes:
    • Base de datos: dijo que contenía PII
    • AWS: se mencionó la posibilidad de acceso mediante las claves expuestas
    • Salesforce: no lo verificó directamente y agregó que los permisos de la cuenta podrían ser limitados
    • Mailgun: dijo que era posible enviar correos arbitrarios desde el dominio de a16z y también leer correos anteriores
    • También mencionó que podría haber más
  • a16z no pagó la recompensa del bug bounty porque el investigador no los contactó en privado y, en cambio, intentó contactarlos públicamente
  • El investigador dio dos razones para haberlos contactado públicamente:
    • No pudo encontrar un contacto utilizable en el sitio principal de a16z
    • El correo que envió a una dirección que sí logró encontrar rebotó
  • Se adjunta como referencia un artículo de TechCrunch, donde se indica que Lorenzo vio el tuit que el investigador publicó para intentar contactar a a16z, se comunicó con él y escribió el artículo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-21
Opiniones en Hacker News

  • Cuando publicamos nuestro proyecto open source (https://github.com/heyPuter/puter/), Eva hizo pruebas de penetración bastante exhaustivas y manejó los reportes de vulnerabilidades de forma muy profesional.
    En ese momento ni siquiera teníamos un programa de bug bounty y no pidió ninguna recompensa. Eva es una hacker excelente y responsable, así que a16z debería tratarla mejor.

  • Una vez cometimos un error parecido.
    Usábamos un CMS de Node.js llamado apostrophecms, y usamos el panel de administración llamado global settings para gestionar claves de API del servidor de autenticación. Solo meses después nos dimos cuenta de que esos valores se imprimían en el código fuente HTML.
    Estaba hecho así para que se usaran desde JavaScript y estaba en la documentación, así que no los culpo, pero nosotros lo pasamos por alto.
    Lo más molesto es que pagamos bastante a una gran consultora para una prueba de penetración y tampoco lo detectaron. Al final lo descubrimos nosotros mismos y, al revisar los logs, no parecía haber señales de abuso, pero fue una filtración bastante impactante.

    • Por esa prueba de penetración, al menos pediría un reembolso.
      Hasta ahora, ninguna prueba de penetración que haya visto ha sido más que llenar casillas.
    • Lamento mucho que hayas tenido una exposición inesperada usando ApostropheCMS.
      Como dijiste, esta forma de compartir datos estaba documentada, pero aun así podía sorprender.
      Para quienes investiguen esto en el futuro, agrego que la versión principal de Apostrophe que actualmente tiene soporte ya no funciona de esa manera.
      Inyectar datos en el frontend para usuarios no autenticados ahora requiere que el desarrollador lo elija explícitamente; se cambió así para evitar este tipo de sorpresas.
      Dicho eso, todavía existen casos de uso en los que una clave de API debe incluirse como parte de la configuración y el contenido de ciertos widgets.
      Como referencia, soy responsable de diseño de Apostrophe y también tengo un rol de ingeniería.
    • Me da curiosidad por qué usaron un sistema de gestión de contenidos basado en web para gestionar secretos.
    • Corrección: no intento culpar a apostrophe cms.
      Esta situación se dio por nuestra configuración multi-tenant y por nuestra falta de comprensión de apostrophe.
    • Dijiste “no los culpo porque estaba en la documentación; nosotros lo pasamos por alto”, pero aun así deberían culparlos.
      Documentar un comportamiento peligroso no exime de responsabilidad, y creo que esta lección ya debería estar ampliamente asumida.

  • Si creas un servicio nuevo y le pones un certificado de LetsEncrypt al servidor con ACME, los logs se llenan de inmediato de solicitudes basura.
    Se ven claramente bots buscando valores por defecto inseguros que algún desarrollador podría haber dejado abiertos, e incluso he visto solicitudes al archivo de entorno del proceso.
    No sé cómo una vulnerabilidad así no fue descubierta o explotada, y puede que a16z haya tenido mucha suerte o que ya haya sido explotada pero no se haya hecho público.
    Resultó que primero los contactó una investigadora de buena fe o alguien aburrido con mentalidad white hat, y aunque es una lástima que no haya un marco legal para este tipo de negligencia, creo que a16z debería recibir una multa grande.

    • “¿Cómo puede ser que una vulnerabilidad así no se haya descubierto o explotado?”
      Quizá sí ocurrió.
      Tal vez valía más dejar esto abierto que romperlo sin más.
    • Para ser justos, el sitio principal en sí no parece tan interesante.
      Pero algunas credenciales tipo OKTA sí se ven bastante peligrosas.

  • La parte de “no dimos bug bounty porque se contactó públicamente; la razón fue que el sitio principal no tenía datos de contacto y el engineering@a16z.com que encontró rebotaba” parece un life hack ingenioso para ahorrarle dinero a la empresa.
    Si eliminas cualquier forma de contactar en privado al equipo de ingeniería, todos los reportes de bug bounty se hacen públicamente y entonces no tienes que pagar nada.

    • Ingenioso en varios sentidos.
      Seguro también ahorraron muchísimo en desarrollo contratando gente por dos pesos en sitios como fiverr, y si un grupo ruso de ransomware los vacía fácilmente, también podrían ahorrarse indirectamente un montón en costos contables.
    • Pero eso entrena al próximo investigador de seguridad a vender la información en lugar de reportarla.
    • La empresa no necesita hacer ningún “hackeo” aparte para no pagar.
      Si no hay un programa público de bug bounty, no deben nada.
      Además, al pie de https://a16z.com/connect hay una dirección de correo de contacto, que la investigadora convenientemente pasó por alto.
      Parece que buscaba visibilidad más que una divulgación responsable.
    • Si esto se repite, se harán conocidos como un lugar que no paga recompensas, y será menos probable que la gente reporte los problemas que encuentre.
    • Si hubiera publicado en HN preguntando cómo contactar a ingeniería de a16z, creo que habría tenido bastante éxito.

  • Cuando las empresas dicen que “las hackearon”, ahora me suena a una expresión corporativa para decir “no protegimos bien credenciales importantes, pero queremos que culpen a una entidad anónima a la que llamamos ‘hacker’”.

    • Si dejaste la puerta de entrada abierta de par en par por accidente y alguien se llevó todas tus cosas, igual dirías que “te robaron”.
      Hay distinciones legales como “allanamiento”, “robo” o “entrada no autorizada”, y que la puerta estuviera abierta puede influir en la ilegalidad o el castigo, pero en el lenguaje cotidiano sigue siendo un robo.

  • Es bastante deplorable que ni siquiera paguen una recompensa de monto simbólico por un agujero tan amplio.

    • La próxima vez que alguien encuentre sus claves, tal vez vea este post y, en vez de reportarlo, las suba a un repositorio público de GitHub.

  • Están ocupados escribiendo enormes white papers de arquitectura de IA generativa.
    Déjenlos descansar un poco; están soñando con un futuro mundo de agentes donde se mueven chatbots a medio hacer.
    Mientras el mundo arde por una actualización de software rota.

    • El mundo ya arde por los efectos del cambio climático.
      La actualización de software rota del viernes fue la cereza del pastel.
    • “engineering@a16z.com rebotaba”
      No me sorprende en lo más mínimo.

  • Si de verdad se podía acceder a la instancia de Salesforce, como fundador me habría puesto muy nervioso.
    Normalmente en lugares como Salesforce quedan registrados correos, y ahí pueden permanecer planes de financiación o planes de M&A que los fundadores de empresas del portafolio no han compartido externamente.

    • Recolectar claves desde el código fuente público de una página web es legal y puede reportarse de forma segura.
      Pero acceder con esas claves a sistemas sin autorización es un delito.
      La diferencia es enorme.
    • Si incluye información de LPs, eso también podría ser un daño bastante grande.

  • El hecho de que esta firma de VC no haya pagado un bug bounty por un agujero de seguridad tan grande no inspira confianza.

  • Los moderadores de HN cambiaron el título por uno menos vergonzoso.
    No sorprende.

    • Parece que mi comentario también era demasiado crítico con a16z.
      No cambió su puntaje, pero pasó de estar arriba de todo a estar al final.
      Qué variedad de formas de ofrecer una respuesta.