Next.js, NGINX i Grafana: vulnerabilitats de maig

que tenemos una semana de vulnerabilidades históricas y apocalípticas, que es que se te ponen los pelos como alfileres. Y empezamos con NextGS, con NextGS, que nada más y nada menos tenemos aquí una vulnerabilidad que te permite hacer server side request forgery, o sea, en la práctica lo que podía hacer un atacante era conseguir que el servidor hiciese peticiones internas en su nombre. O sea, esto sirve para robar credenciales, quedarte con API Keyis, acceder a datos internos de paneles de administración. Esto podía ser peligroso si la app tenía acceso a servicios privados, redes internas, end points con credenciales y cosas así, que suele ser lo típico. No es que podías ejecutar código directamente en remoto, pero puede acabar en una filtración de secretos si el entorno está mal protegido. De hecho, lo tenemos por aquí en GitHub, ¿vale? Cber site request forging applications using websocket upgrades y hombre tiene una severidad de 8,6 sobre 10 y además todas las versiones afectadas son de la 13 a la 15 y la 16, o sea, todas básicamente. Y lo peor de todo es que claro, no han sacado parche para la 13 y la 14. Si tienes una versión de NextJS con 13 o 14, estás [ __ ] Tienes que actualizar como mínimo a la 15 y utilizar la 15.5.16. Y lo peor es que la complejidad del ataque era bastante bastante sencilla. Entonces, esta es una, pero es que resulta, amigos, que esta es una de muchas. Lo que ha pasado este fin de semana es que ha caído hasta macos, amigos. Vulnerabilidad bastante grave de macos. Y grave no porque sea fácil, sino porque los investigadores utilizando mizos preview han encontrado el primer exploit público de corrupción de memoria del kernel en los chips M5. Claro, esto, tened en cuenta que normalmente en los chips de Apple ha habido grandes problemas de vulnerabilidad o conocidos. Claro que ha podido haber, pero no ha habido ninguno conocido. Apple gastó 5 años y un estimado de varios millones miles de millones de dólares en construir Memory Integrity Enforcement. El sistema de seguridad de memoria asistido por hardware construido alrededor del MTE de ARM. Fue la característica de seguridad insignia del M5 y A19 diseñada específicamente para eliminar toda clase de errores de corrupción de memoria. Corrupción de memoria es lo que se utilizar muchas veces para justamente pues cambiar

permisos o intentar inyectar algún tipo de código y cosas así. Claro, porque la memoria la puedes corruptir, le metes ahí con corrupción algo de código, perfecto, y tienes un exploit maravilloso. Pero en Apple normalmente esto lo tenían bastante bastante controlado y dicen que han hecho un exploit funcional en 5 días. Según la propia investigación de Apple, Mia interrumpe cada cadena de exploit públicos contra ellos modernos, incluyendo los kits con una y darkbard filtrado recientemente. El informe técnico completo de 55 páginas se publicará después de que Apple parche la vulnerabilidad. Tú te imaginas from type confusion to root, ¿vale? O sea, seguramente es de nuevo elevación de permisos. Por cierto, yo estado aquí. Total que está bastante bastante claro que seguramente aquí la han puesto para que no se pueda ver nada. Seguramente es elevación de permisos, que son las mismas vulnerabilidades que ha tenido Linux desde hace poco. Y lo mejor es que incluso tenemos un vídeo de cómo lo han conseguido, o sea, no se ve el código, no se ve el exploit, solo se sabe que se puede porque aquí se puede ver, ¿no?, cómo lo han hecho y podemos ver cómo hace la elevación de permisos, ¿vale? Aquí tenemos el root, no sé qué y cómo está inyectando. Y fíjate que han puesto ahí el grif calif y tal y está inyectando cosas, así que ahí lo tenéis. entiendo que será tanto M5 como M5 Pro y tal, eh, serán todos los M5. Esto te podría escalar privilegios hasta root mediante una cadena de explotación en el kernel. No es un ataque remoto directo desde internet, pero sí que es una escalada local. Es lo mismo que pasó con Linux, con Copy Fail y tal, pero bueno, que mucha gente infravalorada, infravaloraba este tipo de ataques, pero es bastante grave pensar que en este tipo de servidores una escalada de permisos es muy importante, o sea, conseguir privilegios de kernel y que te puedas saltar pues protecciones del sistema, pues imagínate si si es importante. Hay rumores que ya han arreglado la vulnerabilidad. Parece ser que ya lo han arreglado. Parece ser, eh, dice que dice que han estado validándolo. Dice que no se sabe si la han parcheado, pero parece ser que en la Security [música] Notes de la última versión de MacOS 265 hay una mención aquí, ¿ves? HFS AVALEV dice Impact. Una

