Te pagan por hackea??

Hace un par de años entré a HackTheBox sin saber muy bien qué esperar. Hoy reporto vulnerabilidades en programas reales de HackerOne y Bugcrowd, y esa distancia — de resolver máquinas de práctica a que una empresa te pague por una falla real — es exactamente el camino del que quiero hablar acá.

Qué es el bug hunting, en criollo

El bug hunting es buscar fallas de seguridad en sistemas reales — apps, APIs, plataformas — y reportarlas a la empresa dueña antes de que un atacante las encuentre primero. No es allanar nada a la fuerza: es entrar por la puerta que la empresa misma dejó abierta para vos, con permiso explícito, dentro de un scope definido.

A ese modelo le dicen bug bounty: la compañía paga por cada vulnerabilidad válida que reportes. Plataformas como HackerOne o Bugcrowd son el punto de encuentro entre hackers y empresas que quieren que las ataquen, legalmente, antes de que lo haga alguien sin buenas intenciones.

Dónde está la plata en serio

Acá suele estar el malentendido más común de quien recién arranca: pensar que hay que romper algo con fuerza bruta, o encontrar un exploit exótico de día cero. En mi experiencia, las fallas que mejor pagan casi nunca son así.

Las mejores suelen estar en la lógica de negocio: un flujo de pago que no valida bien un estado intermedio, un rol de usuario que puede acceder a algo que no debería por un chequeo de permisos mal puesto, una API que confía en un dato que el cliente no debería poder manipular. Nada de esto requiere herramientas exóticas — requiere entender cómo se supone que funciona el sistema, y después preguntarte qué pasa si no seguís ese camino esperado.

Es un tipo de vulnerabilidad que un scanner automático no encuentra, porque no es un patrón conocido de payload: es un problema de diseño. Y por eso mismo, cuando la encontrás, suele valer más.

Cómo arrancar sin perderte

Si estás por dar el primer paso, este es el orden que a mí me funcionó:

1. Practicá en un entorno controlado primero. HackTheBox (u otro similar) te da máquinas diseñadas para romperse, sin el riesgo legal de tocar algo real sin permiso. Ahí construís el criterio técnico de base.
2. Subite a un programa real cuando te sientas listo. HackerOne y Bugcrowd tienen programas públicos con distintos niveles de dificultad y payout. Elegí uno con scope claro y empezá por ahí.
3. No busques la falla espectacular. Buscá entender el producto: qué hace, para quién, qué asume sobre el usuario. Ahí es donde vas a encontrar lo que el equipo de seguridad interno no vio.

El primer bounty tarda. A veces se reportan varias cosas antes de que una sea aceptada como válida y pagada. Pero llega — y cuando llega, entendés que no se trataba de suerte, sino de mirar el sistema con la pregunta correcta.

¿Estás arrancando en bug bounty o ya tenés programas activos? Me interesa leer con qué te encontraste vos en el camino.