Adobe convirtió el código fuente y los registros de clientes en una prueba de rendición de cuentas de credenciales

Resumen

• Adobe declaró públicamente en octubre de 2013 que los atacantes habían accedido a identificadores de clientes de Adobe, contraseñas cifradas, ciertos campos de pedidos y tarjetas de pago de clientes, y código fuente de múltiples productos.
• La pregunta central de rendición de cuentas es: ¿quién tenía control práctico sobre el hash de contraseñas, el alcance de los datos de pago, el acceso al repositorio de código fuente, la orientación de restablecimiento de clientes, el momento del aviso de filtración y la prueba de que el código robado no amplió el riesgo para los clientes?
• El registro público se expandió más allá del primer recuento de clientes de Adobe, con KrebsOnSecurity informando la confirmación de Adobe de unos 38 millones de usuarios activos con contraseñas cifradas válidas en el alcance, y Have I Been Pwned incluyendo 152,4 millones de cuentas afectadas en su corpus de filtraciones.
• Los clientes, desarrolladores, administradores empresariales, equipos de respuesta de tarjetas de pago y revisores de seguridad de productos tuvieron que actuar sin ver los registros internos del repositorio de Adobe, el diseño de almacenamiento de contraseñas, la evidencia del sistema de pago o el mapa de exposición cliente por cliente.
• El registro respalda una conclusión de rendición de cuentas de alta confianza sobre los deberes de control y las brechas de evidencia. No respalda la invención de hechos privados sobre cada sistema interno, paso del atacante, compilación de productos, pérdida de clientes o cambio en el repositorio.

Registro de evidencia y cómo se utiliza

Este artículo trata el registro público como evidencia en capas, no como un relato completo único. Los registros de empresas y gobiernos se utilizan para lo que Adobe Inc. o las autoridades públicas declararon. Los materiales de acuerdos regulatorios, la investigación de seguridad, los índices públicos de filtraciones, los estándares de pago, la guía de seguridad de software y la guía de almacenamiento de contraseñas se utilizan para enmarcar los deberes de control, la cronología y las implicaciones para las partes afectadas. El análisis no trata los informes secundarios como prueba de hechos privados que el registro público no muestra.

El marco de rendición de cuentas es más estricto que la culpa y más amplio que el aviso de filtración

Adobe convirtió el código fuente y los registros de clientes en una prueba de rendición de cuentas compartida porque el caso no encajaba en un solo cubo. No fue solo una filtración de cuentas, no solo un evento de tarjetas de pago, y no solo un incidente de código fuente. El aviso de Adobe dijo que los atacantes accedieron a identificadores de clientes y contraseñas cifradas, eliminaron ciertos campos de clientes y tarjetas de pago de 2,9 millones de clientes, y accedieron al código fuente de múltiples productos. CISA repitió la preocupación por la información de clientes y el código fuente en una alerta pública.

Informes públicos posteriores y registros de índices de filtraciones hicieron que el panorama de datos de cuentas fuera mayor que el primer número. Esa secuencia importa porque la rendición de cuentas en un servicio en la nube no se mide solo por la primera declaración. Se mide por si el operador puede seguir precisando los hechos a medida que clientes, bancos, desarrolladores, administradores y reguladores toman decisiones.

La culpa suele ser demasiado contundente para este registro. Un análisis útil de rendición de cuentas pregunta quién tenía la autoridad, la evidencia, las herramientas y el deber de reducir el riesgo en cada etapa. Adobe controlaba el sistema de identidad, el aviso al cliente, la campaña de restablecimiento de contraseñas, la revisión del código fuente y la declaración pública sobre el cifrado de las tarjetas de pago. Los procesadores de pagos y los bancos controlaban partes del monitoreo de tarjetas y la protección del cliente.

Los clientes controlaban la reutilización de contraseñas, los restablecimientos de cuentas y su propio seguimiento de seguridad local. Los investigadores y reporteros proporcionaron evidencia externa que cambió la comprensión pública del evento. Los reguladores luego probaron si existían medidas razonables antes y durante el ataque.

