Slowloris: DoS para Apache

julio 1, 2009
En líneas generales, para generar un DoS (o DDoS) en un sitio con suficientes recursos, es necesario hacer uso de una botnet, un montón de ordenadores zombies a nuestro servicio, que efectúan peticiones de forma simultánea contra un objetivo común, configurable en tiempo y en lugar por el atacante. Al final, la denegación de servicio del objetivo se puede hacer efectiva por varias causas:
  • Porque el servidor o los servidores, son incapaces de contestar a tantas peticiones de forma simultánea
  • Alguno de los mecanismos intermedios (routers, switches, firewalls, balanceadores…) que atraviesan dichas peticiones se satura de peticiones y se ve incapaz de gestionar la marabunta
  • El ancho de banda disponible de dicha organización se ve desbordado y el tráfico lícito se pierde en un gran porcentaje o se degrada el servicio.

El DoS que os presentamos actualmente corresponde a los del primer tipo descrito.

Hace ya una semana que se ha dado a conocer una nueva herramienta que ha puesto los pelos de punta a la comunidad: Slowloris. El autor de la criatura, Robert Hansen, publicó en http://ha.ckers.org/ el código fuente y el funcionamiento básico.

Este “sencillo” script hecho en Perl implementa una potente e inteligente manera de generar una denegación de servicio sobre un servidor web Apache. Para ello, se basa en la cantidad de peticiones que es capaz de mantener un servidor web de forma concurrente. La forma de saturar el pool de servicios es mediante la creación de “requests” HTTP (con HTTPS también funciona) de manera que se empiezan a enviar cabeceras y más cabeceras al servidor de manera que así se fuerza a mantener abierta las conexiones por parte del servidor. Los servidores web tienen determinado un número máximo global de sockets permitidos (configurados en los ficheros correspondientes).

Se trata de un DoS localizado al servicio web en concreto, manteniendo el resto de los servicios de la máquina accesibles.

¿Cómo mitigarlo?
Madre mía, qué buena pregunta. La verdad es que tiene una respuesta complicada.

He encontrado en Internet multitud de módulos Apache que se pueden incluir en el servidor web para efectuar diferente tipo de restricciones. Describo un poco los que más me han llamado la atención:

  • mod_evasive: Este módulo sirve para gestionar el número de peticiones por IP hacia una misma página en concreto o hacia el servidor en general. Se configuran los umbrales que permitimos así como diferentes sistemas de notificación (bloqueo dinámico con IPTables, correo de notificación de detección de intento de DoS, Syslog, etc,…)
  • mod_limitipconn: Mediante este simple módulo, podemos restringir el número de peticiones origen desde una única IP hacia un servidor. Permite configurar diferentes políticas según el Location, el tipo de fichero a descargar, etc,… para “abrir la mano” y no provocar una autodenegación de servicio.
  • mod_ip_count: Aún más simple que los anteriores, comprueba si el número de peticiones HTTP desde una única IP excede un tamaño máximo definido durante un periodo de tiempo.
Con todos ellos, la verdad es que hay que tener mucho cuidado, puesto que si configuramos de una forma excesivamente restrictiva estos módulos podemos generar la denegación de servicio nosotros mismos. Esto ocurriría por ejemplo, si los visitantes del servidor web acceden al mismo utilizando la misma dirección IP. Esto sucede cuando todas las peticiones salen desde una misma red cuyo router o firewall efectúa un NAT utiliza una única IP pública hacia Internet (lo más normal del mundo) o mediante un proxy.

Otra posible solución para paliar un ataque hecho mediante Slowloris es modificar, en el propio servidor web, el valor del parámetro TimeOut así como KeepAliveTimeOut. Para el primero por defecto son 300 segundos (o sea 5 minutos), lo cual puede hacer que efectivamente nuestro Apache sea carne de DoS en un corto espacio de tiempo. Si lo modificamos a un valor inferior (sin pasarse, puesto que una vez más, peticiones legítimas dejarían de funcionar), obligaríamos a que el atacante con slowloris hiciera uso de más y más máquinas para consumirnos muchas conexiones en muy poco tiempo. El segundo valor es el tiempo que espera para más peticiones bajo una misma conexión persistente. Por defecto viene a 15 segundos; un valor inferior liberará antes los recursos de esas conexiones persistentes.

