Roba mi Bitcoin: el hype de PHP choca con la realidad

Si has pasado un rato en redes sociales de seguridad últimamente, habrás visto la afirmación: los nuevos bugs de ejecución remota de código en PHP son tan triviales que los agentes de IA ya están explotando servidores vulnerables de forma autónoma, por miles. Enjambres de ellos. Imparables. Un desarrollador se cansó del ruido y hizo algo maravillosamente directo al respecto. Montó un servidor con una versión de PHP sin parchear, escondió una clave de Bitcoin con un valor de unos quinientos dólares en un lugar al que un atacante exitoso podría llegar y publicó un enlace con una invitación de dos palabras: róbalo. Al fin y al cabo, se suponía que un exploit de PHP era algo que un chatbot podía escupir antes de almorzar. El cronómetro de la web empezó a contar. Y entonces pasó algo interesante: nada.

Pasaron las horas. Las monedas seguían ahí. La sección de comentarios se llenó de un silencio muy particular: el de decenas de personas que llevaban días insistiendo en que el exploit era pan comido y que, de repente, descubrieron motivos urgentes por los que no podían demostrarlo. Lo que pienses del truco, logró algo poco común en el debate de seguridad: convirtió una afirmación viral en algo falsable.

Un servidor diseñado para ser robado

El montaje toma su mecánica de las competiciones de capture-the-flag. La clave privada de Bitcoin no está en un archivo dentro del directorio web ni en una variable de entorno, sino que la custodia un binario print-flag accesible para la cuenta de usuario de PHP. Eso significa que un atacante exitoso necesita ejecución de código real en la máquina, no solo una fuga de información o un path traversal. Tienes que conseguir una shell, ejecutar el binario, leer la clave y vaciar la cartera antes que nadie. La versión de PHP se eligió deliberadamente de antes de los últimos parches de CVE, y todo se anunció con un alegre descargo de responsabilidad: todo el tráfico se registra y nada en la máquina debe considerarse privado.

Hay una clave de Bitcoin escondida en este servidor con un valor de unos 502 $. Es accesible para la cuenta de usuario de PHP a través del binario print-flag. Quien consiga primero la cartera, gana.

El autor incluso añadió un toque de clase: si no necesitas el dinero, considera donarlo a una organización benéfica. Y la web mostraba amablemente un contador en vivo de horas sin un hackeo exitoso, lo que convertía toda la página en un marcador. Cada hora adicional que pasaba era en sí misma un dato. En menos de un día, el contador se había convertido en la métrica de seguridad más interesante de internet, precisamente porque medía una predicción en la que mucha gente había apostado su reputación.

Por qué una recompensa de 500 $ es una máquina de falsabilidad

La mayoría de las afirmaciones en seguridad son infalsables por diseño. «Los atacantes ya están explotando esto en la naturaleza»: basado en telemetría que tú no puedes ver. «Cualquier analista junior podría convertir esto en arma en una tarde»: nunca demostrado. «Nuestros agentes encontraron exploits funcionales de forma autónoma»: confía en el vídeo de demo. No hay forma de probar un negativo, así que las afirmaciones simplemente se acumulan. El pánico es barato porque el pánico no tiene consecuencias.

Una recompensa pública con un cronómetro público cambia las cuentas. Si miles de agentes autónomos de verdad están recorriendo internet tumbando cada servidor PHP sin parchear que encuentran, entonces una máquina que anuncia exactamente esa vulnerabilidad, con un premio en efectivo y permiso explícito, debería caer en minutos. No en horas. En minutos. Los incentivos están perfectamente alineados: es legal, se fomenta y paga. Cuando el contador siguió subiendo, una afirmación concreta, la de que la explotación masiva autónoma ya estaba ocurriendo, recibió un golpe directo. Como resumió un comentarista, la narrativa de enjambres de agentes comprometiendo todo lo que ven claramente no estaba ocurriendo, o las monedas ya habrían desaparecido.

Este es un truco que vale la pena copiar en tu propio trabajo. La próxima vez que un proveedor o un influencer te diga que una vulnerabilidad se está explotando en todas partes, pregunta qué observación lo demostraría equivocado. Si no existe ninguna, no estás escuchando análisis, sino marketing. La recompensa de Bitcoin funcionó porque convirtió las sensaciones en una apuesta, y las apuestas tienen la maravillosa propiedad de poder liquidarse.

Economía del exploit: por qué los atacantes reales no juegan

Aquí está el contraargumento, y es bueno: el silencio demuestra menos de lo que parece, porque un exploit funcional para un CVE reciente vale mucho más que 500 $, pero solo como secreto. Cada vez que lanzas un exploit contra un objetivo, arriesgas que quede registrado, sea sometido a ingeniería inversa y se queme. ¿Dispararlo contra un servidor cuyo dueño ha anunciado de antemano que todo el tráfico se registra y que todo internet está mirando? Eso no es una recompensa, es una hoguera.

El hilo sacó exactamente este razonamiento desde ambos lados de la valla. Los actores ofensivos tienen objetivos de más valor que una cartera de 500 $ y no tienen interés en entregar sus herramientas a quien esté leyendo los logs. Los investigadores defensivos que tienen inteligencia privilegiada sobre las vulnerabilidades tienen una ventana de parcheo que proteger: un CEO de una empresa de seguridad dijo públicamente que su equipo tenía un RCE funcional, pero no lo iba a demostrar precisamente porque circular detalles mientras la gente todavía estaba parcheando causaría un daño real. Ambos grupos hicieron la misma cuenta: el valor esperado de reclamar las monedas son 500 dólares, y el coste esperado es quemar algo que vale mucho más. Pésimo negocio. Así que la lectura honesta de la recompensa sin reclamar no es «no existe ningún exploit». Es «nadie que tenga un exploit valora 500 $ por encima del secreto». Son conclusiones muy distintas, y solo una de ellas estaba en juicio.