El punto central es el control práctico. Los clientes no podían inspeccionar el diseño de almacenamiento de contraseñas de Adobe, los registros del repositorio o la red de procesamiento de pagos. Solo podían responder a las instrucciones y la evidencia que Adobe puso en el registro público. Cuando un proveedor tiene los hechos y los clientes tienen gran parte del trabajo, el proveedor tiene el deber de hacer que el registro sea claro, escalonado y verificable.

Lo que establece el registro público

El registro público establece varios puntos firmes. El propio aviso de Adobe declaró que su equipo de seguridad encontró ataques que involucraban acceso ilegal a información de clientes y código fuente. Dijo que los atacantes accedieron a identificadores de clientes de Adobe y contraseñas cifradas. Dijo que la empresa creía que los atacantes eliminaron nombres, números de tarjetas de crédito o débito cifrados, fechas de vencimiento e información relacionada con pedidos de 2,9 millones de clientes, mientras que Adobe no creía que números de tarjetas descifrados hubieran salido de sus sistemas.

Adobe dijo que estaba restableciendo las contraseñas de los clientes relevantes, notificando a los clientes cuya información de tarjeta se creía involucrada, ofreciendo monitoreo de crédito cuando estuviera disponible, notificando a los bancos de pago y trabajando con las autoridades. Adobe también dijo que no tenía conocimiento, según los hallazgos disponibles en ese momento, de un riesgo específico aumentado para los clientes derivado del acceso al código fuente.

Las autoridades públicas y los registros externos agregan otras capas. CISA advirtió a los clientes que estuvieran atentos a actividad fraudulenta en cuentas. El informe inicial de KrebsOnSecurity describió un tesoro de código fuente y reportó declaraciones de entrevistas de Adobe sobre la investigación, el posible conjunto de productos y la revisión de integridad de productos.

KrebsOnSecurity luego informó la confirmación de Adobe de que los atacantes obtuvieron acceso a identificadores de Adobe y contraseñas cifradas válidas de unos 38 millones de usuarios activos, con datos adicionales de cuentas inactivas, inválidas y de prueba aún en revisión. Have I Been Pwned luego incluyó la filtración de Adobe como 152,4 millones de cuentas afectadas e identificó correos electrónicos, nombres de usuario, contraseñas y pistas de contraseñas. Los fiscales generales estatales luego anunciaron un acuerdo multinivel que resolvía reclamaciones derivadas de la filtración de 2013.

Esos puntos son lo suficientemente sólidos para analizar los deberes. No son suficientes para afirmar hechos privados que permanecen fuera del registro público. El registro no muestra cada base de datos afectada, cada ruta de acceso interna, cada evento del repositorio, cada detalle de control de contraseñas o cada resultado de cliente. Esa incertidumbre no es una razón para ignorar el caso. Es la razón para centrarse en lo que una parte dependiente necesitaba que Adobe demostrara.

Por qué importa el objeto de confianza

El objeto de confianza en este caso no era un solo archivo. Era un conjunto de identidad de cuenta de Adobe, manejo de datos de pago y custodia del código fuente del software. Los clientes confiaban en que los identificadores de Adobe protegieran el acceso a relaciones creativas, documentales, de desarrollador, comerciales y de soporte. Los bancos y las redes de tarjetas confiaban en que Adobe supiera si los números de tarjetas estaban cifrados, si los números de tarjetas descifrados estaban excluidos y a qué procesadores se debía advertir.

Los desarrolladores y compradores empresariales confiaban en que Adobe supiera si el código fuente del producto robado cambiaba la probabilidad de futuras explotaciones o versiones manipuladas. Ese conjunto de objetos de confianza es más amplio que una base de datos de clientes.

El objeto de confianza amplio explica por qué el evento tuvo poder de permanencia. Una filtración de cuentas puede abordarse con restablecimientos de contraseñas, monitoreo de fraude y advertencias de reutilización. Un evento de tarjetas de pago requiere coordinación bancaria y de redes de tarjetas, evidencia del alcance de datos y notificación al cliente. El acceso al código fuente plantea una pregunta diferente: ¿podían los atacantes estudiar detalles de implementación, controles de seguridad, lógica de compilación o secretos incrustados de manera que cambiaran el riesgo futuro?