Dentro de la propia máquina que alberga Apache (si es un *NIX) se pueden utilizar las herramientas propias del kernel de la máquina o del cortafuegos integrado para establecer políticas de conexión por cada IP.

Asimismo, utilizar las opciones de configuración provistas por los dispositivos intermedios (como firewalls o IPSs) podrían ser de utilidad también, para mitigar el flujo de tráfico que permitimos hacia el servidor web.

Anuncios

Jeff Moss, de hacker a asesor del gobierno estadounidense

junio 9, 2009

El conocido hacker Jeff Moss, fundador de Black Hat y DEFCON, ha sido nombrado asesor de Obama, formando parte de las 16 personas del Consejo Asesor de Seguridad Nacional de Estados Unidos (HSAC). Moss, estará a la altura de miembros de la CIA y FBI, entre otros,  asesorando al gobierno de Obama en materia de seguridad cibernética.

La visión negativa que conlleva la palabra hacker, y en cierto aspecto es culpa de los medios de comunicación, podría chocar con el hecho de que el gobierno estadounidense cuente en terreno de ciberseguridad con una persona con tales cualidades. Sin embargo, no es el primer caso que se da en el que gobiernos piensan en estos expertos en seguridad para aportar sus años de experiencia en un campo virtual de batalla, que es lo que Internet se está convirtiendo con todo tipo de ataques, virus, gusanos, troyanos, etcétera.

Moss ha afirmado tras su elección y en relación a ella: “hay una nueva insistencia en la ciberseguridad y que buscan la diversificación de sus miembros […] Creo que necesitan un punto de vista alternativo que hasta ahora ha estado ausente“.

El fundador de DEFCON, la mayor conferencia mundial abierta de seguridad con la asistencia de hackers, agencias gubernamentales, industria informática y consultores, ha mostrado su satisfacción al haber sido elegido: “(me siento) honrado y entusiasmado en contribuir en la HSAC“.

FUENTE : http://www.theinquirer.es/2009/06/07/jeff-moss-de-hacker-a-asesor-del-gobierno-estadounidense.html


Un grupo turco ¿se infiltró? en servidores del ejército americano

junio 3, 2009
Para los que conozcáis zone-h, el portal de seguridad informática con uno de los archivos de defaces más activos, estaréis hartos de ver como día a día, miles y miles de sitios web sufren las alteraciones de personas o grupos, que dejan mensajes patrióticos, dedicatorias a novios/as y/o amigos/as o un simple “hacked by ponga-aqui-su-nick-con-números-en-vez-de-vocales“. En este archivo, además de poder definir servidor web y sistema operativo afectados, junto al dominio atacado puede marcarse si se considera un ataque especial por tratarse de un sitio web importante o relevante.

Todo esto viene a que recientemente se ha publicado una noticia en informationweek en la que se informaba que el ejército de Estados Unidos había sufrido un ataque en sus servidores web, más concretamente el MCAAP – Army’s McAlester Ammunition Plant, por parte de un grupo turco que se hacía llamar “m0sted” allá por Enero de este año. Realicemos una búsqueda simple en google de este nombre para saber un poco más de ellos, así como en bing.com que parece que da karma positivo últimamente por hablar de él. Se ha tenido constancia de que anteriormente, a finales del 2007, también atacaron los servidores del Army Corps of Engineers.

m0sted” es un claro protagonista de los archivos de Zone-H, con más de 300 dominios “fusilados”, todos marcados como especiales.


Y diréis, “Bien, ha pasado medio año ya del MCAAP, y casi dos años del otro tema, ¿y ahora qué?“. Ahora es cuando el Departamento de Defensa está investigando estos dos sucesos, para evaluar si dichas entradas fueron más allá del deface, y si se pudo llegar a robar información sensible. ¿El actuar después de tantos meses tendrá que ver con la noticia de que Obama ha creado su pequeño equipo que vela por la seguridad cibernética? Igual se lo toman como entrenamiento para cuando vengan esas ciberguerras del futuro de las que nos hablan.