aplicación podría causar una determinación no esperada del sistema o escribir en la memoria el kernel. Entonces puede ser que por aquí vengan los tiros. Puede ser, eh, o sea, hay bastantes, así que me imagino que a lo mejor alguna van por ahí los tiros. Hay bastantes, alguna habrán, alguna quizás puede ser que hayan parcheado de este tipo. Next, Macos, [ __ ] Deb. Sí que puede ser que la inteligencia artificial ahora mismo esté ayudando mucho con el tema de encontrar este tipo de problemas. eh una nueva vulnerabilidad crítica en [ __ ] DB y esta vulnerabilidad lo que te permite es ejecutar código arbitrario. Este tipo de errores son bastante graves porque si tú puedes ejecutar código arbitrario y además en remoto estás [ __ ] O sea, estás muy pero que muy [ __ ] porque al final esto lo que significa es que estás a expensas, le han puesto una puntuación de 8.8, O sea, que quizás necesitabas tener algún tipo, o sea, no es tan tan alta, o sea, es alta la puntuación, pero normalmente un remote code execution, si no tienes que hacer algún tipo de cosa en concreto, seguramente tendría una puntuación peor. ¿Cuál es el problema? Pues que aquí podéis ver todos los software que están siendo afectados, desde el 5, el 6, el 7, el 8, o sea, el 8.2, el 8.3. O sea, es que tienes un montón de versiones, un montón de versiones al que al que le afecta esto. Así que ahí lo tenéis. Vulnerad crítica recientemente revelada. el control total sobre servidores afectados y exponiendo millones de registros al robo. Debido a que Mongos ampliamente utilizado por empresas a nivel global, un servidor sin parchear representa un efectivo muy lucrativo. La divulgación pública significa que es probable que los actores de amenazas conveniencen a realizar ingeniería inversa del parche para crear exploits funcionales. Claro, aunque no sepas exactamente cómo lo han hecho, sí que es verdad que al final lo que pasa es que una vez que tú sabes que hay una vulnerabilidad, te pones a darle al coco, ostras, a ver cómo lo han hecho, a ver cómo lo han hecho y tal. Hay otro sistema operativo que esta semana se ha encontrado también con problemas, Windows. Y lo peor de Windows es que además es una vulnerabilidad que ya estaba arreglada. Windows Mini Plasma

0 Day le permiten a los atacantes tener acceso al sistema. De nuevo, otro ataque de elevación, escala de privilegios hasta system. O sea, no significa que alguien pueda hackearte solo por estar conectado de internet, ¿vale? Pero sí que es un malware o un atacante que haya conseguido ejecutar código podría ganar acceso total a tu sistema porque al final con que ejecutes cualquier código aunque no sea root, pues puede elevarlo al sistema. Lo peor que esto era una vulnerabilidad que ya fue reportada por Google en Project Z0 en septiembre del 2020. se le asignó incluso y se reportó como que estaba arreglada en diciembre del 2020, pues resulta que alguien ha vuelto a hacer como un script para volver a hacer el mismo la misma vulnerabilidad. Es como, [ __ ] tío, si ya estaba arreglada, si ya estabas avisado, ¿cómo no han puesto un test o algo? Me imagino que habrá algún tipo de modificación del vector de ataque original, pero aún así, [ __ ] me parece un poco tela tela, ¿eh? Un poco raro. Entonces, es también, de nuevo, muy parecido a la de Macos y muy parecida a la de Linux. Muchas veces, de hecho, con la de Linux me cayó mucho, pero mucho, mucho, mucho, mucho, mucho hate de muchos linuxeros. Yo esto no lo entiendo. O sea, yo os lo tengo que decir de corazón. Yo quiero mucho a mucha gente y a muchas cosas en esta vida, pero lo que no entenderé nunca en la vida es la gente que tiene como ya no digo un sentimiento, una obsesión por un sistema operativo, por un software, por un hardware, como no es que la PlayStation, la Xbox, no es que te odio, no es que Linux, es que no sé qué, es que no sé cuánto. Que Linux tenga una vulnerabilidad no significa que sea un mal sistema operativo, es que tiene una vulnerabilidad, significa lo que significa. Y ostras, y entonces mucha gente en los comentarios me decía, "Es que de Windows, pero si de Windows se habla un montón." Y aquí tienes una de Windows. Me decían que era Windows 0, que era de Windows 0, porque de Windows nunca hablo mal, cosa que es mentira. Hablo bien, hablo mal, hablo de todo. Oye, no pasa nada, tiene una vulnerabilidad, pues se habla. Si de hecho que lo del Linux sea noticia es

