El documento presenta un análisis de un caso de despido procedente en el que un empleado es acusado de modificar un artículo en un blog de WordPress de la empresa. A través de una auditoría forense informática, se investiga la posibilidad de manipulación de datos y se discieren las vulnerabilidades en la web, concluyendo que la autoría del cambio podría no ser del cliente, sino de otra persona en la empresa. El autor también proporciona recomendaciones para prevenir intrusiones y mejorar la seguridad del sistema.

2. Autor: Jorge Coronado
- Perito informático
- Vocal de la asociación de peritos tecnológicos judiciales de
Andalucía (APTAN)
- Colaborador de Canal Sur Radio desde 2015
- Proyecto WordPressA Security Plugin
(wordpressa.quantika14.com)
- Canal de Youtube “Investiga conmigo desde el Sü”
- Co-autor de los protocolos:
- Violencia de género y redes sociales en Internet
- Búsqueda de personas desaparecidas a través de las
TICS
- Profesor en el curso de detectives en la Pablo Olavides en 2017
- Dinamizador de Hack&Beers de Sevilla
- Blogs:
- blog.quantika14.com
- botentriana.wordpress.com
- Twitter: @jorgewebsec
- Github:
- QuantiKa14
- JWScr33d

3. ¿Qué vamos a
ver?
● Caso 1: “Despido
procedente para el jefe.”
● Caso 2:
“remove_action(‘VIAGRA’);”

6. Situación:
Antecedentes de hechos:
Mi cliente me manifiesta llevar muchos años en la
empresa y haber sido despedido de forma procedente.
Los argumentos que expone la empresa son: haber
modificado la entrada del blog de la empresa y cambiar
un título insultando a la directiva y superiores.
El cliente afirma (varias veces) no haber realizado esa
modificación y ser inocente.
Contrapericial:
La empresa aportó un informe pericial informático que
realizó ante notario. Básicamente describen como
observan una web WordPress, donde en el apartado de
“Noticias”, el artículo más buscado, tiene un título
“insultante para cargos de la directiva de la empresa y
otros trabajadores superiores [..]”. Concluyen que la
autoría de tal hecho es mi cliente. En la web aparece el
usuario, y solo tienen 3 personas con 3 usuarios
diferentes con accesos al panel de control; el jefe y dos
trabajadores. No obstante, según la fecha que se puede
ver en la captura de pantalla, solo puede ser mi cliente.

7. ¿Qué ha podido pasar?
1. Que mi cliente mienta.
a. Indicios en los registros
2. Que haya sido un intruso tercero
a. Web vulnerable
b. Contraseñas flojas (usuarios identificables)
c. Fuerza bruta
d. Backdoor
3. Que haya sido otra persona de la empresa
a. Registros
b. Tienen acceso (panel, DB y servidor)

8. Hacemos una simple auditoría
Buscamos una copia de seguridad en las fechas de los hechos

9. Footprinting a los usuarios y anti-BF

10. Resultados:
1. Es posible obtener la lista de usuarios
2. Es posible hacer fuerza bruta
Huellas:
- En los registros deberían aparecer miles
de peticiones a wp-login

11. Localizando el servidor web
Nos disponen de un clonado del
servidor en un disco duro externo.
Encontramos que es un Ubuntu server
y usamos el comando “locate” para
identificar qué logs y servidor web está
usando.

12. ¿Qué encontramos en access.log?
De momento nuestro cliente es culpable…
Inicialmente descartamos la intrusión por fuerza bruta.

13. ¿Qué timestamp
tiene WP?
- wp_posts:
- post_modified
***Por defecto no almacena las visitas.

14. ¿Cómo funciona
wp_update_post()?
Su funcionamiento es bastante
sencillo. El primer parámetro acepta
un array con los campos de la tabla
“wp_post” de la base de datos que
queramos cambiar. El segundo
parámetro es opcional. Recibe un
booleano que se puede pasar para
controlar lo que se devuelve en caso
de error. La configuración
predeterminada (false) devolverá un 0
si la publicación no se actualiza. Sin
embargo, si la actualización se realiza
de forma correcta, regresará con un
objeto WP_Error. Predeterminado:
false.