m0stedpudo modificar las páginas (como en el caso de la amplia mayoría de sus más de 300 defaces archivados) mediante vulnerabilidades de tipo SQL Injection, inyectando su propio contenido a la base de datos que gestionaba la aplicación para mostrar en los sitios webs mensajes a su antojo. Si revisamos algunos de sus ataques, veremos como sus actos pasados han aparecido en varios medios por los defaces a las páginas web de Naciones Unidas y a la de los laboratorios Karpesky, en su dominio de Malasia entre otras.


Sinceramente, y bajo mi humilde opinión, tras analizar casi todos sus ataques, que se han basado en añadir noticias con dedicatoria de tipo “hacked-by blablabla por la patria blabla guerras de US malas blabla”, sean páginas del gobierno, del ejército como de marcas de coches (mientras manejen sentencias SQL para rescatar contenido y que no se realice una correcta validación en caso de que un visitante introduzca sus propias peticiones modificadas en la URL) y de un modo masivo (si se utiliza el mismo motor de noticias para todas las versiones de la página según idioma u otros criterios, atacando uno ya puedes romper varias), podría poner la mano en el fuego sobre el hecho de que estos ataques por parte de este grupo turco con tanto tiempo libre no han ido más allá de simples sentencias SQL de UPDATE contra las bases de datos. Ya veremos que dice Defensa al respecto, es mi opinión y puedo equivocarme perfectamente.

Esto no quita que ya en pleno siglo XXI, después de años y años y años sabiendo de las posibilidades que dan las vulnerabilides de tipo inyección SQL, todavía muchos desarrolladores web no tengan constancia de como evitar este tipo de ataques.

Fuente: http://www.securitybydefault.com/2009/06/un-grupo-turco-se-infiltro-en.html


cceder a sistemas Linux y Windows sin contraseñas de usuarios

junio 3, 2009

En seguridad informática hay un principio básico: “El acceso físico a la máquina es acceso total a esta”. Y con Kon-Boot podemos demostrar este principio, ya que nos permite acceder a sistemas Linux y Windows sin contraseñas de usuarios.

Kon-Boot no es intrusiva ya que no realiza ninguna modificación en el sistema que pueda ser detectada. Su funcionamiento se basa en parchear el núcleo del sistema cuando se carga en memoria al arrancar el equipo, anular todos los procesos de autentificación y abrir un acceso al sistema en modo root/Administrador.

Kon-Boot esta testeado en los siguientes sistemas:

Windows:
Windows Server 2008 Standard SP2 (v.275).
Windows Vista Business SP0.
Windows Vista Ultimate SP1.
Windows Vista Ultimate SP0.
Windows Server 2003 Enterprise.
Windows XP.
Windows XP SP1.
Windows XP SP2.
Windows XP SP3.
Windows 7.
Linux:
Gentoo 2.6.24-gentoo-r5.
Ubuntu 2.6.24.3-debug.
Debian 2.6.18-6-686.
Fedora 2.6.25.9-76.fc9.i686.

Se puede arrancar desde CD o desde un disquete.

Más información y descarga de Kon-Boot:
http://www.piotrbania.com/all/kon-boot/

Visto en http://vtroger.blogspot.com/

LEIDO EN :http://seguridad-informacion.blogspot.com/2009/05/acceder-sistemas-linux-y-windows-sin.html


El FBI inhabilita su servicio de email tras sufrir un ataque de un virus

junio 1, 2009

Un virus ha sido capaz de hacer que el servicio de webmail tenga que ser suspendido en el FBI estadounidense. De hecho ayer confirmaron que se habían visto forzados a desconectar su red no-clasificada con acceso a Internet debido al mismo incidente.

En un informe del FBI se puede leer: “La red externa, no-clasificada fue desconectada por el FBI como medida de precaución […] En 49 horas se identificó el problema y tras mitigar los riesgos, el tráfico de email fue restaurado en dicha red.”

Los agentes del FBI pueden enviar correos electrónicos a través de la red interna de la agencia que a su vez es más segura, o también vía BlackBerry, pero, según parece, la mayoría hace uso de la red externa para mandar correos a través de un sistema webmail.

