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 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.