Aprende cómo conseguir tus primeros ingresos en bug bounty con consejos prácticos y herramientas para encontrar vulnerabilidades en programas reales.
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
- El bug bounty es una forma legítima de ganar dinero encontrando fallos de seguridad.
- Elegir programas con muchas funcionalidades aumenta las posibilidades de encontrar bugs.
- Usar herramientas como Burp Suite y sesiones de navegador separadas mejora la eficiencia en la auditoría.
- Es fundamental entender y respetar el scope de cada programa para evitar problemas legales.
- La práctica constante, incluso con poco tiempo diario, puede llevar a encontrar vulnerabilidades valiosas.
What the video covers
- El video explica qué es el bug bounty y cómo obtener ingresos encontrando fallos de seguridad en empresas.
- Se mencionan plataformas populares para bug bounty como HackerOne, Yes Hack, Bugcrowd, Integrity y securo.com.
- El creador comparte su experiencia personal encontrando vulnerabilidades y recibiendo pagos, incluyendo hallazgos en la NASA.
- Se enfatiza la importancia de elegir programas con muchas funcionalidades, como login y carritos de compra, para auditar.
- Se muestra cómo usar filtros en HackerOne para seleccionar programas que pagan por vulnerabilidades.
- Se recomienda usar sesiones de navegador separadas para auditar, con extensiones específicas para facilitar el trabajo.
- Se explica el uso de Burp Suite y Foxy Proxy para interceptar y analizar el tráfico web durante la auditoría.
- Se destaca la importancia de revisar el scope del programa para saber qué objetivos se pueden auditar legalmente.
- El video está dirigido a principiantes que quieren empezar a encontrar y reportar bugs, no a expertos.
- Se ofrecen tips prácticos para organizar el trabajo y maximizar las oportunidades de encontrar vulnerabilidades.
Full Transcript — Download SRT & Markdown
Speaker A
Durante esta última semana dije, voy a hacer un poquito de bug bounty y vamos a intentar encontrar vulnerabilidades en programas reales. Y este fue el resultado. Me han aceptado dos vulnerabilidades. En una nada más ha pagado 10 €. Esta otra sí que tengo, pues, mucha mayor esperanza. Y luego por aquí esta otra tengo mucha esperanza también. Luego también he reportado más vulnerabilidades en otros programas, en otras plataformas, pero bueno, eso todavía pues no voy a dar esa información, pero lo que quiero hoy traeros es un vídeo de cómo encontrar vuestro primer bug. Antes de nada, quiero mencionar que yo no soy experto en esto del tema del bug bounty. En España, pues hay auténticos referentes que me dan, vamos, miles de vueltas, pero creo que, bueno, como ya voy encontrando pues algunos bugs, me van aceptando algunas vulnerabilidades, hace un año, pues también encontré pues dos dentro de la NASA, pues creo que podría ser interesante compartir con vosotros pues mis tips o cómo estoy yo haciendo para encontrar los primeros bugs. Bueno, para quien no lo sepa, ¿qué es esto del bug bounty? ¿De qué estoy hablando aquí? Estoy diciendo cosas muy raras. Bueno, para quien no lo sepa, esto del bug bounty básicamente es una forma de obtener ingresos a base de encontrar fallos de seguridad en empresas, ¿no? Hay muchas plataformas, tenemos, por ejemplo, HackerOne, que viene a ser esta que veis en pantalla, o también tenemos pues Yes Hack, que es otra plataforma o incluso también tenemos Bugcrowd. Bugcrowd también es otra plataforma que tiene muchos más programas, ¿no? También tenemos Integrity, que es otra plataforma distinta, o incluso securo.com, que es otra plataforma que, bueno, pues que además es de España y es donde yo tengo, pues, por ejemplo, alojado Dockerlas para que alguien pues intente hacer bug bounty y encuentre fallos de seguridad. Bueno, con esto lo que yo quiero decir es que durante esta última semana pues estuve dándole caña, más o menos unas 5 horas en total. Al día solía destinar media hora, 40 minutos de intentar encontrar pues vulnerabilidades. Y el resultado ha sido ese. El resultado pues ha sido que más o menos con unas 5 horas de trabajo, pues primero obtuve mucho aprendizaje y luego lo segundo es que por fin pues voy encontrando los primeros bugs, ¿no? Entonces yo en este vídeo vengo a compartiros algunos tips o consejos que creo que os pueden ayudar mucho para encontrar vuestro primer bug. Este vídeo está enfocado, ¿no?, a gente que sea experto en el bug bounty, porque obviamente no va a aprender cosa, pero si estás en un punto en el que te gustaría pues encontrar algunos fallos, empezar a encontrar cosas, empezar a reportar, aunque no sean cosas críticas, pero al menos que sea bueno, pues algo vulnerable, pues este vídeo creo que es para ti. Entonces, vamos a ver paso a paso cómo encontrar nuestro primer bug. Bien, vamos a comenzar viendo pues cómo yo suelo hacer una enumeración de los objetivos y en qué cosas yo suelo fijarme para empezar a atacar un objetivo u otro, porque obviamente hay programas que puede que no se encajen más o programas que sea más complicado encontrar un fallo de seguridad. Veréis, yo lo que primero suelo hacer es fijarme en aquellos programas donde puedo, digamos, probar muchas cosas. Con esto, ¿a qué me refiero? Me refiero, pues, a poder hacerme una cuenta, poder iniciar sesión. Si por ejemplo tienen pues imaginemos carritos, por ejemplo, pues pasarelas de pago, un carrito donde añadir productos, un lugar donde puedo pues poner un producto en favoritos, ese tipo de programas son bastante jugosos porque tienen muchas funcionalidades detrás y nosotros podemos auditar mucho. Obviamente no es lo mismo pues auditar una web que no tenga ningún login y que apenas tenga nada que auditar una web que tenga muchísimas funcionalidades. Entonces yo es algo que suelo fijarme mucho. Bueno, yo pues aquí estoy en HackerOne, que quizás es la plataforma más grande que hay pues para practicar bug bounty. Entonces, pues aquí yo suelo hacer un filtro que es poner Bug Bounty program, ¿no? Porque tenemos VDP. VDP es igual, pero no te pagan, es decir, son programas que no te pagan. Lo ideal es pues poner bug bounty y entonces bueno, pues aquí lo ponemos, ¿no? Y nada, pues simplemente hacemos aquí un clic en buscar y aquí tenemos muchísimas empresas que dicen, "Oye, yo estoy aquí anunciado, tengo pues un scope, quiero que encuentres fallos pues bueno, dentro de la legalidad, ¿no? Vamos, pues, por ejemplo, a hacer el pequeño ejercicio con Dyson, por ejemplo, ¿no? Que además estuve yo echándole un ojo el otro día, no encontré nada, tampoco estuve mucho tiempo, pero bueno, vamos a echarle un ojo porque por aquí sí que tenemos un lugar para inicio sesión. Bueno, obviamente no voy a mostrar ninguna vulnerabilidad pública, eso es algo evidente, pero sí que voy a mostraros pues ese proceso que yo suelo seguir, ¿no? Bien, vamos a ver aquí qué detalles tenemos en un programa y lo primero que tenemos que fijarnos es en el scope. Obviamente tenemos que ir al scope y tenemos que ver pues dónde podemos revisar y dónde no podemos revisar, ¿no? Bueno, aquí vemos pues todo lo que podemos ver que bueno, vemos que hay un montón de objetivos y bueno, a mi juicio Dyson pues por ejemplo viene a ser un programa bueno para auditar porque tiene muchas cosas, hay un montón de objetivos y además pues dentro de muchos de ellos podemos crearnos una cuenta y podemos hacer muchas pruebas, ¿no? Para hacer bug bounty yo tengo mi sesión de navegador que viene a ser esta, que esta es la mía personal. Como veis aquí pues tengo marcadores pues de la academia, de Dockerlas, etcétera, etcétera. Yo lo que suelo hacer es tener una sesión del navegador totalmente diferente para poder pues auditar esto, ¿no? Entonces, ¿qué pasa? Que yo lo que hago, como yo estoy en Linux, tengo la ventaja que puedo tener pues el navegador Firefox instalado por los repositorios de apt y otro idéntico instalado por Flatpak. Entonces, yo lo que hago es un Flatpak instalar Firefox. Esto si estáis en Windows, pues bueno, elegís, por ejemplo, la versión Firefox Nightly, por ejemplo, o la de pues la versión de desarrollador. Tampoco tiene por qué ser Firefox, también puede ser el Chrome. La idea es tener una sesión totalmente separada dentro de navegador para hacer bug bounty y ahí guardar todo dentro de los marcadores, porque también además vamos a tener muchas extensiones. Entonces es un poco lo que yo suelo hacer. Entonces, como veis por aquí, yo tengo pues un Firefox totalmente independiente al que yo tengo por aquí, que es pues el mío personal, ¿no? Entonces, claro, yo haciendo esto lo que hago pues es iniciar sesión con una cuenta y entonces así tengo una sesión totalmente independiente con todos estos marcadores y luego sobre todo con estas extensiones de por aquí. Yo solo utilizo estas extensiones. Vamos a ir viendo pues poco a poco para qué sirve cada una de ellas porque esto tiene pues mucha utilidad. Veréis. Vale, lo primero que yo hago es lo siguiente. Si yo tengo un objetivo como puede ser Dyson, es ir a Burp Suite y ponerlo dentro del scope. Veréis, yo si por ejemplo abro por aquí Burp Suite, gracias a que yo tengo la extensión Foxy Proxy, que es esta, y digo, "Vale, quiero que todo el tráfico pase pues por Burp." Esto es una cosa que ya lo hemos aprendido, pues haciendo CTFs y en muchos vídeos, etcétera, etcétera. Entonces, una vez que yo tenga todo el tráfico pasando por Burp, lo suyo es ir a la parte de target scope [música] y aquí añadir pues nuestro objetivo que es en mi caso Dyson, o bueno, el que sea, ¿no? Yo voy aquí, voy a poner que quiero que me incluyas los subdominios. Imaginemos que encuentro pues un API. Yo quiero que esas peticiones quiero también pues verlas, ¿no? Entonces si yo aquí pongo okay, bueno, aquí yo pongo y es si yo pongo okay en la parte de HTTP History, yo voy a limpiar todo el histórico. Entonces ahora mismo, si yo, por ejemplo, recargo en alguna página fuera de Dyson, pues en principio,
Speaker A
mucha mayor esperanza. Y luego por aquí esta otra tengo mucha esperanza también. Luego también he reportado más vulnerabilidades en otros programas, en otras plataformas, pero bueno, eso todavía pues no voy a dar esa información, pero lo que quiero hoy
Speaker A
traeros es un vídeo de cómo encontrar vuestro primer bug. Antes de nada, quiero mencionar que yo no soy experto en esto del tema del bugy. En España, pues hay auténticos referentes que me dan, vamos, miles de vueltas, pero creo
Speaker A
que, bueno, como ya voy encontrando pues algunos bugs, me van aceptando algunas mundabilidades, hace un año, pues también encontré pues dos dentro de la NASA, pues creo que podría ser interesante compartir con vosotros pues mis tips o cómo estoy yo haciendo para
Speaker A
encontrar los primeros bugs. Bueno, para qui no lo sepa, ¿qué es esto del bubon?
Speaker A
¿De qué estoy hablando aquí? Estoy diciendo cosas muy raras. Bueno, para quien no lo sepa, esto del Bubonti básicamente es una forma de obtener ingresos a base de encontrar fallos de seguridad en empresas, ¿no? Hay muchas plataformas, tenemos, por ejemplo,
Speaker A
Hacker One, que viene a ser esta que veis en pantalla, o también tenemos pues Jes Hack, que es otra plataforma o incluso también tenemos Bushcrow.
Speaker A
Búscalo también es otra plataforma que tiene muchos más programas, ¿no? También tenemos Integrity, que es otra plataforma distinta, o incluso securo.com, que es otra plataforma que, bueno, pues que además es de España y es donde yo tengo, pues, por ejemplo,
Speaker A
alojado Dockerlas para que alguien pues intenta hacer bugy encuentre fallos de seguridad. Bueno, con esto lo que yo quiero decir es que durante esta última semana pues estuve dándole caña, más o menos unas 5 horas en total. Al día
Speaker A
solía destinar media hora, 40 minutos de intentar encontrar pues vulnerabilidades. Y el resultado ha sido ese. El resultado pues ha sido que más o menos con unas 5 horas de de trabajo, pues primero obtuve mucho aprendizaje y luego lo segundo es que por fin pues voy
Speaker A
encontrando los primeros bugs, ¿no? Entonces yo en este vídeo vengo a compartiros algunos tips o consejos que creo que os pueden ayudar mucho para encontrar vuestro primer bug. Este vídeo está enfocado, ¿no?, a gente que sea experto en el bubonti, porque obviamente
Speaker A
no va a aprender cosa, pero si estás en un punto en el que te gustaría pues encontrar algunos fallos, empezar a encontrar cosas, empezar a reportar, aunque no sean cosas críticas, pero a menos que sea bueno, pues algo
Speaker A
vulnerable, pues este vídeo creo que es para ti. Entonces, vamos a ver paso a paso cómo encontrar nuestro primer bug.
Speaker A
Bien, vamos a comenzar viendo pues cómo yo suelo hacer una enumeración de los objetivos y en qué cosas yo suelo fijarme para empezar a atacar un objetivo u otro, porque obvmente hay programas que puede que no se encajen
Speaker A
más o programas que sea más complicado encontrar un fallo de seguridad. Veréis, yo lo que primero suelo hacer es fijarme en aquellos programas donde puedo, digamos, probar muchas cosas. Con esto, ¿a qué me refiero? Me refiero, pues, a
Speaker A
poder eh hacerme una cuenta, poder iniciar sesión. Si por ejemplo tienen pues imaginemos carritos, por ejemplo, pues eh paselas de pago, un carrito donde añadir productos, un lugar donde puedo pues poner un producto en favoritos, ese tipo de programas son
Speaker A
bastante jugosos porque tienen muchas funcionalidades detrás y nosotros podemos auditar mucho. Obviamente no es lo mismo pues auditar una web que no tenga ningún login y que apenas tenga nada que auditar una web que tenga muchísimas funcionalidades. Entonces yo
Speaker A
es algo que suelo fijarme mucho. Bueno, yo pues aquí estoy en Hacker One, que quizás es la plataforma más grande que hay pues para practicar Bug Bounty.
Speaker A
Entonces, pues aquí yo suelo hacer un filtro que es poner Bunty program, ¿no? Porque tenemos VDP. VDP es igual, pero no te pagan, es decir, son eh programas que no te pagan. Lo ideal es pues poner bugunty y entonces bueno, pues aquí lo
Speaker A
ponemos, ¿no? Y nada, pues simplemente hacemos aquí un clic en buscar y aquí tenemos muchísimas empresas que dicen, "Oye, yo estoy aquí anunciado, tengo pues un scope, quiero que encuentres fallos pues bueno, dentro de la legalidad, ¿no? Vamos, pues, por
Speaker A
ejemplo, a hacer el pequeño ejercicio con con Dyson, por ejemplo, ¿no? Que además estuve yo echándole un ojo el otro día, no encontré nada, tampoco estuve mucho tiempo, pero bueno, vamos a echarle un ojo porque por aquí sí que
Speaker A
tenemos un lugar para inicio sesión. Bueno, obviamente no voy a mostrar ninguna vulnerabilidad pública, eso es algo evidente, pero sí que voy a mostraros pues ese proceso que yo suelo seguir, ¿no? Bien, vamos a ver aquí qué detalles tenemos en un programa y lo
Speaker A
primero que tenemos que fijarnos es en el scope. Obviamente tenemos que ir al scope y tenemos que ver pues dónde podemos revisar y dónde no podemos revisar, ¿no? Bueno, aquí vemos pues todo lo que podemos ver que bueno, vemos
Speaker A
que hay un montón de objetivos y bueno, a mi juicio Dyson pues por ejemplo viene a ser un programa bueno para editar porque tiene muchas cosas hay un montón de objetivos y además pues dentro de de muchos de ellos podemos crearnos una
Speaker A
cuenta y podemos hacer muchas pruebas, ¿no? Para hacer Bubonti yo tengo mi sesión de navegador que viene a ser esta, que esta es la mía personal. Como veis aquí pues tengo marcadores pues de la academia, de Dockerlas, etcétera,
Speaker A
etcétera. Yo lo que suelo hacer es tener una sesión del navegador totalmente diferente para poder pues auditar esto, ¿no? Entonces, ¿qué pasa? Que yo lo que hago, como yo estoy en Linux, tengo la ventaja que puedo tener pues el
Speaker A
navegador Firefox instalado por los repositorios de aptir idéntico instalado por Flatpack. Entonces, yo lo que hago es un Flatpack Instal Firefox. Esto si estáis en Windows, pues bueno, elegís, por ejemplo, la versión Firefoce de Nightly, por ejemplo, o la de pues la versión de
Speaker A
desarrollador. Tampoco tiene por qué ser Firefoce, también puede ser el Chrome. La idea es tener una sesión totalmente eh separada dentro de navegador para hacer bubunt y ahí guardar todo dentro de los marcadores, porque también además vamos a tener muchas extensiones.
Speaker A
Entonces es un poco lo que yo suelo hacer. Entonces, como veis por aquí, yo tengo pues un Firefox totalmente independiente al que yo tengo por aquí, que es pues el mío personal, ¿no?
Speaker A
Entonces, claro, yo haciendo esto lo que hago pues es iniciar sesión con una cuenta y entonces así tengo una sesión totalmente independiente con todos estos marcadores y luego sobre todo con estas extensiones de por aquí. Yo solo utilizar estas extensiones. Vamos a ir
Speaker A
viendo pues poco a poco para qué sirve cada una de ellas porque esto tiene pues mucha utilidad. Veréis. Vale, lo primero que yo hago es lo siguiente. Si yo tengo un objetivo como puede ser Dyson. es ir a Bursuit y ponerlo dentro del scope.
Speaker A
Veréis, yo si por ejemplo abro por aquí Bursuit, gracias a que yo tengo la extensión Foxy Proxy, que es esta, y digo, "Vale, quiero que todo el tráfico pase pues por Burp." Esto es una cosa que ya lo lo hemos aprendido, pues
Speaker A
haciendo CTFs e en muchos vídeos, etcétera, etcétera. Entonces, una vez que yo tenga todo el tráfico pasando por Burp, lo suyo es ir a la parte de target scope [música] y aquí añadir pues nuestro objetivo que es en mi caso
Speaker A
Dyson. o bueno, el que sea, ¿no? Yo voy aquí voy a poner que quiero que me incluyas los subominios. Imaginemos en que encuentro pues un api.
Speaker A
Yo quiero que esas peticiones quiero también pues verlas, ¿no? Entonces si yo aquí pongo okay, bueno, aquí yo pongo y es si yo pongo okay en la parte de HTTP History, yo voy a limpiar todo el histórico. Entonces ahora mismo, si yo,
Speaker A
por ejemplo, recargo en alguna página fuera de Dyson, pues en principio, veis, aquí no recibo nada. Voy a recibir únicamente el tráfico que venga de Dyson. Así que vamos a ello. Yo voy ahora mismo pues entrar por ejemplo a mi
Speaker A
objetivo. Yo lo que haría pues entro por aquíon. Y vemos que ahora todo esto que estamos por aquí recibiendo con Bursuit son peticiones del dominio de Dyson. No, claro, aquí no hay gran cosa porque esto simplemente estamos entrando dentro de
Speaker A
la página principal, ¿no? Pero una cosa que podemos hacer es pues revisar rápidamente si tenemos algún lugar de iniciar sesión como puede ser en este caso. Yo en esto suelo pues e fijarme mucho porque si no hay ninguna forma de
Speaker A
iniciar sesión en un objetivo, pues hombre, pocas cosas vamos a encontrar, ¿no? Entonces, bueno, vamos a entrar por aquí y lo primero que hago es hacerme una cuenta. Vamos a hacernos una cuenta para ver cómo funciona esto por detrás,
Speaker A
¿no? Y ya estaremos autenticados. Bien, ¿qué pasa? Que yo ahora mismo todo lo que estuve haciendo en este proceso de de registro lo tengo por aquí en Bursuit. Entonces, claro, esto puede ser interesante porque yo aquí puedo aplicar
Speaker A
un filtro y si pongo, por ejemplo, register, podemos ver si hay algún point o alguna llamada, alguna API de eh pues hacer el registro. Y bueno, pues por aquí a simple vista yo encuentro una petición interesante. ¿Qué hice yo por
Speaker A
aquí? Pues yo lo que hago es lo siguiente. Yo voy aquí pues a este filtro y pongo pues por ejemplo el correo que yo pues puse para hacerme una cuenta. Yo es algo que que bueno suelo hacer. Entonces si aplico este filtro
Speaker A
aquí voy a ver todas estas peticiones donde se está utilizando el correo que utilicé pues para hacerme una cuenta.
Speaker A
Claro, viendo el método post, yo sé que bueno, esta es la petición donde se envía el correo para quizás comprobar si existe o no mi usuario no. Entonces, claro, ¿qué pasa? O sea, que yo pues por aquí tengo esta petición, ¿no? Esta
Speaker A
petición pues puede ser un ejemplo de algo interesante porque fijaros que dentro de la respuesta me dice, "Uy, username free." Ojo, esto no sé si es eh vulnerable o no, porque estoy improvisando totalmente, o sea, no lo sé, pero sí que bueno, esto podría ser
Speaker A
interesante, pues quizás comprobar si hay algún tipo de read limit y poder si, bueno, pues ver si podemos enumerar usuarios dentro de el sistema. Por ejemplo, yo esto podría pues pasarlo al repeater o por aquí pues podría esto
Speaker A
subrayarlo, por ejemplo, lo voy a subrayar, voy por aquí, hago un clic en Sens, entonces pues voy viendo un poquito cómo funciona. Esto dice, vale, cuenta existente. Entonces claro, yo lo que podría hacer sería, pues aquí en vez
Speaker A
de poner, pues, por ejemplo, un correo que exista, pues poner un correo que no exista y ver un poco pues cómo funciona esta respuesta. Bueno, dice por aquí us free, si pongo un correo que exista, yo por ejemplo tengo un correo que se llama
Speaker A
bounty [email protected], que lo empleo mucho para hacer experimentos y pruebas. Pues vamos a ver qué me da es dice, uy, cuenta existente.
Speaker A
Pues si aquí, por ejemplo, no hay ningún tipo de read limit, esto puede suponer pues una pequeña vulnerabilidad. Fijaros qué rápido, en qué poco tiempo pues hemos encontrado algo que, ojo, yo creo que sinceramente si reportamos esto no
Speaker A
lo van a pagar porque esto es demasiado leve, es un pequeño fallo de seguridad, pero no es tan grave como para que nos lleguen a pagar. Lo ideal sería pues encontrar otro fallo de seguridad y poder eh combinarlo con este que hemos
Speaker A
encontrado. Claro, yo podría como mínimo sí que podríamos aquí comprobar si existe algún tipo de read límite, es decir, si yo voy enviando muchísimas eh e muchas peticiones y veo que eh pues el eh elpoint de la API no me bloquea, pues
Speaker A
esto, a ver, es un poco mala práctica, pero bueno, mira, pues hemos encontrado algo, una posible enumeración de usuarios. Entonces, yo lo que suelo hacer cuando encuentro algo, pues dentro de la pestaña del repeater pongo user enumeration o lo que sea, ¿no? Insisto
Speaker A
que esto no creo que no nos lo paguen, esto no tiene tanta criticidad, es decir, para que nos paguen por algo haciendo bubunt tiene que ser algo que haga pues más daño, digamos, al objetivo. Así que bueno, sigamos mirando
Speaker A
durante este proceso de registro. Yo por aquí pues tengo todas las peticiones que han ido ocurriendo. Lo que debemos hacer es pues investigar. Hay que mirar, hay que mirar muchas peticiones. Es decir, como veis, el trabajo no es andar
Speaker A
navegando por la web que que también, sino mucho andar navegando por Bullshit y analizar pues el tráfico de las peticiones, ¿no? Es decir, qué qué ocurre en cada petición, qué ocurre en cada respuesta y así todo el rato, ¿no?
Speaker A
Pero chicos, antes de seguir ya sabéis lo que toca y es que, bueno, Balu y yo tenemos un mensaje que daros y es que Rayola Netws está a punto de dar su mensaje de sponsor. Así que vamos con el
Speaker A
mensajito de 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 nuestra academia de ciberseguridad, elriconddehacker. Además de ser nuestro patrocinador oficial, nos ofrecen distintas tarifas de hosting
Speaker A
SSD, por tanto, tenemos una alta velocidad asegurada dentro de nuestra página web. 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
Speaker A
comenzar con un hosting más un dominio a un precio 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
Speaker A
ideales. Además, también, como podemos ver dentro de su 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
Speaker A
incluido. También en caso de que cuentes ya con otro 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
Speaker A
información, las distintas tarifas dependiendo de nuestras necesidades. Tenemos desde la 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
Speaker A
Networks es ideal. Bueno, perfecto, ya he visto este buen mensaje. Pues ahora ya continuamos con el vídeo. A que sí, Balu, dice que sí. Vamos a ver cómo podemos seguir con el bug Bonti, así que venga, vamos a darle caña. Mira, veréis,
Speaker A
por aquí tenemos otro ejemplo de petición que, ojo, no sé si esto es vulnerable o no, eh. Aquí no quiero exponer nada, pero bueno, sí que me llama la atención, ¿no? Vemos aquí pues esta petición que vemos pues bueno,
Speaker A
user etcétera etcétera etcétera. Vemos aquí un ID, lo cual es algo un poquito curioso y vemos un Jason W token. Es decir, si yo bajo por aquí, lo habéis visto antes, a ver dónde está.
Speaker A
Aquí, aquí lo tenemos. Veréis, un Jason Went token. Yo pues al menos estos Jason W tooken suelo analizarlos dentro de una plataforma que se llama Jasonwetoken.io.
Speaker A
Bien. Eh, básicamente un Jon Token es una forma de mantener pues bueno, una sesión abierta dentro de una web, pero toda la información no se guarda en el servidor, sino que se guarda dentro del JS we Token. Yo puedo ver esa
Speaker A
información así pegándolo directamente. Entonces, por aquí veo todo esto, veo muchísima información que quizás podemos intentar encontrar alguna vulnerabilidad. Bien, ¿qué suelo yo probar con los Jason Qu to Token?
Speaker A
Tampoco aquí suelo extenderme mucho, pero al menos si tengo hacer pues una prueba que es cambiar el algoritmo de este que me trae por defecto a poner no.
Speaker A
De esta forma si el servidor me lo acepta yo podría suplantar la identidad de cualquier otro usuario. Esto es eh demasiado crítico el hecho de que funcione, pero bueno, al menos vamos a ver un poquito cómo sería. Ya os digo yo
Speaker A
que en este ejemplo no es vulnerable, pero eso es lo de menos. El tema está ver cómo se hace. Yo para modificar eh elementos de un Jason Web Token suelo utilizar una web que se llama Jason Web Token. Bueno, en verdad la tengo por
Speaker A
aquí en en favoritos esta Jason W Token Edition. Bueno, edito. Entonces yo lo que hago es pues copio todo el Jason Qu to Token y simplemente lo pego por aquí.
Speaker A
Vemos la misma información que veíamos en la página de Jason We tooken, pero yo por aquí pues donde pone alg, yo puedo poner puedo poner no y esto lo que hago es eliminar la firma de Jason W tooken y
Speaker A
así puedo eh suplantar a cualquier otro usuario eh bueno, sin saber nada, es decir, de una forma sers sencilla. Lo que debo hacer es eliminar esta última línea que es de la firma de el JSON Web Token, ¿no? Básicamente veis que al
Speaker A
quitar la última línea, el campo de de N pues acaba de desaparecer, ¿no? ¿Qué puedo hacer yo ahora? Pues puedo copiar todo este Jason Go to Token, puedo ir a mi Pursuite y donde tengo por aquí pues pegado el este Jason W token voy a
Speaker A
mandarlo al repeater y hago una prueba. Primero envío, envío esta petición. Vemos que me devuelve un OK. Vamos a ir a la parte de el token, es decir, que está aquí todo esto. Voy a probar en quitarlo. Voy a pegar el nuevo
Speaker A
que yo acabo de de crear y a ver si me responde con un OK o no. Me responde con un okay. Y bueno, la cosa es un poquito prometedora. Yo os digo que no va a ser vulnerable porque esto no significa que
Speaker A
ya quitando la firma del el Jon Token pues podamos eh ya pues comprobar si es vulnerable o no. Ahora tenemos que mirar otras cosas porque depende cómo esté configurado el servidor, pues es posible que no tenga en cuenta o que esté
Speaker A
ignorando nuestro JSON Web Token, pero que sí que tenga en cuenta pues las cookies de sesión. Es decir, hay que ver si el servidor pues da prioridad al JSOV token o da prioridad a las cookies de de sesión. Yo voy a eliminar varias cookies
Speaker A
que tengo por aquí, como esta de Planet Directory Pro. Esta es una cookie que voy a eliminar por aquí. Perfecto.
Speaker A
También voy a eliminar el SID. Esto lo voy a quitar también. Vamos a hacer aquí esta pequeña prueba. Perfecto. Y voy a eliminar el access token también por aquí. Vamos a eliminarlo. Ahora si el servidor me devuelve un OK, ya la cosa
Speaker A
se va a complicar un poquito más. Voy a probar. Le doy y ahí me dice no autorizado. Esto no es puderable. Pero si aquí me hubiera sacado un OK, esto hubiera sido bien crítico. Pero aún así, aunque hayamos fallado en este intento,
Speaker A
esto ya es un logro, porque el objetivo es aprender a eh comprobar si algo es vulnerable o no, porque si aprendemos esto es cuestión de tiempo que vayamos encontrando cosas. Vale, perfecto. Vamos a dejar un poquito de lado burs y ahora
Speaker A
voy a compartir un poquito con vosotros qué otras cosas yo suelo mirar. Lo que suelo mirar una vez que estoy dentro de una web es las cookies de de sesión. Voy aquí a la parte de inspeccionar del navegador, vamos a la parte de
Speaker A
almacenamiento y pues aquí miro el objetivo que en bueno, en mi caso es Dyson, ¿no? Yo lo que suelo hacer es pues fijarme en estas dos comunas que pone htpoli y se cure por el siguiente motivo. Veréis, yo primero voy a filtrar
Speaker A
aquellas que tengan true y también que tengan true. Bueno, true en la de HTP OLI y en la de secure. ¿Qué significa esto? que una cookie tenga activada eh bueno, el atributo httpoli significa que en caso de encontrar un crossit
Speaker A
scripting podemos robar o podemos capturar esa cookie de sesión. Y si eh en secure aparece también false, significa que la cookie viaja por http.
Speaker A
Ambas cosas son interesantes de mirar. Por ejemplo, en este caso en Dyson, pues bueno, lo tienen bien protegido. Aquí vemos pues esta, bueno, este a sten que tiene pinta que esto es pues principalmente lo que se utiliza para
Speaker A
estar autenticado y bueno, pues tiene activado el achete DPI y él se cure como true, lo cual es una buena práctica.
Speaker A
Esto es algo que nosotros debemos de mirar. Bien, ¿qué hubiera pasado si por ejemplo dentro del atributo HTTP only pone false? Pues eso lo que significa es que tenemos que enfocarnos mucho en encontrar un cross scripting, porque si
Speaker A
encontramos un cross scripting, la eh el impacto que puede tener es mucho mayor a bueno, pues a que el atributo pues tuviera true. Si pone false significa que cualquier usuario podemos robarle la cookie de sesión, entonces obviamente nos van a pagar mucho más. En este caso
Speaker A
en Dyson, como esto lo tiene activado, pues quizás encontrar XSS no va a ser mi máxima prioridad. Bien, una vez que estemos ya pues autenticados, ¿qué cosillas yo suelo revisar? Bueno, yo lo que suelo hacer es ir a la parte de mi
Speaker A
status y por aquí pues suelo intentar colar algún XSS, algún e algún crossit scripting. En este caso ya os digo yo que no va a ser vulnerable porque si no pues no estaría enseñando esto, ¿no?
Speaker A
Pero yo, por ejemplo, pues aquí bueno, pues está bien intentar pues por ejemplo meter un skit alert por ejemplo y a ver qué pasa, ¿no? Por ejemplo, voy aquí y intentaría guardar cambios, pero pero pone por aquí que no pueden procesar la
Speaker A
petición porque, bueno, pues tiene pinta que estamos aquí intentando meter algo malicioso, ¿no? Otra cosa que yo suelo hacer, pues yo suelo hacer un cambio así pequeñito y voy a Bursuit, eh, limpio todo este historial porque ya pues esto
Speaker A
empieza a ser enorme. Lo voy a limpiar por aquí y vamos a ver qué peticiones pues se van enviando por detrás, ¿no? Yo en la parte de apodo, pues esto también lo voy a guardar y pruebo en guardar
Speaker A
cambios. A ver, en bursit cómo se guarda esta información. Yo voy a fijarme en aquellas peticiones que sean del método post, porque yo cuando actualizo un dato, pues eso se hace mediante el método post. Entonces, aquí tenemos un
Speaker A
poco pues dicha petición, ¿no? Yo por aquí tengo justo lo que acabo de de enviar. Bien, este tipo de peticiones suele ser bastante interesantes, pues jugar con ellas desde bullshit. Y bien, porque yo suelo mirar mucho este tipo de
Speaker A
peticiones por una sencilla razón, por la vulnerabilidad IDOR. [música] Un IDOR viene a ser un fallo de seguridad que me permite eh poder consultar datos o hacer alguna acción desde mi cuenta a una cuenta distinta o acceder a un recurso
Speaker A
al que yo no podría acceder. Por ejemplo, desde este lugar quizás podría cambiar directamente el correo electrónico por uno que existe. Yo tengo otra cuenta hecha que es Bounty Penguin.
Speaker A
A lo mejor, bueno, llegaría a funcionar. Voy a probarlo. Le doy y bueno, parece que me pone okay. Pero bueno, otra cosa que se puede probar es pues hacer lo siguiente. Veréis que sería pues meter aquí el email dos veces. ¿Por qué?
Speaker A
Porque, bueno, a veces el servidor pues eh lee el primer correo y dice, "Vale, este es el correcto, pero luego toma en cuenta el segundo." Esto pasa mucho en los idor, de hecho, yo el otro día reporté pues un idor en otro otro
Speaker A
programa y que era pues algo así, es decir, que leía el primer dato para validar y luego aplicaba el cambio en el segundo. Entonces, claro, así podías conseguir unidor. Puede ser, puede colar. Vamos a probar esto a ver qué
Speaker A
pasa. Y bueno, vemos que en este caso tampoco ha funcionado porque si no no estaría enseñándoslo en este vídeo.
Speaker A
¿Veis? Yo por aquí pues recargo la página y no hay nada interesante. Pero, ¿qué más cosas podemos revisar? Pues mucho más podemos ver. Pues podríamos dentro de esta sesión eh cambiar el nombre de usuario a una cuenta distinta.
Speaker A
Bueno, yo para este tipo de cosas solo hacer una prueba y es lo siguiente.
Speaker A
Veréis, yo tengo pues una extensión que se llama Pomfo Fox. Esta extensión lo que hace es dentro de el mismo navegador del Firefo tener dos sesiones. Entonces, así yo puedo probar, es decir, puedo interceptar eh la misma petición con
Speaker A
Bursuit, pero que procede de dos cuentas diferentes. Entonces, yo, por ejemplo, por aquí, pues tengo mi sesión con este correo que tengo por aquí inventado, ¿no? Entonces, voy a esta extensión, a Pum Fox y voy, por ejemplo, a verme un
Speaker A
nuevo contenedor que, fijaros que tiene el colorcito verde. Si yo copio esta URL de de mi objetivo, vais a ver que yo no voy a entrar a mi cuenta, porque esto es como tener pues un navegador totalmente distinto. Y aquí estamos viéndolo. Yo
Speaker A
tengo ya pues cada otra cuenta por aquí. Yo ya pues me la he creado que es esta.
Speaker A
Y entonces fijaros lo que tengo por aquí. Tengo en esta pestaña pues una cuenta y en esta otra pestaña tengo una cuenta distinta, todo dentro del mismo navegador. Esto es realmente útil para probar eh idors. Entonces, claro, ¿qué
Speaker A
pasa? que yo pues por ejemplo a tener pues por aquí esto otra petición, yo desde Bursit voy a estar recibiendo dentro de la parte del HTTP History el tráfico de ambas sesiones y así puedo probar fácilmente vulnerabilidades de
Speaker A
Idor. Vamos a ver un poquito cómo sería esto. Veréis, yo por aquí pues tengo, por ejemplo, esta petición que voy a copiar, bueno, voy esto a mandarlo al repeater y yo lo que hago es pues por ejemplo esta llamarle pues eh usuario
Speaker A
uno o bueno, por ejemplo, mi usuario se llama Docker CTF, que es un correo que pego para hacer pruebas. Entonces, pues yo esta petición le pongo este nombre.
Speaker A
Luego voy otra vez a la parte del HTP History y entonces pues copio toda esta URL, voy por aquí, lo pego y voy a buscar a ver eh en cuál de ellas está el nuevo correo de Buny Penguin, que viene
Speaker A
a ser pues este de por aquí. Claro, ¿qué pasa? Que tengo que hacer algún cambio dentro de pues mi perfil, ¿no? Para poder interceptar esta petición. Pero bueno, voy aquí pues por ejemplo a interceptar esto. Guardo cambios.
Speaker A
Perfecto. Por aquí pongo pongo un número de teléfono totalmente random y entonces ahora sí que puedo aplicar este filtro.
Speaker A
Vamos aquí. Aplicamos el filtro. Perfecto. Y por aquí tenemos la petición, la misma, pero con el otro correo. Yo esto lo voy a mandar al repeater. Y entonces esto es muy muy cómodo porque tenemos dentro de el bursuite
Speaker A
dos peticiones que son iguales donde se cambian información pero de dos cuentas diferentes para aprobar de una forma muy cómoda la vulnerabilidad de oror.
Speaker A
Tenemos aquí una sesión y por aquí tenemos otra sesión. Entonces, claro, yo aquí ya puedo hacer muchas bas. Por ejemplo, lo primero pues aquí en vez de poner Docker CTF, voy a poner pues por ejemplo Bunty Penguin, que es el correo
Speaker A
de la otra cuenta dentro de la sesión de la cuenta de Docker CTF, por ejemplo, ¿no? Yo envío esto. Bueno, vemos que en principio pues no va a funcionar porque si yo pues por ejemplo aquí e recargo, pues el correo sigue siendo el mismo.
Speaker A
Pero bueno, es algo interesante a probar. Otra cosa que yo podría hacer pues sería eh, por ejemplo, dentro de la sesión de Docker CTF poner en el nombre Hacket, pero el correo poner Bonti Penguin. Si la cuenta de Buny Penguin se
Speaker A
cambia el nombre a hack, pues sería vulnerable. No es el caso, no va a funcionar. Ya os lo digo yo.
Speaker A
¿Veis? Yo voy por aquí, recargo esta página, pero el nombre sigue siendo el mismo, no ha funcionado, pero bueno, es algo interesante a probar. Bien, por aquí otra cosa que puede ser vulnerable dentro de esta petición, fijaros que
Speaker A
tengo un campo de password, es decir, eh lo que suele ocurrir es que dentro de una página web segura te pide tu contraseña actual y luego que le des tu contraseña nueva. En este caso es un poco extraño que me ponga pues una
Speaker A
contraseña y ya. Yo puedo probar en cambiarla de esta forma. Yo, por ejemplo, voy a probar pues en poner pues un carácter más, por ejemplo, ¿no? Voy a darle por aquí y bueno, parece que ha funcionado. Puedo probar en recargar
Speaker A
esta página y primero vemos que seguimos dentro de la sesión, pero bueno, esto quizás puede que no se me haya cambiado la contraseña. Podemos probarlo. Yo lo que voy a hacer va a ser lo siguiente.
Speaker A
Lo mismo, me abro mi extensión de Pom Fox, me abro pues otra nueva pestaña por aquí y voy a probar en entrar con la cuenta de Bounty Penguin con la contraseña nueva que acabo de poner desde Bursit. A ver si funciona. Si esto
Speaker A
funciona, sería una pequeña vulnerabilidad. Vamos a probar. Voy a probar. Y no ha funcionado. Perfecto.
Speaker A
Esto no ha sido vulnerable. Si pongo la contraseña correcta, pues ahora ya estamos dentro de la página. Perfecto, no funcionó. mejor, porque así puedo mostrarlo en el vídeo.
Speaker A
Bueno, chicos, otra cosa que yo suelo probar, que también es eh algo bastante interesante, es la vulnerabilidad Crossside Request Fogery. Ya lo hemos visto pues en mi canal, en otros vídeos o en la academia, en directos, bueno, estamos siempre viéndolo. es un tipo de
Speaker A
bueno, es básicamente pues un fallo de seguridad que permite eh bueno que la víctima desde un una ubicación externa si se hace clic un botón que se le cambie pues a lo mejor su contraseña o que se le cambie su nombre dentro de su
Speaker A
de su cuenta. Es una vulnerabilidad pues bastante chunga, ¿no? ¿Qué pasa? Que yo pues bueno, dentro de esta petición yo pues como estáis viendo pues puedo cambiar mis datos, mi información. ¿Qué pasa si yo, pues, por ejemplo, elimino
Speaker A
el crosside Record for token por aquí? ¿Qué pasa si yo elimino esto? Si yo, por ejemplo, elimino esto y el servidor me sigue dejando eh cambiar mi usuario, mi correo etcétera etcétera significa que está puesto de paripé y eso sería un
Speaker A
poquito chungo, ¿no? Voy a probarlo. Le doy y pone forbiden. No puedo hacerlo. Perfecto. Esto es esto es una buena noticia para eh Dyson, ¿no? Mira, aquí pone eh fil to validate CSRF token, como debe ser, ¿no? Eh, otra cosa que también
Speaker A
podemos probar, bueno, voy a poner otra vez el token. Lo acabo de poner otra vez haciendo control Z. Y ahora veis que la petición ha funcionado bien, ¿no?
Speaker A
Podemos también probar y quitarlo por aquí porque veis que, bueno, también se proporciona dentro de esa parte. Le doy y lo mismo me da otra vez el mismo error. Otra cosa que se puede probar, pues bueno, a ver si este crossin
Speaker A
request fory, pues sí, si yo le llego a cambiar el valor por uno aleatorio, a ver si funciona, ¿no? Yo puedo darle y lo mismo dice, "Uy, ha fallado. Sigue siendo esto protegido. Está bien implementado también." ¿Qué más podemos
Speaker A
hacer? Pero bueno, ahora mismo estamos empleando el método post. ¿Qué pasa? Imaginaos que que yo, pues, por ejemplo, elimino por aquí la cabecera de el clay request fory, la elimino por aquí y cambio el método de la petición a GET.
Speaker A
Por ejemplo, si yo le cambio a GET, seguirá pidiéndome eh el token. No lo sé. Vamos a probar. Le doy y dice, "Okay, por aquí." Y bueno, se pone la cosa un poquito interesante porque vemos que cambiándole el método de post a get,
Speaker A
el servidor me devuelve mucha información de mi cuenta. Bueno, veo cosas como credencial ID, CRMID, que pueden ser interesantes. ¿Qué pasa si yo, claro, como estoy empleando el método GET aquí arriba, fijaros, ¿qué pasa si yo le llego a pasar el Creden ID
Speaker A
de otra cuenta diferente? ¿Funcionará? ¿Me sacará información de esa cuenta? No lo sé. Vamos a comprobarlo. Yo lo que voy a hacer va a ser lo siguiente. Voy aquí dentro de la URL y pongo pues barra es barra y bueno, no bueno barra no
Speaker A
ponemos una interrogación para pasar como parámetro el credencial ID, por ejemplo, ¿no? Vamos aquí ponemos igual a y le paso todo el credential ID de mi cuenta. Yo primero voy a verlo con mi propia cuenta, luego ya veré si lo puedo
Speaker A
hacer con cuentas de otras personas. Y bueno, vemos que bueno, no sé, parece que está funcionando. Voy a hacer una prueba. Voy a hacer una prueba. Voy a conseguir el cred ID de mi otra cuenta de la de Bounty Penguin y voy a
Speaker A
pasársela aquí. Y si [música] en la respuesta el servidor me da toda la info de la otra cuenta es unido como una casa. Vamos a probarlo. Vamos aquí a la cuenta de Bounty Penguin que esta es la otra sesión. Y lo mismo, change request
Speaker A
method. Cambiamos al método get. Enviamos esta petición y vemos por aquí, ahí está, tenemos el credal ID de esta otra cuenta.
Speaker A
Voy a mi sesión de la cuenta de la de Docker CTF y voy a probar en cambiar el ID. Le doy y a ver qué pasa. Y no ha funcionado. Mejor, menos mal. Veis que me saca el mismo correo, no me saca el
Speaker A
correo de mi otra cuenta. Mejor porque así puedo compartirlo en el vídeo. Yo aquí no quiero encontrar ninguna vulnerabilidad. Bueno, hemos probado con el Credencial ID, pero tenemos el CRMD.
Speaker A
Vamos también a probarlo. Lo mismo. Vamos aquí, ponemos CRMD. Voy aquí, copio, pego. Vamos a ver si esto pues más o menos funciona. Le doy y, bueno, me saca información de mi cuenta. Lo mismo, voy a la cuenta de
Speaker A
Bounty Penguin y voy a copiar el CRMD de esta otra cuenta a mi cuenta inicial. Lo mismo, doy en send y lo mismo si me saca información del otro correo sería vulnerable. y tampoco funcionó, así que perfecto. Bueno, estamos viendo también
Speaker A
por aquí en esta respuesta que tenemos otro valor interesante que es este objeto de default address y de repente vemos esto de ID cuando estamos haciendo pues en general e hacking web y veamos en algún lado el campo de ID, tenemos
Speaker A
que vamos encender las alarmas porque eso significa que podemos probar muchos sidor. Yo puedo pues probar en cambiar el ID, podemos hacer muchas cosas. Yo aquí estoy viendo que de alguna forma eh esta [música] cuenta de Docker CTF tiene
Speaker A
un ID que es este. Yo este ID puedo probarlo, puedo probarlo y podemos intentar enumerar otros usuarios cambiando el ID. ¿Cómo podemos probar esto mismo? Pues bueno, pues aquí arriba dentro de la URL, como estamos empleando el método get, yo puedo pasarle
Speaker A
información dentro de la propia URL. Si fuera el método post, se pasa la información por el propio cuerpo de la petición htp. Entonces, yo lo que voy a hacer va a ser pues por ejemplo pues poner aquí barra ID. Yo pruebo y meto mi
Speaker A
ID, por ejemplo. Claro, yo no sé cuál es el ID correcto. Claro, pone not found, pero en vez de ID si pongo address.
Speaker A
Bueno, yo eso no lo sé, tampoco me lo encontró. Y tras hacer varias pruebas encontré Adresis, que esto os juro que está siendo totalmente improvisado. No hemos todavía encontrado nada ni mucho menos, pero estamos probando muchas cosas. Si hemos encontrado que si yo
Speaker A
pongo Adresis y pongo pues el ID de mi usuario, pues el servidor me va a devolver todo esto, toda la información de mi usuario. Volvemos a lo mismo. ¿Qué pasa si yo voy a la sesión de Bounty Penguin, [música] eh, utilizo este ID y
Speaker A
lo paso por aquí arriba? me va a mostrar toda la la información del usuario Bounty Penguin. Vamos a verlo. Le doy por aquí y funciona bien. Fijaros, esto es muy pero que muy divertido. Pone por aquí un mensajito al servidor que dice
Speaker A
lo siguiente. Y esto es muy importante leerlo. Fijaros. Dice por aquí, "Uy, cuidado." Bueno, el identificador o no existe o bien pertenece a otro usuario.
Speaker A
Esto es para nosotros un éxito. ¿Por qué? porque eh eh obviamente esto no ha sido vulnerable, pero lo hemos hecho bien. Hemos intentado explotar unidos, hemos intentado pues obtener información de otro usuario, no hemos podido, no ha funcionado, pero lo hemos hecho bien. Y
Speaker A
esto es un logro porque esto supone aprendizaje. Ahora, si esto hubiera funcionado hubiera sido un íor que yo el otro día más o menos encontré algo así, era otro íor un poquito diferente y lo reporté y bueno, pues fue una de las
Speaker A
bulls que me han aceptado. Pero bueno, que esto podía haber funcionado tranquilamente. Esto significa que ya no ha funcionado y que nos tenemos que rendir. No, no, no tiene por qué. Vamos a probar otra cosa también interesante, que esto sí que fue
Speaker A
bastante parecido al or que encontré yo el otro día, bueno, la semana pasada haciendo buonti, que es que en muchas ocasiones e, bueno, dentro de la URL, el servidor pues tiene en cuenta, digamos, el primer ID y luego el segundo que le
Speaker A
pasemos no lo tiene en cuenta o al revés. Entonces, vamos a probar eso a ver si funciona. ¿Qué voy a hacer yo aquí? Pues bueno, vamos a mirar este UID que tenemos por aquí de la sesión de Bounty Penguin y vamos a combinarlo con
Speaker A
el con su ID. Vamos a ver qué tal. Lo primero vamos a copiar el UID del usuario Bounty Penguin. Yo voy a copiarlo, voy por aquí. Entonces, dentro de la URL, por ejemplo, yo puedo probar en poner users, por ejemplo, barrita.
Speaker A
Pego el UID de la cuenta de Bounty Penguin y pongo barrita otra vez y pongo Adressis, que este es el point que yo sé que existe.
Speaker A
Y ponemos el ID de la cuenta de Bounty Penguin, que viene a ser el ID de la cuenta de Bounty Penguin es esta de por aquí. Copiamos por aquí este lo pamos por aquí y a ver qué pasa. A ver si
Speaker A
cuela. Y bueno, pone bad request, ¿no? Esto algo hice mal por aquí, ¿vale? Y es por lo que me estaba imaginando y es que aquí arriba acabo de incluir un pipe que esto pues hombre no tiene mucho sentido
Speaker A
y por eso estaba petando, ¿no? Por eso estaba fallando. Bueno, ahí está. Ahora pone not found. Bueno, hemos visto que no ha funcionado, no pasa nada. Vamos a probar ahora un path traversal. Yo, por ejemplo, podría probar esto dentro del
Speaker A
método get que estamos aquí empleando. Puedo básicamente pues poner un punto para ir hacia atrás y luego pues poner el UID combinado del ID. Vamos a ver qué pasa si yo, por ejemplo, envío esto.
Speaker A
Vemos que ahí de repente ya me salta a Kamai Ghost. Es decir, que Akamai, que es el waff que está en plano, en este caso Dyson, ha visto que estoy intentando explotar un patraversal, ¿no?
Speaker A
Entonces esto no ha funcionado. Vale, no voy a seguir probando más porque ya estoy avanzando mucho, tampoco quiero aquí pues eh exponer ninguna información ni mucho menos. Sí que bueno, debo mencionar que enhorabuena para Dyson, que tiene una una seguridad bastante
Speaker A
robusta, así que genial, pero ha sido aún así un éxito porque hemos probado muchas cosas. [música] Fijaros algo importante y es que no he intentado apenas ni explotar eh XSS, no he probado inyecciones SQL, no he empleado ninguna
Speaker A
herramienta automatizada y por una sencilla razón, el uso de de las herramientas automáticas creo que es también emplearlas, pero cuando ya sabemos a 100% hacer eh digamos explotación manual, si no sabemos hacer eh [música] cosas de forma manual o no sabemos qué
Speaker A
revisar con bush de forma manual, no tiene sentido ido automatizar nada porque no vamos a encontrar nada y muchas otras personas que son principiantes ya están intentando automatizar todo tipo de cosas y no encuentran nada. Yo al menos los
Speaker A
pequeños resultados que estoy viendo siempre fueron eh pues siguiendo una metodología manual al 100%. Yo lo que hago siempre es pues revisar, revisar, abrir por aquí bursar pues aquí todos estos ends de de la API, eh probar [música] en bueno, pues en cambiar
Speaker A
cosas, quitar, poner. Por aquí sí que hemos visto cosas muy interesantes. Fijaros cómo hemos intentado cambiar el método para intentar explotar pues un ídor. Y aquí sí que es una cosa que quiero hacer pues mención y es que eh
Speaker A
por ejemplo en en todos reales pues eh ataques como por ejemplo inyecciones SQL yo al menos nunca encontré. Sí que es verdad que si miramos pues dentro de Hactivity, por ejemplo, que esto es un lugar donde podemos ver pues reportes de
Speaker A
de Bubontti, veis que por ejemplo si miramos pues el histórico de reportes, pues a ver, sí que existen, o sea, sí que es verdad que es una bueno que es un fallo de seguridad que a día de hoy está
Speaker A
bastante controlado, pero eso no significa que no exista. Pero yo esto ya no suelo mirarlo porque creo que es muy raro encontrarlo. Creo que es mucho más fácil encontrars.
Speaker A
Elor, yo creo que es básicamente eh la vulnerabilidad estrella, porque los escáneres automáticos, como por ejemplo akunetis o bueno, pues hay muchos otros, los sidor no los encuentran tan bien como por ejemplo pues pueden encontrar pues inyecciones SQL o incluso XSS
Speaker A
sencillos. Es decir, yo creo que cuando hacemos eh hoy en día hacking web es más es más efectivo eh bueno, intentar encontrar que eso, pues intentar encontrar un XS sencillo o una inyección SQL con la vulnerabilidad XSS. Eh, hay
Speaker A
muchos también, de hecho yo pues encontré varios, lo que pasa que siempre que encuentro uno está ya duplicado, pero bueno, da lo mismo porque sigue siendo un logro igualmente, pero eh cuando yo encuentro uno, suelen ser XSS que están en lugares escondidos. Por
Speaker A
ejemplo, si vamos aquí a Dyson, va a ser casi imposible que dentro de este buscador haya un XS, que ojo, puede ser, eh, puede ocurrir, puede, vamos, pero sería bastante extraño porque es un buscador que está a simple vista, todo
Speaker A
el mundo prueba por aquí. Bueno, sería muy raro. Ahora bien, a lo mejor pues los XSS pues bueno, pueden estar pues en secciones un poco más escondidas, por ejemplo, la parte de mis datos como puede ser aquí. Es decir, si
Speaker A
yo, por ejemplo, pues aquí donde tengo el nombre, pues pongo un XSS, a lo mejor podría funcionar. Esto sí que es un poquito más frecuente. Yo todavía el otro día encontré pues aquí un XSS, no en este objetivo, obviamente en otro. Lo
Speaker A
que pasa que era un XSS self, que eso se conoce en un tipo de XSS que únicamente es reproducible en tu propia cuenta, entonces no tiene impacto, pero bueno, seguía siendo pues un XSS, ¿no? Con esto lo que quiero decir es que intentemos
Speaker A
evitar pues ir a programas copiando y pegando el mismo Paylud de el típico, pues pues aquí por ejemplo script alert, es decir, esto intentemos evitarlo porque va a ser casi perder el tiempo, es decir, por aquí pues va a ser casi
Speaker A
imposible encontrar algo, pero ahora bien, si queremos probar XSS, sí que está bien pues mirar por aquí en estos sitios o en cualquier eh lugar donde se refleje lo que estemos poniendo, pero evitando los buscadores princip. Bueno, luego también otra cosa que yo suelo
Speaker A
utilizar ya para terminar es esta extensión de Dart Reader que yo aquí pues pongo sí, entonces todo me sale en coloritos negro, que cuando estás un ratito grande haciendo bugy, a veces el color blanco de las páginas te revienta
Speaker A
la vista. Entonces, bueno, pues yo suelo utilizar esto, ¿no? Y luego, ¿qué más también suelo emplear? Bueno, ya os enseñé todas las extensiones. Luego también tengo Wapalizer, que también está bastante bien, que yo puedo ver un poco pues en que está hecho pues digamos
Speaker A
un objetivo. En este caso, Poston, pues bueno, emplea todo esto, ¿no? Y bueno, yo otra cosa que también suelo hacer eh claro, porque todo lo que hemos hecho ahora mismo ha sido pues dentro de navegador y de bullshit, pero bueno, en
Speaker A
muchas ocasiones es posible que, bueno, querramos utilizar herramientas de la terminal como por ejemplo puede ser Fuff. Es decir, [música] yo aquí pues por ejemplo, a lo mejor quiero emplear Fuf o quiero emplear un NMAP o quiero emplear un DIF. Oye, puede ser. Eh,
Speaker A
todavía pues hace un poco eh bueno, empleando Dirf, pues encontré un archivo bastante crítico expuesto. Ya ya lo ya lo reporté, obviamente, o sea, que puede darse el caso. Yo para estas cosas suelo utilizar lo siguiente. Yo dentro de mi
Speaker A
repositorio de GitHub, yo tengo pues una imagen que se llama Hack Penguin, que es un Docker. Yo tengo un Docker que es un Cali. Entonces, claro, yo evito tener que utilizar un Cali en máquina virtual para hacer buffti porque va muy lento,
Speaker A
es muy incómodo. Entonces, yo lo que hago es lo siguiente. Voy aquí donde ponen Docker file y yo pues por aquí tengo todo el contenido para crearme una imagen de Kali Linux con las herramientas más básicas que yo utilizo
Speaker A
para hacer bubontti, incluyendo pues herramientas mías. Por ejemplo, yo tengo pues una herramienta que es esta que se llama don't shaker, ¿no? Por ejemplo.
Speaker A
Entonces, yo lo que suelo hacer es lo siguiente. Yo hago un eh bueno, por ejemplo, voy a mi escritorio, hago un eh nano de Docker File y me construyo una imagen. Sudo Docker build guion guion tag, me creo una imagen de Docker de esto
Speaker A
mismo y entonces pues por aquí tengo un cali para pues hacer buunty sin tirar de máquina. virtual, que es un rollo. Ahora os voy a enseñar qué enumeración básica yo también suelo hacer dentro de, bueno, pues eh de la terminal, ¿no? Para
Speaker A
encontrar pues end points que estén activos, encontrar sub dominios, etcétera, etcétera, etcétera. Vale, perfecto. Ya tenemos por aquí la imagen creada. Yo lo que suelo hacer ahora mismo es lo siguiente. Bueno, yo si hago usudo de Docker imágenes, pues por aquí
Speaker A
tengo mi cali en Docker. Entonces, lo voy a lanzar con un sudo Docker Ruan it y pego pues aquí básicamente el nombre de mi imagen. Y tengo pues un Cali. Ahí está. Tengo por aquí un cali para utilizarlo de una forma supercmoda, ¿no?
Speaker A
Bien. Eh, ¿por qué esto es muy útil? Pues veréis por lo siguiente. Si yo, por ejemplo, empiezo a mirar el programa de Dyson, fijaros que, bueno, aquí tenemos un objetivo WiCard. Esto, ¿qué significa Wildcard? Wildcard significa que podemos
Speaker A
enumerar todos los subdominios que tenga pues este dominio principal. Entonces, claro, yo qué puedo hacer aquí, pues yo puedo hacer lo siguiente. Yo puedo copiarme esto, puedo ir por aquí y con su finder yo puedo, bueno, por ejemplo,
Speaker A
su subfinder men d y ahora menos o eh subdominios, por ejemplo. Y entonces ahora mismo yo voy a encontrar subominios de un objetivo. Entonces, claro, vamos a ver qué pasa esto. Claro, veis que desde el navegador, hombre, hay
Speaker A
páginas que me ayudan a hacerlo, pero desde a terminal es bastante rápido. Y bueno, tenemos todos estos. Estos son todo subominios que podemos investigar uno por uno y podemos ver pues bueno, cuál de ellos puede tener algún fallo de
Speaker A
seguridad. Por ejemplo, yo podría, pues copiar este, por ejemplo. Veréis, yo pues copio este y bueno, estoy bloqueado. Este no no me dejó entrar, no pasa nada. Vamos a probar este otro.
Speaker A
Pues bueno, vamos a seguir probando. Este vemos que no existe. Claro, algunos existen, otros no. Yo para esto yo tengo una herramienta que me he creado yo, aunque también tenemos otras. Eh, pero bueno, si yo quiero eh de una forma
Speaker A
automática filtrar aquellos subominios que estén operativos y que no lo estén, lo hago con o bien la herramienta de HTTPX, que es una herramienta pues que está bastante bien, o con una que yo tengo que se llama D Checker, que ya
Speaker A
pues os la incluí dentro de este mismo eh cali. Esta es la herramienta que yo tengo. Sí que es verdad que ahora me da un error porque esto no debería de de pedirme la ruta absoluta, pero bueno, ya
Speaker A
lo miraré. Entonces, yo con esta herramienta que se llama Don Checker, yo lo que hago es pasarle el archivito de subdominios que me encontró antes, pues digamos su Fer. Entonces, fijaros que de una forma bastante rápida me comprueba
Speaker A
los 37 subominios que tenemos y me filtra cuáles están activos y cuáles no. Esta herramienta, pues bueno, la la hice yo. ¿Y por qué yo elijo siempre que pueda utilizar herramientas creadas por mí en lugar de otras que ya existen? Por
Speaker A
un motivo que yo creo que bueno, puede ser interesante y es ho, por ejemplo, todo el mundo utiliza herramientas como httpx o utiliza herramientas que ya están creadas. Entonces, claro, los resultados que se tienen van a ser siempre los mismos, pero a veces está
Speaker A
bien pues utilizar otras herramientas que no utilice tanta gente o que estén esas por nosotros porque vamos a tener unos resultados diferentes. Mira, yo por ejemplo con mi herramienta pues encontré este objetivo. Por ejemplo, yo puedo pues aquí ir y bueno, pues esto como
Speaker A
estamos viendo funciona. Este es un sub dominio que está operativo porque a lo mejor lo que una herramienta no me proporciona, la otra sí que me lo proporciona y al revés. No obstante, esto de la enumeración de forma más
Speaker A
automática y este tipo de de acciones, creo que debe de ser más secundario. Lo principal, yo creo que es utilizar burs siempre que se pueda y eh más enumeración manual, entender cómo funciona pues la la web, entender pues
Speaker A
lo los endoints de la API, si hay una API o no detrás. entender pues bueno, qué hace cada una de las cabeceras HTTP por aquí.
Speaker A
Eh, bueno, pensaba, vale, si si cambio este método por este otro, si quito esto y pruebo esto, si dentro de esta otra sesión utilizo este dato para esta otra sesión podré enumerar algo, estas cosas creo que son pues bastante interesantes,
Speaker A
¿no? Aún así, ya os digo, yo no soy un experto en el tema del bubonti, de hecho creo que para ser expertof tener muchísimos años ahí en este mundillo, pero bueno, sí que está muy interesante pues al menos enfocar este vídeo pues en
Speaker A
quienes quieran encontrar su primer bug. Ya os digo yo más o menos eh con una una media hora al día durante esta última semana pues encontré pues eso, dos bulls que me las han aceptado. Encontré otra que yo creo que deberían aceptarla al
Speaker A
100%. Encontré pues algunas otras que estaban ya duplicadas, pero bueno, que también existían y bueno, creo que se pueden contener, digamos, resultados. No obstante, sí que es obligatorio, y esto yo sí que creo que es un requisito indispensable y es tener bases de la
Speaker A
ciberseguridad. [música] Si no tenemos bases ni de informática ni de ciberseguridad, pues claro, obviamente pues aquí no vamos a hacer apenas nada. Pero si nosotros entendemos pues un poco pues bueno, cómo funciona digamos la red, cómo funciona pues esa
Speaker A
comunicación entre cliente, servidor, e qué son pues lo los métodos HTTDTP fundamental, qué es una API, eh, bueno, ese tipo de cosas. Es decir, tener bases de la informática y del hacking web. Eso creo que es obligatorio para empezar en
Speaker A
este mundillo del del Buonti. Así que bueno, esto ha sido todo. Espero que lo hayáis entendido. Espero que os haya gustado. Un vídeo bastante interesante y bastante potente. Y bueno, creo que apenas hay vídeos en YouTube así, pues
Speaker A
bueno, hablando sobre e duonti, hay vídeos, hay vídeos, pero hay poquitos. Y creo que este pues puede ser muy interesante para quienes estéis empezando, ¿no? Así que nada, muy importante. Antes de finalizar tenemos de todo en la descripción del vídeo,
Speaker A
tenemos academia, tenemos el búnker, que es nuestra membresía, tenemos newsletter, que está super guay para aprender, para, bueno, pues ver ahí cosillas eh bueno bueno cosas cosas chulas, todo lo tenéis en la propia descripción del vídeo. También tenemos
Speaker A
servidores de Telegram y de Discord, tenemos Dockerlabs si queréis practicar hackinético y ciberseguridad. Así que nada, nos vemos en otra ocasión.
Speaker A
Hasta la próxima.
Topics:bug bountyvulnerabilidadesseguridad informáticaHackerOneBurp Suiteauditoría webprogramas bug bountyconsejos bug bountyseguridad digitalbug bounty para principiantes











