Exploit Profanity en Wintermute

El 20 de septiembre de 2022, el creador de mercado con sede en Londres Wintermute fue drenado por aproximadamente $160 millones de una hot wallet DeFi cuya dirección había sido generada por Profanity, un popular generador de direcciones vanity de Ethereum que resultó usar una fuente de números aleatorios críticamente débil.

Qué ocurrió

La herramienta Profanity permitía a los usuarios generar direcciones Ethereum con prefijos o sufijos personalizados (0x0000…, 0xWINT…, etc.). Para hacerlo eficientemente, fuerza bruteaba claves privadas hasta que una producía una dirección con el patrón deseado.

El fallo fatal: Profanity inicializaba su CPRNG con un entero de 32 bits — un espacio de claves de solo ~4.000 millones de semillas posibles. Un atacante con recursos GPU modestos podía enumerar todo el espacio de semillas en días y reconstruir cada clave privada que Profanity hubiera producido. La vulnerabilidad había sido divulgada públicamente por 1inch aproximadamente una semana antes del incidente de Wintermute.

Wintermute vio la divulgación y actuó al respecto — retiraron todo el ETH de la hot wallet afectada. Lo que no hicieron fue eliminar el rol de administrador de esa dirección del contrato de bóveda DeFi. Cuando el atacante finalmente fuerza bruteó la clave privada generada por Profanity para esa billetera, usaron el rol admin aún activo para drenar $160M en tokens directamente de la bóveda.

Consecuencias

• Wintermute ofreció al atacante una recompensa white-hat del 10%, que fue rechazada; los fondos fueron enviados a Tornado Cash.
• El CEO Evgeny Gaevoy divulgó que la firma permanecía solvente con ~$320M en capital tras la pérdida.
• Profanity fue deprecado y se emitieron advertencias para cada dirección que se había generado con él — muchas de las cuales fueron drenadas posteriormente por operadores separados usando la misma técnica.

Por qué importa

Wintermute es el caso de libro de texto para la disciplina de limpieza post-incidente: saber que una clave puede estar comprometida no es suficiente; cada sistema, contrato y rol que esa clave alguna vez tocó debe ser revocado, no solo vaciado. La misma lección recurre en formas diferentes — una clave admin robada en un contrato actualizable (PlayDapp), un rol de firma sin rotar tras una brecha de proveedor — cada vez que la remediación de un incidente de seguridad queda a medias.