Mi batalla contra un bot "sweeper": os cuento como recuperé 1000 $ de un shur
ForoCoches: Usuario
04-jun-2022 14:15
#1
|
Muy buenas shurs, me gustaría compartir con vosotros esta historia que terminó con final feliz y que tal vez os pueda servir de ayuda en caso de que os pase algo similar o simplemente para que conozcáis un poco más el funcionamiento de la blockchain. Para mí toda esta batalla contra el bot me ha servido para aprender un poco más sobre este mundillo con la doble satisfacción de poder ayudar a alguien a recuperar sus fondos. Problema Hace unos días el shur @Iberia, abrió el siguiente hilo: Hackeo de METAMASK + Bot borrador En el hilo expone el siguiente problema: Cada vez que envío algo de BNB a mi wallet aparece justo después una transacción firmada por mi propia wallet que envía ese BNB al monedero del bot.  Esto ocurre porque en algún momento la clave privada del shur se vio comprometida (phishing, robo de información, etc.) y el "hacker" lo único que tuvo que hacer es conectar un bot para que automáticamente limpiara los fondos. Este bot es conocido en la comunidad con el nombre de bot "sweeper" (barrendero) y su funcionamiento se basa en vigilar la lista de transacciones pendientes (mempool) para detectar un envío de BNB hacia la wallet comprometida. Cuando lo detecta, envía en el menor tiempo posible una transacción de retiro de fondos para que al titular de la wallet no le dé tiempo a realizar ninguna acción. Sin BNB no es posible operar con la wallet porque no podemos pagar el gas, por lo que la cuenta queda inutilizada. El problema es que al quedar la wallet inutilizada el shur no podía sacar unos fondos que tenía en Staking desde hace meses y que ya se habían desbloqueado, estos fondos ascendían a algo más de 1000 $. Toma de contacto Tras leer su hilo y mas o menos entender la naturaleza del problema me pongo en contacto con él para ayudarle. Una vez me da la dirección de su Wallet puedo ver que efectivamente el problema ocurre tal cual lo cuenta:  En azul: La wallet limpia desde la que envía BNB para poder operar la wallet comprometida. En amarillo: Es la wallet comprometida desde donde se realizan operaciones sin su consentimiento. En rojo: La wallet del hacker, una de ellas, en realidad tenía bastantes más. En un primer momento, cuando veo esto, pienso que la solución es muy fácil porque en la imagen se puede apreciar que el envío de BNB y el robo ocurre en 2 bloques distintos (18318520 y 18318522) pensando erróneamente que el bot no estaba mirando la mempool y que podría colocar mi transacción en el mismo bloque que la del envío del BNB. Intento de solución 1  Monto una estrategia muy sencilla que es hacer un script que mire la mempool detecte el envío de BNB a la wallet comprometida y automáticamente lance una transacción de test para ver si mi transacción cae por delante de la del bot y puedo empezar a operar la wallet del shur. Pero... cuando voy a enviar la transacción ocurre esto: Código:
"error":{"code":-32000,"message":"insufficient funds for gas * price + value"}
¿tiene la wallet fondos suficientes como para pagar el coste de la transacción y el valor BNB que envías? La respuesta es que no, porque la transacción de envío de BNB aún está pendiente, por lo que la mía la descarta y ni siquiera entra a la mempool. Intento de solución 2  Como no sé cuando es el momento exacto para poder enviar la transacción y el bot sí, intento hacer frontrun al bot para invalidar su transacción con algo más de gas. Esto es muy sencillo de hacer, me pongo a mirar en la mempol una transacción que salga de la wallet comprometida, veo que nonce (el nonce es un índice que usan los nodos para saber cuál es la última transacción enviada) tiene, envío la mía con un poquito más de gas y el mismo nonce. Tras varios intentos puedo ver que en TODAS las ejecuciones la transacción minada siempre es la del bot y no la mía. Para ver porque narices no estaba entrando mi transacción primero decido "depurar" la mempool y ver que está ocurriendo cuando el bot envía su transacción. Me encuentro lo siguiente: Código:
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 642,
data: '0x',
}
{
from: '0x98442BDA3A28...'
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 638,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 641,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
value: BigNumber { _hex: '0x026dc545c64176', _isBigNumber: true },
nonce: 639,
}
.
.
.otras 30 más
 sí, como lo veis, no envía una sola transacción envía más de 30 transacciones pendientes con distintos precios de gas, distintos nonces... Todo esto lo hace para despistar porque realmente la única transacción que va a entrar ahí es la que tiene el nonce correcto.En el ejemplo que os he puesto, en ese momento, la transacción correcta y la que entró fue la cuarta, la que tenía nonce 639. Tuve que modificar mi script para que no pillara la primera transacción que salía de la wallet hackeada. Tenía que tener en cuenta también el nonce correcto. Volví a probar y empecé a ver en los logs que seguía teniendo problemas con el gas. Guerra de gas A partir de este punto me doy cuenta de que tal vez el problema es que no estoy seleccionando correctamente el gas. Básicamente tenemos dos variables con las que podemos enviar una transacción:
