Speaker A
El otro día subí en mi canal un vídeo explicando cómo empezar en Bug Bounty y obtener los primeros ingresos, pero en ese vídeo solamente tenía este pequeño reporte que me han pagado $5 nada más, pero por aquí tenemos novedades. En otro
Guía práctica para reportar vulnerabilidades en Bug Bounty y maximizar pagos usando plataformas como YesWeHack y Bugcrowd.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Un reporte bien documentado aumenta las posibilidades de recibir una recompensa.
- Es fundamental respetar el scope y usar cuentas oficiales para evitar problemas.
- El CVSS es una herramienta estándar para evaluar la gravedad de vulnerabilidades.
- Herramientas como Burp Suite facilitan la identificación y documentación de bugs.
- Practicar y aprender de errores es clave para mejorar en Bug Bounty.
What the video covers
- El vídeo explica cómo empezar en Bug Bounty y obtener ingresos reportando vulnerabilidades.
- Se centra en dos plataformas principales: YesWeHack y Bugcrowd.
- Se detalla cómo documentar un reporte profesional para aumentar las posibilidades de pago.
- Se explica la importancia de entender el scope y usar cuentas proporcionadas por la plataforma.
- Se muestra un ejemplo ficticio de reporte de una vulnerabilidad XSS en DailyMotion.
- Se describe cómo rellenar campos clave en el reporte: tipo de bug, scope, método HTTP, parámetro vulnerable y payload.
- Se introduce el sistema CVSS para valorar la criticidad de la vulnerabilidad.
- Se menciona el uso de herramientas como Burp Suite para interceptar y analizar peticiones.
- Incluye recomendaciones para evitar errores comunes al reportar vulnerabilidades.
- Se ofrece información adicional y recursos en la descripción del vídeo.
Chapters
- 00:00Introducción y experiencia inicial en Bug Bounty
- 01:34Importancia del scope y uso de cuentas oficiales
- 02:50Ejemplo de reporte: vulnerabilidad XSS reflejado
- 04:41Documentación técnica del reporte: métodos y parámetros
- 06:15Evaluación de la criticidad con CVSS
- 08:01Patrocinador y recomendaciones para hosting web
- 09:51Detalles adicionales sobre la severidad y confidencialidad
- 13:04Resumen y consejos finales para reportar bugs
Full Transcript — Download SRT & Markdown
Speaker A
reporte pues ya han pagado bastante más y tenemos por aquí este otro, así como otros tantos que yo creo que también deberían de pagarme pues en cada uno de ellos. Pero, ¿por qué os estoy contando esto? ¿Es para presumir, para hacerme
Speaker A
chulo? No, nada de eso en absoluto. La idea es que, bueno, a lo largo de estos días, de estas últimas semanas, pues bueno, hice muchos reportes y esto implica que fui aprendiendo muchas cosas. Tuve errores, hice cosas bien,
Speaker A
cosas mal, pero he aprendido mucho y como no puede ser de otra manera, pues vengo aquí a mi canal a compartiros todo esto para que podáis hacer un reporte lo más profesional posible para maximizar esas posibilidades de que os paguen en
Speaker A
un reporte de Bug Bounty. Vale, yo para este vídeo voy a centrarme en dos plataformas, en YesWeHack y en Bugcrowd. No por nada, hay otras muchas, también tenemos One Integrity, pero bueno, yo pues donde más he reportado ha sido en estas dos.
Speaker A
Entonces, bueno, pues por eso voy a centrarme en estas dos plataformas, en Bugcrowd y en YesWeHack. Bien, vamos a ver un poquito cómo se hace un reporte porque hay muchos trucos y muchas cosas que debemos hacer que en muchas
Speaker A
ocasiones, pues bueno, se nos escapa por algo o nos olvidamos de hacerlo y es muy importante. Veréis, yo por ejemplo voy a entrar dentro de pues algún programa aleatorio, por ejemplo, voy a entrar en DailyMotion, que me sale aquí el
Speaker A
primero. Y bien, antes de nada, una cosa que tenemos que mirar mucho es el scope, lo que entra, eh, pues bueno, básicamente lo que podemos hackear o donde podemos revisar si hay vulnerabilidades, pero esto puede ser de
Speaker A
sentido común. Podemos pensar, vale, sí, si yo pues veo esto, pues vale, el scope es dailymotion.com o cualquier subdominio, ¿vale? Pero hay una cosa que hay que tener en cuenta que si nos registramos con alguna cuenta, no debemos de
Speaker A
utilizar nuestra cuenta personal, hay que utilizar una cuenta que nos proporciona la plataforma de Bug Bounty.
Speaker A
Este tipo de cosas. Pues bueno, cuando uno empieza se le olvidan o no lo sabe.
Speaker A
Entonces, esto es un poco lo que vamos a ver en este vídeo. Bien, vamos, por ejemplo, a suponer que, bueno, obviamente aquí no voy a mostrar ninguna vulnerabilidad real, pero bueno, vamos, por ejemplo, a suponer que dentro de la
Speaker A
página principal de DailyMotion o en algún subdominio, el que sea, encontramos un XSS, por ejemplo, un cross-site scripting. Me lo estoy imaginando.
Speaker A
Obviamente pues esto no es una realidad, pero vamos a imaginároslo. No, tenemos un XSS, por ejemplo, pues aquí dentro, ¿no? Este panel de búsqueda, que obviamente esto no es vulnerable, obviamente ya lo probé, sí que encontré otras cosas, pero bueno, esto no es.
Speaker A
Entonces, ¿qué vamos a hacer? Pues vamos a suponer que aquí tenemos un XSS y vamos a reportarlo. Bien, antes de nada, submit report. Aquí tenemos este pequeño botón. Vamos aquí a hacer un clic y se nos abre esta ventana. Bien, lo primero
Speaker A
bug type. Aquí tenemos un pequeño buscador para, bueno, pues seleccionar la vulnerabilidad que hemos encontrado.
Speaker A
Si es un XSS, pues bueno, ponemos XSS, ¿no? Puede ser reflejado, almacenado. Bueno, vamos a eh imaginar que es un XSS reflejado, el típico XSS de lo más normal, ¿no? Bien, ponemos esto.
Speaker A
Perfecto. Scope. Aquí es básicamente dónde lo hemos encontrado. Si lo hemos encontrado tanto, bueno, o bien dentro del dominio principal como en algún subdominio, pues ponemos bueno asterisco.dailymotion.com que lo hemos encontrado en API dailymotion, pues ponemos aquí API. Yo,
Speaker A
por ejemplo, vamos aquí poner dailymotion.com en point. ¿Esto qué es? Bueno, pues básicamente lo ideal es cuando estamos pues haciendo pues ataques o estamos intentando encontrar alguna vulnerabilidad, lo ideal es estar con Burp Suite, pues bueno, interceptando la petición. Por aquí lo tenemos. Y
Speaker A
bueno, pues aquí debemos de tener ubicada pues básicamente la petición que se hace donde se explota ese XSS. Es decir, por ejemplo, si yo estoy aquí dentro del buscador, bueno, voy a activar aquí la interceptación y pongo,
Speaker A
pues, por ejemplo, aquí un payload, ¿no? Pongo cualquier cosa. Si yo pongo esto, pues aquí tenemos la API, que en este caso es un GraphQL, que es otro tipo de APIs. Y bueno, pues aquí sería un un
Speaker A
poquito mirar dónde hemos explotado pues ese XSS muy entre comillas, ¿no? Yo, por ejemplo, como yo he puesto pingu dentro del buscador, pues yo puedo aquí aplicar un filtro y entonces aquí lo tenemos, ¿no? Pues mira, por ejemplo, aquí con el
Speaker A
método POST vamos a que poner pingu y se utilizó aquí search query pingu. Entonces yo dentro del reporte pues bueno, podríamos poner simplemente la raíz, ¿no? Que en vez de hacerlo en la raíz, pues se hace en cualquier otra
Speaker A
ruta, pues aquí pondremos la ruta en sí, ¿no? Yo como lo hice pues dentro de la raíz, pues simplemente pondría aquí la raíz, ¿no? Por ejemplo, ¿no? Aquí lo típico es pues por ejemplo pues una ruta estilo v1 login o v1 search, bueno, un
Speaker A
API de la API, ¿no? Ponemos la raíz parte vulnerable que hemos empleado el método POST, método GET, método PUT, fue a través de alguna cabecera, lo que sea.
Speaker A
En este caso, como estamos dentro de un buscador, pues bueno, sería el método POST part name. ¿Esto qué es? Pues aquí, por ejemplo, sería para especificar pues el parámetro que quizás se esté utilizando para recibir pues ese payload. Por ejemplo, pues imaginemos
Speaker A
que dentro de la API pues que aquí tenemos un imaginemos barra search eh interrogación eh Q = A. Y bueno, pues ahí metemos eh el parámetro Q sería básicamente el parámetro, por ejemplo, ¿no? O también puede ser que el XSS que
Speaker A
lo hayamos inyectado con el user agent por poder. Entonces, pues ahí tendremos que poner básicamente, ¿no? Bien, yo en este caso pues bueno, como claro es que en verdad me lo estoy inventando, pero por ejemplo vamos a poner pues e
Speaker A
interrogación Q igual A, por ejemplo, y luego pues aquí el payload en sí, por ejemplo, el payload pues aquí metemos el payload, imaginemos que hemos explotado un XSS, pues bueno, pues podríamos hacer algo así. Perfecto. Bueno, aquí pues
Speaker A
bueno, podríamos pues por ejemplo Linux, Windows, eh, Burp Suite Community, lo que sea, ¿no? Yo, por ejemplo, voy a poner Linux, Ubuntu, eh, Burp Suite Community, por ejemplo, ¿no? Luego estos tres campos son opcionales, así que no hay ningún problema. Y luego por aquí
Speaker A
ponemos nuestra IP. Yo hago un clic y por aquí se me carga mi IP pública, ¿no?
Speaker A
Perfecto. Luego, ¿esto qué es? Aquí tenemos este gráfico. Este, básicamente es el CVSS. Y esto es algo muy importante porque esto no es exclusivo en el Bug Bounty, sino que esto es algo pues bueno, fundamental dentro de la ciberseguridad. Esto es básicamente una
Speaker A
tabla o bueno, una forma que tenemos de valorar la criticidad de una vulnerabilidad en función de si es, por ejemplo, pues eh fácil de explotar, si requiere la interacción del usuario, si bueno, pues ese tipo de cosas, ¿no? Es
Speaker A
decir, si yo voy aquí pues a Internet y pongo community vulnerability scoring system, que es justo a lo que estamos refiriéndonos, bueno, es el estándar de la industria de código abierto para evaluar la gravedad de las vulnerabilidades en los sistemas
Speaker A
informáticos. Así que vamos a ello. Es sencillo. Pero antes de seguir tenemos un mensaje de nuestro sponsor Rayola Networks. Si estás pensando en montar una página web Rayola Networks es tu solución. Por ejemplo, nosotros confiamos en sus servicios para alojar
Speaker A
nuestra academia de ciberseguridad, el RicondeHacker. Además de ser nuestro patrocinador oficial, nos ofrecen distintas tarifas de hosting SSD, por tanto, tenemos una alta velocidad asegurada dentro de nuestra página web.
Speaker A
Además, con estas ofertas podremos tener un 20% de descuento en contrataciones anuales junto al registro o traslado de un dominio gratis, lo cual permite tener todo lo necesario para co
Speaker A
realmente económico para los seguidores del canal. Tanto si queremos un único dominio, si queremos más de un dominio, tanto dependiendo de el almacenamiento, es decir, si queremos crear una página web, estas ofertas son ideales. Además, también, como podemos ver dentro de su
Speaker A
página web, cuentan con un soporte de 24 horas tanto por teléfono como por ticket, así como 30 días de garantía, soporte para WordPress, una alta velocidad SSD muy importante y también certificado SSL incluido. También en caso de que cuentes ya con otro
Speaker A
proveedor y quieras hacer el cambio, Rayola Networks nos ofrecen la migración gratuita, así como también backups automáticos cada día y tutoriales y recursos gratis. Por aquí también tenemos más detallada la información, las distintas tarifas dependiendo de nuestras necesidades. Tenemos desde la
Speaker A
tarifa más básica, que sigue siendo muy completa, hasta una tarifa mucho más avanzada como puede ser la Pro. Así que en definitiva, si quieres crear una página web, Rayola Networks es ideal.
Speaker A
Listo, ya he visto el mensaje. Seguimos con el vídeo. Lo primero, attack vector. ¿Esto qué es? Pues bueno, aquí pondremos network. ¿Por qué? Porque básicamente aquí la idea es decir eh cómo se hace el ataque. Bueno, casi siempre en el bug
Speaker A
bounty pues se hace a través de internet enviando un link, enviando un enlace. Entonces, aquí por lo general ponemos network. Claro, por ejemplo, physical, pues imaginemos que que vamos de forma presencial a un sitio para explotar la bundelabilidad. Pues bueno, obviamente
Speaker A
en función de cómo se explote elegimos una opción u otra. Bien, ahora lo siguiente, complejidad de ataque, si es difícil de de explotar o si es fácil. En este caso es un XS, por ejemplo, que nos hemos inventado. Entonces, sería fácil.
Speaker A
Privilegios requeridos, en este caso, known. ¿Por qué? Porque para explotar este XSS no hace falta eh estar logueado, ¿no? Vale, imaginemos que para explotarlo pues hiciera falta tener una cuenta hecha o ser administrador, pues ahí ya la cosa cambia, ¿no? Ahora, user
Speaker A
interaction. Esto, bueno, para poder ser explotada esta vulnerabilidad requiere interacción por parte del usuario, ¿sí o no? En este caso, sí, porque si no el XS pues no se ejecuta. Es decir, el usuario tiene que hacer el clic al botón para
Speaker A
que le salte pues eh ese popup de XS. Scope. ¿Esto qué es? Pues básicamente aquí está si el atacante pues rompe algo y luego si el daño ocurre en ese mismo lugar o si ocurre en otro sitio. Por
Speaker A
ejemplo, con el XS se explota dentro de la máquina víctima, pero se ejecuta en nuestro navegador. Entonces aquí sería change porque básicamente cambia de ubicación, por así decirlo. Es decir, el XSS salta de el servidor al navegador a
Speaker A
al nuestro. Y luego, bueno, si yo quisiera poner unchange, esto sería más bien si nosotros pues rompemos algo y permanece en ese mismo lugar. Es la diferencia. Claro, el XS sería change, confidencialidad, en este caso sería low. ¿Por qué? Esto depende de lo que
Speaker A
podamos, digamos, eh, robar una vez que explotemos la vulnerabilidad. Es decir, por ejemplo, imaginemos que hemos explotado pues una inyección SQL y podemos ver toda la base de datos de la víctima. Pues entonces sería HIG porque estamos pues bueno, accediendo a
Speaker A
información muy confidencial. Ponemos low porque el XLSS no llega tanto, pero sí que podemos pues quizás capturar alguna cookie de sesión. Bueno, entonces aquí ponemos low y luego tenemos integrity. Esto básicamente es si podemos pues eh aceptar la integridad de
Speaker A
la página. Yo con el XS pues puedo cambiar la página web porque puedo inyectar código de JavaScript. Entonces, aquí ponemos low y luego disponibilidad, en este caso porque esto implica que la página web deje de funcionar o no. El
Speaker A
XSS pues no va a romper nada porque esto no explota ningún ataque de OS.
Speaker A
Entonces claro automáticamente fijaros como arriba se me pone la criticidad, que sería pues un medio 6,1.
Speaker A
Bueno, el reporte, esta parte es muy interesante porque esto funciona en mar y es una cosa que tenemos que tener en cuenta. Es decir, si yo Bueno, aquí tenemos esta plantilla, como podemos ver. Entonces, bueno, pues lo ideal
Speaker A
sería, al menos yo, como hago es eh ceñirme eh justo como ya me trae por aquí, ¿no? Yo, pues aquí primero, primero pues pongo una explicación de qué es el XS, es decir, yo aquí lo que haría en la parte de la descripción
Speaker A
sería pues decir eh pues qué es el XS, luego pues explicar cómo se explota.
Speaker A
Luego la proof of concept, que aquí pues podemos meter un vídeo, capturas de pantalla, el riesgo que implica para los usuarios, cómo prevenir pues esta vulnerabilidad, es la idea. Y luego pues aquí esto todo podemos aquí quitarlo porque son indicaciones, ¿no? Es decir,
Speaker A
nosotros tenemos que ceñirnos básicamente aquí, ¿no? Tenemos estos títulos, por ejemplo, la parte de la descripción, pues yo tengo esto preparado, ¿no? Pues es pues básicamente una pequeña explicación de lo que hace pues esta vulnerabilidad explotación.
Speaker A
Pues aquí lo ideal sería hacer algo así, veréis. Pum. pegamos esto que es un poco para explicar, pues oye, primero tienes que identificarte, luego tienes que ejecutar, pues bueno, un poquito dar el paso a paso de cómo se explota la
Speaker A
vulnerabilidad, ¿no? Luego la POC es básicamente pues justo la demostración de cómo se explota. Aquí, por ejemplo, pues podemos poner un pequeño texto y podemos pues decir justo el peluz que hemos utilizado. Aquí lo ideal es meter capturas de pantalla. Yo puedo hacer,
Speaker A
por ejemplo, un pantallazo. Mira, veis. Yo, por ejemplo, pues hago aquí un pantallazo aleatorio, ¿no? Esto se me se me queda copiado dentro del portapapeles. Yo si hago control V, pues pego el pantallazo. Entonces, bueno, queda bastante bien poner el pantallazo
Speaker A
a medida que hacemos las explicaciones. Bueno, el riesgo, pues nada, ponemos el riesgo. Yo aquí pues tengo esta plantilla y bueno, pues la remediación, cómo eh bueno, protegernos de esta vulnerabilidad y ya estaría. Ya con esto pues enviamos el reporte y listo. Yo
Speaker A
obviamente no voy a enviarlo porque esto pues me lo acabo de inventar, pero bueno, sería así. Bueno, el título muy importante aquí, pues bueno, yo aquí podría poner pues por ejemplo Reflective XS on y aquí pues ponemos el nombre de
Speaker A
la API, por ejemplo, o bueno, pues básicamente donde ocurra esta vulnerabilidad, ¿no? Y listo, así es como sería un reporte sencillo, pero ojo, hay mucho más y hay cosas a tener en cuenta. Claro, por lo general, cuando queremos encontrar alguna
Speaker A
vulnerabilidad, lo que solemos hacer pues es registrarnos, es decir, hacernos una cuenta, etcétera, etcétera, ¿no?
Speaker A
Entonces, por ejemplo, yo voy a hacer ahora y hack. Esto os lo voy a explicar con Bookcrow porque creo que está bastante más claro. Bueno, yo por ejemplo pues voy a entrar en Bit Panda, por ejemplo, que tienen un programa,
Speaker A
¿no? Bien, aquí hay que tener en cuenta una cosa, bueno, ya sea en este programa o en cualquier otro y es que tenemos que utilizar un correo específico que nos dan las plataformas de Bubont. Veréis, e, si miramos aquí un poco, pues bueno,
Speaker A
el scope, eh, bueno, pues las instrucciones. Fijaros aquí en esto, Bookcraft Ninja. Bien, hay que tener en cuenta este tipo de cosas. Nosotros cuando hagamos pues por ejemplo peticiones con Bursit o una API o estemos intentando explotar algo,
Speaker A
debemos de añadir esta cabecera con el correo que tengamos nuestro. Y bueno, pues aquí tenemos un ejemplo de cómo se vería, pero si queremos registrarnos hay que hacerlo también así con este correo.
Speaker A
Vamos a ver un poquito cómo se hace. Y claro, estaréis pensando, "Vale, pero yo ese correo no lo tengo." No pasa nada porque si yo me hago una cuenta con el correo de Busc Ninja, Buscot o bueno, pues también ocurre en Hacker One,
Speaker A
etcétera, etcétera, redirige el correo a nuestro correo personal por el que estemos registrados en la plataforma.
Speaker A
Bien, vamos a ver un poquito esto, cómo funciona. A ver, yo, por ejemplo, pues voy a entrar en bueno, pues este objetiva que se llama Bit Panda, por ejemplo, y voy a dar aquí pues hacerme una cuenta, ¿no? Voy a hacerme por aquí
Speaker A
una cuenta. Yo, por ejemplo, vamos a poner por aquí que me llamo Pingu, ¿no?
Speaker A
Me llamo Pingu y mi apellido Pepe, ¿no? El correo aquí yo no puedo poner un correo mío personal, podría hacerlo, ¿eh? Y bueno, a mí en mi caso pues me ha llegado a pagar alguna que otra vulnerabilidad a pesar de utilizar un
Speaker A
correo de Gmail, pero no es lo idóneo. Para evitar posos problemas mejor siempre utilizar pues un correo, bueno, el correo que nos proporcionan aquí, ¿no? Entonces yo lo que voy a hacer va a ser pues en mi caso, claro, ¿cómo yo me
Speaker A
llamo? Yo me llamo en BushCrow, pues en mi caso me llamo Pingüino de Mario, ¿no?
Speaker A
Me llamo por aquí Pingüino de Mario. Perfecto. Así que pongo pingü[email protected]. Ponemos nuestro nombre de usuario con el correo de BCR Ninja. Perfecto.
Speaker A
Contraseña, la que queramos. Bien, nos hacemos una cuenta y ahora tenemos por aquí el típico mensaje de, "Oye, confirma tu correo electrónico. Te hemos enviado un correo." Claro, yo puse un correo de Bookroom Ninja. ¿Dónde dónde me habrá llegado eso? Vamos a nuestro
Speaker A
correo desde el cual estemos registrados en Bookcraoud y fijaros por aquí. Este es mi correo personal, eh, ojo, eh, este es mi correo personal, pero por aquí tenemos Bookro Relay. aquí y el correo de Bit Panda en este caso del objetivo,
Speaker A
me llegó básicamente a mi correo personal, que esto es un correo de Gmail, pero bueno, se hizo esa redirección y claro, se envía al correo donde yo esté donde yo tengo la cuenta hecha en Busc. Entonces, bueno, yo por
Speaker A
aquí pues podría confirmar el correo y listo, ya lo tendríamos, cuenta hecha por aquí, ¿no? Bueno, ahora vamos a suponer que ya comenzamos a hacer la auditoría, que estamos revisando, pues oye, ¿dónde alguna vulnerabilidad, etcétera, etcétera. Bueno, otra cosa a
Speaker A
tener en cuenta, bueno, yo lo primero en buso pues el scope porque si no es un rollo, es decir, vamos aquí al scope y yo pues voy a poner en este caso bitpanda.com que es nuestro objetivo, ¿no? Damos aquí, ponemos Sh, incluimos,
Speaker A
bueno, pues todos los subominios y bueno, limpiamos todo el histórico. Y bien, ¿qué pasa? que yo, por ejemplo, pues aquí voy a hacer pues bueno, voy a refrescar esta página, ¿no? Por ejemplo, aquí pues eh refresco y tengo la
Speaker A
petición por aquí en Bushwing, ¿no? Vamos a suponer que estamos auditando este end point por aquí, ¿no? Por ejemplo, no es el caso, pero bueno, yo voy a mandar esto al repeater. Lo ideal es utilizar básicamente la eh cabecera
Speaker A
del user agent que nos habían sugerido en el programa. Ver y si vamos aquí a las instrucciones del programa, pues por aquí tenemos esto. Dice, "Oye, añad cabecera." Bueno, añade esta en verdad, o sea, sería esta. Vamos aquí, copiamos,
Speaker A
pegamos, vamos aquí a Bursuit y pegamos esta cabecera. Pero aquí, básicamente en vez de poner eh researcher, pues ponemos nuestro correo de Bookro Ninja, que en mi caso es pingüino de Mario.
Speaker A
Bookro-pingü[email protected]. Entonces ahora yo puedo eh hacer pues ataques y ellos pues lo más seguro es que tengan un equipo de shock, un equipo de ciberseguridad defensiva y claro, pues cuando vean que tenemos esta cabecera van a decir, "Vale, esto es un
Speaker A
falso positivo porque es alguien haciendo bugunty desde Bugcrof, así que todo guay." Vale, ahora en este vídeo eh quiero compartir con vosotros algo pues que yo considero de mucha utilidad, sobre todo quienes queréis pues empezar a practicar en entonos reales, pero
Speaker A
tenéis el problema que bueno, quizás la barrera de entrada para empezar en el Bubonti es muy alta porque ya a mí pues me está llegando a costar mucho encontrar bugs y eso ya que llevo unos años en este mundillo, no me quiero ni
Speaker A
imaginar pues alguien que lleve unos meses y que quiera pues encontrar pues fallos reales en empresas. cuesta mucho, cuesta mucho. Hoy quiero compartir con vosotros un truco, sobre todo, bueno, para quienes estéis empezando, pero que a su vez no os conforméis únicamente con
Speaker A
hacer CTF, sino que también queréis pues encontrar fallos de seguridad en aplicaciones que se utilizan, en aplicaciones reales, ¿no? Un truco que yo tengo es el siguiente. Veréis, una cosa que yo a veces hago también para ensayar y bueno, para aprender dentro de
Speaker A
en todos reales, pues es lo siguiente, es ir a Jithub Vulnerability. Veréis, esto es muy interesante porque además así a lo mejor conseguís que os den algún CVE, ¿no? Entonces, entramos en esta página y fijaros aquí lo que
Speaker A
tenemos. Tenemos un montón de reportes que se hacen como si esto fuera a hacer Bugunty pero sin cobrar, pero son reportes que se hacen a herramientas que existen, que son herramientas que están pues en repositorios de GitHub.
Speaker A
Entonces, esto es muy interesante porque si por ejemplo vosotros encontráis algún bug, algún bug real, podéis ganaros un CV. Yo ya encontré ya un montón de de bugs y estoy ahí pues eh enviando reportes porque la verdad que me encanta
Speaker A
y es mucho más fácil encontrar por aquí bugs en comparación a encontrarlo pues en plataformas de Bugy, porque obviamente no es igual auditar una aplicación que tienes a cientos y cientos de de expertos pues también auditando que pues bueno, un repositorio
Speaker A
en GitHub que hay muchas menos personas, ¿no? Mira, por ejemplo, aquí tenemos este, bueno, este pequeño reporte que pone listable to store XS, etcétera, etcétera. Podemos entrar aquí, por ejemplo. Y bueno, pues aquí, bueno, yo podría investigar en qué aplicación se
Speaker A
encontró este bug. Claro, lo que aquí está, obviamente esto ya está corregido, pero ¿qué pasa? Que yo puedo hacer lo siguiente, por ejemplo, Lismon, ¿vale?
Speaker A
Vamos a poner Lismk GitHub, por ejemplo. Y aquí tengo el repositorio. Tengo pues el repositorio y yo por aquí puedo esto bajármelo en local y hacer todo tipo de pruebas. Por ejemplo, yo aquí en Codía pues bueno, voy a pillarme el
Speaker A
repositorio, me lo clono por aquí, entramos y bueno, pues por lo general suelen tener pues un archivito de Docker Compose para poder desplegarlo de forma automática. Entonces yo lo que haría sería un sudo Docker compose eh appo men
Speaker A
D. Entonces yo por aquí con un comando me lanzo toda la aplicación. Ahora diréis, "Vale, ¿dónde está corriendo esto?" Bueno, Docker PS por aquí, bueno, sudo Docker PS y bueno, pues la interfaz que viene a ser esta, pues corre por el
Speaker A
puerto 9000. Así que nada, vamos aquí a navegador, ponemos local host 9000 y tenemos la aplicación. A partir de aquí podemos auditarla a más no poder. Yo, por ejemplo, pues voy a hacerme aquí una cuenta y bueno, pues aquí podremos
Speaker A
auditarla todo en local. Yo estoy ya yo estuve auditando, de hecho reporté alguna que otra cosilla que obviamente no voy a compartir por aquí, pero bueno, es un ejemplo que doy, ¿no? Entonces, un truco, eh, ahora mismo si vais a
Speaker A
Bursuit, eh, y bueno, pues aquí eliminamos el scope. Fijaros que, bueno, voy a eliminar todo, eh, por aquí elimino todo. Si yo, por ejemplo, recargo esta página, veis que el tráfico no me llega por aquí en Bursuite. No me
Speaker A
llega en Bullsituite. ¿Cómo podemos arreglar esto? Esto pasa por una sencilla razón y es porque estamos aquí poniendo local host. Lo que yo recomiendo hacer es lo siguiente, consultar cuál es vuestra IP de máquina atacante, que en mi caso pues es esta
Speaker A
IP. Esta es mi IP privada. Entonces aquí pongo, en vez de poner local host pongo mi IP. Y entonces ahora esto funciona de igual forma, funciona exactamente igual, pero la diferencia es que con Burssite eh, bueno, tráfico deberíamos de estar
Speaker A
recibiéndolo. Eh, a veces, bueno, es un pequeño bug que tiene Bursit que simplemente pues tengo que cerrar y abrir. A ver, ahora estoy aquí en Bursit y por aquí lo tengo. Mira, aquí tengo, pues por ejemplo la la primera petición,
Speaker A
¿no? Si yo por ejemplo recargo esta página, pues por aquí en bullsit recibo más peticiones, ¿no? Claro, yo puedo poner dentro del scope mi propio IP, entonces esto es mucho más cómodo. Mira, hago así. OK, proxy. Limpiamos el
Speaker A
historial y ahora únicamente voy a estar recibiendo las peticiones de esta página web, veis. Y ya, pues a partir de aquí yo puedo auditar y puedo probar sin ningún límite porque esto corre en local. Aquí no hay ningún problema.
Speaker A
Cuando yo encuentre algún bug, yo esto puedo reportarlo directamente en GitHub. Y esto es algo que está muy bien porque, bueno, vamos a avisar pues al al dueño de la aplicación y bueno, de paso a lo mejor si lo arreglan pues van a dar van
Speaker A
a entregarnos un CVE, una vulnerabilidad pública porque GitHub tiene pues esa capacidad. GitHub al igual que otras empresas pueden proporcionarnos un CV, ¿no? Yo iría aquí la parte de security y por aquí yo podría reportar la vulnerabilidad. Fijaros que yo aquí pues
Speaker A
en triaje tengo dos, que esto obviamente no voy a enseñarlo, pero bueno, vamos a hacer la simulación de que vamos a reportar pues una vulnerabilidad y esto es igual a cuando hacemos bunto, eh, el campo de la descripción, que esto
Speaker A
también pues lo haríamos en Mardown, la versión donde bueno, pues hayamos pues encontrado un bug, por ejemplo, y luego la severidad, si es algo moderado, si es algo crítico, bueno, un poquito como queramos, ¿no? Y luego pues aquí
Speaker A
enviamos la vulnerabilidad y listo. Y luego pues una vez reportada pues bueno, se verá si os va a salir pues este este pequeño triaje, este pequeño aviso que bueno una vez que se corrija pues el fallo de seguridad os van a avisar y que
Speaker A
a lo mejor os van a dar un CV en función de lo que encontréis. Obviamente tiene que ser en aplicaciones que tengan ciertas estrellas o que tengan cierta popularidad, como por ejemplo, pues puede ser una aplicación de este estilo
Speaker A
que tiene 18,000 estrellas, ¿no? Claro, si esto lo hacéis en un en un repo estrella, pues hombre, no van a daros un CVE y tampoco cuentan mucho pues ese reporte, evidentemente. Pero bueno, hasta aquí el vídeo de hoy. Es un vídeo
Speaker A
donde lo he pues partido en dos, como habéis podido ver. La idea primero era pues ver cómo hacer un reporte, qué cosas hay que tener en cuenta cuando estamos haciendo bugunty y luego también pues este pequeño truco o este pequeño
Speaker A
tip para encontrar fallos en aplicaciones que es mucho más fácil que encontréis cosas y de paso podéis también reportar, no os van a pagar, pero para aprendizaje es ideal. También hay un truco bastante guapo que es encontrar bugs en plugins de WordPress,
Speaker A
que eso es un espectáculo porque hay cientos y cientos de de plugins y un montón de de bugs de fallos de seguridad. Si queréis en próximos vídeos, bueno, podéis aquí ponerlo en los comentarios, podemos hacer un vídeo de cómo eh hacer una auditoría de
Speaker A
seguridad a plugins de WordPress y cómo yo hago para encontrar pues bugs, que ya pues también llevo un tiempo ahí e investigando pues en plugins de de WordPress y está bastante chulo para aprender. Eh, de momento aquí nos
Speaker A
quedamos. Espero que bueno, este vídeo pues hayáis aprendido, que os haya gustado. Y lo último, tenemos muchas cosas en la descripción del vídeo.
Speaker A
Tenemos, bueno, newsletter, que os recomiendo mucho que entréis a la newsletter porque se aprende mucho. Yo os envío un correo al día con cosillas de la de la ciberseguridad. A veces os doy apuntes, incluso os comparto pues un
Speaker A
montón de de tips, de consejos y también tenemos canales de Telegram y de Discord. Y obviamente también tenemos la academia elriconejacker.es para aprender ciberseguridad, paso a paso, desde cero.
Speaker A
Todo lo tenéis en la propia descripción de esta clase. Así que nos vemos en otra ocasión. Hasta la próxima.
Topics:Bug Bountyvulnerabilidadesseguridad informáticaYesWeHackBugcrowdXSSreportes de bugsciberseguridadCVSSBurp Suite
