Hackers listos para el Black Friday y Cyber Monday

Si piensas que hackear un website es difícil, aquí vamos a compartir un caso interesante que involucra a dos de las aplicaciones CMS más populares del momento: vBulletin y WordPress.

En esta entrada analizaremos un caso real que implica un atacante empeñado en robar información de tarjetas de crédito.

Seguramente te hará reflexionar sobre lo importante de tomar la seguridad de tu WordPress seriamente.

Disfrútalo.

Entorno

El cliente ejecuta un sitio web de comercio electrónico con bastante éxito. Se ejecutan dos aplicaciones principales dentro de su arquitectura – vBulletin y WordPress.

vBulletin se utiliza apoyo y colaboración mediante sus foros, mientras que WordPress se utiliza como sitio web principal y como plataforma de comercio electrónico.

Esta parece ser una configuración bastante estándar usada por una gran parte de las aplicaciones web de estos días.

Todo está sentado en una pila LAMP (Linux / Apache / MySQL / PHP), así que nada demasiado especial.

En su mayor parte, las actualizaciones están al día.

En lo que respecta a la seguridad, que se están ejecutando CloudFlare.

 Sinopsis del caso de hacking

Probablemente te estés preguntando donde se ponen las cosas divertidas.

Recuerdas que dije que eran un sitio de comercio electrónico? Bueno, el atacante no estaba tratando de inyectar malware, estaba robando información de tarjetas de crédito:

 Screen Shot 27/11/2013 a las 6.38.35 PM

Como puedes ver, el código deja caer la información en htdocs / css / css / shop . txt desde donde el atacante puede luego recuperarlo, como se ve en estos registros sin procesar:

En ese archivo, css / shop.txt , adjunta a la parte inferior, la siguiente información para cada transacción:

  1. billing_first_name
  2. billing_last_name
  3. paypal_pro_card_type
  4. paypal_pro_card_number
  5. paypal_pro_card_expiration_month
  6. paypal_pro_card_expiration_year
  7. paypal_pro_card_csc
  8. billing_country
  9. billing_state
  10. billing_city
  11. billing_address_1
  12. billing_postcode
  13. billing_email

¡No tenemos que ser un desarrollador para entender esta información!

¿Como lo hizo?

Al parecer, no hubo vulnerabilidad de día cero o debilidad nivel de servidor lo que concedió al atacante el acceso al sitio.

En su lugar, el atacante fue capaz de aprovechar las credenciales existentes de un usuario que le permitía acceder a los foros como usuario privilegiado.

Con esta cuenta, llegó a crear un nuevo plugin en vBulletin con el que instalar y aprovechar una inclusión de archivos locales (LFI)  en WordPress.

Esto le permitió al atacante interceptar las transacciones de tarjetas de crédito entrantes.

Esas operaciones se guardaban en un archivo local en el servidor que más tarde era recuperado por el atacante.

Podría el propietario del sitio web haber hecho algo para protegerse?

La respuesta es sí y no. En este escenario es bastante evidente que el atacante fue capaz de hacer uso de credenciales.

En estos casos, suelen conseguirse de dos maneras:

  • Un ataque de fuerza bruta que coincidió con el uso de contraseñas débiles
  • Simplemente una mala administración de las cuentas

 

Si deseas saber más detalles del ataque, puedes leer la información completa aqui: WordPress and vBulleting Hacking

Si tienes problemas de seguridad en tu sitio y deseas que un experto te aconseje, click aqui.

Leave a Reply

Your email address will not be published. Required fields are marked *