Adobe no necesitaba publicar detalles forenses sensibles para satisfacer a todos los clientes, pero sí necesitaba explicar los límites de esos objetos de confianza lo suficientemente bien para que otros actuaran.

Aquí es donde se vuelve visible una prueba de rendición de cuentas compartida. La palabra credencial no debe leerse solo como una contraseña. Las credenciales pueden incluir contraseñas, pistas de contraseñas, manejo de tokens de pago, acceso al repositorio de código fuente, secretos de servicio, controles de firma o compilación, y las garantías que permiten a un administrador empresarial seguir confiando en un proveedor de software. El registro público muestra claramente los lados de contraseñas y código fuente. Deja muchos detalles de prueba privados.

El almacenamiento de contraseñas convirtió la identidad del cliente en la primera carga de trabajo práctica

La primera acción de Adobe orientada al cliente fue una campaña de restablecimiento de contraseñas para cuentas relevantes. Esa fue la clase correcta de protección inmediata del cliente, pero también expuso una pregunta más profunda: ¿por qué el almacén de credenciales era un objeto de riesgo reutilizable después del robo? El anuncio de Adobe llamó a las contraseñas cifradas. El análisis público posterior se centró en el riesgo creado por el enfoque de almacenamiento de contraseñas y las pistas de contraseñas en texto plano.

Have I Been Pwned describe un corpus posterior que contiene identificadores de registros de clientes, nombres de usuario, direcciones de correo electrónico, contraseñas cifradas y pistas, con una criptografía de contraseñas deficiente que facilitó la resolución de muchas contraseñas. El análisis público de Troy Hunt del conjunto de datos enfatizó que las pistas pueden revelar el mismo secreto que el mecanismo de contraseña está destinado a proteger.

El problema de rendición de cuentas no es solo si las contraseñas fueron restablecidas. Restablecer es respuesta. El almacenamiento de credenciales es prevención. Los clientes no tenían capacidad práctica para elegir el método de hash de Adobe, el uso de sal, el factor de trabajo, el diseño de pistas, la práctica de retención o el sistema de verificación. Solo podían evitar la reutilización de contraseñas, responder a los avisos de restablecimiento y cambiar contraseñas en otros lugares. Eso significa que el deber de control de Adobe estaba aguas arriba del usuario.

Una buena práctica de almacenamiento de contraseñas trata la base de datos robada como un escenario para el que hay que planificar, no como un caso extremo que gestionar después del hecho.

La guía moderna de NIST y OWASP ayuda a explicar la clase de control. Un proveedor que posee verificadores de cuentas debe protegerlos con diseños destinados a resistir ataques fuera de línea y debe evitar patrones de recuperación de cuentas que revelen secretos de usuario. El caso de Adobe de 2013 sigue siendo útil porque muestra el costo de tratar los registros de credenciales como datos de cuentas ordinarios. Una vez copiados, el conjunto de datos se convierte en una ayuda de ataque a largo plazo en todos los servicios, especialmente donde los usuarios reutilizaron contraseñas.

El alcance de las tarjetas de pago requería evidencia, no solo tranquilidad

El aviso inicial de Adobe separó los datos de tarjetas cifrados de los datos de tarjetas descifrados. Esa distinción era central. La empresa dijo que los atacantes eliminaron números de tarjetas de crédito o débito cifrados, fechas de vencimiento e información de pedidos de 2,9 millones de clientes, pero que Adobe no creía que se hubieran eliminado números de tarjetas descifrados. Adobe también dijo que notificó a los bancos que procesaban pagos de clientes para que pudieran trabajar con compañías de tarjetas y bancos emisores.

Por lo tanto, el registro público colocó el riesgo de pago en un recuadro más estrecho que el riesgo de datos de cuentas, pero el recuadro aún requería evidencia.

La rendición de cuentas de los datos de pago no termina con la palabra cifrado. Las preguntas responsables son qué sistemas contenían datos de tarjetas, qué campos se almacenaban, cómo se protegían las claves de cifrado, si los atacantes podían intentar descifrar, si los procesadores y adquirentes recibieron suficientes detalles y a qué clientes se les dijo que vigilaran el uso indebido.

