Saludos estimados informaticos hoy vengo con una duda de un pequeño ejercicio que a manera de autoestudio estoy haciendo...

La duda ...

En mi red local, en la cual estoy practicando conceptos de ataques en redes LAN (hoy estoy con ARP Spoofing) Tengo la siguiente configuracion:

El modem del ISP (con el wifi apagado)
Que se conecta a un router TP Link AC 1200 (el cual uso como AP)
Multiples laptops conectadas al AP

Sucede que desde el laptop atacante estoy spameando paquetes ARP hacia el laptop victima, indicandole a manera de engaño que el default gateway (el modem del ISP) se asocia a mi MAC. Asi mismo estoy bombardeando el default gateway (el modem del ISP) con ARP replies indicandole que la ip del laptop victima se asocia con la mac de la PC atacante.

Para comprobarlo voy al laptop victima y ejecuto arp -a para mirar la tabla de ARP, una vez hecho esto puedo ver que el laptop victima esta asociando la IP del default gateway con la mac del equipo atacante, y tambien veo otra entrada donde asocia la IP del laptop atacante a su respectiva mac.

Al tener la herramienta de arpspoof corriendo en una terminal y wireshark en la GUI, si aplico el siguiente filtro ip.src==LA_IP_VICTIMA puedo ver el trafico que se genera desde el laptop victima el cual asumo mi laptop atacante esta forwardeando al default gateway ya que el equipo victima sigue navegando con normalidad. Mi objectivo de estudio es dropear el trafico saliente desde el laptop victima que esta pasando a traves de mi laptop atacante para denegarle el acceso a internet.

Para esto estuve mirando un poco sobre IP Tables (aun no cubro el tema, pero ya me adentrare en linux networking) y veo que puedo denegar con alguna regla el trafico proveniente desde el laptop victima para que no sea forwardeado, por lo que mirando por encima el tema, pienso en ejecutar en una terminal del laptop atacante el siguiente comando: iptables -A FORWARD -j REJECT con la intension de dropear los paquetes que estan siendo forwardeados al host remoto (internet), al ejecutar el comando y luego listar las reglas con iptables -L puedo ver que el forward ahora sale como reject, pero a su vez tambien puedo ver que el equipo victima puede seguir navegando con normalidad por la red, por lo que mi intento de DDOS no tiene efecto...

Agradeceria alguna idea o pista para poder entender porque no funciona para poder remediar mi error y entender el concepto de raiz, espero no encuentren la pregunta floja, en el futuro planeo estudiar otros temas como SSL stripping, MAC flooding y formas de mitigacion.


Y ya que creo que es primera vez que paso el foro. Les comparto un poco sobre mi.

Sobre mi background y meta...

Soy un ingeniero de software con 5 años de experiencia y 26 de edad apasionado por adentrarme en el hacking y seguridad
informatica, he empezado por cubrir mi gaps desde abajo, reciente empece un curso de networking de cisco del cual ya complete
la primera etapa Networking Essentials y ahora ando en proceso de terminar la Network Tecnician. En paralelo y para variar un
poco estudio con el material de Hack The Box (que es demasiado material que me abre las puertas a investigar otros temas), de momento he podido aprender muchos conceptos basicos importantes sobre las redes de computadoras OSI y TCP/IP, ARP, ICMP, entre otros mas, reconozco la estructura de los paquetes segun la capa a la que pertenecen, he estado neceando con wireshark, mirando como fluyen los datos, etc.. y voy en camino a estudiar el material de CCNA de cisco (no me interesa la certificacion sino el conocimiento) para conocer un poco de protocolos de enrutamiento y otros conceptos utiles. Proximamente quiero enlistarme en algun curso de administracion de sistemas linux, kernel y hardening para poder refrescar los temas de permisos, configuraciones, IP Tables y entender con mas facilidad temas de escalada de privilegios, exploits y demas... asi que voy moliendo conocimiento poco a poco, espero ir por el buen camino. Un abrazo a todos y si tienen algunas sugerencias para seguir avanzando e hidratando mi repertorio son mas que bienvenidas.

Entiendo, muchas gracias por la aclaración.
Salu2!

Al parecer si tiene relevancia,



aquí ejecuté el mismo payload pero esta vez con el operador || y corrió sin errores

Saludos, eso que comentas tiene sentido, sin embargo cabe destacar que en postgres el operador || funciona para hacer concatenacion y no como un booleano (como lo haría OR).

Aquí me he animado a montar un container con postgres en docker y traté de correr el payload y obtuve lo siguiente.



Creo que es bastante claro para mi a este punto, es por el tipo de retorno que espera el operador OR, dado que pg_sleep() retorna void el operador OR no puede preceder a la funcion per sé.
pero por el contrario || acepta cualquier tipo de dato por lo que el void no generara un error de sql.

Creo que esperare un poco mas antes de marcarlo como resulto por si depronto alguien mas quiere aportar un punto de vista valido distinto al expuesto.
Saludos!!!

Saludos gente, estoy haciendo los labs de la Web Security Academy de Burpsuite, y estoy aprendiendo cosas muy interesante.
Recientemente he llegado a un lab donde se trata de un web site que tiene una cookie que es vulnerable a SQLi, el lab dice que se puede explotar con conditional delays.

He intentado de muchas maneras:

• x' or pg_sleep(10)--
• ' and pg_sleep(10)--
• x' or sleep(10)--

Entre otras varias mas...
Pero hay una en particular que funciona

' || pg_sleep(10)--

A lo que me brinca el ojo al tratar de entender por qué usando el operador de concatenación de postgres se consigue introducir el delay, mientras que con otras condiciones basadas en lógica booleana simplemente no funciona?

Agradeceria cualquier recurso para tratar de entender esto, he estado mirando en la documentación de postgres y lo que veo es que el pg_sleep retorna void, pero no entiendo como no es ejecutada la instrucción del delay, acaso el planner de la db sabe de antermano que no existe forma de lograr que la condicion booleana sea exitosa (true) usando un sleep con un operador?

happy hacking...