El representante del FBI Paul Bresson afirmó en un email: “Podemos mandar emails a cualquiera … y tenemos acceso a Internet. También tenemos un sistema seguro de email que conecta las más de 400 oficinas a lo largo del país y 60 oficinas en el extranjero.”
Los agentes del FBI pueden enviar correos electrónicos a través de la red interna de la agencia que a su vez es más segura, o también vía BlackBerry, pero, según parece, la mayoría hace uso de la red externa para mandar correos a través de un sistema webmail.

El representante del FBI Paul Bresson afirmó en un email: “Podemos mandar emails a cualquiera … y tenemos acceso a Internet. También tenemos un sistema seguro de email que conecta las más de 400 oficinas a lo largo del país y 60 oficinas en el extranjero.”

FUENTE : http://www.theinquirer.es/2009/05/30/el-fbi-inhabilita-su-servicio-de-email-tras-sufrir-un-ataque-de-un-virus.html


DoS a WorldWide DN

mayo 27, 2009

Al igual que el año pasado, el proveedor WorldWide DNS ha vuelto a ser víctima de ataques de denegación de servicio distribuido o DDoS desde las 1:00 a las 4:30 AM CST.

De momento, sólo lo indican en su página web, pero todos aquellos clientes de este proveedor (DNS fijos y dinámicos) se han encontrado esta mañana sin servicio. Las recomendaciones que el propio proveedor sugiere a sus clientes son aumentar el TTL (Time To Live) para las zonas DNS a 12 horas (43200 segundos) o más si no necesitan tener un valor de TTL muy bajo. La mayoría de los ISPs recomiendan un TTL de 24 horas (86400 segundos) o más.

Según WorldWide DNS, el ataque vino sin aviso ni provocación por su parte. Actualmente el servicio está restablecido, aunque no saben durante cuánto tiempo puesto que no conocen aún el origen del mismo.

En general, un ataque de denegación de servicio distribuido (DDoS) es uno de los más difíciles de defender debido al inmenso volumen de tráfico que viene desde diferentes orígenes (con muchas probabilidades de IPs spoofeadas). Hay que distinguir que, por un lado puede darse un ataque de denegación de servicio porque el caudal de ancho de banda entrante a una organización es colapsado, y por otra parte aquellos ataques basados en el comportamiento de una aplicación de procesamiento pesado (aquellas aplicaciones que una sola petición ya exige muchos recursos de una máquina).

En el primer caso, las soluciones son muy pocas. Por lo visto aquellos sitios que se han visto amenzados y/o atacados de esta manera, han podido mitigar el impacto mediante la utilización de servicios como Akamai (una red de cachés y aceleración de tráfico mediante la distribución de procesos). En el segundo caso, aplicaciones pesadas (pero el consumo de ancho de banda no se ve colapsado), hay otro tipo de soluciones, como incrementar el número de servidores que van a dar el servicio, utilización de dispositivos gestores de ancho de banda que permitan devolver a un cliente una respuesta de “ocupado” cuando los servidores aún no estén colapsados, permitiendo dar servicio con los recursos disponibles al menos a un número limitado de usuarios manteniendo la calidad del mismo.

Fuente:http://www.securitybydefault.com/2009/05/dos-worldwide-dns.html


Descubierta vulnerabilidad en OpenSSH

mayo 20, 2009

Un grupo de investigadores del Information Security Group (ISG) de la Universidad Royal Holloway de Londres acaba de hacer público un fallo en el ampliamente utilizado protocolo de comunicación SSH. El fallo se ha encontrado en la versión 4.7 de OpenSSH y recomiendan que todos los usuarios actualicen a la versión 5.2 ya que ofrece varias contra-medidas que pueden evitar un ataque. Pueden ser vulnerables también otras implementaciones de SSH, según el grupo de seguridad londinense. Enviando paquetes especialmente manipulados, un atacante tiene una probabilidad entre 262.144 de recuperar 32 bits de texto plano de un texto previamente cifrado, de forma arbitraria. “Es un fallo de diseño de OpenSSH. Las otras vulnerabilidades han sido más por errores de codificación.” Declaró Patterson, profesor del ISG. Queda claro que las probabilidades son muy limitadas. Pero el fallo de diseño sigue planteando una amenaza significativa, dada la forma en que muchas aplicaciones emplean SSH.