El anuncio del acuerdo del Fiscal General de Ohio luego describió un hallazgo de que Adobe supo que un atacante intentaba decodificar números de tarjetas de pago cifrados de clientes y que el atacante había comprometido un servidor web y lo había utilizado para acceder a otros servidores. Ese relato regulatorio público hizo que la historia del control de pagos fuera más concreta que el primer aviso solo.

Los materiales de PCI DSS son útiles aquí no porque decidan la responsabilidad de Adobe en este artículo, sino porque nombran el ecosistema. Las entidades que almacenan, procesan, transmiten o pueden afectar los datos de titulares de tarjetas están dentro de una red de comerciantes, procesadores, adquirentes, emisores y proveedores de servicios. En esa red, la evidencia de pago de un proveedor de software en la nube no es solo para su propio archivo legal. Es la base para el monitoreo descendente, las notificaciones a clientes, las decisiones de reemplazo de tarjetas y la respuesta al fraude.

El código fuente era un riesgo de confianza del producto, no solo propiedad intelectual

El robo de código fuente a menudo se presenta como robo de propiedad de la empresa. En este caso, la pregunta de riesgo para el cliente era más amplia. Los productos de Adobe incluían software creativo, de documentos, de servidor y de aplicaciones web ampliamente implementados. KrebsOnSecurity informó que el material de código fuente expuesto parecía incluir ColdFusion y Acrobat, y reportes posteriores sugirieron que el código fuente de Photoshop también estaba en el alcance. HKCERT advirtió que el acceso ilegal al código fuente podría ayudar a los atacantes a estudiar productos y encontrar vulnerabilidades durante un período más largo.

El propio aviso de Adobe dijo que no tenía conocimiento de un riesgo específico aumentado para los clientes derivado del incidente de código fuente según los hallazgos disponibles en ese momento.

La brecha entre esas declaraciones es el espacio de rendición de cuentas. Es posible que el código fuente sea robado sin que se demuestren versiones manipuladas, exploits de día cero o compromiso de clientes. También es posible que el código fuente robado aumente el riesgo futuro al dar a los atacantes un mejor conocimiento de los detalles de implementación, las suposiciones de seguridad y los aspectos internos del producto. Un registro público responsable no necesita publicar detalles específicos sensibles del código fuente.

Sí necesita decir cómo la empresa verificó la integridad de la compilación, el acceso al repositorio, las confirmaciones anómalas, los secretos incrustados y el historial de versiones del producto.

El Marco de Desarrollo de Software Seguro del NIST ayuda a nombrar los deberes del productor. Proteger el software incluye proteger los entornos de desarrollo y los artefactos de software contra manipulaciones y acceso no autorizado. Responder a las vulnerabilidades incluye identificar debilidades residuales y comunicarse con los consumidores. Las páginas posteriores de PSIRT y boletines de seguridad de Adobe muestran la estructura continua a través de la cual los clientes reciben información de seguridad de productos.

La pregunta de 2013 era si la evidencia del código fuente detrás de esa confianza era lo suficientemente sólida para los clientes dependientes.

El reloj del aviso cambió lo que los clientes podían hacer

El registro de tiempos importa porque la divulgación transfiere trabajo. El anuncio público inicial de Adobe se produjo el 3 de octubre de 2013. La alerta de CISA el mismo día impulsó la concienciación pública hacia los clientes. El primer aviso proporcionó un recuento inicial de clientes y describió restablecimientos de contraseñas, notificaciones a bancos de pago y revisión de código fuente.

Más tarde en octubre, KrebsOnSecurity informó la confirmación de Adobe de que alrededor de 38 millones de usuarios activos con contraseñas cifradas válidas estaban afectados, junto con datos de cuentas inactivas, inválidas y de prueba que aún se investigaban. Have I Been Pwned luego reflejó un corpus de filtración público mucho más grande.

Esa ampliación no significa automáticamente que el primer aviso fuera malo. Los avisos tempranos a menudo son escalonados porque las empresas aún no conocen el alcance completo. Pero el aviso escalonado tiene un deber de claridad. Los clientes necesitan saber qué hechos están confirmados, cuáles aún se están midiendo y qué acciones deben tomarse incluso antes de que se conozca el recuento final. El primer aviso de Adobe advirtió adecuadamente a los clientes que cambiaran las contraseñas reutilizadas en otros lugares.