porque no suele ser tan común, lo cual es una cosa positiva. Pero [ __ ] si hay una de Windows, pues se comenta también. Y esta, de hecho, lo preocupante es que se supone que era una que ya tenían solucionada, ya la habían solucionado en 2020. Pues nada, la han vuelto, la han vuelto a abrir las cosas como son. Bueno, pues alguien diría, "Bueno, ya está, ¿no? Ya has terminado." Bueno, obviamente vulnerabilidades hay siempre, pero es que se nos han juntado vulnerabilidades bastante graves en diferentes sistemas bastante críticos, porque es que otro software que ha caído con una vulnerabilidad que lleva escondida 18 años es nada más y nada menos que Engine X con una vulnerabilidad de 18 años que lo que te permitía hacer un overflow para explotar una vulnerabilidad que lo que te permita permitía era ejecutar código remoto, o sea, una de las vulnerabilidades más críticas y que, como os digo, lleva 18 años escondida en sus en sus tripas, amigos, en sus tripas. Y aquí podéis ver un 9,2. Ha sacado más de una, 9,2, 8,3, 6,3 6,3, un 9,2. Ya estamos hablando de una puntuación bastante bastante grave. un montón de versiones afectadas y por supuesto Engine X, para el que no lo sepa, es uno de los servidores Proxis inversos de código abierto más utilizados en el mundo. Es muy ligero, de alto rendimiento, tiene una arquitectura que está basada en eventos, asincronía, es espectacular. En Ginex se utiliza un montón de sitios especialmente para servir contenido estático, pero no solo porque puedes tener aplicaciones de no GS, de Python, balanceador de carga, terminaciones de SSL TLS, o sea, tiene un montón de cosas y el consumo de recursos es increíblemente bajo. De hecho es la mejor alternativa de Apache HTTPD, pero mira, no es muy común. Sí ha tenido vulnerabilidades antes, o sea, no es perfecto, pero una con 18 años de tiempo que tiene esta vulnerabilidad y que te permita ejecutar código en remoto. Os digo una cosa, como tengáis un servidor VPS por ahí que utilicen Ginex y que por lo que sea no lo parchéis, a mi gato pongo por testigo que os quedan menos de dos semanas de que os hacken el servidor. O sea, no tengo pruebas, pero tampoco tengo dudas. Lo tengo clarísimo porque este es el típico ataque que se suele añadir automáticamente y que

eventualmente lo explotan y se ponen a controlar tus servidores sin que te des cuenta muchas veces al hacer ataques y tal. Actualiza cuanto antes porque de verdad este tipo este tipo de vulnerabilidades son muy graves. La gente se toma estas vulnerabilidades a jaja y para nada. Son bastante preocupantes y más en una pieza de software tan crítica. Si estás utilizando Engine X 1.30.0 cer o menor, tienes que parchear. Ya dice que los atacantes pueden hacer estallar los workers con una sola petición. Es verdad que ahí hay ciertas cosas, o sea, no es 100% fácil, o sea, hay que tener algunas cosas activadas, eso sí que es verdad, lo tenéis por aquí. El código solo es posible en dispositivos donde address space layout randomization, una salvaguardia contra ataques basados en memoria está desactivado. O sea, que podéis mirar esto. Realmente el problema es que depende de una configuración de Enginex que es totalmente vulnerable. Entonces, obviamente por no puedes depender de eso. O sea, al final lo que tienes que tener es que el software no tenga ese problema y ya está. Hablemos de OpenClow, porque OpenClow ha tenido una cadena de vulnerabilidades críticas que ha permitido el hecho de poder saltarte las políticas y darte acceso archivos, variables de entorno, tokens, APIs, herramientas internas. Puedes encadenar diferentes fallos y vulnerabilidades de OpenClow y acceder a día de hoy a más de 245,000 servidores de agentes que están expuestos a este ataque y puedes robar los secretos. escapar de los límites del sbox, abusar de los permisos del propio agente y eso utilizando una cadena de vulnerabilidades que son estas de aquí, que como podéis ver hay una de ellas que tiene un 9,6 porque haciendo una race condition lo que hace es que el atacante redirige las operaciones de escritura fuera del sbox y eso lo que te permite ya es cambiar la configuración y tener un backdoor persistente en tu agente. Así que amigos, si tenéis un agente de nuevo, echadle un vistazo. Yo os digo ya per sé, por más que tengáis cuidado y tal, creo que es mala idea a día de hoy tener Open Clow en tu propio ordenador, eso seguro. O sea, lo tenéis que tener como mucho en un servidor totalmente separado, totalmente separado. Luego aseguraros que estáis utilizando bien eh todas las reglas de seguridad y tal y

