Cuando un sitio web es hackeado, el ataque no termina con el payload de contenido malicioso o spam. Los hackers saben que la mayoría de los administradores del sitio web podrán eliminar la infección y buscarán por ella. Algunos admins fijan software vulnerable, cambian sus contraseñas, y realizan otros pasos después del hackeo. Todo esto es bueno, pero los hackers tras el ataque también buscan formas de reinfectar fácilmente el sitio web.
Después de invadir un sitio web, los hackers aseguran que todavía tengan acceso al sitio web si se reparó la falla de seguridad original. La mayor parte del tiempo, cargan puertas traseras o crean nuevos usuarios maliciosos. También combinan los dos enfoques: login bypasses. Por lo tanto, los atacantes obtenen derechos administrativos sin autenticación mediante un parámetro especial en la petición HTTP.
Login Bypass en WordPress
Recientemente, hemos encontrado este código de bypass con un error en un archivo wp-login.php de WordPress.
la petición fue puesta dentro de un comentario legítimo, lo que la hizo más sospechosa, ya que este truco sólo es utilizado por el malware.
El objetivo de este código es proporcionar un ID de usuario de administración al parametro kidsid al buscar por wp-login.php. Esto permite al atacante acceder al panel de WordPress con el permiso de administrador.
Por ejemplo, con N como ID del usuario admin:
httx://infected-site.com/wp-login.php?kidsid=N
Mejor que Admins Falsos
Esta técnica tiene ventajas con respecto a la creación de nuevos usuarios que se pueden notar y se eliminar. No se eliminará un usuario legítimo administrador durante una limpieza. Los hackers ni siquiera necesitan saber el nombre del usuario administrador. Muchos sitios web de WordPress todavía tienen el usuario administrador por defecto creado durante la instalación. Este usuario tiene ID 1. Sin embargo, los atacantes no tienen que usar sólo el conocimiento de este hecho.
Con herramientas como wpscan, es facil para cualquiera descubrir los ID de usuario de administración de WordPress. Si el atacante puede inyectar código en wp-login.php, más probable es que se le permita ejecutar un SQL query sencillo e identificar todos los ID del administrador del sitio web.
Código con Bug
La intención del bug es bastante clara. Sin embargo, este código no funcionará en particular por razones obvias para cualquiera que esté familiarizado con la API de WordPress o incluso sólo PHP. El error es muy tonto.
Teniendo en cuenta que este código se basa casi por completo en un ejemplo que se puede encontrar en el WordPress Codex, se puede sugerir que el hacker es un “script kiddie”, que sólo puede utilizar scripts de terceros y tiene habilidades copy/paste limitadas.
Además, la inyección en wp-login.php está condenado a ser eliminada porque este archivo se sobrescribe durante las actualizaciones de WordPress.
Secuestrando el Login Form
Otra manera de asegurarse de que tiene credenciales válidas en WordPress es secuestrando el formulario de acceso (login form). Para ello, los hackers suelen inyectar el malware en el wp-login.php como habíamos visto.
Sigue otro ejemplo reciente:
Cuando un usuario entra correctamente en WordPress, este código envía un correo electrónico con la dirección URL del sitio web y las credenciales del usuario al atacante.
Detalle interesante: Ese malware también tiene un bug.
Si usted verifica la línea 843 en la imagen de arriba, ve que la concatenación $body no es completa y no hay el punto y coma al final de la línea. Parece que el atacante modificó esta línea, pero se olvidó de terminarla correctamente.
PHP es muy indulgente cuando se trata de este tipo de errores (que por lo general resultan en todo tipo de efectos secundarios inesperados) y este código realmente funciona. El PHP sólo convierte literales sin comillas en strings y concatena el $bodycon los $headers en la línea siguiente. Como resultado de ello, el texto del correo electrónico termina con MIME-Version: 1.0 (que debe ir a los encabezados de los correos electrónicos), pero aún así, funciona.
Aprendiendo con el Malware
Incluso si estas muestras tienen errores y el código de desvío no es funcional, nos enseña algunas lecciones de seguridad.
- Sepa si sus archivos core de WordPress están intactos. El monitoreo de integridad va a ayudarle a detectar este tipo de inyección.
- Remueva el usuario administrador por defecto de WordPress con el ID 1. La primera cosa que debe hacer después de instalar un nuevo blog de WordPress es la creación de un nuevo administrador con un nombre difícil de adivinar y eliminar el usuario administrador por defecto. Esto reducirá significativamente las posibilidades de ataques de fuerza bruta, y también cambiará el ID del administrador por defecto.
- No se debe publicar cualquier cosa usando la cuenta de administrador. Es fácil encontrar los ID de usuario que publican mensajes en su blog. Utilice una cuenta especial en el editor o autor para postar en el blog y utilizar la cuenta de administrador sólo para las tareas de gestión del sitio web. Por lo tanto, los atacantes sólo serán capaces de encontrar cuentas limitadas cuando escanearem su sitio web.
- Sea notificado cuando un administrador iniciar sesión en su sitio web para ver si su cuenta se ha visto comprometida. Hay muchos plugins que lo hacen.
- Considere la posibilidad de restringir el acceso al área de administración de WordPress. Proteja el área protegida por contraseña en el servidor, o proporcione acceso sólo a las direcciones IP fiables. Incluso si los hackers roban las credenciales de WordPress o inyectan un código de bypass, no estarán en condiciones de usar, incluso el área de administración de WordPress.
- Mantenga copias de seguridad de su sitio web. Los hackers no son los mejores programadores. Los errores no son poco comunes, tanto en sus herramientas como en las inyecciones de malware. A menudo vemos como sus errores corrompem archivos legítimos. Por eso hay que tener una buena estrategia de copias de seguridad que incluya el almacenamiento de copia de seguridad en un servidor diferente.
Por supuesto, esto no es una lista completa de cosas que debe hacer para proteger a un sitio web de WordPress. Es altamente recomendable la lectura de la guía oficial de Hardening de WordPress en WordPress Codex, así como los recursos especializados de los miembros de la comunidad, como Yoast.
Fuente:https://blog.sucuri.net/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