Ese consejo fue especialmente relevante porque el registro público posterior destacó un gran corpus de credenciales y pistas de contraseñas.

El estándar de rendición de cuentas no es la perfección instantánea. Es una comunicación oportuna que se actualiza a medida que la evidencia se consolida. Un cliente que intenta proteger un identificador de Adobe, una contraseña reutilizada o un patrimonio de software empresarial necesitaba saber si debía tratar el evento como un problema estrecho de tarjetas de pago, un problema amplio de identidad, un problema de fuente de producto o los tres. La respuesta fueron los tres, con diferentes niveles de prueba para cada parte.

La orientación de restablecimiento de clientes era necesaria pero incompleta por diseño

Los restablecimientos de contraseñas son una de las pocas acciones de cliente que un proveedor puede realizar de inmediato. Adobe restableció las contraseñas de los clientes relevantes y les indicó que cambiaran las contraseñas en otros sitios web donde se hubiera utilizado el mismo identificador de usuario y contraseña. Esa orientación abordó el daño posterior más predecible: la reutilización de credenciales. La orientación también revela la asimetría de una filtración de cuentas en la nube. Adobe poseía el almacén de identidad. Los usuarios soportaban la carga de cambiar las contraseñas reutilizadas en todo Internet.

La orientación de restablecimiento es necesaria porque convierte un aviso abstracto en acción. Es incompleta por diseño porque no puede decirle a cada cliente dónde reutilizó una contraseña, si una pista expuso otro secreto, si una cuenta antigua seguía siendo significativa o si un administrador de identidad empresarial tenía cuentas inactivas vinculadas a adquisiciones, licencias o soporte. Para los consumidores, el trabajo era higiene de seguridad personal.

Para las organizaciones, el trabajo podía incluir inventario de cuentas, revisión de administradores, verificaciones de proveedores de identidad, comunicación con el servicio de asistencia y educación de usuarios.

La calidad de la orientación de restablecimiento debe juzgarse por si le dice a las personas qué hacer ahora, qué vigilar después y qué incertidumbre persiste. El aviso de Adobe incluía instrucciones inmediatas de restablecimiento, advertencias de reutilización y contexto de monitoreo de pagos.

Los registros públicos posteriores muestran por qué un registro de seguridad de cuentas más sólido habría ayudado: los clientes necesitaban entender las pistas de contraseñas, las categorías de cuentas, los registros activos versus inactivos y la diferencia entre la primera población de tarjetas afectadas de Adobe y el corpus de datos de cuentas más grande.

Los administradores empresariales tenían un problema diferente al de los clientes individuales

Un cliente individual podía cambiar una contraseña de Adobe y monitorear una cuenta de tarjeta. Un administrador empresarial tenía que hacer un conjunto diferente de preguntas. ¿Qué identificadores de Adobe estaban vinculados a licencias de software, adquisiciones, soporte, almacenamiento en la nube, flujos de trabajo de publicación, colaboración creativa o cuentas de desarrollador? ¿Estaban afectadas cuentas de administrador? ¿La reutilización de contraseñas conectaba cuentas de Adobe con correo electrónico corporativo, rutas de recuperación de inicio de sesión único o portales de proveedores?

¿Estaban los equipos de soporte preparados para phishing que hiciera referencia a la filtración? ¿Estaban capacitados los empleados para evitar enlaces de restablecimiento falsos?

El registro público no proporcionó un mapa administrativo por inquilino, y no podría haberlo hecho en un aviso general. Pero el incidente muestra por qué los clientes empresariales necesitan avisos de proveedores que separen el consejo de nivel consumidor de la evidencia de nivel administrador. Los restablecimientos de contraseñas importan, pero las empresas también necesitan inventarios de cuentas, exposición basada en roles, cambios de autenticación, notificación de dominio y una forma de confirmar si las cuentas privilegiadas estaban afectadas. Esas necesidades eran especialmente agudas porque Adobe no era solo un sitio web casual.

Era un proveedor de software con cuentas en la nube, herramientas creativas, herramientas de documentos y dependencias de seguridad de productos.