luego actualizar siempre constantemente a la última versión. No podéis dejar open close sin actualizar, o sea, porque tiene demasiada exposición. es muy goloso y además cada dos por tres estánd encontrando vulnerabilidades muy graves. Lo peor y y esto lo voy a decir claramente, lo peor de esto en realidad es que todo esto es AI slop. No quiero decir que un humano no vaya a cometer estos errores, porque supuesto que los va a cometer y es lo que hay. Pero esto también viene de esto. Este es el creador de de Open Clow, Peter Steinberger, y el otro día estaba anunciando una nueva versión de Codex Bar, donde había mejorado la gráfica y tal. Y oye, es una aplicación bastante interesante para ver el uso y consumo que estás teniendo de cada uno de las suscripciones que utilizas. Oye, está interesante. Pero se le coló en la propia imagen donde señaba la gráfica, su propio consumo de créditos en, por ejemplo, la API de Open AI. Y aquí podéis ver en 30 días ha consumido 1,300,000, o sea, en solo una semana consumió $250,000 en la API de Open AI. En 30 días 1,300,000. Obviamente, ya os podéis imaginar, o sea, mucha gente no se lo creía. Yo me lo creo, ¿eh? Yo me lo creo. Mira, 7 millones de peticiones. Es gracioso porque muchas veces, bueno, dice que podría desactivar el modo rápido, que sea un 70% más rápido, que bueno, que no, que pasa que lo que quiere es que sea lo más rápido posible. Y una de las cosas que comentaba por aquí es que dice que esto lo está haciendo, esto de gastarse más de un millón de dólares y tal, esto lo está haciendo como por el bien de la ciencia, para llevar al límite cómo sería el uso de la de tener agentes de inteligencia artificial construyendo y programando constantemente, ¿no? Pero claro, hay un coste asociado y yo creo que se ve un poco aquí el hecho de construir tan rápido también. Lo que pasa, o sea, está aquí. El hecho de construir tan rápido es que de alguna forma, cuanto más construyes, también más fácil es que cometas errores, por más que haga una inteligencia artificial, un humano y tal. Lo que pasa es que el humano no va tan rápido y seguramente tiene que sopesar mejor los cambios o tiene que

enfocarse mejor en qué es lo que va a aportar valor. El problema que veo de la inteligencia artificial, y no sé si lo estáis notando cada vez más, pero a mí es una cosa que me pasa, es que veo gente que construye cosas que no le importan a nadie o que se están construyendo cosas que cada vez más tienen menos valor. como lo haces tan rápido, como lo haces con tan poco esfuerzo, realmente lo que estás construyendo no es que no lo use nadie, que no lo va a usar nadie, que nadie lo quiere, nadie lo necesita. Y yo creo que eso es lo peor que te puede pasar cuando sobreproduces software de forma innecesaria. Y creo que también le puede pasar un poco a Peter Steinberger, o sea, que creo que está construyendo muchas cosas y de hecho y está muy bien porque que sí ha construido, mira, todas estas ha construido todas estas herramientas. De nuevo, me parece bien porque al final cuanto más construyes alguna la petará y aprenderás de ello y tal y yo creo que parte de su éxito ha sido el ser tan constante a la vez también piensas, pero de todas estas, ¿qué no es basura? Ese es el problema, qué estamos construyendo realmente porque al final, y esto es lo más [ __ ] eh, el código siempre ha sido la herramienta, siempre ha sido el medio para solucionar un problema, pero en cambio ahora se está se está convirtiendo directamente en la generación, en lo que quieres hacer, no en tanto lo que terminas al final, sino generar código. O sea, hemos pasado a lo peor que podía pasar con el código, el hecho de generar código por generar código, cuando en realidad siempre el código ha sido intentar construir o hacer el menor código posible. Bueno, no sé, para pensar, eh, para pensar. Es que he visto esto y me ha aparecido un poco por ahí eso, esos tiros y digo, "Hostia, no sé, a ver qué pasa." El código se vuelve un producto. Efectivamente, mano, el código se vuelve un producto. Mira cuántos tokens he quemado porque he hecho todo este código. Cada vez me escribe más gente con el tema de, "Es que he hecho esta aplicación, quiero que le eches un vistazo, me gustaría tu opinión, no sé qué, no sé cuánto, bla

