Yannis Smaragdakis - Real-Time Security Monitoring for Smart Contracts: a Relational Approach

Everyone, can you hear me? Well, okay. It's very nice to meet you guys. I'm Stephano. I'm co-ounder of Saf and today I have a duty to introduce you the uh book talks.

Uh we are talking about violations and real time monitoring. It's a very pleasure for me to introduce our professor and uh we are talking about real time security for startup a relational approach. So, I hope you will enjoy it. If you need something, I'm going to do it right there. Okay.

Thank you very much.

Can you can you hear me? Okay. Okay. Let's disable the other one. Okay.

So, uh this is going to be part and part demo. uh so I will need your attention at sometimes and uh I need to know whether you can read code uh like whether you can read this or it's too small a font is this readable from the back from the next to last row is that readable not so much can you move closer because I cannot enlarge the font anymore and still have a screen you need to be able to read a little bit if you want to follow everything. Uh like this part especially. I don't think that you can even hear me very well. Is the screen readable this part?

Okay. So if you want to be able to read code, please come closer to the front and I'll get started. Otherwise, uh we can go over slides quite a bit, but it's going to be much more productive if we can actually see some some real examples. So I'm Janice. I'm co-founder of DOB.

It's a security company. I'm going to talk about uh real-time security monitoring. Everything you see today, you can access with a free account on our site. You can run all these queries and it's basically the entirety of our technology. Anything that we have is exported through this monitoring queries that you will see anything we have technology wise.

So uh has anyone here heard of DDO as a company? Who has heard of us before? Nobody. Okay. So we are best known for our decompiler.

So it's been running since uh 2018. So everyone who wants to investigate smart contracts on any VM network, smart contracts that don't have source code, they visit our sites. That's many hundreds of people every day. We have over 8,000 uh registered users. So you may have used us without really knowing that you use our service because we are the the main decompilation service for investigating security incidents, for reading the code of MEV bots, anything that doesn't have source code.

Uh we are a fairly well-known security company. We've gotten lots of bounties. Uh we've done many security audits for leading projects u for chain link layer liquidity zero lots of top names. Uh so generally we are a security company that has its origins in technology and you can access most of the technology everything that I'm showing today on our tool site app.dub.

com and the first thing that you will see there is the decompiler. So for instance if we want to go there you may have seen something like this before. which is decompiled code from our tools. It's a browser for all deployed smart contracts on eight different blockchains that decompiles all the deployed code. Uh so this is not the source.

This is the decompiled code. This is recovered from bite code. That's the output of our tools. So getting back to the point of monitoring here. Uh what we have in the DOB security suite is a possibility for you to be writing monitoring agents.

So simple queries that can monitor in real time as well as for analytical queries but mostly tuned to monitoring in real times the behavior of a problem like seeing if something can go wrong. And of course you can get very nice graphs but the essence is probably not the graphs although these may give you insights. The essence may be something like what you see at the bottom here which is alerts uh investors with vulnerable contracts for instance in this particular case and of course you can receive alerts over any conditions that you want. So we'll see what technology lies behind that and how you can exploit it with uh writing your own queries. So when we're talking about writing custom monitoring agents using our language, DWQL, it's basically SQL.

It's basically SQL uh with some macros. And why do you need to write custom monitoring agents? Why can't you use something that's already there? I mean, lots of companies have monitoring and they tell you we blacklist everyone malicious and we notify you. Well, there's much more than just blacklisting some malicious addresses.

So there are many needs for monitoring that are different for different D5 protocols and we're giving some applications here. Uh for instance, if you have a DEX uh then you may want to detect large trades. These are these have nothing to do with anything malicious, but this is a very natural monitoring condition. Or you may want to see anything that you can define as an anomalous transaction, something with high gas growth or a large withdrawal if you have an L2. or you may want to monitor governance proposals if you have a DA uh or any of any kind of different conditions uh you can write with our monitoring language.

So let's start looking at what the monitoring language looks like. It's like I said it's a variant of SQL. So it's it's really SQL with some extra macros. It's Postgress uh SQL. So the example that you see on the slide is very very simple.

It's actually something that you don't need a database for. You can actually ask a blockchain node and get well indexed results for events. So this here just says give me this information block number transaction index and investor from the logs here from the event logs emitted by this contract for this event the ad whitelisted event. And the only interesting perhaps thing here is that this part the investor that comes from the event is exported here in the query. So you actually have access to who was the investor from the query.

That's something that our language gives you. So this is a good time to switch and try to write a query together. So let's look at what we would write. uh something very very simple with logs again. So we can go here.