La realidad de los agentes de IA

La parte más entretenida del hilo fue ver cómo las afirmaciones sobre IA chocaban con un objetivo real. Un comentarista puso cinco modelos de frontera ante el reto y publicó las pruebas. Dos modelos lo interpretaron como un desafío público legítimo, que lo era, y se pusieron manos a la obra. Uno lo marcó como una petición de ciberseguridad y redirigió al usuario a un programa de verificación. Otro se negó directamente. Uno fue bloqueado por un filtro de contenido del proveedor antes de poder responder siquiera. Así que, de cinco sistemas de última generación, dos llegaron a intentarlo y, en las primeras fases, ninguno consiguió la bandera.

Ese resultado mixto importa más que cualquiera de los extremos. El grupo reflexivo que dice «la IA nunca hackeará nada» se equivoca: los modelos sí se implicaron, y la explotación agéntica de objetivos tipo CTF con vulnerabilidades conocidas está mejorando de verdad. Pero el grupo de «los enjambres autónomos vacían todos los servidores sin parchear» estaba haciendo una afirmación mucho más fuerte, y es esa afirmación fuerte la que un honeypot público, con permiso y con premio en efectivo, pone a prueba. Mientras tanto, un conocido perfil de pentesting acababa de afirmar que había construido un PoC genérico y funcional con un chatbot en dos horas, y luego, en una coincidencia que seguro no tiene relación, pasó a promocionar su plataforma de pentesting con IA. Si esa afirmación se hubiera sostenido, la recompensa habría desaparecido antes de que el cronómetro llegara a una hora. No desapareció. Ya hemos visto este patrón: las demos y los rankings halagan capacidades que se derrumban al enfrentarse al trabajo real, que es exactamente la brecha que exploramos en por qué los benchmarks de IA no reflejan la mayor parte del trabajo real.

El caso de que el experimento estaba amañado

Antes de coronar el cronómetro como ciencia, hay una objeción técnica que merece un análisis honesto: quizá la configuración concreta del servidor no sea explotable con los CVE en cuestión. Un comentarista perspicaz lo explicó: la máquina usa el servidor CLI de PHP en lugar de una configuración CGI tradicional, limita las peticiones a 1 MiB, sirve una página esencialmente inerte y permite un límite de memoria alto. Dependiendo de en qué rutas de código vivan las vulnerabilidades, esa combinación puede cerrar las primitivas que necesita un exploit. En otras palabras, el honeypot podría ser invulnerable no porque los bugs sean difíciles, sino porque esta máquina concreta no expone la superficie vulnerable.

Si eso es cierto, el experimento sigue siendo útil: recoge intentos de prueba de concepto para configuraciones que sí son vulnerables y falsa la idea de un exploit trivial, universal y que funciona en todas partes. Pero no falsaría la existencia de un exploit funcional contra despliegues reales, que en su gran mayoría no se parecen a una caja CTF endurecida. Esta es la lección general sobre los resultados negativos en seguridad: solo son tan sólidos como la fidelidad del entorno de prueba. La ausencia de evidencia es evidencia de ausencia solo cuando de verdad estabas mirando en el lugar correcto y con los instrumentos adecuados. El cronómetro mide la capacidad de internet para hackear este servidor, lo que resulta ser una pregunta más estrecha e interesante que la que todos estaban discutiendo.

Lo que los defensores deberían llevarse en realidad

Nada de esto es un argumento para la complacencia. La ventana de parcheo después de que se publica un RCE en PHP es realmente peligrosa. Escribimos sobre por qué desenchufar el servicio fue mejor que los arreglos ingeniosos durante la última ventana de CVE de PHP, y ese consejo sigue vigente. Lo que cambia la recompensa es la calibración de tu miedo. Parchea porque los RCE expuestos a internet son existenciales, no porque un hilo te dijera que el cielo ya se estaba cayendo.

• Exige falsabilidad. Cuando alguien afirme que hay una explotación masiva en curso, pregunta qué evidencia la resolvería. Un honeypot público con cronómetro es rudimentario, pero es más riguroso que mil retuits.
• Pon tus propios canarios. Un comentarista mencionó que durante años ha tenido una cartera de Bitcoin sin cifrar en su equipo personal como cable trampa. Los canary tokens, las credenciales trampa y los archivos señuelo son sistemas de alerta temprana baratos que convierten la pregunta «¿estoy comprometido?» de una cuestión de sensaciones en una cuestión de telemetría.
• Respeta la economía. Los atacantes expertos acaparan exploits; los comentaristas ruidosos monetizan el miedo. Ninguno de los dos grupos tiene incentivos alineados con tu necesidad de una evaluación de amenazas precisa, así que da más peso a la telemetría primaria que a los comentarios.
• Separa las afirmaciones. «Existe un exploit», «se está explotando» y «los agentes autónomos lo explotan todo» son tres afirmaciones distintas con tres niveles de evidencia diferentes. El pánico las funde en una sola. No lo permitas.
• Parchea rápido de todos modos. Un honeypot tranquilo no significa exposición tranquila. Tus servidores de producción no ofrecen un premio de 500 $, lo que paradójicamente los convierte en objetivos más atractivos para alguien que tiene un exploit funcional guardado.

Lo mejor de todo el truco es que le costó a su autor casi nada y produjo una señal real. Un VPS, una versión vulnerable de PHP, un binario de bandera y quinientos dólares compraron una medición que todo el debate necesitaba. La brecha entre «existe un exploit» y «el exploit está en todas partes» es donde vive el pánico, y ahora hay un cronómetro contando en silencio en medio de esa brecha, retando a cualquiera a cerrarla.