Por lo tanto, la transacción con el menor "fee" que puedes hacer dentro de la Binance Smart Chain es 5*0.000000001BNB x 21000 = 0,000105 BNB Si, ¿adivináis quien estaba haciendo estas transacciones con un coste tan reducido? El bot:  Tiene lógica este comportamiento, gasta el menor gas posible para pagar menos "fees" y robar más cantidad de BNB para su cuenta. Esto además, ofrece una doble ventaja al bot, ya que para un usuario que quiera colocar una transacción por delante de él, siempre competirá en desventaja porque cualquier transacción que no sea envío de BNB cuesta más gas utilizado. La transacción que estaba probando yo, era aprobar un token cualquiera (el típico aprobado que hacéis en Metamask cuando queréis vender un token). El coste de gas mínimo que necesita tu transacción se puede estimar con la función "estimateGas", en concreto, aprobar la venta de un token me costaba un mínimo de 41000 de gas aproximadamente. En resumen, si el bot quería, reduciendo sus beneficios siempre podría colocar su transacción por delante de la mía porque la mía es más cara y él podría pagar siempre más "fees" que yo. Aquí pensé que era jaque mate. Intento de solución 3: adelantar mi transacción al bot A pesar de mi reflexión anterior, no me doy por vencido e intento colocar mi transacción antes que la del bot. En ese momento había descubierto como hacerlo con la función estimateGas. Cuando estimas gas y el nodo no puede estimarlo porque en la wallet no hay BNB da un error. Sin embargo, cuando ya puede estimarlo significa que ya hay BNB en su cuenta y eso me sirve como "marcador" para poder enviar mi transacción en primer lugar a la mempool.  Tras montar esta estrategia recibo todo el rato el siguiente error: Código:
"error":{"code":-32000,"message":"Replacement transaction underpriced"}
Solución 4: definitiva Con todos los intentos que estuve haciendo pude darme cuenta de que el bot modificaba su comportamiento en función de si yo enviaba una transacción a la misma vez que él o no. Si detectaba que en la transacción actual o en transacciones previas había habido competidores, el bot subía el precio del gas de su transacción para vencer a la mía. Sin embargo, si yo lo único que hacía era enviar pequeñas cantidades de BNB a la wallet hackeada y no competía con el bot, este se relajaba y empezaba a bajar su precio del gas. Este comportamiento es inteligente, porque en todo momento lo que busca el bot es maximizar los beneficios y no que se lo coman las comisiones. Los desarrolladores del bot se han movido en una dicotomía: ¿pago más por la transacción para estar seguro de que el que roba el BNB soy yo?, o ¿pago menos por la transacción para robar más BNB arriesgándome a que me coloquen una transacción por delante? Así es como di con la solución, explotando esa dicotomía. Además de aprovecharme de su comportamiento introduje otra variación que hizo que el bot se liara un poco más sobre que precio de gas poner a su transacción. Monté la siguiente estrategia:  1. Vuelvo al esquema donde mi transacción va a ir justo por detrás de la suya (para intentar colocarle una transacción con más gas y que sea la suya la descartada por el nodo) 2. Previamente a mi prueba, envío dos o tres transacciones con muy poco BNB sin competir con su transacción para que reduzca su agresividad. 3. Envío 3 o 4 transacciones con BNB a la vez para causar confusión al bot. 4. Detecto la primera transacción del bot que salga de la wallet hackeada con el nonce correcto y le meto la mía con +1 de gas. ¿Resultado? Tras varias horas de intentos y pagar más de 30 $ en total en pruebas desde mi wallet... Consigo colocar mi transacción de prueba por delante de la suya!. Engaño al bot, cuando envía esa transacción con el nonce correcto se piensa que es la única que va a haber y que no hay nadie compitiendo, además la envía con menos gas del que debería porque han entrado 3 transacciones a la vez con BNB y hay más BNB para llevarse por lo que debería de pagar más gas. Los siguientes pasos ya son más sencillos, realizo dos transacciones: - Una hace el withdraw de los tokens invocando el contrato donde tiene el shur los 1000 $. - Tras llegar los tokens a su wallet comprometida, hago seguido otra transacción para enviarlos a su wallet limpia.  En verde son las transacciones que coloco por delante del bot y la cantidad de tokens que entran y salen de la wallet hackeada. En azul, es la dirección del contrato donde estaban en staking los tokens, en naranja es la wallet hackeada y en morado es la cuenta del shur limpia. Había otras posibles formas de vencer al bot según se describe en la comunidad: 1. Crear un contrato y llamar a la función selfDestruct con la dirección de la wallet comprometida, esto genera una transacción interna con el BNB del contrato y no puede ser detectada en la mempool por el bot. (Esta solución no me gustaba del todo porque el bot vigilaba la wallet del shur llamando a la función balanceOf cada poco tiempo, aparte de vigilar la mempool) 2. Pagar a un minero el gas por otra vía y dejar que el minero ejecute tu transacción sin pagar gas por ella, esta creo que hubiera sido la solución más eficaz. Y por último me gustaría agradecer al shur @Iberia por haber confiado en mí sin conocerme de nada y por haberme devuelto 200 $ como agradecimiento por todo este trabajo. Siempre he pensado que en forocoches hay más gente dispuesta a ayudar que a estafar y de momento creo que no me equivoco. Gracias por leerme y espero que hayáis disfrutado con la historia. Dejo este tweet como recordatorio: |
ForoCoches: Miembro
04-jun-2022 14:24
#2
|
Impresionante, cinco estrellas y además de las de verdad. Ya tenía entendido que la mempool es zona de guerra. |
Asociado en sociedad
04-jun-2022 14:28
#3
|
Muy buenas shurs, me gustaría compartir con vosotros esta historia que terminó con final feliz y que tal vez os pueda servir de ayuda en caso de que os pase algo similar o simplemente para que conozcáis un poco más el funcionamiento de la blockchain.
Para mí toda esta batalla contra el bot me ha servido para aprender un poco más sobre este mundillo con la doble satisfacción de poder ayudar a alguien a recuperar sus fondos. Problema Hace unos días el shur @Iberia, abrió el siguiente hilo: Hackeo de METAMASK + Bot borrador En el hilo expone el siguiente problema: Cada vez que envío algo de BNB a mi wallet aparece justo después una transacción firmada por mi propia wallet que envía ese BNB al monedero del bot. Esto ocurre porque en algún momento la clave privada del shur se vio comprometida (phishing, robo de información, etc.) y el "hacker" lo único que tuvo que hacer es conectar un bot para que automáticamente limpiara los fondos. Este bot es conocido en la comunidad con el nombre de bot "sweeper" (barrendero) y su funcionamiento se basa en vigilar la lista de transacciones pendientes (mempool) para detectar un envío de BNB hacia la wallet comprometida. Cuando lo detecta, envía en el menor tiempo posible una transacción de retiro de fondos para que al titular de la wallet no le dé tiempo a realizar ninguna acción. Sin BNB no es posible operar con la wallet porque no podemos pagar el gas, por lo que la cuenta queda inutilizada. El problema es que al quedar la wallet inutilizada el shur no podía sacar unos fondos que tenía en Staking desde hace meses y que ya se habían desbloqueado, estos fondos ascendían a algo más de 1000 $. Toma de contacto Tras leer su hilo y mas o menos entender la naturaleza del problema me pongo en contacto con él para ayudarle. Una vez me da la dirección de su Wallet puedo ver que efectivamente el problema ocurre tal cual lo cuenta: En azul: La wallet limpia desde la que envía BNB para poder operar la wallet comprometida. En amarillo: Es la wallet comprometida desde donde se realizan operaciones sin su consentimiento. En rojo: La wallet del hacker, una de ellas, en realidad tenía bastantes más. En un primer momento, cuando veo esto, pienso que la solución es muy fácil porque en la imagen se puede apreciar que el envío de BNB y el robo ocurre en 2 bloques distintos (18318520 y 18318522) pensando erróneamente que el bot no estaba mirando la mempool y que podría colocar mi transacción en el mismo bloque que la del envío del BNB. Intento de solución 1 Monto una estrategia muy sencilla que es hacer un script que mire la mempool detecte el envío de BNB a la wallet comprometida y automáticamente lance una transacción de test para ver si mi transacción cae por delante de la del bot y puedo empezar a operar la wallet del shur. Pero... cuando voy a enviar la transacción ocurre esto: Código:
"error":{"code":-32000,"message":"insufficient funds for gas * price + value"}
¿tiene la wallet fondos suficientes como para pagar el coste de la transacción y el valor BNB que envías? La respuesta es que no, porque la transacción de envío de BNB aún está pendiente, por lo que la mía la descarta y ni siquiera entra a la mempool. Intento de solución 2 Como no sé cuando es el momento exacto para poder enviar la transacción y el bot sí, intento hacer frontrun al bot para invalidar su transacción con algo más de gas. Esto es muy sencillo de hacer, me pongo a mirar en la mempol una transacción que salga de la wallet comprometida, veo que nonce (el nonce es un índice que usan los nodos para saber cuál es la última transacción enviada) tiene, envío la mía con un poquito más de gas y el mismo nonce. Tras varios intentos puedo ver que en TODAS las ejecuciones la transacción minada siempre es la del bot y no la mía. Para ver porque narices no estaba entrando mi transacción primero decido "depurar" la mempool y ver que está ocurriendo cuando el bot envía su transacción. Me encuentro lo siguiente: Código:
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 642,
data: '0x',
}
{
from: '0x98442BDA3A28...'
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 638,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 641,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
value: BigNumber { _hex: '0x026dc545c64176', _isBigNumber: true },
nonce: 639,
}
.
.
.otras 30 más
sí, como lo veis, no envía una sola transacción envía más de 30 transacciones pendientes con distintos precios de gas, distintos nonces... Todo esto lo hace para despistar porque realmente la única transacción que va a entrar ahí es la que tiene el nonce correcto.En el ejemplo que os he puesto, en ese momento, la transacción correcta y la que entró fue la cuarta, la que tenía nonce 639. Tuve que modificar mi script para que no pillara la primera transacción que salía de la wallet hackeada. Tenía que tener en cuenta también el nonce correcto. Volví a probar y empecé a ver en los logs que seguía teniendo problemas con el gas. Guerra de gas A partir de este punto me doy cuenta de que tal vez el problema es que no estoy seleccionando correctamente el gas. Básicamente tenemos dos variables con las que podemos enviar una transacción:
Por lo tanto, la transacción con el menor "fee" que puedes hacer dentro de la Binance Smart Chain es 5*0.000000001BNB x 21000 = 0,000105 BNB Si, ¿adivináis quien estaba haciendo estas transacciones con un coste tan reducido? El bot: Tiene lógica este comportamiento, gasta el menor gas posible para pagar menos "fees" y robar más cantidad de BNB para su cuenta. Esto además, ofrece una doble ventaja al bot, ya que para un usuario que quiera colocar una transacción por delante de él, siempre competirá en desventaja porque cualquier transacción que no sea envío de BNB cuesta más gas utilizado. La transacción que estaba probando yo, era aprobar un token cualquiera (el típico aprobado que hacéis en Metamask cuando queréis vender un token). El coste de gas mínimo que necesita tu transacción se puede estimar con la función "estimateGas", en concreto, aprobar la venta de un token me costaba un mínimo de 41000 de gas aproximadamente. En resumen, si el bot quería, reduciendo sus beneficios siempre podría colocar su transacción por delante de la mía porque la mía es más cara y él podría pagar siempre más "fees" que yo. Aquí pensé que era jaque mate. Intento de solución 3: adelantar mi transacción al bot A pesar de mi reflexión anterior, no me doy por vencido e intento colocar mi transacción antes que la del bot. En ese momento había descubierto como hacerlo con la función estimateGas. Cuando estimas gas y el nodo no puede estimarlo porque en la wallet no hay BNB da un error. Sin embargo, cuando ya puede estimarlo significa que ya hay BNB en su cuenta y eso me sirve como "marcador" para poder enviar mi transacción en primer lugar a la mempool. Tras montar esta estrategia recibo todo el rato el siguiente error: Código:
"error":{"code":-32000,"message":"Replacement transaction underpriced"}
Solución 4: definitiva Con todos los intentos que estuve haciendo pude darme cuenta de que el bot modificaba su comportamiento en función de si yo enviaba una transacción a la misma vez que él o no. Si detectaba que en la transacción actual o en transacciones previas había habido competidores, el bot subía el precio del gas de su transacción para vencer a la mía. Sin embargo, si yo lo único que hacía era enviar pequeñas cantidades de BNB a la wallet hackeada y no competía con el bot, este se relajaba y empezaba a bajar su precio del gas. Este comportamiento es inteligente, porque en todo momento lo que busca el bot es maximizar los beneficios y no que se lo coman las comisiones. Los desarrolladores del bot se han movido en una dicotomía: ¿pago más por la transacción para estar seguro de que el que roba el BNB soy yo?, o ¿pago menos por la transacción para robar más BNB arriesgándome a que me coloquen una transacción por delante? Así es como di con la solución, explotando esa dicotomía. Además de aprovecharme de su comportamiento introduje otra variación que hizo que el bot se liara un poco más sobre que precio de gas poner a su transacción. Monté la siguiente estrategia: 1. Vuelvo al esquema donde mi transacción va a ir justo por detrás de la suya (para intentar colocarle una transacción con más gas y que sea la suya la descartada por el nodo) 2. Previamente a mi prueba, envío dos o tres transacciones con muy poco BNB sin competir con su transacción para que reduzca su agresividad. 3. Envío 3 o 4 transacciones con BNB a la vez para causar confusión al bot. 4. Detecto la primera transacción del bot que salga de la wallet hackeada con el nonce correcto y le meto la mía con +1 de gas. ¿Resultado? Tras varias horas de intentos y pagar más de 30 $ en total en pruebas desde mi wallet... Consigo colocar mi transacción de prueba por delante de la suya!. Engaño al bot, cuando envía esa transacción con el nonce correcto se piensa que es la única que va a haber y que no hay nadie compitiendo, además la envía con menos gas del que debería porque han entrado 3 transacciones a la vez con BNB y hay más BNB para llevarse por lo que debería de pagar más gas. Los siguientes pasos ya son más sencillos, realizo dos transacciones: - Una hace el withdraw de los tokens invocando el contrato donde tiene el shur los 1000 $. - Tras llegar los tokens a su wallet comprometida, hago seguido otra transacción para enviarlos a su wallet limpia. En verde son las transacciones que coloco por delante del bot y la cantidad de tokens que entran y salen de la wallet hackeada. En azul, es la dirección del contrato donde estaban en staking los tokens, en naranja es la wallet hackeada y en morado es la cuenta del shur limpia. Había otras posibles formas de vencer al bot según se describe en la comunidad: 1. Crear un contrato y llamar a la función selfDestruct con la dirección de la wallet comprometida, esto genera una transacción interna con el BNB del contrato y no puede ser detectada en la mempool por el bot. (Esta solución no me gustaba del todo porque el bot vigilaba la wallet del shur llamando a la función balanceOf cada poco tiempo, aparte de vigilar la mempool) 2. Pagar a un minero el gas por otra vía y dejar que el minero ejecute tu transacción sin pagar gas por ella, esta creo que hubiera sido la solución más eficaz. Y por último me gustaría agradecer al shur @Iberia por haber confiado en mí sin conocerme de nada y por haberme devuelto 200 $ como agradecimiento por todo este trabajo. Siempre he pensado que en forocoches hay más gente dispuesta a ayudar que a estafar y de momento creo que no me equivoco. Gracias por leerme y espero que hayáis disfrutado con la historia. Dejo este tweet como recordatorio: |
ForoCoches: Usuario
04-jun-2022 14:32
#4
|
Joder se ve que manejas bastante, yo no me he enterado de una mierda, pero me alegro de que pudieses recuperar el dinero del shur! 5 estrellas |
ForoCoches: Miembro
04-jun-2022 14:37
#6
| ENHORABUENA! Me he leído en detalle lo que expones y eres un máquina. Da gusto leer esta información tan interesante en medio de tantos posts de shitcoins, referidos y spam! Un hacker “hackeado”. Ironías del destino. |
ForoCoches: Usuario
04-jun-2022 14:48
#10
| 10/10 me ha encantado el hilo. Una pregunta, como miras la meempol? Tienes tu propio nodo o hay alguna forma de mirarla sin tener un nodo? |
Buena persona
04-jun-2022 14:57
#11
|
Me hubiese gustado hacer la pole, por qué este tío es un genio que me ha ayudado con un quebradero de cabeza, pero bueno, ahora estoy en el móvil pero cuando esté en el pc haré un poco el relato de lo que esté shur hizo. En serio, las buenas personas existen y este shur es una de ellas, me quitaron 15 mil pavos que fueron 50 mil en mi wallet, y lo poco que me quedaba era eso en staking para volver a empezar. Estuvimos desde las 00;00 o así hasta las dos y no hubo manera, enviando bnbs para testear, me fui a sobar y cuando me despierto este cabroncete se tiro hasta las seis de la mañana y lo consiguió y no solo lo consiguió, si no que me lo envió íntegramente a mi cuenta.  https://imgur.com/a/uMmPeyS |
Editado: 04-jun-2022 15:05 -
ForoCoches: Usuario
04-jun-2022 15:48
#17
| Lectura entretenida, y buen curro, apostaría a que se te pasaron las horas volando mientras peleabas contra ese bot. |
ForoCoches: Miembro
04-jun-2022 16:22
#18
| Grande, entiendo vagamente la estrategia pero ole tu!! Gracias por aportar tu granito de arena shur |
ForoCoches: Miembro
04-jun-2022 16:55
#21
|
Por esto forocoches es GRANDE!!! Gran historia! Gracias por compartirla! |
ForoCoches: Miembro
04-jun-2022 16:55
#22
|
Muy buenas shurs, me gustaría compartir con vosotros esta historia que terminó con final feliz y que tal vez os pueda servir de ayuda en caso de que os pase algo similar o simplemente para que conozcáis un poco más el funcionamiento de la blockchain.
Para mí toda esta batalla contra el bot me ha servido para aprender un poco más sobre este mundillo con la doble satisfacción de poder ayudar a alguien a recuperar sus fondos. Problema Hace unos días el shur @Iberia, abrió el siguiente hilo: Hackeo de METAMASK + Bot borrador En el hilo expone el siguiente problema: Cada vez que envío algo de BNB a mi wallet aparece justo después una transacción firmada por mi propia wallet que envía ese BNB al monedero del bot. Esto ocurre porque en algún momento la clave privada del shur se vio comprometida (phishing, robo de información, etc.) y el "hacker" lo único que tuvo que hacer es conectar un bot para que automáticamente limpiara los fondos. Este bot es conocido en la comunidad con el nombre de bot "sweeper" (barrendero) y su funcionamiento se basa en vigilar la lista de transacciones pendientes (mempool) para detectar un envío de BNB hacia la wallet comprometida. Cuando lo detecta, envía en el menor tiempo posible una transacción de retiro de fondos para que al titular de la wallet no le dé tiempo a realizar ninguna acción. Sin BNB no es posible operar con la wallet porque no podemos pagar el gas, por lo que la cuenta queda inutilizada. El problema es que al quedar la wallet inutilizada el shur no podía sacar unos fondos que tenía en Staking desde hace meses y que ya se habían desbloqueado, estos fondos ascendían a algo más de 1000 $. Toma de contacto Tras leer su hilo y mas o menos entender la naturaleza del problema me pongo en contacto con él para ayudarle. Una vez me da la dirección de su Wallet puedo ver que efectivamente el problema ocurre tal cual lo cuenta: En azul: La wallet limpia desde la que envía BNB para poder operar la wallet comprometida. En amarillo: Es la wallet comprometida desde donde se realizan operaciones sin su consentimiento. En rojo: La wallet del hacker, una de ellas, en realidad tenía bastantes más. En un primer momento, cuando veo esto, pienso que la solución es muy fácil porque en la imagen se puede apreciar que el envío de BNB y el robo ocurre en 2 bloques distintos (18318520 y 18318522) pensando erróneamente que el bot no estaba mirando la mempool y que podría colocar mi transacción en el mismo bloque que la del envío del BNB. Intento de solución 1 Monto una estrategia muy sencilla que es hacer un script que mire la mempool detecte el envío de BNB a la wallet comprometida y automáticamente lance una transacción de test para ver si mi transacción cae por delante de la del bot y puedo empezar a operar la wallet del shur. Pero... cuando voy a enviar la transacción ocurre esto: Código:
"error":{"code":-32000,"message":"insufficient funds for gas * price + value"}
¿tiene la wallet fondos suficientes como para pagar el coste de la transacción y el valor BNB que envías? La respuesta es que no, porque la transacción de envío de BNB aún está pendiente, por lo que la mía la descarta y ni siquiera entra a la mempool. Intento de solución 2 Como no sé cuando es el momento exacto para poder enviar la transacción y el bot sí, intento hacer frontrun al bot para invalidar su transacción con algo más de gas. Esto es muy sencillo de hacer, me pongo a mirar en la mempol una transacción que salga de la wallet comprometida, veo que nonce (el nonce es un índice que usan los nodos para saber cuál es la última transacción enviada) tiene, envío la mía con un poquito más de gas y el mismo nonce. Tras varios intentos puedo ver que en TODAS las ejecuciones la transacción minada siempre es la del bot y no la mía. Para ver porque narices no estaba entrando mi transacción primero decido "depurar" la mempool y ver que está ocurriendo cuando el bot envía su transacción. Me encuentro lo siguiente: Código:
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 642,
data: '0x',
}
{
from: '0x98442BDA3A28...'
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 638,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 641,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
value: BigNumber { _hex: '0x026dc545c64176', _isBigNumber: true },
nonce: 639,
}
.
.
.otras 30 más
sí, como lo veis, no envía una sola transacción envía más de 30 transacciones pendientes con distintos precios de gas, distintos nonces... Todo esto lo hace para despistar porque realmente la única transacción que va a entrar ahí es la que tiene el nonce correcto.En el ejemplo que os he puesto, en ese momento, la transacción correcta y la que entró fue la cuarta, la que tenía nonce 639. Tuve que modificar mi script para que no pillara la primera transacción que salía de la wallet hackeada. Tenía que tener en cuenta también el nonce correcto. Volví a probar y empecé a ver en los logs que seguía teniendo problemas con el gas. Guerra de gas A partir de este punto me doy cuenta de que tal vez el problema es que no estoy seleccionando correctamente el gas. Básicamente tenemos dos variables con las que podemos enviar una transacción:
Por lo tanto, la transacción con el menor "fee" que puedes hacer dentro de la Binance Smart Chain es 5*0.000000001BNB x 21000 = 0,000105 BNB Si, ¿adivináis quien estaba haciendo estas transacciones con un coste tan reducido? El bot: Tiene lógica este comportamiento, gasta el menor gas posible para pagar menos "fees" y robar más cantidad de BNB para su cuenta. Esto además, ofrece una doble ventaja al bot, ya que para un usuario que quiera colocar una transacción por delante de él, siempre competirá en desventaja porque cualquier transacción que no sea envío de BNB cuesta más gas utilizado. La transacción que estaba probando yo, era aprobar un token cualquiera (el típico aprobado que hacéis en Metamask cuando queréis vender un token). El coste de gas mínimo que necesita tu transacción se puede estimar con la función "estimateGas", en concreto, aprobar la venta de un token me costaba un mínimo de 41000 de gas aproximadamente. En resumen, si el bot quería, reduciendo sus beneficios siempre podría colocar su transacción por delante de la mía porque la mía es más cara y él podría pagar siempre más "fees" que yo. Aquí pensé que era jaque mate. Intento de solución 3: adelantar mi transacción al bot A pesar de mi reflexión anterior, no me doy por vencido e intento colocar mi transacción antes que la del bot. En ese momento había descubierto como hacerlo con la función estimateGas. Cuando estimas gas y el nodo no puede estimarlo porque en la wallet no hay BNB da un error. Sin embargo, cuando ya puede estimarlo significa que ya hay BNB en su cuenta y eso me sirve como "marcador" para poder enviar mi transacción en primer lugar a la mempool. Tras montar esta estrategia recibo todo el rato el siguiente error: Código:
"error":{"code":-32000,"message":"Replacement transaction underpriced"}
Solución 4: definitiva Con todos los intentos que estuve haciendo pude darme cuenta de que el bot modificaba su comportamiento en función de si yo enviaba una transacción a la misma vez que él o no. Si detectaba que en la transacción actual o en transacciones previas había habido competidores, el bot subía el precio del gas de su transacción para vencer a la mía. Sin embargo, si yo lo único que hacía era enviar pequeñas cantidades de BNB a la wallet hackeada y no competía con el bot, este se relajaba y empezaba a bajar su precio del gas. Este comportamiento es inteligente, porque en todo momento lo que busca el bot es maximizar los beneficios y no que se lo coman las comisiones. Los desarrolladores del bot se han movido en una dicotomía: ¿pago más por la transacción para estar seguro de que el que roba el BNB soy yo?, o ¿pago menos por la transacción para robar más BNB arriesgándome a que me coloquen una transacción por delante? Así es como di con la solución, explotando esa dicotomía. Además de aprovecharme de su comportamiento introduje otra variación que hizo que el bot se liara un poco más sobre que precio de gas poner a su transacción. Monté la siguiente estrategia: 1. Vuelvo al esquema donde mi transacción va a ir justo por detrás de la suya (para intentar colocarle una transacción con más gas y que sea la suya la descartada por el nodo) 2. Previamente a mi prueba, envío dos o tres transacciones con muy poco BNB sin competir con su transacción para que reduzca su agresividad. 3. Envío 3 o 4 transacciones con BNB a la vez para causar confusión al bot. 4. Detecto la primera transacción del bot que salga de la wallet hackeada con el nonce correcto y le meto la mía con +1 de gas. ¿Resultado? Tras varias horas de intentos y pagar más de 30 $ en total en pruebas desde mi wallet... Consigo colocar mi transacción de prueba por delante de la suya!. Engaño al bot, cuando envía esa transacción con el nonce correcto se piensa que es la única que va a haber y que no hay nadie compitiendo, además la envía con menos gas del que debería porque han entrado 3 transacciones a la vez con BNB y hay más BNB para llevarse por lo que debería de pagar más gas. Los siguientes pasos ya son más sencillos, realizo dos transacciones: - Una hace el withdraw de los tokens invocando el contrato donde tiene el shur los 1000 $. - Tras llegar los tokens a su wallet comprometida, hago seguido otra transacción para enviarlos a su wallet limpia. En verde son las transacciones que coloco por delante del bot y la cantidad de tokens que entran y salen de la wallet hackeada. En azul, es la dirección del contrato donde estaban en staking los tokens, en naranja es la wallet hackeada y en morado es la cuenta del shur limpia. Había otras posibles formas de vencer al bot según se describe en la comunidad: 1. Crear un contrato y llamar a la función selfDestruct con la dirección de la wallet comprometida, esto genera una transacción interna con el BNB del contrato y no puede ser detectada en la mempool por el bot. (Esta solución no me gustaba del todo porque el bot vigilaba la wallet del shur llamando a la función balanceOf cada poco tiempo, aparte de vigilar la mempool) 2. Pagar a un minero el gas por otra vía y dejar que el minero ejecute tu transacción sin pagar gas por ella, esta creo que hubiera sido la solución más eficaz. Y por último me gustaría agradecer al shur @Iberia por haber confiado en mí sin conocerme de nada y por haberme devuelto 200 $ como agradecimiento por todo este trabajo. Siempre he pensado que en forocoches hay más gente dispuesta a ayudar que a estafar y de momento creo que no me equivoco. Gracias por leerme y espero que hayáis disfrutado con la historia. Dejo este tweet como recordatorio: Enhorabuena shur, lo tuyo sí que se merece reconocimiento, no solo por conseguirlo, sino por ser una persona decente, con valores e implicada. Tienes mis dieses.  Además que yo he tenido trato con Iberia en el pasado, y era un buen tipo, no sabía que le había pasado tremenda putada, me alegro por él que haya recuperado algo |
ForoCoches: Usuario
04-jun-2022 17:26
#26
|
Te doy un 10 en el hilo. Y bueno como friki informatico tambien me ha surgido una potencial idea de lo que has construido. Crees que por ejemplo aplicando una lista blanca de direcciones aceptadas y no, se podria utilizar tu script como una medida de seguridad para evitar que se limpien carteras? Algo en plan detectar cuando has sido hackeado asi con tu frase semilla y el script sea capaz de adelantarse a la transaccion maliciosa y volcar tus fondos en una cartera limpia. Ojo que podrias tener tiron por ahi… |
ForoCoches: Miembro
04-jun-2022 18:25
#28
|
Muy buenas shurs, me gustaría compartir con vosotros esta historia que terminó con final feliz y que tal vez os pueda servir de ayuda en caso de que os pase algo similar o simplemente para que conozcáis un poco más el funcionamiento de la blockchain.
Para mí toda esta batalla contra el bot me ha servido para aprender un poco más sobre este mundillo con la doble satisfacción de poder ayudar a alguien a recuperar sus fondos. Problema Hace unos días el shur @Iberia, abrió el siguiente hilo: Hackeo de METAMASK + Bot borrador En el hilo expone el siguiente problema: Cada vez que envío algo de BNB a mi wallet aparece justo después una transacción firmada por mi propia wallet que envía ese BNB al monedero del bot. Esto ocurre porque en algún momento la clave privada del shur se vio comprometida (phishing, robo de información, etc.) y el "hacker" lo único que tuvo que hacer es conectar un bot para que automáticamente limpiara los fondos. Este bot es conocido en la comunidad con el nombre de bot "sweeper" (barrendero) y su funcionamiento se basa en vigilar la lista de transacciones pendientes (mempool) para detectar un envío de BNB hacia la wallet comprometida. Cuando lo detecta, envía en el menor tiempo posible una transacción de retiro de fondos para que al titular de la wallet no le dé tiempo a realizar ninguna acción. Sin BNB no es posible operar con la wallet porque no podemos pagar el gas, por lo que la cuenta queda inutilizada. El problema es que al quedar la wallet inutilizada el shur no podía sacar unos fondos que tenía en Staking desde hace meses y que ya se habían desbloqueado, estos fondos ascendían a algo más de 1000 $. Toma de contacto Tras leer su hilo y mas o menos entender la naturaleza del problema me pongo en contacto con él para ayudarle. Una vez me da la dirección de su Wallet puedo ver que efectivamente el problema ocurre tal cual lo cuenta: En azul: La wallet limpia desde la que envía BNB para poder operar la wallet comprometida. En amarillo: Es la wallet comprometida desde donde se realizan operaciones sin su consentimiento. En rojo: La wallet del hacker, una de ellas, en realidad tenía bastantes más. En un primer momento, cuando veo esto, pienso que la solución es muy fácil porque en la imagen se puede apreciar que el envío de BNB y el robo ocurre en 2 bloques distintos (18318520 y 18318522) pensando erróneamente que el bot no estaba mirando la mempool y que podría colocar mi transacción en el mismo bloque que la del envío del BNB. Intento de solución 1 Monto una estrategia muy sencilla que es hacer un script que mire la mempool detecte el envío de BNB a la wallet comprometida y automáticamente lance una transacción de test para ver si mi transacción cae por delante de la del bot y puedo empezar a operar la wallet del shur. Pero... cuando voy a enviar la transacción ocurre esto: Código:
"error":{"code":-32000,"message":"insufficient funds for gas * price + value"}
¿tiene la wallet fondos suficientes como para pagar el coste de la transacción y el valor BNB que envías? La respuesta es que no, porque la transacción de envío de BNB aún está pendiente, por lo que la mía la descarta y ni siquiera entra a la mempool. Intento de solución 2 Como no sé cuando es el momento exacto para poder enviar la transacción y el bot sí, intento hacer frontrun al bot para invalidar su transacción con algo más de gas. Esto es muy sencillo de hacer, me pongo a mirar en la mempol una transacción que salga de la wallet comprometida, veo que nonce (el nonce es un índice que usan los nodos para saber cuál es la última transacción enviada) tiene, envío la mía con un poquito más de gas y el mismo nonce. Tras varios intentos puedo ver que en TODAS las ejecuciones la transacción minada siempre es la del bot y no la mía. Para ver porque narices no estaba entrando mi transacción primero decido "depurar" la mempool y ver que está ocurriendo cuando el bot envía su transacción. Me encuentro lo siguiente: Código:
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 642,
data: '0x',
}
{
from: '0x98442BDA3A28...'
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 638,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 641,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
value: BigNumber { _hex: '0x026dc545c64176', _isBigNumber: true },
nonce: 639,
}
.
.
.otras 30 más
sí, como lo veis, no envía una sola transacción envía más de 30 transacciones pendientes con distintos precios de gas, distintos nonces... Todo esto lo hace para despistar porque realmente la única transacción que va a entrar ahí es la que tiene el nonce correcto.En el ejemplo que os he puesto, en ese momento, la transacción correcta y la que entró fue la cuarta, la que tenía nonce 639. Tuve que modificar mi script para que no pillara la primera transacción que salía de la wallet hackeada. Tenía que tener en cuenta también el nonce correcto. Volví a probar y empecé a ver en los logs que seguía teniendo problemas con el gas. Guerra de gas A partir de este punto me doy cuenta de que tal vez el problema es que no estoy seleccionando correctamente el gas. Básicamente tenemos dos variables con las que podemos enviar una transacción:
Si, ¿adivináis quien estaba haciendo estas transacciones con un coste tan reducido? El bot: Tiene lógica este comportamiento, gasta el menor gas posible para pagar menos "fees" y robar más cantidad de BNB para su cuenta. Esto además, ofrece una doble ventaja al bot, ya que para un usuario que quiera colocar una transacción por delante de él, siempre competirá en desventaja porque cualquier transacción que no sea envío de BNB cuesta más gas utilizado. La transacción que estaba probando yo, era aprobar un token cualquiera (el típico aprobado que hacéis en Metamask cuando queréis vender un token). El coste de gas mínimo que necesita tu transacción se puede estimar con la función "estimateGas", en concreto, aprobar la venta de un token me costaba un mínimo de 41000 de gas aproximadamente. En resumen, si el bot quería, reduciendo sus beneficios siempre podría colocar su transacción por delante de la mía porque la mía es más cara y él podría pagar siempre más "fees" que yo. Aquí pensé que era jaque mate. Intento de solución 3: adelantar mi transacción al bot A pesar de mi reflexión anterior, no me doy por vencido e intento colocar mi transacción antes que la del bot. En ese momento había descubierto como hacerlo con la función estimateGas. Cuando estimas gas y el nodo no puede estimarlo porque en la wallet no hay BNB da un error. Sin embargo, cuando ya puede estimarlo significa que ya hay BNB en su cuenta y eso me sirve como "marcador" para poder enviar mi transacción en primer lugar a la mempool. Tras montar esta estrategia recibo todo el rato el siguiente error: Código:
"error":{"code":-32000,"message":"Replacement transaction underpriced"}
Solución 4: definitiva Con todos los intentos que estuve haciendo pude darme cuenta de que el bot modificaba su comportamiento en función de si yo enviaba una transacción a la misma vez que él o no. Si detectaba que en la transacción actual o en transacciones previas había habido competidores, el bot subía el precio del gas de su transacción para vencer a la mía. Sin embargo, si yo lo único que hacía era enviar pequeñas cantidades de BNB a la wallet hackeada y no competía con el bot, este se relajaba y empezaba a bajar su precio del gas. Este comportamiento es inteligente, porque en todo momento lo que busca el bot es maximizar los beneficios y no que se lo coman las comisiones. Los desarrolladores del bot se han movido en una dicotomía: ¿pago más por la transacción para estar seguro de que el que roba el BNB soy yo?, o ¿pago menos por la transacción para robar más BNB arriesgándome a que me coloquen una transacción por delante? Así es como di con la solución, explotando esa dicotomía. Además de aprovecharme de su comportamiento introduje otra variación que hizo que el bot se liara un poco más sobre que precio de gas poner a su transacción. Monté la siguiente estrategia: 1. Vuelvo al esquema donde mi transacción va a ir justo por detrás de la suya (para intentar colocarle una transacción con más gas y que sea la suya la descartada por el nodo) 2. Previamente a mi prueba, envío dos o tres transacciones con muy poco BNB sin competir con su transacción para que reduzca su agresividad. 3. Envío 3 o 4 transacciones con BNB a la vez para causar confusión al bot. 4. Detecto la primera transacción del bot que salga de la wallet hackeada con el nonce correcto y le meto la mía con +1 de gas. ¿Resultado? Tras varias horas de intentos y pagar más de 30 $ en total en pruebas desde mi wallet... Consigo colocar mi transacción de prueba por delante de la suya!. Engaño al bot, cuando envía esa transacción con el nonce correcto se piensa que es la única que va a haber y que no hay nadie compitiendo, además la envía con menos gas del que debería porque han entrado 3 transacciones a la vez con BNB y hay más BNB para llevarse por lo que debería de pagar más gas. Los siguientes pasos ya son más sencillos, realizo dos transacciones: - Una hace el withdraw de los tokens invocando el contrato donde tiene el shur los 1000 $. - Tras llegar los tokens a su wallet comprometida, hago seguido otra transacción para enviarlos a su wallet limpia. En verde son las transacciones que coloco por delante del bot y la cantidad de tokens que entran y salen de la wallet hackeada. En azul, es la dirección del contrato donde estaban en staking los tokens, en naranja es la wallet hackeada y en morado es la cuenta del shur limpia. Había otras posibles formas de vencer al bot según se describe en la comunidad: 1. Crear un contrato y llamar a la función selfDestruct con la dirección de la wallet comprometida, esto genera una transacción interna con el BNB del contrato y no puede ser detectada en la mempool por el bot. (Esta solución no me gustaba del todo porque el bot vigilaba la wallet del shur llamando a la función balanceOf cada poco tiempo, aparte de vigilar la mempool) 2. Pagar a un minero el gas por otra vía y dejar que el minero ejecute tu transacción sin pagar gas por ella, esta creo que hubiera sido la solución más eficaz. Y por último me gustaría agradecer al shur @Iberia por haber confiado en mí sin conocerme de nada y por haberme devuelto 200 $ como agradecimiento por todo este trabajo. Siempre he pensado que en forocoches hay más gente dispuesta a ayudar que a estafar y de momento creo que no me equivoco. Gracias por leerme y espero que hayáis disfrutado con la historia. Dejo este tweet como recordatorio: |
