Más de 20 o 25 años hablando del phishing. Si nos paramos a pensarlo, quizá más años, ya que la ingeniería social y todo lo que ello engloba está en el ser humano desde que este ser es humano. Es decir, el engañar a alguien para conseguir un beneficio se ha hecho desde tiempos inmemoriales, desde que el ser humano, seguramente, estuviera en cavernas. No siempre con engaños graves, ¿Por qué no hacerte un halago con el fin de que seas más susceptible a una petición mía? El ser humano lo hizo y, seguramente, lo hará.
Pero hoy no hablaremos de la ingeniería social de la vida, seguiremos hablando de los riesgos en el mundo Web3, dónde ya hemos comentado algunos ataques como el Re-Entrancy Attack, un ejemplo de DoS aplicado al mundo SmartContract y un phishing a tx.origin del tipo de la clasificación que veremos hoy.
Figura 1: BlockChain & SmartContracts: Ataques de Ice Phishing
Pero hoy no hablaremos de la ingeniería social de la vida, seguiremos hablando de los riesgos en el mundo Web3, dónde ya hemos comentado algunos ataques como el Re-Entrancy Attack, un ejemplo de DoS aplicado al mundo SmartContract y un phishing a tx.origin del tipo de la clasificación que veremos hoy.
Hoy hablaremos del concepto de "Ice Phishing" y es que muchas veces pensamos que el phishing busca robarnos credenciales. Si hacemos un paralelismo con el mundo TI vemos que el phishing ha sido y es una de las amenazas más graves a las que se enfrentan las organizaciones, ya que un clic puede hacer caer la política de seguridad de la empresa y poner en ‘jaque’ un buen número de recursos. La sociedad está concienciada con el robo de credenciales, si les hablas de phishing entiende robo de credenciales, pero no siempre es así.
Hemos hablado en este blog sobre diferentes tipos de engaños que buscan que el usuario realice una acción y no se le piden credenciales, pero a efectos prácticos el riesgo para el usuario es el mismo. Un ejemplo son las técnicas de QRLJacking y cómo el uso de un Código QR puede conllevar acciones que uno no quiere realizar sobre su cuenta, por ejemplo, de Whatsapp.
Además, hemos hablado de los riesgos de OAuth cuando uno no tiene conocimiento sobre lo que puede ocurrir cuando se dan permisos a una app. En esta charla de 2016 en RootedCON se mostraba la herramienta de SAPPO. Estos dos ejemplos, son muy claros a la hora de entender que no siempre nos quieren robar las credenciales si no que existen otras técnicas para lograr un beneficio por parte del atacante. Esto debemos tenerlo claro y concienciarnos y concienciar a la sociedad.
Figura 3: Sólo hay que besar un Sappo
Figura 4: Libro dedicado a "Bitcoin: La tecnología Blockchain y su investigación" de Yaiza Rubio y Félix Brezo |
Microsoft ha publicado un reporte sobre los riesgos del mundo Web3 y hay conceptos como el Ice Phishing que quedan definidos y expuestos para el conocimiento de las personas que entran en el mundo Web3. Como cualquier otra tecnología, la Web3 va a tener un boom y ese boom es un incentivo para los delincuentes que tendrán como objetivo beneficiarse. En el reporte, Microsoft, habla de que la tecnología aún es incipiente, por lo que pueden surgir nuevos tipos de ataque. Existen diferentes tipos de phishing y que en algunos casos se heredan vulnerabilidades y debilidades del mundo Web2, aunque en otros casos son exclusivas del mundo Web3.
Uno de los aspectos más relevantes e importantes es entender la transparencia de la web3. En otras palabras, el poder observar y estudiar todo, ya que todo está en la blockchain, permite conocer y poder estudiar, para lo bueno y para lo malo. Es decir, un atacante puede ver cómo está construido un Smart Contract y poder aprovecharse si detecta algún bug, pero al contrario también ocurre. Se puede estudiar lo que ha pasado a posteriori, como si de un Incident Response se tratase, ya que se dispone de esa transparencia.
En el informe también se comenta que algunas de las técnicas de phishing clásicas son poco comunes en el mundo Web3, debido a la complejidad que puede suponer intentar robar una clave privada a través de un email, pero en lo que sí se pone ‘foco’ es en las técnicas Ice Phishing, que no suponen un robo de las claves privadas, sino que implica engañar al usuario para que firme una transacción en la que se delega la aprobación de los tokens del usuario al atacante. Este tipo de transacción es común en entornos con SmartContracts, ya que son éstos los que interactúan con los tokens de un usuario.
En la imagen se puede ver el esquema. Los Tokens ERC 20 disponen de unas funciones que permiten aprobar que un usuario delegue en un contrato el manejo de ciertas cantidades de tokens. Esto es algo normal, ya que en función de la aplicación que se esté dando a todo esto, puede que el contrato tenga que ‘pagar’ con tus tokens a otro usuario o a otro contrato. Esa delegación debe ser realizada de forma consciente por el usuario. En el esquema anterior, se puede ver lo siguiente:
Uno de los aspectos más relevantes e importantes es entender la transparencia de la web3. En otras palabras, el poder observar y estudiar todo, ya que todo está en la blockchain, permite conocer y poder estudiar, para lo bueno y para lo malo. Es decir, un atacante puede ver cómo está construido un Smart Contract y poder aprovecharse si detecta algún bug, pero al contrario también ocurre. Se puede estudiar lo que ha pasado a posteriori, como si de un Incident Response se tratase, ya que se dispone de esa transparencia.
En el informe también se comenta que algunas de las técnicas de phishing clásicas son poco comunes en el mundo Web3, debido a la complejidad que puede suponer intentar robar una clave privada a través de un email, pero en lo que sí se pone ‘foco’ es en las técnicas Ice Phishing, que no suponen un robo de las claves privadas, sino que implica engañar al usuario para que firme una transacción en la que se delega la aprobación de los tokens del usuario al atacante. Este tipo de transacción es común en entornos con SmartContracts, ya que son éstos los que interactúan con los tokens de un usuario.
Figura 5: Técnicas de Ice Phishing
En la imagen se puede ver el esquema. Los Tokens ERC 20 disponen de unas funciones que permiten aprobar que un usuario delegue en un contrato el manejo de ciertas cantidades de tokens. Esto es algo normal, ya que en función de la aplicación que se esté dando a todo esto, puede que el contrato tenga que ‘pagar’ con tus tokens a otro usuario o a otro contrato. Esa delegación debe ser realizada de forma consciente por el usuario. En el esquema anterior, se puede ver lo siguiente:
- El usuario 1 tiene 1 token USDC y 0 tokens LINK.
- El usuario 1 aprueba que el contrato de uniswap v3 puede ‘manejar’ 1 token de la cuenta del usuario 1.
- En este momento, uniswap v3 (contrato) puede transferir el token del usuario 1 sin aprobación a LINK, como se ve en la imagen.
Figura 6: Ejemplo de Ice Phishing con Metamask
En el ejemplo anterior, no sabemos si la dirección del spender es realmente la de uniswap o la de otro (un atacante). Una vez que la transacción es aprobada, firmada, enviada y, por supuesto, minada, el ‘spender’ puede acceder a los fondos. Si se llega a este paso y el atacante logra esto, seguramente vaciará la cuenta (o el número de tokens para los que obtuvo la aprobación). El ataque Badger DAO es un ejemplo de este tipo de ataques. El atacante consiguió millones de dólares entre noviembre y diciembre de 2021.
Microsoft y las recomendaciones que deja el informe
En el reporte Microsoft pone algunas recomendaciones para que podamos protegernos de este tipo de ataques:
- Revisión de los Smart Contracts con los que interactuamos. Es importante poder leerlos y revisarlos.
- La dirección del contrato que nos ponen como ‘Spender’, ¿Es correcta? Este paso es crítico. Al igual que en web2 miramos mucho si estamos conectados con el servidor legítimo y verificamos una serie de cosas, aquí deberíamos verificar también otras cuantas cosas. Por ejemplo, la dirección del contrato ‘spender’ al que daremos la aprobación.
- El Smart Contract en el que vamos a confiar ha sido previamente auditado. Esto es algo fundamental y es que cada vez más se requieren auditorías de Smart Contracts y demás componentes de la web3.
- ¿Es el Smart Contract actualizable? Una buena práctica en el desarrollo de Smart Contract es utilizar un ‘Proxy Pattern’ para conseguir que el Smart Contract o su lógica pueda ser acutalizada, sin tocar la parte de datos.
- Utilizar múltiples wallets y diversificar los ‘ahorros’ cómo podrías hacer en el mundo financiero clásico. Revisar periódicamente la configuración de los wallets y revocar la aprobación de utilización de nuestros tokens. Lo ideal sería aprobar el uso de nuestros tokens (en su justa medida) y por un corto período de tiempo, el tiempo que se necesite.
- Blockchain & SmartContracts: Una serie para aprender
- BlockChain & SmartContrats: Primer SmartContract con Solidity
- Blockchain & SmartContracts: Cómo probar y desplegar un SmartContract en Ethereum
- WWW, Web 1.0, Web 2.0, Web 3.0, Web3 y ¿Web 4.0?
- Metaverso, multiverso y las tierras digitales en que vivimos en forma de avatar
- Los Fan Tokens vs. las Criptomonedas y los NFTs: Level 101
- Tokenomics: Las criptomonedas y las "Proof-of-work": Level 101
- Los NFTs y el registro mundial de los dueños de activos digitales en el Metaverso
- BitCoin: Blockchain y su investigación
- BlockChain & SmartContrats: El Internet descentralizado y el almacenamiento off-chain en IPFS
- Reentrancy Attack: Cómo te roban criptomonedas por un bug en tu SmartContract
- BlockChain & SmartContract: Bugs que pueden dejar tu SmartContrat "fuera de juego"
- Blockchain & SmartContracts: Patrones y buenas prácticas de seguridad
- Blockchain & SmartContracts: Herramientas de Auditoría de Seguridad de SmartContracts
- BlockChain & SmartContracts: Ataque de phishing a tx.origin y robo de criptomonedas
- BlockChain & SmartContracts: Ataques de Ice Phishing
- Blockchain & SmartContracts: Herramientas de análisis dinámico
- ZIION: Una distribución Linux para auditar SmartContracts (& BlockChain)
- Dominios Web3 en Etherenum Name Service y la trazabilizad de las transacciones Blockchain
- BlockChain & SmartContracts: Actualizar SmartContracts como los grandes protocolos
- Jumping level up (from) web2 (to) web3: Vulnerabilities & SCAMs - SmartContracts
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica. Para consultas puedes usar el Buzón Público para contactar con Pablo González
Contactar con Pablo González |
No hay comentarios:
Publicar un comentario