15. ¿Se puede cambiar la
fecha de publicación?
1. Un usuario “administrador” y
“editor” puede cambiar desde el
panel la fecha de publicación.
2. Un usuario “autor” solo puede
cambiar los post suyos
3. El “colaborador” pasa una
revisión y NO puede editar la
fecha de publicación

16. Pero si puede modificar todos los campos…
¿Cómo averiguamos cuando fue modificado?

17. Post_modified
No tiene el atributo de “on update CURRENT_TIMESTAMP”.

18. Y si han modificado el core: wp-includes/posts.php

19. Analizando la actividad

20. Resultados:
1. Paranoia del perito (se descarta)
2. Los archivos del core tenían el mismo hash MD5 que la API de WP
3. Creamos un archivo que lo haga automáticamente

21. Un plugin programado para cambiar el post un día
concreto...

22. Y si estaba programado… cronjobs
WordPress usa un archivo llamado wp-cron.php para realizar un cron virtual de
tareas programadas, con la finalidad de automatizar las actualizaciones, la
autopublicación de entradas, envío de correos, etc.
Para visualizar los cron jobs que tiene nuestra página podemos hacerlo por
código o usando el plugin WP-control.

23. Resultados:
1. Paranoia del perito (no había nada raro)
2. Todo era normal

24. Entonces qué pasó:
Resumen:
1. Aunque el WP no tiene medidas con BF, no hay registro de un ataque
2. La fecha de modificación del artículo corresponde con una hora (intervalo)
que el cliente accede al panel
3. WP permite cambiar la fecha de publicación (y existen 3 usuarios que son
administradores)
4. No hay ningún cronjob peligroso
5. La actividad aparentemente no aparece nada raro
6. Los archivos del core coinciden el hash de la API de WP

25. ¿Qué puede ser entonces?

27. ¿Qué sucedió?
PRIMERO.- Una IP que no es la de mi cliente y coincide con la de su JEFE, se
conecta un día y crea un POST insultado a la directiva de la empresa
SEGUNDO.- El mismo día se conecta una IP que concuerda con la de su
compañero y modifica la fecha de publicación a un día que solo estaba mi cliente
trabajando en la empresa

28. ¿Qué pruebas tenemos?
PRIMERO.- En la base de datos en “post_date” aparece la fecha en la que mi cliente estaba trabajando. Sin embargo,
“post_modified” aparece un fecha posterior.
SEGUNDO.- Si el artículo hubiera sido publicado en la fecha que aparece el ID sería menor. Otros artículos con con fecha
anterior tienen un ID mayor.
TERCERO.- En el registro “access.log” se encuentra la misma IP del compañero que edita el post a la misma fecha y hora
que aparece que es modificado

29. El crimen perfecto...
1. Modificar el “post_modified” desde
phpmyadmin
2. Modificar el access.log y auth.log para no
dejar rastro
Aún así dejarás rastro...

31. Modo operandis
1. Buscan un plugin vulnerable a ISQL y WordPress desactualizados
2. Hacen un footprinting de usuarios
3. Recuperar contraseña con el nombre de usuario
4. Con la ISQL obtienen “user_activation_key”
5. /wp-login.php?action=rp&key=%KEY%&login=admin -> cambiamos %KEY%
por el user_activation_key
6. Cambian la contraseña
7. Insertan el malware / shell desde el editor o instalando un plungin/theme,
subiendo en media, etc

32. ¿Cómo funciona?
Cuando insertan el malware, este se reproduce por el resto de archivos JS y PHP
de la web, insertando un código ofuscado:

33. El código
ofuscado...
- Redireccionan a otra web
(viagra, estafas, etc)
- Gestionan una cookie para
mantener a los usuarios
habituales durante un tiempo
- Para no llamar la atención no
se ejecuta en el panel de
administración

34. ¿Cómo prevenir?
1. WP, plugins y themes
actualizados
2. Implementar plugins de
seguridad
3. Desactivar el editor
4. Implementar medidas contra
fuerza bruta y uso de
contraseñas fuertes
5. Implementar medidas contra
footprinting
6. Copias de seguridad

35. ¿PREGUNTAS?
WWW.QUANTIKA14.COM