This is the environment that you would see. I have a an empty query here and I can write. It's very hard to write to type standing. Uh especially if that's not your natural position. You probably know.

Uh so if I type select start star start from uh Ethereum dot logs. Okay. And now you say well how do I know events? Do do you expect me to to remember event signatures? So let's just go to our explorer.

Pick any contract you want. I mean, I picked one. It's pretty arbitrary. I hope this one issues some events. Um, what I'll write here is, and the moment I type dot, it prompted me with the events that the contract actually emits.

I had not tried this before. It's completely live. I had not seen that contract before. So, you don't need to remember the signature. it finds it itself.

Of course, now that you found the event signature, you can remove the contract because maybe you want the same event from any contract that has emitted it to index over that in the database. It's perfectly supported. So, but this is basically our query here. So, if I run it, it will tell me that I have a syntax error most likely, but if not, it's going to work. That's rare.

That's going to work the first time. Well, in this case, there was no event like that. Let's pick another one. But it ran. That's the point is we just wrote our first query.

It queried all event logs. Actually, let's try something different. Let's remove the contract and keep the event because that same event could be emitted by any of a different number of contracts. So, I don't know how fast this will be, but eventually it's going to give us all the results. So that's exactly the kind of thing that you can do by combining our database with live node data.

Any questions so far? Yes.

What are the chains we are supporting? So I'm not sure that it's eight. It could be seven right now. But it's uh Ethereum mainet, Binance, BNB chain, uh arbitum, optimism base, blast, uh avalanche C chain. Actually, if I'm forgetting one, it will be here.

Uh let me actually go here. and play Ethereum. I think I gave you all of them and polygon. Yes. So those are the those are the chains that we fully support in our database right now.

Okay. So I think you got the idea. We can write many complex monitoring queries. They're not always going to be terribly fast. This one in particular here, it tries to find all events of this kind ever emitted.

You can make them incremental though. That's the whole idea. The whole idea is you write those, you set the duration. Actually, I had set the duration because of the demo I want to give later. So, that's pretty long.

It's over many, many days. You can set the duration. You can set a an incrementalization policy. And as long as what you're quering grows monotonically, it only adds new things. Then, it's going to be maintained incrementally.

So, you're going to get the increments in real time. Is it clear what what I just said about the increments in real time? Okay, cool. So let's get back to the presentation so we get an idea and my hope here is that we will eventually come and see more complex queries that I have here that will show a lot of this. Now what we just saw is logs which is a table gadget.

It's basically functionality that looks like a table. It's like a virtual table in our database that it actually there there is a real table behind it but there's also computation behind it and we have many such table gadgets that you can use in macros and query various aspects. Logs of course is easy but there are many many more. We can you can completely deconstruct transactions for instance you don't need to have events you can parse all transactions all call data everything that you want there. So the idea with our monitoring system is you you set up those monitoring queries.

You set them up to incrementally give you alerts and then you set an alerting policy. you say, "I want to get emails or I want to get uh messages through some kind of hook on Slack or Telegram or whatever." And you get notified every time there's a notification, every time there's an alert. Now, what we can do here is write queries and build queries on top of others. So for instance another table gadget that we see here in the macro is ref and this refers to the query that we saw before.

So the query that we saw before was whitelisted investors added and it just found investors based on emitted events whitisted inventors that were act investors that were added. We can combine this with another query. Refer to both of them. Combine those. Say I want all of the first where they have not been removed after being added.

And the this is exactly what these conditions down here set up and get the result of that. What more can I do? Sorry about that. Take it down one. Okay.

So what more can I do? Not only do I have a database, but I also have the ability to call any Ethereum functionality, any node functionality. I have the ability to do an if call from inside the query. So for instance, here we're doing an if call. That's another table gadget.

That's another macro from our SQL variant. that says I will do an ETH call and I will get the name from this token. I will format it like this for database querying purposes. I'm going to get it as a string column and based on that I will run the rest of the query. So this first part gets the name of this MMI fund token and down here what we are actually outputting from the query is date token name uh some staking token from here uh and a sum of the quantity.

And how do we get all of those? We get all of those by reading the redeem events from our uh from a different query that reads logs. Here we group by day order. I mean I'm not I I'm realizing right now that I don't fully understand every single word here. I need to look it up to connect exactly what SD token does.

But the the main idea should be pretty clear here. And there are many other queries that I've written and we will go into depth. So the idea is we can combine information from a live blockchain node. We can combine information from our database that summarizes all past transactions and you can parse those. And the third kind of information that we will combine is information from a whole lot of static analysis algorithms and machine learning classifiers over the compact code.

