5 ms·

> Weird that it would be a boon for both forensic accountants and fraudsters. How do you reconcile that sentence? It is very common to track people by the toke

> Weird that it would be a boon for both forensic accountants and fraudsters. How do you reconcile that sentence? It is very common to track people by the tokens they hold and target them for theft and fraud. One example is to airdrop a backdoored token, and when the user tries to move it they wind up authorizing movement of their other valuable tokens. Or to just use the airdrop to lead a curious user to the airdrop event's website, which is then a phishing campaign that achieves the same result.

theK 5y ago
Tracking partial identity through tokens is actually a very common concept amongst the newer blockchain platforms which also have addressed such topics as the drawback you describe. While said attack is theoretically possible it only is applicable to tokens managed by the same contract and only on platforms which do manifest tokens as script state (think erc20). Platforms with native assets (Cardano and some others) are immune to such attacks.
- vmception 5y ago
  where can I learn more about that approach? I just assumed the eUTXO model would be more like the UTXO model where assets could still be tracked to a single address, like with the old Counterparty or OMNI model in Bitcoin. What would you consider Solana's approach to assets? I was surprised to find that each address has another unique address for its balance and possession of any asset issued on that network.
  - theK 5y ago
    The key is not in eUTXO (allthough eUTXO is a great piece of work, especially because it solves a multitude of scaling issues in the long run), it is in the ledger's capability of handling custom assets natively. This way a wallet exactly shows you which tokens you own are affected by a contract invocation. I don't know how solana handles assets but I personally stay clear from that ecosystem. Too much VC hype for my likes and way too little decentralization of funds.