bla bla." Y es que digo, pero tío, no conozco tu producto. Veo el producto y claramente está hecho con inteligencia artificial que no tiene ni el mínimo cariño, que no no significa que esté mal. Ya solo el hecho de detectar que está hecho con inteligencia artificial, yo a mí se me quita un poco realmente las ganas de decir, ostras, o sea, y no digo que esté mal utiliza inteligencia artificial, está bien, pero que se note tanto, ¿sabes? ya denota el hecho de es que es un producto que está como a medio hacer, o sea, es un producto que que oye, yo que sé, que lo has hecho por hacer, que bueno, está bien, que puedes validar la idea por ahí, que a lo mejor tiene sentido, pero no me lo mandes a mí, ¿sabes? No me mandes a mí este producto como para que hable de él, para darte distribución porque no va a pasar y porque justamente la distribución es parte del desarrollo del software. La distribución es parte, si no, ¿qué qué solución está? O sea, qué problema está solucionando realmente. En fin, Grafana también la han hackeado. Recientemente descubrimos que una parte no autorizada obtuvo un token de acceso al entorno de GitHub de Grafana Laps, lo que le permitió al actor de amenazas descargar nuestro código base. Nuestra investigación ha determinado que no se ha filtrado ninguna información de datos de clientes ni información personal durante este incidente y no hemos encontrado evidencia de impacto en los sistemas u operaciones de los clientes. Inmediatamente hemos iniciado un análisis forense, hemos invalidado los credenciales comprometidas, hemos implentado medidas de seguridad y el atacante nos ha chantajeado exigiendo un pago para evitar la publicación de nuestro código base, el código base de la parte enterprise, porque ya sabéis que Grafana, que es un dashboard de datos, es totalmente de es de código abierto la parte que es de código abierto. Basándonos en nuestra experiencia operativa y la postura publicada por el FBI, que señala que pagar un rescate no garantiza que usted o su organización recupere algún dato y solo ofrece un incentivo para que otros se involucren en este tipo de actividad ilegal. Hemos tomado la decisión adecuado hacia delante de no pagar rescate. Como parte de las prácticas estándar de seguridad de Grafana, compartiremos información adicional de nuestra revisión posterior incidente

cuando nuestras investigaciones estén completas. Hasta aquí bien, pero tengo que tirarle las orejas y es una cosa que tengo que decir cada vez me enfada más y no me parece bien. El tema es que Grafana ha anunciado esto eh, bien en Twitter, ¿vale? 1 millón de vistas, 6,000 likes, ¿vale? ha puesto, "Esto no está mal, perfecto." Pero tú entras a la página web de Grafana y no pone nada, no pone nada. Dice, "Bueno, pues estará en el blog, ¿no? Grafana con AI observability, Grafana Cloud, AI, todos los post y no pone nada. Pero tío, o sea, tendrás que poner nada. Y en la topb, ¿qué hay de nuevo en Grafana? Hemos lanzado Grafana 13. ¡Ostras! Twitter no es un canal de comunicación con tus clientes y usuarios, es parte de tus clientes y usuarios, ¿vale? Y está bien, no sé, me parece bien que lo hagas en Twitter, me parece un extra, pero en tu página web deberías ponerlo, tío, por transparencia. Y mira, si además tienes aquí una un sitio perfecto, lo pones aquí, hola, tenemos un aviso. Pum, haces un blog post, lo pones y ya está. Que no tienes Twitter, te jodes y no te enteras. O sea, esto, ¿qué es? Es un poco raro, tío. O sea, esto tiene que estar en la parte oficial. A ver, son empresas muy grandes. Si me dices que lo hace la panadería, Paco, lo puedo entender. Yo sé, una empresa de cuatro personas, pero [ __ ] una empresa tan grande como Grafana que no que no sea capaz de informar de esto más allá de ponerlo en un tweet. No sé, tío. No, no, o sea, no entiendo. Esto es una cosa que a mí cada vez me enfada más porque creo que es vital y es verdad que parece ser que no ha tenido acceso a información personal, pero aún así me parece lo suficientemente importante porque le están haciendo amenazas de blackmail y hay mucha gente que está pagando el Grafana Enterprise y de repente se va a encontrar que ese código es totalmente público, que creo que tienen que tener cuidado con este tipo de cosas. Eh, esto solo se supone que afecta a gente de Enterprise, no tiene por qué ser grave, pero bueno, sí que me ha parecido espectacular que que no para, eh, pero lo que te quiero comentar de esto es

