Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Forense en WordPress

155 visualizaciones

Publicado el

Presentación utilizada por Jorge Coronado en el meetup de WordPress Sevilla el pasado 20 de marzo de 2019. Dos casos: uno donde culpaban al cliente de haber publicado un POST insultando a los jefes y otro sobre el malware de "viagra" que infecta tantos WP.

Publicado en: Tecnología
  • Sé el primero en comentar

Forense en WordPress

  1. 1. 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
  2. 2. ¿Qué vamos a ver? ● Caso 1: “Despido procedente para el jefe.” ● Caso 2: “remove_action(‘VIAGRA’);”
  3. 3. 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.
  4. 4. ¿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)
  5. 5. Hacemos una simple auditoría Buscamos una copia de seguridad en las fechas de los hechos
  6. 6. Footprinting a los usuarios y anti-BF
  7. 7. 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
  8. 8. 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.
  9. 9. ¿Qué encontramos en access.log? De momento nuestro cliente es culpable… Inicialmente descartamos la intrusión por fuerza bruta.
  10. 10. ¿Qué timestamp tiene WP? - wp_posts: - post_modified ***Por defecto no almacena las visitas.
  11. 11. ¿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.
  12. 12. ¿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
  13. 13. Pero si puede modificar todos los campos… ¿Cómo averiguamos cuando fue modificado?
  14. 14. Post_modified No tiene el atributo de “on update CURRENT_TIMESTAMP”.
  15. 15. Y si han modificado el core: wp-includes/posts.php
  16. 16. Analizando la actividad
  17. 17. 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
  18. 18. Un plugin programado para cambiar el post un día concreto...
  19. 19. 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.
  20. 20. Resultados: 1. Paranoia del perito (no había nada raro) 2. Todo era normal
  21. 21. 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
  22. 22. ¿Qué puede ser entonces?
  23. 23. ¿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
  24. 24. ¿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
  25. 25. 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...
  26. 26. 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
  27. 27. ¿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:
  28. 28. 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
  29. 29. ¿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
  30. 30. ¿PREGUNTAS? WWW.QUANTIKA14.COM

×