And that's going to give us the full monitoring language uh inside the queries. Okay, so let's get to see the rest. As a company, what we've done traditionally is write static analysis algorithms or write program analysis overall because it's there's static analysis, there's fuzzing also that we're running and now there are ML classifiers. So we do a lot of code analysis. Every deployed contract out there we've analyzed and many of those results are in our database.

Most of those results are in our database. So our queries all these queries have access to all this information. So let's look at something here. What this says is again appeals to the previous query whitelisted investors added and then it joins this and says I will want to get the investors that were whitelisted but at the same time have been marked by a static analysis algorithm as having a vulnerability with high confidence. I guess the noise is distracting from back there.

I don't think there's a way to close that door. If there's a way to close that door, it would be great, but it's okay. Cool. Oh, much better. Okay.

So, the idea here is I'm not telling you what vulnerability type. Uh I'm I'm leaving it this pretty abstract at this point. All I'm saying is any vulnerability type with high confidence uh for a whit listed investor I would like to be notified for. So let's go and look at actual queries that we can play with and instead of just the vulnerability types we'll see a lot more. So the vulnerability types of this kind come from either fuzzing or static analysis of the code but we also have other classifiers.

So if we go back here, I would very quickly like to see this query which is actually a very realistic query that we run all the time and we continuously monitor for. So this we can actually dissect a bit. This is one of the queries that it's worth looking into in a little more detail. So you can actually follow this even though it may look scary at first. So the first part here says I will define a subquery that I will call vulnerability filter and it will say give me all the code identifiers.

give me all the unique bite codes which are identified by MD5 hash that have been classified to be a suspicious contract. Now, how did this come about? The classifier that's a machine learning classifier that we run on every contract out there. It's an engram based classifier. This particular one, we have others that are based on LLMs.

We have lots of code analysis algorithms that output results into this database. But this is one of our best classifiers for high precision. It's not going to find all suspicious contracts, but everything it marks is very likely suspicious. So something that is classified as suspicious. I'm actually going to join this with a few more filters to get more and more precision.

And if you want to see what I'm going to be trying to do, it's encoded in a comment at the top of the query which says what really this query computes is contracts that are classified as suspicious by the machine learning classifier. They call a function signature that is deemed to be probably privileged. That part comes from static analysis. They are not part of any predefined protocol. Sorry.

Oh, what did I do? They're not part of any well-known protocol on Ethereum. They have no source code and no human has inspected them to be safe on our system. So let's look at all of these one by one. We already defined the first part.

We already got the answer from the machine learning classifier. Second part here is calls possibly privileged function. That's another table in the database. It came from static analysis. This is an analysis that we run on every single deployed contract.

It tells you which functions call other functions that have monetary significance. We join with whether there has been a human inspection. This whole part here join left join with uh inspected vulnerabilities. There's going to be a wear clause at the bottom that's going to say nobody has marked it to be a false positive. So this here goes with line 26 as a filter.

And then the rest is it's not part of a well-known protocol and it doesn't have verified source code. So with those five elements that I just showed you, we created a query that's extremely precise for blacklisting suspicious contracts. This is an absolutely realistic blacklisting query. I I mean I don't want to refer to other companies that do blacklisting, monitoring, etc. But basically, this is state-of-the-art.

This is you just wrote a query that's about as good as you will get from anyone who's doing monitoring and telling you who is suspicious out there is the point. Any questions right now? Yes. is it server?

It's running on our database machine.

Yes.

Okay.

Yeah, it's a centralized service. It's our database server that runs this.

Correct. Correct. Everything that you see here, this web interface, it's something that anyone here can access. There are limits to how many queries you can be having simultaneously in the free tier unless you buy something. But you can run all these queries yourself right now.

Yes, we have our own database in the tables here. You can get the APIs for everything that's deployed on on most networks. Like some networks we support partially like for base we don't go very far back in transactions like maybe transactions of only the past year. So if you need things that happened like over a year ago we may have some gaps but for the most part we are pretty complete. Okay.

So um are we good with what we've seen so far? Who's lost? Let's see bravery here. I want brave people to raise their hands and tell me I'm lost. I don't even know what you're talking about.

Okay. If you can formulate anything as a question, it's going to be very useful for other people. Yes. Dub. Yes.

The company. Yeah. Fine. [Music]

In the future security.

Okay. So the question is how how realistic is it in the future to hope that security will be guaranteed by tools without the need for manual audits. I'm an old-timer. I would say it's not realistic. But the tools have surprised us all in the past 3 years.

