{"id":86088,"date":"2026-05-05T12:24:12","date_gmt":"2026-05-05T17:24:12","guid":{"rendered":"https:\/\/niixer.com\/?p=86088"},"modified":"2026-05-05T12:24:13","modified_gmt":"2026-05-05T17:24:13","slug":"que-tan-segura-es-tu-web-una-travesia-de-hacking-etico-por-pokemon-wuaze-com","status":"publish","type":"post","link":"https:\/\/niixer.com\/index.php\/2026\/05\/05\/que-tan-segura-es-tu-web-una-travesia-de-hacking-etico-por-pokemon-wuaze-com\/","title":{"rendered":"\u00bfQu\u00e9 tan segura es tu web? Una traves\u00eda de Hacking \u00c9tico por pokemon.wuaze.com"},"content":{"rendered":"\n

En el vasto y a veces ca\u00f3tico mundo de la ciberseguridad<\/a> y el hacking \u00e9tico, existe una regla de oro que todo administrador de sistemas deber\u00eda tatuarse en la memoria: no basta con que una p\u00e1gina “se vea bien” o funcione sin errores aparentes . En la superficie, nuestro sitio de pruebas, dedicado al fascinante universo de Pok\u00e9mon<\/a>, parece una plataforma inofensiva, un rinc\u00f3n digital para entusiastas. Sin embargo, como expertos en seguridad, nuestro trabajo es ponernos las gafas de rayos X y mirar detr\u00e1s de la cortina de c\u00f3digo.<\/p>\n\n\n\n

Recientemente, nos pusimos el sombrero de hackers \u00e9ticos<\/a><\/strong> (o “pentesters<\/a>“) para evaluar minuciosamente el sitio de ecommerce [https:\/\/pokemon.wuaze.com\/]<\/a><\/code> dise\u00f1ado espec\u00edficamente como ejercicio acad\u00e9mico para realizar dichas pruebas. Esta no fue una simple visita de cortes\u00eda; fue una auditor\u00eda t\u00e9cnica dise\u00f1ada para encontrar las grietas, los susurros de vulnerabilidades<\/a> y los fallos de configuraci\u00f3n antes de que un actor malintencionado los aproveche. En esta cr\u00f3nica, te llevar\u00e9 de la mano por el proceso, desde el primer “saludo” digital hasta el descubrimiento de debilidades que podr\u00edan poner en jaque toda la infraestructura.<\/p>\n\n\n\n

\"pokemon.waze.com\"
pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

El primer contacto del hacking: \u00bfQui\u00e9n responde al otro lado de la red?<\/strong><\/h2>\n\n\n\n

Nuestra aventura de hacking \u00e9tico comenz\u00f3 con lo que en el argot t\u00e9cnico llamamos Reconocimiento Pasivo y Activo<\/strong>. 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\u00e9n entra y qui\u00e9n sale. Nuestra primera herramienta fue el “ping<\/a>“, que es b\u00e1sicamente el saludo m\u00e1s sencillo que existe en el mundo de las redes. Es como tocar la puerta y esperar un “\u00bfqui\u00e9n es?”.<\/p>\n\n\n\n

\"ping
ping pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

Curiosamente, al intentar este saludo b\u00e1sico, el servidor nos dio la espalda por completo, mostrando un 100% de p\u00e9rdida de paquetes [Fig 3]. Pero aqu\u00ed es donde entra la experiencia: no te enga\u00f1es pensando que el sitio est\u00e1 ca\u00eddo solo porque no responde a un ping. Muchos servidores modernos est\u00e1n configurados para ignorar el protocolo ICMP<\/a> (el que usa el ping) para evitar ataques de denegaci\u00f3n de servicio o simplemente para pasar desapercibidos ante escaneos autom\u00e1ticos de aficionados.<\/p>\n\n\n\n

Para confirmar que el objetivo segu\u00eda ah\u00ed, decidimos rastrear la ruta (usando la herramienta traceroute<\/a><\/code>). Fue fascinante observar c\u00f3mo nuestros paquetes de datos viajaban por el oc\u00e9ano digital, pasando por diferentes nodos y proveedores de internet<\/a>, hasta encontrarse con un “muro” de seguridad perimetral que bloqueaba la trazabilidad final [Fig 4]. Este muro es una se\u00f1al de que el hosting tiene capas de protecci\u00f3n activa. A pesar de este silencio administrativo, logramos identificar la “matr\u00edcula” del servidor: su direcci\u00f3n IP real es la 185.27.134.223<\/code> [Fig 5]. Es como si el servidor nos enviara un mensaje silencioso: “S\u00e9 que est\u00e1s ah\u00ed intentando rastrearme, y aunque no te voy a saludar de forma amable, aqu\u00ed estoy, protegiendo mi territorio”<\/em>.<\/p>\n\n\n\n

\"traza
traza pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

Hacking \u00e9tico: Escaneando las “ventanas” de la casa<\/strong><\/h2>\n\n\n\n

Una vez que confirmamos que la “casa” estaba habitada y ubicada en una direcci\u00f3n espec\u00edfica, el siguiente paso de las pruebas de hacking \u00e9tico fue identificar sus puntos de entrada. En inform\u00e1tica, esto se conoce como Escaneo de Puertos<\/a><\/strong>. Imagina que el servidor<\/a> 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\u00e1gina web que todos vemos.<\/p>\n\n\n\n

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

\"puertos
puertos pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

\u00bfPor qu\u00e9 es esto bueno? Porque en seguridad, menos es m\u00e1s. Cada puerto abierto es una oportunidad para un ataque. Al ver que servicios<\/a> cr\u00edticos como las bases de datos (puerto 3306), el acceso por consola (SSH<\/a>, puerto 22) o la transferencia de archivos antigua (FTP<\/a>, 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<\/a><\/code> para intentar forzar una conexi\u00f3n a estos puertos cerrados, y efectivamente, el firewall del servidor nos rechaz\u00f3 de inmediato, lo cual es un excelente indicador de una pol\u00edtica de “denegaci\u00f3n por defecto”.<\/p>\n\n\n\n

\"telnet
telnet pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

El arte del apret\u00f3n de manos: Criptograf\u00eda y Confianza<\/strong><\/h2>\n\n\n\n

Hoy en d\u00eda, 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\u00f3n de manos” criptogr\u00e1fico del sitio (paso fundamental en nuestras pruebas de hacking \u00e9tico). Cuando entras a [https:\/\/pokemon.wuaze.com<\/a>]<\/code>, tu navegador<\/a> y el servidor se ponen de acuerdo en c\u00f3mo van a cifrar la informaci\u00f3n para que nadie en el camino pueda leerla.<\/p>\n\n\n\n

Aqu\u00ed las noticias son excelentes y merecen un aplauso t\u00e9cnico. El sitio no solo usa un certificado de seguridad v\u00e1lido emitido por ZeroSSL<\/strong>, sino que ha implementado el est\u00e1ndar TLS 1.3<\/a><\/strong> [Figs 12 y 13]. \u00bfQu\u00e9 significa esto en lenguaje humano? TLS 1.3 es la versi\u00f3n m\u00e1s moderna, r\u00e1pida y segura de los protocolos de cifrado. Elimina algoritmos<\/a> antiguos que ya han sido rotos por hackers y asegura que la comunicaci\u00f3n tenga una “armadura” de 256 bits (TLS_AES_256_GCM_SHA384).<\/p>\n\n\n\n

\"ssl
ssl (1) pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n
\"ssl
ssl (2) pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

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

<\/p>\n\n\n\n

El gran desaf\u00edo del hacking: Poniendo a prueba el Top 10 de OWASP<\/strong><\/h2>\n\n\n\n

Para que una auditor\u00eda<\/a> sea seria, debemos seguir un est\u00e1ndar de oro: el OWASP Top 10<\/a><\/strong>. OWASP es una fundaci\u00f3n mundial que cada pocos a\u00f1os publica una lista de los 10 riesgos de seguridad web m\u00e1s cr\u00edticos. Es, por as\u00ed decirlo, la “Biblia” de lo que un hacker siempre va a intentar primero.<\/p>\n\n\n\n

La defensa del “Guardaespaldas” Digital (WAF)<\/strong><\/h3>\n\n\n\n

Algo que nos llam\u00f3 poderosamente la atenci\u00f3n durante las pruebas din\u00e1micas fue la presencia de un “guardaespaldas” muy estricto: un WAF<\/strong> (Web Application Firewall<\/a>) o sistemas como ModSecurity<\/a>. Cada vez que intentamos usar herramientas automatizadas para “adivinar” contrase\u00f1as en el panel de administraci\u00f3n (wp-admin<\/code>), o cuando probamos enviar caracteres extra\u00f1os en los formularios para ver si el servidor se confund\u00eda (ataques de inyecci\u00f3n), el servidor cortaba la conexi\u00f3n de golpe.<\/p>\n\n\n\n

\"OWASP_A01
OWASP_A01<\/figcaption><\/figure>\n\n\n\n
\"OWASP_A07
OWASP_A07<\/figcaption><\/figure>\n\n\n\n
\"OWASP_A10
OWASP_A10<\/figcaption><\/figure>\n\n\n\n

En nuestras pantallas aparec\u00eda un error t\u00e9cnico de “Unexpected EOF” o cierre inesperado de la conexi\u00f3n 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\u00f3tico o malicioso y decidiera colgar el tel\u00e9fono antes de que el atacante pueda decir una palabra m\u00e1s. Esta capa de protecci\u00f3n es vital para detener los millones de bots que recorren internet buscando v\u00edctimas f\u00e1ciles cada segundo.<\/p>\n\n\n\n

El hallazgo cr\u00edtico: El peligro de los componentes olvidados<\/strong><\/h3>\n\n\n\n

Sin embargo, en ciberseguridad hay una m\u00e1xima: “El atacante solo tiene que tener suerte una vez; el defensor tiene que tener suerte siempre”. Y aqu\u00ed fue donde encontramos la grieta en la armadura. Nos enfocamos en la categor\u00eda A08: Fallas en la Integridad de Software y de los Datos<\/strong>.<\/p>\n\n\n\n

Al analizar la estructura de WordPress<\/a> 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<\/em> o Wordfence<\/em>, son excelentes, pero el problema es que cada nuevo plugin es una puerta m\u00e1s que hay que vigilar.<\/p>\n\n\n\n

\n
\n
\"OWASP_A06
OWASP_A06<\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n
\"OWASP_A06
OWASP_A06<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

El descubrimiento m\u00e1s preocupante fue el acceso a una herramienta interna: el gestor de bases de datos phpMyAdmin<\/strong>. Al investigar la versi\u00f3n que estaba corriendo (la 2.6.4), se nos encendieron todas las alarmas. Resulta que esta versi\u00f3n es extremadamente antigua y est\u00e1 catalogada con una vulnerabilidad cr\u00edtica conocida como CVE-2005-3299<\/strong> [Fig 23].<\/p>\n\n\n\n

\u00bfQu\u00e9 tan grave es esto? Se trata de una falla de “Inclusi\u00f3n de Archivos Locales” (LFI)<\/a>. En t\u00e9rminos sencillos, un atacante astuto podr\u00eda manipular las direcciones de la web para obligar al servidor a mostrar archivos que deber\u00edan ser secretos, como archivos de configuraci\u00f3n con contrase\u00f1as o datos de otros usuarios del sistema. Es el equivalente t\u00e9cnico a tener una puerta blindada con esc\u00e1ner de retina en la entrada principal, pero haber dejado una ventanita de madera vieja y podrida en el s\u00f3tano que nadie revisa desde hace a\u00f1os.<\/p>\n\n\n\n

An\u00e1lisis de registros y el rastro de migajas | hacking \u00e9tico<\/strong><\/h2>\n\n\n\n

Durante la fase de Footprinting<\/a><\/strong> (huella digital), tambi\u00e9n indagamos en los registros DNS y WHOIS. Quer\u00edamos saber qui\u00e9n es el due\u00f1o del terreno donde est\u00e1 construida esta web. Descubrimos que la infraestructura se apoya en gigantes como ByetHost y NameCheap [Figs 10 y 11].<\/p>\n\n\n\n

\n
\n
\"whois
whois pokemon.waze.com<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n
\"whois
whois pokemon.waze.com<\/figcaption><\/figure>\n\n\n\n

Aunque el servidor est\u00e1 bien configurado para no dar demasiada informaci\u00f3n cuando alguien busca una p\u00e1gina que no existe (los famosos errores 404 <\/a>son gen\u00e9ricos y limpios) [Fig 24], el hecho de que se pueda identificar tan f\u00e1cilmente la tecnolog\u00eda subyacente (como la versi\u00f3n exacta de PHP en algunos encabezados) le da pistas valiosas a un atacante. En el hacking, la informaci\u00f3n es poder, y cuanta menos informaci\u00f3n t\u00e9cnica regalemos (“somos un Apache <\/a>versi\u00f3n X corriendo en Linux<\/a> versi\u00f3n Y”), m\u00e1s dif\u00edcil se lo ponemos al enemigo.<\/p>\n\n\n\n

\"OWASP_A09\"
OWASP_A09<\/figcaption><\/figure>\n\n\n\n

\u00bfQu\u00e9 aprendimos y c\u00f3mo podemos fortalecer nuestra web?<\/strong><\/h2>\n\n\n\n

Llegamos al final de nuestra traves\u00eda de hacking \u00e9tico con un sabor agridulce, pero muy educativo. Por un lado, tenemos una base s\u00f3lida: la conectividad est\u00e1 controlada, el firewall hace su trabajo de bloquear ataques autom\u00e1ticos y la criptograf\u00eda 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\u00f3n constante.<\/p>\n\n\n\n

Hoja de ruta<\/h3>\n\n\n\n

Para que este laboratorio de Pok\u00e9mon pase de ser “bueno” a “impenetrable”, aqu\u00ed tienes mi hoja de ruta recomendada:<\/p>\n\n\n\n

    \n
  1. Cirug\u00eda de Software (Actualizaci\u00f3n Inmediata):<\/strong> El riesgo n\u00famero uno es ese phpMyAdmin<\/a> antiguo. Mi recomendaci\u00f3n es eliminarlo si no se usa constantemente, o actualizarlo a la versi\u00f3n m\u00e1s reciente. No podemos permitirnos tener un CVE (vulnerabilidad conocida) de hace a\u00f1os abierto en nuestro servidor.<\/li>\n\n\n\n
  2. Limpieza de WordPress:<\/strong> Menos es m\u00e1s. Cada plugin<\/a> 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.<\/li>\n\n\n\n
  3. Ocultar la Identidad (Obscuridad):<\/strong> Debemos configurar el servidor para que sea m\u00e1s “t\u00edmido”. Esto implica desactivar las firmas del servidor que revelan versiones de software en los encabezados HTTP. Si el atacante no sabe qu\u00e9 versi\u00f3n de PHP<\/a> usas, no sabr\u00e1 qu\u00e9 ataque intentar.<\/li>\n\n\n\n
  4. Monitoreo de Integridad:<\/strong> Instalar herramientas que vigilen los archivos del sistema. Si de repente el archivo index.php<\/code> cambia su tama\u00f1o o su contenido sin que nosotros hayamos hecho nada, el sistema deber\u00eda enviarnos una alerta roja al m\u00f3vil de inmediato.<\/li>\n\n\n\n
  5. Reforzar el WAF:<\/strong> Aunque el firewall actual es bueno, se puede configurar para que sea a\u00fan m\u00e1s agresivo contra escaneos de vulnerabilidades espec\u00edficos, bloqueando por IP a cualquier origen que intente buscar archivos sensibles como \/etc\/passwd<\/code>.<\/li>\n<\/ol>\n\n\n\n

    En conclusi\u00f3n, la seguridad web es una carrera de fondo. El sitio pokemon.wuaze.com<\/a><\/code> tiene unos cimientos muy fuertes y defensas modernas admirables, pero como cualquier entrenador Pok\u00e9mon sabe, incluso el equipo m\u00e1s 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.<\/p>\n\n\n\n

    \n