Auditoría de Seguridad Web con Hacking Ético: Así se Protege una Tienda Online Real
¿Qué tan seguro está un sitio de comercio electrónico ante los ojos de un atacante? Esta es la pregunta que un grupo de estudiantes de Ingeniería de la Universidad Central de Colombia respondió con herramientas reales, metodologías internacionales y un enfoque completamente ético y legal. El resultado: una auditoría completa sobre el dominio celularestechologic.free.nf, una tienda en línea de venta de dispositivos móviles, que expone con claridad cómo funciona el hacking ético desde adentro y qué tan vulnerable o resistente puede ser una infraestructura web moderna.
En este artículo desglosamos paso a paso los hallazgos de esa auditoría, desde el reconocimiento de red hasta las pruebas de las diez vulnerabilidades más críticas según OWASP, la organización de referencia mundial en seguridad de aplicaciones web.
¿Qué es el Hacking Ético y por Qué Importa?
El hacking ético es la práctica de aplicar las mismas técnicas que usaría un atacante malicioso, pero con autorización expresa del propietario del sistema y con el objetivo de identificar vulnerabilidades antes de que alguien las explote. No se trata de una actividad clandestina ni ilegal: todo lo contrario. Un hacker ético trabaja dentro de un marco legal estricto, documentado y acordado con el cliente. En un mundo donde los ciberataques cuestan a las empresas millones de dólares al año y donde el comercio electrónico maneja datos financieros y personales de miles de usuarios, contar con auditorías de seguridad periódicas no es un lujo, es una necesidad. La ciberseguridad preventiva es siempre más económica que responder a una brecha de datos después del hecho.
El Punto de Partida: Las Reglas de Compromiso
Antes de ejecutar cualquier herramienta o enviar un solo paquete de red, el equipo auditor formalizó un documento legal conocido como Reglas de Compromiso (Rules of Engagement). Este acta define con precisión el alcance de la prueba, el dominio autorizado, las herramientas permitidas, la ventana de tiempo en la que se ejecutarán las pruebas y los canales de comunicación en caso de emergencia.
Para esta auditoría, los parámetros fueron los siguientes:
- Dominio objetivo: celularestechologic.free.nf
- Dirección IP autorizada: 185.27.134.112
- Herramientas aprobadas: Ping (ICMP), Tracert/Traceroute y Nmap
- Ventana de ejecución: 11 de abril de 2026, de 19:00 a 23:59 hrs (GMT-5)
- Restricciones: Prohibido realizar ataques DoS/DDoS, explotar vulnerabilidades o alterar datos
Este marco no es un simple formalismo. Es la línea que separa al profesional de la ciberseguridad del delincuente informático.
Fase 1: Reconocimiento de Red — Ping e ICMP
La primera herramienta utilizada fue Ping, un comando que envía solicitudes de eco mediante el protocolo ICMP para verificar si un servidor está activo y medir la latencia de la conexión.
El resultado fue llamativo: se obtuvo una pérdida del 100% de los paquetes. Sin embargo, esto no significó que el servidor estuviera inactivo. Lo que reveló fue algo más valioso desde el punto de vista de la seguridad: el proveedor de alojamiento (InfinityFree) tiene configurado un firewall que bloquea todo el tráfico ICMP entrante, una práctica estándar para mitigar ataques de denegación de servicio (DDoS) básicos.
Lo más relevante de esta prueba fue que, a pesar del bloqueo, el comando cumplió su función de reconocimiento al resolver exitosamente el nombre de dominio a la dirección IP pública 185.27.134.112. Obtener esta dirección fue el primer paso crítico para los análisis posteriores.
Trazando la Ruta: Tracert y el Viaje Internacional de los Paquetes
El siguiente paso fue ejecutar Tracert (Traceroute), una herramienta que mapea la ruta lógica que siguen los paquetes de datos desde el equipo del auditor hasta el servidor de destino, identificando cada nodo o salto intermedio.
Los resultados revelaron información fascinante sobre la infraestructura de red global. Los paquetes no tomaron una ruta directa: partieron desde la red local (192.168.0.1), atravesaron la infraestructura del proveedor de internet local, cruzaron por nodos de tránsito en Miami (salto 5) y finalmente llegaron hasta el Reino Unido (Manchester, saltos 7 y 8), pasando por redes troncales Tier 1 como Level3 y Twelve99.
A partir del salto 9, todos los nodos dejaron de responder, lo que confirmó que el firewall perimetral de InfinityFree está configurado para no revelar la topología interna de su centro de datos, ocultando deliberadamente la infraestructura final al mapeo no autorizado.
Escaneo de Puertos con Nmap: ¿Qué Servicios Están Expuestos?
La fase de reconocimiento activo culminó con el escaneo de puertos mediante Nmap, la herramienta de análisis de red más utilizada en el mundo de la ciberseguridad. El objetivo era identificar qué servicios TCP estaban escuchando activamente en la dirección IP del servidor.
Los resultados del escaneo mostraron únicamente tres puertos en estado abierto:
- Puerto 80/tcp (HTTP): Servicio web estándar sin cifrado.
- Puerto 443/tcp (HTTPS): Servicio web seguro con cifrado SSL/TLS.
- Puerto 2049/tcp (NFS): Network File System, característico de entornos de hosting compartido donde los servidores interconectan el almacenamiento de clientes mediante sistemas de archivos en red.
Adicionalmente, el reporte indicó que 776 puertos se encontraban filtrados y 221 estaban cerrados. Esto confirmó la existencia de un firewall perimetral activo que restringe el acceso a cualquier servicio no esencial, reduciendo significativamente la superficie de ataque disponible.
DNS, WHOIS y Certificado SSL: La Identidad Digital del Sitio
El análisis de reconocimiento pasivo complementó la fase anterior con tres consultas fundamentales:
DNS con nslookup: La herramienta confirmó que el dominio celularestechologic.free.nf resuelve a la dirección IP 185.27.134.24, verificando la conectividad y la correcta configuración de los servidores de nombres.
WHOIS: La consulta a la base de datos pública reveló que el dominio raíz *free.nf* fue creado el 14 de junio de 2023, con última actualización el 25 de noviembre de 2025 y fecha de vencimiento el 14 de junio de 2026. Los nameservers están alojados en InfinityFree (ns1.infinityfree.com / ns2.infinityfree.com). Esta información, aunque pública, es de alto valor para un atacante, ya que permite conocer cuándo vence el dominio y qué registrador gestiona la cuenta.
Certificado SSL: El sitio presenta un certificado válido emitido por ZeroSSL, con fecha de emisión el 26 de marzo de 2026 y vencimiento el 25 de junio de 2026. La presencia de este certificado protege las comunicaciones mediante cifrado, previniendo ataques de intermediario (Man in the Middle / MITM).
Fase 2: La Metodología OWASP Top 10, auditando la Capa de Aplicación
Con el reconocimiento de red completado, la auditoría avanzó hacia la capa más crítica: la aplicación web. Para estructurar este análisis, el equipo adoptó el estándar OWASP Top 10 (versión 2021), el marco de gestión de riesgos en aplicaciones web más reconocido a nivel mundial. Este modelo evalúa cada vulnerabilidad según su prevalencia, detectabilidad e impacto técnico potencial.
A continuación, se presentan los hallazgos más relevantes de cada categoría analizada.
A01 — Control de Acceso: Directorios Protegidos y Administración Segura
La prueba consistió en intentar acceder directamente a directorios internos del CMS, como `/wp-includes/`, y al panel de administración `/wp-admin/` sin credenciales válidas. En ambos casos, el servidor respondió correctamente:
- El acceso al directorio interno devolvió un error 403 Forbidden, bloqueando cualquier visualización del árbol de archivos.
- El acceso al panel administrativo redirigió al formulario de autenticación sin revelar información del sistema.
Resultado: El sitio está mitigado contra estas formas básicas de pérdida de control de acceso. Se recomienda complementar la protección con Autenticación Multifactor (MFA) y límites en los intentos de inicio de sesión.
A02 — Fallas Criptográficas: HTTPS Obligatorio y Certificado Válido
Se realizó una petición forzada al servidor usando el protocolo no seguro HTTP (sin cifrado) para comprobar si el sitio permite tráfico en texto plano. El servidor respondió con una redirección 301 automática hacia HTTPS, garantizando que todas las comunicaciones estén cifradas.
La auditoría del certificado SSL/TLS confirmó que se encuentra activo, vigente y reconocido por los navegadores modernos. Como recomendación de mejora, se sugiere implementar la cabecera HSTS (HTTP Strict Transport Security) para obligar a los navegadores a usar HTTPS de forma permanente, incluso ante intentos de degradación de protocolo.
A03 — Inyección SQL: El Sistema Resistió el Ataque
Una de las pruebas más esperadas fue la inyección de código SQL en el formulario de inicio de sesión. Se ingresó el vector de ataque clásico `’ OR ‘1’=’1` en el campo de usuario para intentar forzar una condición lógica verdadera que permitiera saltarse la autenticación.
El sistema respondió de forma ejemplar: no devolvió errores de base de datos ni permitió el acceso no autorizado. WordPress trata los datos ingresados como texto inofensivo gracias al uso de consultas parametrizadas (Prepared Statements) a través de su clase nativa `$wpdb` y el método `prepare()`. El payload fue interpretado como un texto inválido y el formulario simplemente rechazó el acceso.
A04, A05 y A07 — Diseño Inseguro, Configuración y Autenticación: Tres Victorias para la Seguridad
Diseño Inseguro (A04):
Se probó la enumeración de usuarios mediante el parámetro `/?author=1` en la URL. El sistema rechazó la solicitud mostrando el mensaje “prohibido – número en el nombre del autor no permitido”, impidiendo que un atacante descubra nombres de usuario válidos para usarlos en ataques de fuerza bruta.
Configuración Defectuosa (A05):
Se intentó acceder al archivo `xmlrpc.php`, un protocolo de WordPress frecuentemente explotado para amplificar ataques. El servidor devolvió un error `ERR_EMPTY_RESPONSE`, confirmando que el acceso está bloqueado a nivel de firewall.
Autenticación (A07):
Al ingresar credenciales incorrectas, el sistema respondió con el mensaje genérico “Datos de acceso no válidos”, sin especificar si el error provenía del usuario o la contraseña. Esta respuesta ambigua es una excelente práctica de seguridad que dificulta la enumeración de cuentas.
A06 — El Talón de Aquiles: WordPress Desactualizado
Este fue el hallazgo más crítico de toda la auditoría. El panel de administración reveló que el sitio ejecuta WordPress 6.9.1, mientras que la versión más reciente disponible en el momento de la prueba era la 6.9.4. Además, cuatro plugins instalados —Everest Forms, PageLayer, Starter Templates y WooCommerce— también presentaban actualizaciones pendientes.
Operar con versiones desactualizadas representa un riesgo severo. Las bases de datos públicas de vulnerabilidades (CVEs) documentan en detalle las fallas conocidas de cada versión, y los atacantes las explotan activamente. La recomendación inmediata es aplicar todos los parches disponibles y activar las actualizaciones automáticas en segundo plano.
A08 y A09 — Integridad del Software y la Gran Deuda Pendiente: el Monitoreo
Integridad del software (A08):
Se verificó que WordPress descarga todos sus parches desde los repositorios oficiales, donde se validan firmas digitales antes de instalar cualquier paquete. Sin embargo, el sistema mostró una advertencia crítica: “Actualización automática con un retraso de 2 meses. Puede que haya un problema con WP-Cron.” Esto significa que el mecanismo automático de actualización está fallando, forzando una dependencia total de la intervención manual del administrador.
Registro y monitoreo (A09):
Se intentó acceder al archivo de registro del sistema (`/wp-content/debug.log`) a través del navegador. El servidor devolvió un error 404, lo que confirmó que el sistema no está generando ni almacenando registros de seguridad. En la práctica, esto significa que, ante un ataque de fuerza bruta o una intrusión, los administradores no tendrían alertas ni evidencia forense para investigar lo ocurrido.
Esta es la vulnerabilidad más peligrosa en términos operativos, porque no se trata de un punto de entrada directo para el atacante, sino de la ausencia de visibilidad sobre lo que ocurre en el sistema. La recomendación principal es instalar un plugin de auditoría como WP Activity Log y activar la generación de logs de forma segura.
A10 — SSRF: El Servidor No Hace lo que el Atacante Quiere
La última prueba evaluó la vulnerabilidad de Falsificación de Solicitudes del Lado del Servidor (SSRF). En entornos WordPress, el principal vector de este ataque es el archivo `xmlrpc.php`, cuya función de Pingback puede ser abusada para obligar al servidor a realizar peticiones HTTP hacia infraestructuras internas o externas, ocultando el origen real del ataque.
Al intentar acceder a este archivo, el servidor cortó la conexión abruptamente devolviendo un error `ERR_EMPTY_RESPONSE`. Esto confirma que InfinityFree aplica reglas de firewall que bloquean cualquier tráfico hacia este punto de entrada crítico, neutralizando el riesgo de SSRF por esta vía.
Conclusiones: Un Sistema Robusto con Tareas Pendientes
La auditoría completa sobre celularestechologic.free.nf dejó un balance claro y honesto:
Lo que funciona bien:
- Firewall perimetral sólido que filtra el tráfico no esencial.
- HTTPS habilitado y funcionando con certificado SSL válido.
- Protección contra inyección SQL gracias a la arquitectura de WordPress.
- Bloqueo de acceso a directorios sensibles y al panel administrativo.
- Mensajes de error genéricos que dificultan la enumeración de usuarios.
- Bloqueo del archivo xmlrpc.php a nivel de infraestructura.
Lo que necesita atención urgente:
- Actualizar el núcleo de WordPress de la versión 6.9.1 a la 6.9.4 y mantener los plugins al día.
- Reparar el sistema WP-Cron para restablecer las actualizaciones automáticas.
- Implementar un sistema de registro y monitoreo activo (logs de seguridad y auditoría).
- Añadir Autenticación Multifactor (MFA) para las cuentas administrativas.
- Implementar la cabecera HSTS para reforzar la política de transporte seguro.
La ciberseguridad no es un estado binario entre “seguro” e “inseguro”. Es un proceso continuo de evaluación, mejora y adaptación. Esta auditoría demostró que incluso un sitio con buenas prácticas de base puede tener brechas operativas que, de no corregirse, se convierten en la puerta de entrada que un atacante necesita.
Créditos:
Autores: Omar Daniel Gaitán Porras, Andrés Camilo Plaza Jiménez, Kevin Camilo Lozano Castellanos
Editor: Carlos Iván Pinzón Romero
Código: UCHE-1
Universidad: Universidad Central
Fuentes:
InfinityFree. (s. f.). Knowledge base: Security and firewalls.
https://www.infinityfree.com/support/
Mockapetris, P. (1987). Domain names - implementation and specification (RFC 1035). Internet Engineering Task Force. https://doi.org/10.17487/RFC1035
NIST. (2008). Technical guide to information security testing and assessment (Special Publication 800-115). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-115
WP Activity Log. (2024). WordPress activity log: Features and documentation. https://wpactivitylog.com/features/
WordPress.org. (s. f.). Debugging in WordPress: WP_DEBUG_LOG documentation. https://wordpress.org/documentation/article/debugging-in-wordpress/
ZeroSSL. (2026). Terms of service and certificate issuance. https://zerossl.com/terms/