seanhunter 5y ago
Looking at the token standards[1], I can't see how you could create a "backdoored token" that would authorize movement of other tokens but that sounds like a scary threat vector. Could you explain how that would work please? I've heard about ERC20 tokens that allowed the issuer to pull them back (that's the SoarCoin thing[2]) but not a token that allowed other tokens to be transferred. [1] https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-1155 https://eips.ethereum.org/EIPS/eip-1155 [2] https://iterative.capital/erc20-backdoor-allows-you-to-steal-your-payment-back/?__cf_chl_tk=nOfxpUKV22Dau7LfMEFLBiVMLxi00tTae_m.Gc9HviA-1641114914-0-gaNycGzNCGU https://iterative.capital/erc20-backdoor-allows-you-to-steal...
- cinquemb 5y ago
  The standards only really define what should be done at the interface or what the function inputs and outputs should be, but don't really define the internals of the functions. For example inside of a malicious approve function call, you could hardcode a list of popular addresses that also approved those tokens if the msg.sender is holding (balanceOf calls) them and even potentially then have transfer functions calls inside of the approve function call for the malicious token. For me, its only scary if one regularly interacts with tokens they haven't bothered to look up for the source code for. People really shouldn't be interacting with contracts if their first time hearing of it is from looking at who randomly airdropped them a token with a domain name in it. But hey, people regularly do stuff in crypto that i just think "wtf arw the thinking", so w/e.
  - exo762 5y ago
    Both of you are wrong. ZK fundamentally does not allow to hide the rules (the code). It only allows to hide particular executions. So yes, while you can have an ERC20 interface and some censorious garbage inside (I look at you, USDC), you can't hide that fact from observers.
    - cinquemb 5y ago
legutierr 5y ago
> One example is to airdrop a backdoored token, and when the user tries to move it they wind up authorizing movement of their other valuable tokens. Do you have an example of where something like this was actually deployed? How would a user moving one token would result in another token being moved? I can only imagine a situation where a user might be induced to install a compromised wallet, and then to give that wallet keys to the their account. But this is not an attack strategy that depends on there being a "backdoored token" of any kind. Is there some way to code an ERC20 token that would somehow give you access to a user's other tokens?
- vmception 5y ago
  To me this is like asking if I have an example of a phishing site, not off the top of my head? Just embed approval methods for a predefined external token contract address into the transfer() method of the airdropped token Then you can also chain the transfer within it or you can wait and transfer them all yourself Doing too much in one transaction will alert more users because the gas price will be unexpectedly large
  - legutierr 5y ago
    Ah, am I right that you are referring to something similar to what is discussed in this article? https://blocksecteam.medium.com/unlimited-approval-in-erc20-convenience-or-security-1c8dce421ed7 https://blocksecteam.medium.com/unlimited-approval-in-erc20-... But is it not the case that the approve() method must be invoked directly by the sender (i.e. by the account that holds the tokens that are the target of the theft)? Wouldn’t the invocation be rejected by the ERC20 token if it is made indirectly, i.e. if the invocation were made from within another method (provided that the target ERC20 token is coded properly)?

theK 5y ago

Tracking partial identity through tokens is actually a very common concept amongst the newer blockchain platforms which also have addressed such topics as the drawback you describe. While said attack is theoretically possible it only is applicable to tokens managed by the same contract and only on platforms which do manifest tokens as script state (think erc20). Platforms with native assets (Cardano and some others) are immune to such attacks.

vmception 5y ago
where can I learn more about that approach? I just assumed the eUTXO model would be more like the UTXO model where assets could still be tracked to a single address, like with the old Counterparty or OMNI model in Bitcoin. What would you consider Solana's approach to assets? I was surprised to find that each address has another unique address for its balance and possession of any asset issued on that network.
- theK 5y ago
  The key is not in eUTXO (allthough eUTXO is a great piece of work, especially because it solves a multitude of scaling issues in the long run), it is in the ledger's capability of handling custom assets natively. This way a wallet exactly shows you which tokens you own are affected by a contract invocation. I don't know how solana handles assets but I personally stay clear from that ecosystem. Too much VC hype for my likes and way too little decentralization of funds.

seanhunter 5y ago

Looking at the token standards[1], I can't see how you could create a "backdoored token" that would authorize movement of other tokens but that sounds like a scary threat vector. Could you explain how that would work please? I've heard about ERC20 tokens that allowed the issuer to pull them back (that's the SoarCoin thing[2]) but not a token that allowed other tokens to be transferred. [1] https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-721 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-998 https://eips.ethereum.org/EIPS/eip-1155 https://eips.ethereum.org/EIPS/eip-1155 [2] https://iterative.capital/erc20-backdoor-allows-you-to-steal-your-payment-back/?__cf_chl_tk=nOfxpUKV22Dau7LfMEFLBiVMLxi00tTae_m.Gc9HviA-1641114914-0-gaNycGzNCGU https://iterative.capital/erc20-backdoor-allows-you-to-steal...

cinquemb 5y ago
The standards only really define what should be done at the interface or what the function inputs and outputs should be, but don't really define the internals of the functions. For example inside of a malicious approve function call, you could hardcode a list of popular addresses that also approved those tokens if the msg.sender is holding (balanceOf calls) them and even potentially then have transfer functions calls inside of the approve function call for the malicious token. For me, its only scary if one regularly interacts with tokens they haven't bothered to look up for the source code for. People really shouldn't be interacting with contracts if their first time hearing of it is from looking at who randomly airdropped them a token with a domain name in it. But hey, people regularly do stuff in crypto that i just think "wtf arw the thinking", so w/e.
- exo762 5y ago
  Both of you are wrong. ZK fundamentally does not allow to hide the rules (the code). It only allows to hide particular executions. So yes, while you can have an ERC20 interface and some censorious garbage inside (I look at you, USDC), you can't hide that fact from observers.
  - cinquemb 5y ago

legutierr 5y ago

> One example is to airdrop a backdoored token, and when the user tries to move it they wind up authorizing movement of their other valuable tokens. Do you have an example of where something like this was actually deployed? How would a user moving one token would result in another token being moved? I can only imagine a situation where a user might be induced to install a compromised wallet, and then to give that wallet keys to the their account. But this is not an attack strategy that depends on there being a "backdoored token" of any kind. Is there some way to code an ERC20 token that would somehow give you access to a user's other tokens?

vmception 5y ago
To me this is like asking if I have an example of a phishing site, not off the top of my head? Just embed approval methods for a predefined external token contract address into the transfer() method of the airdropped token Then you can also chain the transfer within it or you can wait and transfer them all yourself Doing too much in one transaction will alert more users because the gas price will be unexpectedly large
- legutierr 5y ago
  Ah, am I right that you are referring to something similar to what is discussed in this article? https://blocksecteam.medium.com/unlimited-approval-in-erc20-convenience-or-security-1c8dce421ed7 https://blocksecteam.medium.com/unlimited-approval-in-erc20-... But is it not the case that the approve() method must be invoked directly by the sender (i.e. by the account that holds the tokens that are the target of the theft)? Wouldn’t the invocation be rejected by the ERC20 token if it is made indirectly, i.e. if the invocation were made from within another method (provided that the target ERC20 token is coded properly)?