Por lo tanto, el problema de rendición de cuentas es compartido pero desigual. Adobe tenía los hechos sobre la filtración. Los clientes empresariales tenían los hechos sobre su propio uso de cuentas. Un registro compartido más sólido conectaría ambos: criterios de cuentas afectadas, orientación para administradores, patrones sospechosos de phishing y declaraciones claras sobre lo que Adobe podía y no podía verificar. Sin eso, los clientes tienen que traducir un aviso general en su propio plan de control.

La soberanía y localidad de los datos aparecieron a través de la red de avisos

El registro de Adobe era global, aunque gran parte del registro de ejecución pública era norteamericano. Adobe tenía clientes en todas las regiones, productos y líneas de servicio. CISA publicó una alerta de Estados Unidos. HKCERT publicó un aviso de Hong Kong advirtiendo a los usuarios sobre el mismo evento, incluido el riesgo de phishing y el riesgo a largo plazo del código fuente robado. Los fiscales generales estatales luego resolvieron reclamaciones de protección al consumidor y privacidad en un acuerdo multinivel.

El resultado es un ejemplo útil de cómo una filtración de servicios en la nube cruza los sistemas locales de rendición de cuentas.

La soberanía de datos en este caso no se trata solo de dónde estaban los bytes. Se trata de qué autoridad pública tenía la capacidad de advertir a las personas afectadas, qué leyes regían el aviso, qué clientes recibieron monitoreo de crédito, qué bancos o redes de tarjetas actuaron y qué organismos regionales de seguridad tradujeron el evento en consejos. El cliente ve una cuenta de Adobe. El registro de rendición de cuentas pasa por aviso de la empresa, alerta cibernética federal, acción regulatoria estatal, informes independientes y orientación regional de CSIRT.

Ese patrón importa para cualquier servicio global en la nube. La arquitectura interna de un proveedor puede ser centralizada, distribuida o subcontratada, pero las partes afectadas reciben el riesgo a través de canales locales. Necesitan un aviso que sobreviva a través de esos canales. Si una empresa dice que los datos de tarjetas estaban cifrados, los reguladores y bancos locales aún necesitan suficiente evidencia para decidir cómo actuar.

Si una empresa dice que el código fuente no creó un riesgo específico aumentado, los organismos de seguridad regionales aún necesitan suficiente contexto para advertir a los usuarios sin crear certeza falsa.

Los informes secundarios cambiaron el registro utilizable

El papel de KrebsOnSecurity en el registro de Adobe es importante porque la comprensión pública de la filtración no se construyó solo a partir del anuncio de Adobe. El informe inicial de Krebs describió el descubrimiento de un gran tesoro de código fuente y reportó declaraciones de entrevistas de Adobe sobre la investigación. El seguimiento posterior de Krebs informó que Adobe había confirmado que alrededor de 38 millones de usuarios activos con contraseñas cifradas válidas estaban en el alcance y que aún investigaba datos de cuentas inactivas, inválidas y de prueba.

Have I Been Pwned y Troy Hunt luego proporcionaron al público una visión duradera de los datos de cuentas y las pistas de contraseñas.

Esto no convierte a las fuentes secundarias en un sustituto de la evidencia propia de Adobe. Pero sí muestra por qué los informes independientes y los índices de filtraciones pueden ser vitales en un incidente de alta asimetría. Los clientes a menudo conocen la forma de un evento a través de una mezcla de declaraciones de la empresa, hallazgos de reporteros, datos públicos de filtraciones y alertas gubernamentales. Cuando esas fuentes divergen, el proveedor debe reconciliarlas de una manera que las partes afectadas puedan entender.

Si el primer número de clientes es de 2,9 millones para registros relacionados con pagos y un recuento posterior de usuarios activos es mucho mayor para credenciales de cuentas, la diferencia debe explicarse en términos sencillos.

Por lo tanto, el caso Adobe también es un caso de comunicación. Un proveedor debe esperar que la evidencia externa desafíe o refine su primera declaración. La respuesta correcta no es la actitud defensiva. Es un mapa más preciso de categorías de datos, estado de cuentas, validez de contraseñas, alcance de tarjetas de pago, alcance de código fuente e incógnitas restantes.