Uh philosophically we're all lost as humankind right now. We don't know how good the tools will get. Uh so who can say no? But of course nobody can say right now certainly manual inspection is the best one can get for security assurance. At the same time tools are very valuable.

I mean the tools in the hands of a good security researcher are invaluable. Okay. If there are no other questions I will return to my script here which I think you got the idea. We integrate in this database everything that's happened summaries of everything that happened in the past in the blockchain everything that we have analyzed from the code using static analysis fuzzing and machine learning and we export lots of building blocks. So here's an example of five building blocks among many tens that we have.

If you want to write a query and at some point in the query you want to talk about properties of the code of the smart contract, you can use concepts such as this. Oh, this function does a transfer, but before it does the transfer, it makes sure that the only caller that can reach that line is the owner of the contract. That's what we call a check transfer. That's very useful if you want to say, "Hey, there there are some privileges in this contract. It does something.

It does a privilege transfer at that point." And now I saw it somehow being executed by someone who's not the owner, for instance. Possibly re-entrant call. It's it's a table in the database. It's actually a sub uh subtable.

It's part of a big table called proto vulnerabilities. These are the building blocks. and it tells you that the function makes a call on one of its arguments. For instance, it's going to tell you function fu. It takes three arguments and it makes an inter external call on the second one.

You can use this as a building block for detecting re-entrances as they happen and all sorts of other things sensitive arguments both on the caller and making calls with sensitive arguments unguarded external calls and many tens more building blocks. So you have a very rich vocabulary from existing code analysis that you can combine with what's happening right now. You can combine there's a transaction, it happens like this, it happens like that. And the code that either got called or started that call has these properties. You can write extremely powerful queries is the idea.

And of course we already saw this. We can use machine learning classifiers. We have classifiers for suspicious contracts etc. At the same time, it's a it's a general purpose query language. So you can also write analytical queries if what you want is to be monitoring your protocol and finding for instance how much volume you have, whether you're hitting some targets, whether you're getting anything that's a legitimate yet unusual transaction, etc.

You can certainly do all that. You can write all sorts of analytical queries just like you would do with dune analytics for instance. But the emphasis on on our database is on real time alerting. It's on getting the incremental diff for transactions that just happened. It's the intent is that most of these queries you run all the time and you get the new results.

Uh so for instance again here there's uh there's a query on transfer events. uh and then you can actually do all sorts of aggregations there. And we also have lots of tables to map transfer events with real world US dollar value. So if you want to say give me every transaction that withdrew more than a million from my protocol, you can very quickly do that. And of course sums and maximums and all that.

And you can visualize all of those in dashboards. So we actually have some graphical representations. You can connect queries to graphical representations and be visualizing this in the in a dashboard at all times. Uh okay. So I think instead of boring you more because I know we cannot parse all the code in real time.

I'm trying to give you a taste of of what you can do. Uh it's not going to be an easy language. Obviously it's it's going to take effort. It's going to take a lot of trial and error and some consulting of us. Uh but I hope that I gave you an idea of the power.

So, but instead of going over more examples here, uh I would like to go and perhaps see some real queries again and if we walk over them, maybe we can have a few more questions on things that are unclear. Are there any questions right now? person. No. Okay.

So, by the way, this is a a very standard query. Uh we have a subquery for tornado cache recipients across all chains. It's very standard to say has anyone is anyone who's funded by tornado cache calling my protocol. In this particular case, is is anyone funded by tornado cashache calling any smart contract that's that are under the balancer protocol? This is very easy to write.

But let's go and look at actual examples and see if we can get something out of that. Okay, so we saw the highly suspicious contract deployed. Of course, we can write some very simple analytical queries. For instance, if you want statistics like for a research paper or something, uh give me all the deployed bite codes on Ethereum that are more than 14 uh kilobytes. that's going to run right away and it's going to tell you it's 233,000 out of about 800,000 deployed on Ethereum.

Those are unique bite codes. Obviously, there are u I think right now 80 million deployed contracts, but most of them are duplicates or near duplicates. So, we're talking about unique bite codes. There are only a few hundred,000 and 233,000 are large enough. Uh let's look at other interesting queries.

Here's a query that's actually running. I I mean that's actually useful. It's not useful right now. Right now, if I run it, it's going to give zero results. That's why I interrupted it last time I ran it.

Uh but three months ago, four months ago, there was a live vulnerability discovered in the liquidity protocol that had just deployed uh liquidity v2. We were one of the auditors of liquidity. It was a very sneaky vulnerability and we installed monitoring to make sure that the protocol is safe until it gets redeployed or until the balances drop enough that there was no threat. So what does this query do? Same thing as we saw on the slide.

It talks it refers to the other query in our library which is the tornado cache recipients and then it takes the transitive closure of that. So it actually sees who's transitively funded by tornado cash and then checks who has ever called liquidity and that filtering is done based on events here and it's one particular kind of call. It was the batch update batch liquidation that exposed the vulnerability. So that's exactly what this very realistic query examines. Another pause here.

Any questions or anything that came to mind? Yeah.

Okay. So much activity on chain like contracts verifying all the do you have or to detect sensitive activity?

Okay. So the question is many times as human developers we get the impression that all the activity on a chain is from robots. Uh do we have a script for that? I don't know what would be the science of robot activity but we do have a classifier for MEV bots for instance which is highly precise and complete. So I can tell you the addresses of all deployed contracts that are MEV bots.

That's easy because you can tell an MEV bot by its use of flashbot specific positioning in a block sometimes. So we have a good sign. If you think of a good definition for what tells you that some something is a bot. I mean if if you want me to if you want to say something is a smart contract, I can obviously say that. But something is a bot versus something is a smart contract from a protocol.

If we come up with a definition, I'm sure we can write the query. Okay. Anything any other questions? I think we're good. So, we saw already quite a few very interesting uh queries.

Here's another one. Uh that gives you an idea of how to write a multi-et network query. I ran it actually. This runs pretty fast. I have set the duration so I can get these results.

I had to set the duration to about a month and a half. Uh what does this do? We already have a vulnerability type for sensitive callback does not check sender. This came from this vulnerability is a static analysis was defined based on a hack that happened a month ago. Uh and we are running it to get warnings for anything else that might be susceptible to very similar logic to very similar hacks.

So we have a call back that does not check who called it. uh we have actually a couple of different static analysis for that and but the the main point here is that this is a loop over all the networks we support. So this says for network being ethereum, polygon, binance, optimist from avalanche base and glass go and take the union of all the contracts that are flagged for this vulnerability. Okay. and 2 minutes 3 minutes basically it's been interactive throughout so I think you got the idea uh another chance for any questions yes

on which networks which chase you forward and How do we decide which is next or which one to drop?

Okay, so the question is how do we decide which chains to support on which is that one to drop? First of all, for full support by our technology, we needed to be an EVM chain. So it's not so easy for us to go we don't have a decompiler for Solana or for Sugi or for Apptos or for anything like that. So we're talking EVM chains. For EVM chains in theory, we can support anything.

So it depends on popularity of the chain. Uh otherwise there's there's no limitation. Now we have not supported ZK sync for instance yet but we may do so in the future because now it only just became an fully VM compatible chain. There are many other chains that we may support in the future. It's just a matter of finitness of resources.

There's no there's nothing deep there. uh we could support anything especially now uh that we are moving to a third-party uh node infrastructure because so far we've been running our own nodes for all these chains and we need archival nodes and this is very very human intensive to maintain uh up-to-date nodes for everything. Okay, so I think it's time to return and wrap up. Basically you got the idea of the kinds of things that we can do. The idea again is that these are monitoring agents.

They run periodically. They give you incremental results. They use the full vocabulary that we export. Uh behind the scenes what's happening here is that we have a Postgress SQL instance. So we have a regular database but we optimize for time series.

So we actually use time scale DB if you've heard of that. So for anything that's older than a million blocks, we use time scale DB. So we've compress we compress it quite a bit. That's why we are great for incremental queries for things that will mostly run on the on the last couple of months of activity. If you want historical, it may take a while to run and then after that we catch up incrementally.

And again, we're DDO. Uh we are a security company. If you've used us, you've probably used the decompiler. That's what most people use from us. Uh, but we've we're doing general security work and most of our technology.

Uh, anything that's behind, for instance, all the uh the hacks that we found, all the bug bounties that we got from deployed code, we've gotten 11 different bug bounties. We've gotten more than 3 million in bug bounties alone. All of this is based on the same algorithms that you have available right now. Of course, we have the extra luxury of being able to tune the algorithms, but still all the knowledge is right there in the database for you to use in your own queries. Thank you very much.

There's another question, but I don't think so. Maybe. Is there a final question from anyone? Yes.

Uh what what does it cost to use the what you just saw? It's free. No,

you can write queries for free, but you can have up to two queries that give you alerts uh as a free user. So all of this is free.

All of this is free. There are usage limits. If you are a heavy protocol, then it's there's enterprise pricing. We need to talk. Thank you.

something I would ever do.