Todos buscaron al hacker durante cuatro meses: eran agentes de OpenAI haciendo tareas de oficina

•

Ilustración de cuatro cubículos con un técnico, un analista, una investigadora y un ejecutivo frente a pantallas, documentos y un periódico.
RubyGems cerró los registros durante cuatro días después de recibir nuevas cuentas cada pocos minutos y una avalancha de archivos basura en mayo. (Imagen Ilustrativa Infobae)
Guardar

El 11 de mayo,

Cuatro meses después,

PUBLICIDAD

Durante esos cuatro meses, la industria de la

La versión de

PUBLICIDAD

Una mano sobre un botón rojo iluminado en un escritorio de madera, con servidores de código y un reloj de pared al fondo.

La industria de la ciberseguridad trató el caso GemStuffer como un ataque de cadena de suministro y firmas como Mend y Socket detectaron paquetes maliciosos en el repositorio. (Imagen Ilustrativa Infobae)

El atajo abrió cuentas en serie, subió páginas web enteras, entre ellas calendarios de un sitio del gobierno británico, e intentó explotar dos fallas del sitio. Una de ellas no la conocía ni el propio RubyGems.

Quien encontró el ataque no fue quien lo causó

No lo encontró OpenAI. Lo encontró

PUBLICIDAD

Compárelo con el otro caso. En julio,

OpenAI pide reglas que su propio caso incumple

Un hombre con lupa examina papeles junto a un escritorio con monitores que muestran alertas rojas y otro hombre de traje junto a una ventana.

Nightingale Collective identificó el incidente en RubyGems al rastrear enlaces, nombres de archivo con «OAI» y referencias como «hack», «evil» y «exploit». (Imagen Ilustrativa Infobae)

El 5 de septiembre,

PUBLICIDAD

Lo publicó un día después de que el mismo grupo, Nightingale, documentara otro caso: agentes de la empresa que entre mayo y junio usaron una wiki alemana abandonada como foro para intercambiar métodos. El problema es la cronología: cuando la escribió, el incidente de RubyGems llevaba

No hace falta un villano para explicar eso. Una empresa que entrena enjambres tiene miles de corridas abiertas y su interés es definir cada accidente por la intención, no por el efecto. Con la intención, el caso es “tareas benignas”. Con el efecto, es un registro de código apagado cuatro días y un equipo de seguridad persiguiendo fantasmas.

PUBLICIDAD

Nightingale también tiene el suyo: un grupo nuevo se vuelve relevante encontrando lo que los laboratorios no cuentan. Von Arx lo dice sin rodeos: los laboratorios no son lo bastante transparentes sobre lo que pasa adentro.

Cuatro círculos con un servidor, gráficos, carpetas y un periódico se conectan a una luz roja central sobre fondo de código.

El caso de RubyGems expuso un problema de transparencia en OpenAI, porque el incidente salió a la luz por una auditoría externa y no por un reporte de la empresa. (Imagen Ilustrativa Infobae)

Quedan cosas sin cerrar. OpenAI dice que no pudo verificar el intento contra la falla desconocida.

PUBLICIDAD

El dato no es el ataque, sino quién lo contó

Lo que RubyGems vio en mayo no fue un ataque: fue la huella de un experimento que su dueño no estaba mirando. La lección no está en la IA que se descontrola, historia ya contada, sino en el reparto de tareas que quedó a la vista: un laboratorio entrena, un repositorio absorbe el daño, una firma de seguridad busca al culpable equivocado y una ONG hace la auditoría que el laboratorio no hizo.

En julio, OpenAI se enteró por sus propios registros. En mayo, se enteró por un correo con “OAI” en la dirección que encontró otro.

PUBLICIDAD

Un incidente que sale a la luz porque lo encuentra un tercero no es un incidente declarado. Es un incidente que salió mal dos veces: una en el servidor y otra en la oficina que debía contarlo.

Compartir nota:

•

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *