ERC20 Misbehaviors

Transcript

hello everyone will talk today about your c20 misbehaviors so I'm Sergi I'm working as a security auditor at consensus diligence we're doing lots of security artists with different kind of projects almost every one of them are using here sea trenches so this would be a nice nice opportunity to talk to you about common mistakes common issue that they have just to avoid them in future so basically what is your c20 I'm pretty sure all of you know what that is but just to recap the the main information

this is the most common talking standard in in the cerium ecosystem it's pretty elegant and small it has only necessary functions to keep some tokens and transfer them from people to people this is the the basically the main interface but it can be extended lots of different function can also exist and take it it can can get really really complicated but the basic is like just getting balanced transfer in approving transferring from you to somebody yeah but what is interesting about your z20 that it's only an interface so

basically you can extend it with totally different kind of complexity and you have that for example or C 223 or C 777 is the kind of token standards that allows callbacks so for example in 223 every receiver has a callback just for for the purpose of not sending tokens to contract that cannot handle it so if contract cannot handle tokens it will be locked there forever so basically they just have callbacks to make sure contract can handle it and ear C 777 is going even further they have callbacks to sender before the transfer and callbacks to the receiver

after the transfer which gives a lot of opportunity to build on top of a different kind of functionalities it's also like much more complex things like security tokens what is the main different about them they want to be more compliant to like normal legal things more look more like security assets in the real world and what they do usually have is like KYC whitelisting really different kind of modularity arresting so they have different partitions some of the logins some of the tokens might be locked so it's like common a pretty complex functionality and lots and lots of other custom implementations like minami token to gesture all the history or just to be

able to then copy this token or for example a proven Cole token to do transfers in in one in one in one transaction instead of two approving to transfer from any other kind of centralized Lee control tokens so basically the one who issues token can control it eventually even stillage but nobody really cares about it so the common issue that we find and what can be interesting for you it's mostly issues related to like exchanges or some investment funds so any any any hazard kind of protocols it works with different lots of different tokens that they do not control so it's just like they have lots and lots of different

tokens to work with and they need to be more cautious about it so the most interesting I guess and the most unexpected and dangerous attacks is for entrance II so it's this is a basic this is just a basic example so we see these three functions they are located in different contracts so the token function is like the simple pure C seven seven seven kind of function so center of the token receives a call back during the transfer before the transfer is happening there's like some exchange function that at some point during the trade makes transfer from somebody to somebody and

I guess you will not really see it because um but it should be a attackers function that makes a trade then receives a call back and make one more trade inside this exchange before the first trade is finished so you can see the attack flow it's pretty simple just like I just described so sender makes a call by calling make trade in the exchange then inside of this call transfer from is called callback is called and then attackers basically the first person can make one more trade basically if this is like a bundle of for example it may be the attacker makes a trade with the old price instead of

doing it with a new price which is beneficial and by doing it multiple times attacker can just drain can just drain everything every money all the money from from the bonding curve there are different types of references in terms of tokens I could like separate them depending on who can do this for example sender receiver or any other third party Kay basic service or anything it's actually really important because for if you have your CE 223 to again only receiver can do this and only after token transfer with your CE 777 sender can also do this and usually sender is attacker also it's also really important when they are entrance is

happening either before or after well a transfer which is also really important because if you can do the if you can do this before you do not have transfer balance changes and you can do a lot of stuff knowing that there will be transfer after one of the really good examples of rendering their taxes unit swap so I guess you might all her about it it's a really elegant bonding curve exchange totally automated market making system so it is also interesting that by the time we did the audit it was already alive and maenette so this bug is not fixed and here see 777 tokens are not supported by eunice wap on the website

but contract wise you can you can set up a liquidity pool and it can be stolen so nobody should do it and I guess nobody does but you never know like there might be some custom implementations that can be stolen and it requires research but it's like a known thing and I guess hope nobody does it so basically I guess I just told about it so their exchange didn't have our entrance of protection this is the basic way how you have you protect you know protect from this kind of attacks we just do not allow to do trade inside of other trade also complexity about

this attack was that it's not it's hard to understand that this is actually the malicious attack because you just do one trade you do one trade inside of it one more trade inside of it and it it's not really clear that you can make use out of it but if you dig deeper into Bund incurved math you understand that you do the trade with a little bit just a little bit better price and by doing it multiple times with bigger volumes like getting a flash law on somewhere and just do it with huge volume you can really mint money in one transaction and just drain liquidity pool so how to protect from from this kind of attack the simplest way is just to inherit rent

and cigar contracts from up in Zeppelin and use nan wrench and modifier for every function you can see it's pretty small and simple implementation what is really important to mention that you should not only use this modifier for functions that does it do external calls to external contracts sometimes it also makes sense to add this modifier to other functions even to view functions they might not change anything but inside of the rear entrance e they can be used somehow as an Oracle or something else you never know how it can be used even before the trade is

finished so it's it's not only trade itself that should not be rendered some other data is like transaction on the exchange is not complete that means that data is not stable right now and it shouldn't be used so everything that is relevant for that should have non renter and modifier also after recent upgrade it became cheaper previously using non renter and required it still require storage changes but previously it was more expensive now formula gets more expensive now formula gets more complicated how the gas is calculated but it should be cheaper no thank you and also yeah do it only when your

entrance is not intended because sometimes you need your entrance e if you have like multi-sig or voting contract you would want to vote to call functions of the same contract with the same transaction and sometimes it's really necessary so yeah be mindful about it also even if you fix all the external stuff you you you make sure somehow that there is no very entrance e and you are protected from it sometimes people also consider that transfer should not fail if you have enough balance which is not true and like a lot of tokens they have different kind of functionalities but inside like kyc

blacklist in like whitelisting for example USD c can blacklist you and you will not be able to receive it and you developing some kind of exchange or anything like pipeline where you send in tokens to somebody just make sure it doesn't break anything because it might not pass yeah also like some tokens can be locked for different reasons is like vesting for example or any kind of different locking mechanisms also sometimes tokens just use a lot of gas which is not a good behavior but still it's possible so there should not be assumptions that for example hundreds of transfers can be done in one transaction for like random token that's just not

true and sometimes are really really expensive and also some coaches can be custom you know and also upgradable so you cannot make assumptions or some functionality for that kind of code because it can change over time so the basic remediation here is to isolate all the transfers don't do them in for loops what like avoid batches best transfers and always try to use pull pattern for any token withdrawals so people can withdraw their own tokens and you never do your transfers to two like random addresses what is also like really interesting it's and really something that people never think about if that if

you're working with like lots and lots of tokens you're one of your tokens can get broken and it's total supply can potentially overflow so even if you do the pool patcher and so everybody with drove their own tokens you do not to iterate over tokens everything should be safe but you still store balances of people's accounts in your system usually just so people can withdraw this balance and sometimes if the token is broken this this balance can just overflow underflow depending on math that you have so if some tokens can be broken and they can just mean more than maximum you int amount of total supply and total

supply can just give wrong Walia and why it can be a problem it's like this token would most likely be worthless because it's either malicious or broken nobody would care about it after but what is important is that your system doesn't break because of this if you like having for example if you are signing rewards in different tokens like with different values for for some for some user for example you can people tend to do it in the array because they know the gas price and they might know the limit of token lengths and it's kind of fine class wise they do not call in external transfers but they can still break this function this is a good example of a function that is

breaking and after that you just cannot assign anymore reverse so just to be conscious it's the possible remediation to just move safe mass from this kind of operations you will allow our flow or underflow but it's only when you really consider that if that happens then this token is worthless and you don't really care about the balance of these tokens you can also stir balances into you in two variables but this is really complex like also alternative is just to like use kept safe mass without like under flow and over flow but it all depends on the project what is more suitable for you also sometimes your situation to

have just wrong implementation this is a known thing like there are like hundreds of tokens that have run implementation gets balanced is one of them and usually transfer should return true and when you use when you use tokens you just use this line which is required token transfer that's how people usually use it and withdrawn implementation you do not return anything till some point between one of the upgrades in the EVM it was fine it was always returning true and nobody knew the the bug right after that it started returning false for like more complex reasons and all the

transfers were like failing and well you can ignore it obviously but you can also like use wrappers on top of it and handle this kind of thing for example I can say Aragon has has some libraries for it so they have safe transfer and they also try to handle this kind of tokens just to remember that there exists and again if you're deploying your own chokin well first of all think of if your standard is supported by other projects for example UNICEF does not support your CE 777 other projects might also have some mistakes you know

like lots of recent news from security in defy you never know that your CE 777 or like other more complex kind of tokens they might introduce new attack lectures and just gives more opportunity to the attackers so either don't you them simple simple is always good it's if you don't really need this extra functionality you can still use normal simple early twenties or like consider the brain chancy protection with with your C twenties or with their systems and seven or other kind of callbacks Kohlberg standards also make sure your gas cost is optimized because also other

projects which would assume you're pretty cheap and and they might have problems it would not be necessarily your mistakes but you would not want to be in a center of some other bug because other exchange has about you will just turn target number one if you have one of these issues and also make sure it come it complies to your C twenty just like previous example doesn't yeah that's it contact us at consensus diligence and if you have some questions questions it's great presentation thank you for

that I think you you must have gone very deep in like looking at all the years see 20 contracts what's like the best automatic coverage tool for these because I imagine like there has been so many attacks and so many like known issues with them like who's like the one who provides so far the best tool that actually tries all out tries out at least everything that hasn't happened already in the past kind of thing I would definitely recommend do the manual audits of any kind of tokens like that because automated tools can give you like a bunch of hints like for the initial research but anyway yeah like manual audit would do much much more work especially if it's gone go go into like custom tokens some tokens are

huge like I think the biggest audit I've did so far like with major like amount of lines of code is token eventually here's a 20 compliant so in terms of tools yeah I'm not sure about like already set up on the foresee 20 out of the box we have me six tools that do the different automatic stuff but yeah I'm not sure about exactly done automated for here's a 20 out of the box who is all of the do you need okay thank you any other questions yeah maybe what's like the most

interesting book that you have encountered almost funny but or not in year C 20 that we were supposed to - aw dit I think your youness trop was the most interesting one because it was already live on the minute and we had to check all of the tokens that were already listed had some money in there yeah like had some money in liquidity pool and where we were like iterating over all of them some of that most of them are simple early twenties we filtered the one that has external calls some of them are receipt 223 which is safe in unit op example your no air see 777 lots of centralized centrally controlled tokens so actually admins can

steal your money and people know about it and still put money in that and yes there are some custom implementation that we don't have access to the code which is also interesting token which is private and we don't know what's happening in there but yeah that was the most interesting one okay thank you [Applause] you