Hay una diferencia importante entre una herramienta que se equivoca y una herramienta de seguridad que se equivoca. Si un ranking de criptomonedas falla, pierdes dinero. Si un detector de phishing falla, alguien mete su frase semilla en una web falsa porque un semáforo verde le dijo que podía.
Por eso la regla que he acabado escribiendo en el código, y que resume los seis arreglos, es esta:
Una herramienta que presenta un «no lo sé» como un «está bien» es peor que no tener herramienta.
Peor, porque la de verdad no existe y esta te da confianza.
Los seis
1. Fallaba en verde
CríticoCuando una fuente externa no respondía, el motor usaba valores por defecto optimistas: TLS correcto, hosting limpio, sin phishing. Si la base de datos de phishing no cargaba, un dominio creado ayer salía «Verde — Perímetro contenido», sin un solo aviso.
2. La letra que se comía los dominios
CríticoUna línea: host.lstrip("www."). En Python, lstrip no quita un prefijo — quita caracteres. Todo dominio que empezara por «w» perdía su primera letra antes de cotejarse contra la base de phishing.
3. Acusaba a los inocentes
AltoLa capa de contratos clasificaba como «drainer de nivel alto» a cualquier token legítimo, porque approve y transferFrom están en todos los ERC-20 que existen. Un token normal se llevaba 74 puntos de riesgo.
4. Una contraseña en el navegador
AltoUn usuario y una contraseña escritos a mano dentro de un componente de cliente. Viajaban al navegador de cada visitante y se leían con Ver código fuente. Ni siquiera bloqueaban nada: eran decorado.
5. Servía de sonda contra redes internas
AltoEl servicio aceptaba cualquier host y le abría conexiones. Alguien podía pedirle «localhost» o la dirección de metadatos del proveedor cloud y usarlo para mirar dentro de la red.
6. Una comprobación que nunca se disparaba
MedioLa «reputación de hosting» venía de un servicio de geolocalización consultado por HTTP sin cifrar, buscando palabras como «bulletproof» en el nombre del proveedor. Ningún proveedor se describe así: la señal no saltó jamás, pero aparecía en el informe como si fuera una comprobación real.
Lo que cambia en la práctica
| Situación | Antes | Ahora |
|---|---|---|
| La base de phishing no carga | Verde | Amarillo, y dice qué falta |
| Dominio wallet-falso.com en la lista negra | No lo encontraba | Lo encuentra |
| Un ERC-20 perfectamente legítimo | 74 puntos de riesgo | 0 puntos |
| Alguien pide analizar 169.254.169.254 | Se conectaba | Rechazado |
La tercera fila es la que más me importa. Un scanner que marca en rojo a USDC no es un scanner estricto: es uno que enseña a la gente a ignorar las alertas. Y el día que aparece la de verdad, ya nadie la mira.
Lo que sigue sin saber hacer
La conclusión técnica más incómoda de toda la auditoría: buscar funciones en el bytecode de un contrato no permite distinguir uno malicioso de uno legítimo. Los dos usan exactamente las mismas. Lo que cambia es la intención, y eso no está en los primeros cuatro bytes de nada.
Así que la herramienta lee el contrato, te dice qué contiene, y se calla el veredicto. Podría haberlo dejado como estaba y nadie se habría dado cuenta en meses. Pero entonces estaría vendiendo una certeza que no tengo, que es exactamente lo que critico de los demás.
Decir «no lo sé» tiene un coste comercial. Decir «está bien» sin saberlo tiene un coste que paga otro.
Wolf Security es una herramienta educativa de análisis de riesgo. No sustituye a una auditoría profesional ni garantiza que un dominio, correo o contrato sean seguros: un veredicto verde significa que las señales comprobadas no superaron el umbral, no que el activo sea inofensivo. Ninguno de los fallos descritos llegó a afectar a personas usuarias: se encontraron y corrigieron antes de la publicación de la herramienta.