¿Qué tan segura es tu web? Una travesía de Hacking Ético por pokemon.wuaze.com

En el vasto y a veces caótico mundo de la ciberseguridad y el hacking ético, existe una regla de oro que todo administrador de sistemas debería tatuarse en la memoria: no basta con que una página “se vea bien” o funcione sin errores aparentes . En la superficie, nuestro sitio de pruebas, dedicado al fascinante universo de Pokémon, parece una plataforma inofensiva, un rincón digital para entusiastas. Sin embargo, como expertos en seguridad, nuestro trabajo es ponernos las gafas de rayos X y mirar detrás de la cortina de código.

Recientemente, nos pusimos el sombrero de hackers éticos (o “pentesters“) para evaluar minuciosamente el sitio de ecommerce [https://pokemon.wuaze.com/] diseñado específicamente como ejercicio académico para realizar dichas pruebas. Esta no fue una simple visita de cortesía; fue una auditoría técnica diseñada para encontrar las grietas, los susurros de vulnerabilidades y los fallos de configuración antes de que un actor malintencionado los aproveche. En esta crónica, te llevaré de la mano por el proceso, desde el primer “saludo” digital hasta el descubrimiento de debilidades que podrían poner en jaque toda la infraestructura.

El primer contacto del hacking: ¿Quién responde al otro lado de la red?

Nuestra aventura de hacking ético comenzó con lo que en el argot técnico llamamos Reconocimiento Pasivo y Activo. Imagina que eres un detective que llega a una escena y, antes de entrar a la casa, camina alrededor de la manzana para ver quién entra y quién sale. Nuestra primera herramienta fue el “ping“, que es básicamente el saludo más sencillo que existe en el mundo de las redes. Es como tocar la puerta y esperar un “¿quién es?”.

Curiosamente, al intentar este saludo básico, el servidor nos dio la espalda por completo, mostrando un 100% de pérdida de paquetes [Fig 3]. Pero aquí es donde entra la experiencia: no te engañes pensando que el sitio está caído solo porque no responde a un ping. Muchos servidores modernos están configurados para ignorar el protocolo ICMP (el que usa el ping) para evitar ataques de denegación de servicio o simplemente para pasar desapercibidos ante escaneos automáticos de aficionados.

Para confirmar que el objetivo seguía ahí, decidimos rastrear la ruta (usando la herramienta traceroute). Fue fascinante observar cómo nuestros paquetes de datos viajaban por el océano digital, pasando por diferentes nodos y proveedores de internet, hasta encontrarse con un “muro” de seguridad perimetral que bloqueaba la trazabilidad final [Fig 4]. Este muro es una señal de que el hosting tiene capas de protección activa. A pesar de este silencio administrativo, logramos identificar la “matrícula” del servidor: su dirección IP real es la 185.27.134.223 [Fig 5]. Es como si el servidor nos enviara un mensaje silencioso: “Sé que estás ahí intentando rastrearme, y aunque no te voy a saludar de forma amable, aquí estoy, protegiendo mi territorio”.

Hacking ético: Escaneando las “ventanas” de la casa

Una vez que confirmamos que la “casa” estaba habitada y ubicada en una dirección específica, el siguiente paso de las pruebas de hacking ético fue identificar sus puntos de entrada. En informática, esto se conoce como Escaneo de Puertos. Imagina que el servidor es un edificio enorme con miles de ventanas posibles. Cada ventana (puerto) sirve para algo distinto: una para el correo, otra para la base de datos, otra para la página web que todos vemos.

Utilizando la herramienta reina en este campo, Nmap, lanzamos un escaneo profundo para ver qué ventanas estaban abiertas de par en par. Descubrimos que la casa está bastante bien protegida y mantiene un perfil bajo: solo el puerto 80 (para la web básica sin cifrar), el puerto 443 (para la web segura que todos preferimos) y el puerto 2049 (relacionado con sistemas de archivos en red o NFS) estaban escuchando activamente [Fig 6].

¿Por qué es esto bueno? Porque en seguridad, menos es más. Cada puerto abierto es una oportunidad para un ataque. Al ver que servicios críticos como las bases de datos (puerto 3306), el acceso por consola (SSH, puerto 22) o la transferencia de archivos antigua (FTP, puerto 21) estaban cerrados o filtrados, supimos que el administrador ha hecho un buen trabajo cerrando las puertas innecesarias [Fig 7]. Realizamos pruebas manuales con telnet para intentar forzar una conexión a estos puertos cerrados, y efectivamente, el firewall del servidor nos rechazó de inmediato, lo cual es un excelente indicador de una política de “denegación por defecto”.

El arte del apretón de manos: Criptografía y Confianza

Hoy en día, navegar por una web que no sea segura es como caminar por una calle peligrosa de noche sin luz. Por eso, nos detuvimos a analizar el “apretón de manos” criptográfico del sitio (paso fundamental en nuestras pruebas de hacking ético). Cuando entras a [https://pokemon.wuaze.com], tu navegador y el servidor se ponen de acuerdo en cómo van a cifrar la información para que nadie en el camino pueda leerla.

Aquí las noticias son excelentes y merecen un aplauso técnico. El sitio no solo usa un certificado de seguridad válido emitido por ZeroSSL, sino que ha implementado el estándar TLS 1.3 [Figs 12 y 13]. ¿Qué significa esto en lenguaje humano? TLS 1.3 es la versión más moderna, rápida y segura de los protocolos de cifrado. Elimina algoritmos antiguos que ya han sido rotos por hackers y asegura que la comunicación tenga una “armadura” de 256 bits (TLS_AES_256_GCM_SHA384).

Hicimos una inspección profunda con herramientas de OpenSSL y calificamos la configuración con un Grade A (Nota: Excelente) [Fig 16]. Esto garantiza que si un usuario llena el formulario de contacto con sus datos personales, esa información viajará por internet como un mensaje en clave que solo el servidor de Pokémon puede descifrar. La confidencialidad e integridad están, en este punto, totalmente blindadas.

El gran desafío del hacking: Poniendo a prueba el Top 10 de OWASP

Para que una auditoría sea seria, debemos seguir un estándar de oro: el OWASP Top 10. OWASP es una fundación mundial que cada pocos años publica una lista de los 10 riesgos de seguridad web más críticos. Es, por así decirlo, la “Biblia” de lo que un hacker siempre va a intentar primero.

La defensa del “Guardaespaldas” Digital (WAF)

Algo que nos llamó poderosamente la atención durante las pruebas dinámicas fue la presencia de un “guardaespaldas” muy estricto: un WAF (Web Application Firewall) o sistemas como ModSecurity. Cada vez que intentamos usar herramientas automatizadas para “adivinar” contraseñas en el panel de administración (wp-admin), o cuando probamos enviar caracteres extraños en los formularios para ver si el servidor se confundía (ataques de inyección), el servidor cortaba la conexión de golpe.

En nuestras pantallas aparecía un error técnico de “Unexpected EOF” o cierre inesperado de la conexión SSL [Figs 15, 22 y 25]. Esto no es un error de la web, es una defensa activa. Es como si el servidor detectara un comportamiento robótico o malicioso y decidiera colgar el teléfono antes de que el atacante pueda decir una palabra más. Esta capa de protección es vital para detener los millones de bots que recorren internet buscando víctimas fáciles cada segundo.

El hallazgo crítico: El peligro de los componentes olvidados

Sin embargo, en ciberseguridad hay una máxima: “El atacante solo tiene que tener suerte una vez; el defensor tiene que tener suerte siempre”. Y aquí fue donde encontramos la grieta en la armadura. Nos enfocamos en la categoría A08: Fallas en la Integridad de Software y de los Datos.

Al analizar la estructura de WordPress que da vida al sitio, encontramos una lista enorme de plugins y temas instalados [Figs 20 y 21]. Muchos de ellos, como Contact Form 7 o Wordfence, son excelentes, pero el problema es que cada nuevo plugin es una puerta más que hay que vigilar.

El descubrimiento más preocupante fue el acceso a una herramienta interna: el gestor de bases de datos phpMyAdmin. Al investigar la versión que estaba corriendo (la 2.6.4), se nos encendieron todas las alarmas. Resulta que esta versión es extremadamente antigua y está catalogada con una vulnerabilidad crítica conocida como CVE-2005-3299 [Fig 23].

¿Qué tan grave es esto? Se trata de una falla de “Inclusión de Archivos Locales” (LFI). En términos sencillos, un atacante astuto podría manipular las direcciones de la web para obligar al servidor a mostrar archivos que deberían ser secretos, como archivos de configuración con contraseñas o datos de otros usuarios del sistema. Es el equivalente técnico a tener una puerta blindada con escáner de retina en la entrada principal, pero haber dejado una ventanita de madera vieja y podrida en el sótano que nadie revisa desde hace años.

Análisis de registros y el rastro de migajas | hacking ético

Durante la fase de Footprinting (huella digital), también indagamos en los registros DNS y WHOIS. Queríamos saber quién es el dueño del terreno donde está construida esta web. Descubrimos que la infraestructura se apoya en gigantes como ByetHost y NameCheap [Figs 10 y 11].

Aunque el servidor está bien configurado para no dar demasiada información cuando alguien busca una página que no existe (los famosos errores 404 son genéricos y limpios) [Fig 24], el hecho de que se pueda identificar tan fácilmente la tecnología subyacente (como la versión exacta de PHP en algunos encabezados) le da pistas valiosas a un atacante. En el hacking, la información es poder, y cuanta menos información técnica regalemos (“somos un Apache versión X corriendo en Linux versión Y”), más difícil se lo ponemos al enemigo.

¿Qué aprendimos y cómo podemos fortalecer nuestra web?

Llegamos al final de nuestra travesía de hacking ético con un sabor agridulce, pero muy educativo. Por un lado, tenemos una base sólida: la conectividad está controlada, el firewall hace su trabajo de bloquear ataques automáticos y la criptografía es de primer nivel (ese TLS 1.3 es un lujo). Pero por otro lado, el hallazgo de software antiguo y vulnerable nos recuerda que la seguridad no es un producto que compras una vez y te olvidas; es un proceso que requiere atención constante.

Hoja de ruta

Para que este laboratorio de Pokémon pase de ser “bueno” a “impenetrable”, aquí tienes mi hoja de ruta recomendada:

1. Cirugía de Software (Actualización Inmediata): El riesgo número uno es ese phpMyAdmin antiguo. Mi recomendación es eliminarlo si no se usa constantemente, o actualizarlo a la versión más reciente. No podemos permitirnos tener un CVE (vulnerabilidad conocida) de hace años abierto en nuestro servidor.
2. Limpieza de WordPress: Menos es más. Cada plugin es un riesgo potencial. Debemos auditar la lista de extensiones [Fig 20] y borrar todas aquellas que no sean estrictamente necesarias para el funcionamiento del sitio.
3. Ocultar la Identidad (Obscuridad): Debemos configurar el servidor para que sea más “tímido”. Esto implica desactivar las firmas del servidor que revelan versiones de software en los encabezados HTTP. Si el atacante no sabe qué versión de PHP usas, no sabrá qué ataque intentar.
4. Monitoreo de Integridad: Instalar herramientas que vigilen los archivos del sistema. Si de repente el archivo index.php cambia su tamaño o su contenido sin que nosotros hayamos hecho nada, el sistema debería enviarnos una alerta roja al móvil de inmediato.
5. Reforzar el WAF: Aunque el firewall actual es bueno, se puede configurar para que sea aún más agresivo contra escaneos de vulnerabilidades específicos, bloqueando por IP a cualquier origen que intente buscar archivos sensibles como /etc/passwd.

En conclusión, la seguridad web es una carrera de fondo. El sitio pokemon.wuaze.com tiene unos cimientos muy fuertes y defensas modernas admirables, pero como cualquier entrenador Pokémon sabe, incluso el equipo más fuerte puede caer si tiene una debilidad elemental que no ha sido protegida. Mantenerse actualizado, ser curioso y nunca dar la seguridad por sentada son las mejores armas que cualquier administrador puede tener en su arsenal.

Flipbook de las pruebas completas de pentesting:

Créditos

Autor: Cristian Obando

Editor: Carlos Iván Pinzón Romero

Código: UCHEG1-8

Universidad: Universidad Central

Fuentes

Nmap Software LLC. (2025). Nmap Reference Guide. https://nmap.org/book/ 

Nmap Software LLC. (2025). Nmap Linux manual page. https://linux.die.net/man/1/nmap 

Open Web Application Security Project (OWASP). (2025). OWASP Top 10: 2025. https://owasp.org/Top10/2025/ [owasp.org] 

The OpenSSL Project. (2026). openssl-s_client documentation. https://docs.openssl.org/3.0/man1/openssl-s_client/ [docs.openssl.org] 

The Linux Foundation. (2026). ping (8) — Linux manual page. https://www.man7.org/linux/man-pages/man8/ping.8.html [man7.org] 

Cisco Networking Academy. (2017). ICMP, ping y traceroute. https://ccnadesdecero.es/verificar-conectividad-red-icmp-ping/ 

PhoenixNAP. (2026). OpenSSL s_client: How to test SSL connectivity. https://phoenixnap.com/kb/openssl-s-client