cómo ha pasado, como Grafana, y no solo Grafana, sino un montón de empresas, como por ejemplo lo que pasó con Tamstack, se le han atacado. Este miércoles, te voy a explicar mejor esto porque este miércoles vamos a hacer un curso de Gigap actions y entre las cosas hablaremos de estos, los diferentes hooks que hay disponibles, ¿vale? Así que si queréis aprender GHP actions, cómo automatizar vuestros despliegues y tal, que sepáis que aquí, mira, en YouTube ya tenemos aquí tanto eh lo que vamos a hacer, el Google IO, que vamos a hacer mañana en vivo y en directo, y el curso desde cero de GHub Actions que lo vamos a hacer el miércoles, así que le podéis dar a recibir aviso, le dais aquí, pum, y ya os enviará una notificación. Pero aparte de esto, ¿por qué os lo cuento? Porque en realidad esto que le ha pasado Grafana es por una vulnerabilidad o una mala praxis que tenemos con la GHUp actions. Parece mentira, pero es así. ¿Cómo ha pasado esto? Pues ha pasado por culpa de las Ghup actions, por utilizar el pull requester, ¿no? No pull requester, no. En realidad el que se utiliza es el pull request target, ¿vale? Cuando utilizas de forma incorrecta en un flujo de trabajo el pull request target. Pull request target. Al final el problema que tiene es que contribuidores externos pueden tener acceso a variables de entorno, AP keys, ejecutar código arbitrario desde un fork. O sea, no puedes utilizar el pull request target. Es una mala práctica. No utilicéis pull request target, ¿vale? El que hay que utilizar en realidad es el otro. Por ejemplo, el pull request target. En lugar del pull request, el pull request es el correcto que tienes que utilizar. el put request target lo que hacen es que realmente te funciona el flujo de trabajo en el contexto del repositorio base donde todos los secretos están expuestos. Tienes un GHub token de escritura y de lectura. Así es como atacaron a la gente de Tamstack y así es como han atacado a la gente de Grafana. Entonces, si encontráis un pun request target en vuestros repositorios, estáis jodidos, sobre todo si son públicos. Si no son públicos, en muchos repositorios Enterprise sí que se utiliza muchas veces esto. ¿Por qué? Porque request normalmente lo hace la gente que está dentro del equipo, pero si tú tienes un

repositorio público, ni se te ocurra tener un pull request target. A mí es que me parece hasta un fallo de seguridad de GHub, tío, el hecho de que te permita hacer esto sin un doble check, ¿sabes? De que tú lo metes a un flujo, ah, ya lo tienes. Y no debería. O sea, no debería porque el tema es que el pull request target te permite ejecutar flujos de trabajo sin requerir la aprobación manual. O sea, a mí me parece un error. No sé, no sé por qué permiten esto, de verdad, porque creo que debería, al menos de forma manual, tuvieras que aceptar que se ejecute el flujo de trabajo, pero no. Ahora esto es automático, por lo tanto, tú fíjate lo que puedes hacer. Dices, "Vale, pues venga, quiero aquí utilizar el token de Gigard token." Claro, una vez que tienes el GH token, tú aquí puedes ejecutar lo que te dé la gana. Ya ves, ejecutas este script. Tú tienes aquí todas las variables de entorno, además con permisos de escritura y todo que puedes hacer. Así que nada, lo que puedes hacer es buscar, fíjate, es que hay un montón, pero un montón de gente que lo ha utilizado. Lo que tienes que hacer, pues normalmente buscar esto. Buscas esto en GitHub, te vas a GitHub, buscas esto y como esto esté en algún código, pues ya está [ __ ] ¿Ves cosas así? Si tú ves esto, está [ __ ] Está [ __ ] está [ __ ] está [ __ ] Por ejemplo, este. Este está [ __ ] O sea, ¿cómo va? A ver, no sé que algunos serán de documentar, ¿vale? Pero por ejemplo este workflow que imagínate que tienes este workflow lady con p request target, a no ser que no tengan ninguna variable de entorno y tal, estás estás [ __ ] Y así es como han atacado Grafana y así como han atacado un montón de gente y así es como atacaron a Tamstack. Así que tengan mucho, mucho cuidado con esto, que esto es una una verdadera pesadilla. Así que nada, darle en caña. [música] [música]