[00:03.000 --> 00:08.420]  Hello and welcome to the State of Blockchain Security here at the Blockchain Village at
[00:08.420 --> 00:14.760]  DEF CON 28. I'm excited to share with you just a really zoomed out view of the current state
[00:14.760 --> 00:19.880]  of our industry. We'll talk about a variety of blockchain security related events, major
[00:19.880 --> 00:25.160]  incidents. We'll gather some insights and make future predictions. And most importantly, we'll
[00:25.160 --> 00:31.060]  talk about a lot of opportunities how to build a stronger and more trustworthy financial system.
[00:32.360 --> 00:37.060]  In case we have not met, my name is Peter Kaczynski. I'm a blockchain security engineer
[00:37.060 --> 00:42.340]  at Coinbase, where I spend most of my time trying to break and secure a variety of standalone
[00:42.340 --> 00:48.720]  blockchain systems and smart contracts. On the side, I also publish a blockchain
[00:49.440 --> 00:54.440]  threat intelligence newsletter where I share the latest news. And partially, I will be recapping
[00:54.440 --> 00:59.340]  some of the major events that I cover in that newsletter. And in the past, I was also organizer
[00:59.340 --> 01:07.320]  of the Capture the Coin competition at DEF CON. In the past, I was working also as a malware
[01:07.320 --> 01:12.120]  reverse engineer at FireEye. If you're a malware reversal, you may have run into a few of my tools
[01:12.120 --> 01:19.880]  such as Flare VM and FakeNetNG. And I've also reversed a whole lot of APT malware that I care
[01:19.880 --> 01:26.720]  to remember. Zooming even back out, I was more on the offensive side as well for the Federal
[01:26.720 --> 01:31.800]  Reserve System, where I was working as a penetration tester, trying to break Finance 1.0.
[01:32.420 --> 01:38.380]  I guess everyone shares their story of how they got into crypto. The revealing moment for me was
[01:38.380 --> 01:42.800]  just basically my past growing up in the Soviet Union and observing what hyperinflation means
[01:42.800 --> 01:53.120]  in the first place. So it really, it really stroke a chord in me when I understood what the future
[01:53.120 --> 01:59.360]  offered by the cryptocurrencies. And I take it as a personal mission to make this field succeed
[01:59.360 --> 02:03.600]  by making it more secure. And I hope you join me on that mission as well.
[02:04.520 --> 02:11.120]  So what are we going to talk about? I would like to help inform, educate, and identify as many
[02:11.120 --> 02:16.100]  opportunities for you as possible. So if you feel like this is the field for you, you will know
[02:16.100 --> 02:23.100]  exactly where to plug in and what to pursue. Within this talk, we're going to talk about a
[02:23.100 --> 02:28.600]  variety of incidents, as I mentioned, from the newsletter. But the key point here is that it's
[02:28.600 --> 02:32.960]  less about me being right. I will offer some insight and opinions here, but I'm even more
[02:32.960 --> 02:38.340]  excited to start a discussion and learn from you during the Q&A session or offline if you care to
[02:38.340 --> 02:45.060]  reach out. I would be highly excited to hear your thoughts on it. In our presentation, we'll begin
[02:45.060 --> 02:50.560]  by defining the field in the ecosystem. So we'll talk, what is blockchain security? How is it
[02:50.560 --> 02:57.320]  different from any other security disciplines, let's say web application or IoT security? What
[02:57.320 --> 03:04.220]  makes it unique? We will also talk about the overall ecosystem that we're trying to protect
[03:04.220 --> 03:10.880]  and also think how it's getting attacked. Next, we're going to break down all of the variety of
[03:11.440 --> 03:16.120]  components within the blockchain security field. So we'll talk about exchange security.
[03:16.120 --> 03:21.220]  What were the major incidents this year so far? What can we learn from it? We're going to talk
[03:21.220 --> 03:26.700]  about the asset security. So we will discover a variety of protocol issues that are being
[03:26.700 --> 03:31.500]  exploited. We'll talk about software getting attacked, other weak points. And last but
[03:31.500 --> 03:36.600]  definitely not least is user security. We're going to deep dive into the main point of why we're
[03:36.600 --> 03:40.460]  this is for the users, for people to be able to transact securely.
[03:42.320 --> 03:46.980]  We will finish the presentation with thoughts about building this industry, how to make it
[03:46.980 --> 03:54.520]  more mature, what we can do to share the guidelines that people can just pick up and
[03:55.260 --> 03:58.480]  implement in their next projects, the tools that still need to be developed,
[03:58.480 --> 04:00.860]  as well as how we can build up our community.
[04:02.440 --> 04:09.200]  So let's begin first by defining what is blockchain security. I believe it's a brand
[04:09.200 --> 04:15.120]  new field. It's a new discipline of information security with a mission of securing and defending
[04:15.120 --> 04:23.540]  the cryptocurrency ecosystem. What is cryptocurrency ecosystem? We, again, I mentioned users are at the
[04:23.540 --> 04:30.580]  core of it. We have a variety of assets, both layer one and layer two. So smart contracts and
[04:30.580 --> 04:37.220]  all of that. So nodes, wallets, smart contracts are all within the scope of this field. Of course,
[04:37.220 --> 04:44.520]  exchanges, a variety of people choose to delegate and use centralized points of
[04:45.060 --> 04:51.380]  storage instead of holding all the keys themselves. And a variety of attacks and
[04:51.380 --> 04:56.570]  security implications that that brings, including what are the issues with cold hot storage,
[04:57.090 --> 05:01.430]  the incidents that are happening in this world and other issues.
[05:03.430 --> 05:08.230]  So some of the threats that we'll cover throughout this talk, we'll talk a lot about malware,
[05:08.230 --> 05:13.150]  just because of my background, we'll cover how it's affecting both the assets where
[05:13.150 --> 05:19.190]  they're getting backdoored, malware attacks against users themselves, the ransomware and
[05:19.190 --> 05:24.870]  the miners and all that good stuff, as well as how it affects exchanges. We'll go through fraud
[05:24.870 --> 05:30.010]  and scam schemes that are perpetrated against users. We'll talk about what are the losses,
[05:30.010 --> 05:34.310]  what can we do to defend ourselves against it, make users feel a little bit more comfortable
[05:34.310 --> 05:40.110]  and safer. We'll talk about network attacks. So we'll dive into nitty gritty technical details
[05:40.110 --> 05:47.670]  of attacks against a variety of different chains and lessons that we can learn from them.
[05:48.150 --> 05:53.490]  We'll talk about phishing attacks against exchanges and users, and definitely about
[05:53.490 --> 05:58.650]  bad actors, who are the people behind those threats, what can we learn, how we can better
[05:58.650 --> 06:05.250]  defend ourselves against them. So let's first dive into the exchange security.
[06:06.790 --> 06:11.130]  I mean, last year, if you've been paying attention in 2019, there were so many incidents
[06:11.130 --> 06:16.510]  when one exchange after another was falling down with millions and millions of dollars lost
[06:16.510 --> 06:22.450]  from the hot wallet theft. This year, what I'm observing is something different, is that we're
[06:22.450 --> 06:27.070]  seeing two incidents from BlockFi and CoinCheck, where the attackers chose not necessarily to go
[06:27.070 --> 06:33.310]  after the, you know, just grab the coins and run off. Instead, they were content with just getting
[06:33.310 --> 06:39.430]  to PII data. So we're talking about emails, addresses, other personally identifiable
[06:39.430 --> 06:45.590]  information from the customers. So the first incident that I'm going to cover is BlockFi,
[06:45.590 --> 06:52.810]  and they were good at publishing the incident reports fairly quickly. However, what
[06:52.810 --> 06:56.490]  they described as the reason, the root cause for the attack, is that one of their employees was
[06:56.490 --> 07:04.050]  SIM-ported. SIM-ported to access the internal portal. So this sounds like something preventable.
[07:04.050 --> 07:11.210]  I mean, if you're defending your internal portal with a phone,
[07:11.210 --> 07:17.490]  you're using 2FA, which is like some kind of SMS or a phone system, it really could have
[07:17.490 --> 07:23.250]  been improved. It's something that could have been avoided. Similarly, CoinCheck reported a
[07:23.250 --> 07:31.330]  loss of 200 customer PII data. And again, the root cause for it
[07:31.330 --> 07:35.690]  was the main registrar was hacked. It's something that could have been avoided by maybe picking
[07:35.690 --> 07:40.970]  someone more secure or trying to find a way how to secure your registration so it wouldn't be
[07:40.970 --> 07:47.950]  hijacked as easily. And of course, this year, we had good old hot wallet theft. So the year
[07:47.950 --> 07:56.830]  started alt-spit with really tiny financial loss. It was only 7 bitcoins stolen and 23 ETH.
[07:57.230 --> 08:02.750]  LulzSec took credit for this compromise. Unfortunately, the exchange shut down as a result,
[08:02.750 --> 08:06.950]  and so we don't really know as much information about what caused it, what was the underlying
[08:06.950 --> 08:13.770]  issue. But it just continues on the trend from last year that these things happen. And this
[08:13.770 --> 08:18.290]  happened early in the year, I believe back in January. A more recent incident was from the
[08:18.290 --> 08:24.410]  Kasha exchange, which reported a loss of 336 bitcoins. And again, the reasoning that they
[08:24.410 --> 08:29.970]  described was that their employee was using a personal laptop to conduct official business.
[08:29.970 --> 08:34.910]  So they were running OTC desk from their personal machine, which apparently got malware on it,
[08:34.910 --> 08:39.370]  and the attacker was able to get away with the keys. Again, something that could have been
[08:40.110 --> 08:47.010]  avoided. So some insights, some observations that we're seeing so far. Are exchanges getting
[08:47.010 --> 08:52.350]  more secure? I think so. We're observing a decrease in the number of incidents. Back in
[08:52.350 --> 08:57.150]  2019, it was absolutely insane where we had multiple exchanges sometimes compromised within
[08:57.350 --> 09:02.610]  a single week. So far, we're seeing four exchanges with only two of them, resulting in a direct
[09:02.610 --> 09:10.570]  monetary loss. Speaking of damage, financial damage itself, the total amount of loss was in
[09:11.250 --> 09:19.550]  $175 million. Back last year, we're almost six months into the year and the total losses so
[09:19.550 --> 09:25.270]  far only $4 million. So the financial damage is going down. What's also very interesting to see
[09:25.270 --> 09:31.070]  is that folks are very open about the compromises. They release incident reports within 24 hours.
[09:31.070 --> 09:38.750]  They tell exactly who is affected, what was the issue. So that response is just really good to see.
[09:39.890 --> 09:44.170]  On the other hand, as I mentioned, the types of incidents that could have been really easily
[09:44.170 --> 09:51.030]  avoided. SIM swapping, that could have been locked down ahead of time. Letting people,
[09:51.030 --> 09:58.510]  employees run official work on unmanaged personal laptops is just a very risky thing to do.
[10:00.410 --> 10:05.530]  Another trend is the attackers going after more than just HawkWallet, not more than just
[10:05.530 --> 10:11.410]  the coins themselves. So I imagine that whatever PII they stole on Monday, come Monday, they will
[10:11.410 --> 10:16.910]  turn around and try to perform SIM swapping attacks. In fact, there was an article, I believe,
[10:16.910 --> 10:20.410]  where there was an interview with the attackers where they explicitly said that, well, you know
[10:20.410 --> 10:26.050]  what, we could, the best way for us to monetize is to actually just to start SIM swapping instead
[10:26.050 --> 10:32.590]  of trying to sell that data or using any other type of attack. So this is something we may see
[10:32.590 --> 10:40.890]  more in the future. Next, let's talk about the asset security, specifically security of the
[10:40.890 --> 10:46.510]  protocols. We're talking about the interaction between different chains and nodes and all of
[10:46.510 --> 10:53.850]  that. Well, the best example are the variety of 51% attacks, which have been always happening,
[10:53.850 --> 11:00.390]  continue happening. First, we'll cover two incidents with Bitcoin Gold. So the first
[11:00.390 --> 11:07.410]  incident was back in January 23rd and 24th. So there were in fact two 51% attacks back-to-back.
[11:07.410 --> 11:15.450]  It resulted in 29 block re-ORC, which is fairly sizable, and it definitely resulted in a double
[11:15.450 --> 11:23.690]  spin. So this is unfortunate. This is something that we observed happening for a while. Any
[11:23.690 --> 11:31.730]  coin which is relatively lower hash power and has a hash power available for sale that you can
[11:31.730 --> 11:38.870]  easily rent on something like NiceHash is getting a 51% attack. What's interesting is the second
[11:38.870 --> 11:45.170]  incident on July 10th is that the attacker apparently once again tried to rent out some
[11:45.170 --> 11:50.110]  hashing power on NiceHash. But in this case, the miner who rented out their capacity apparently
[11:50.110 --> 11:56.630]  figured out they're doing something bad and was able to notify Bitcoin Gold developers. So what
[11:56.630 --> 12:02.610]  they did in response to that was fascinating and potentially trend for the future is that they
[12:02.610 --> 12:09.470]  contacted miners in secret and distributed a modified piece of node software which had a
[12:09.470 --> 12:15.090]  checkpoint. That checkpoint essentially invalidated whatever new chain that the attacker was mining
[12:15.090 --> 12:21.210]  in secret. So what happened was once the attacker actually published the reorg
[12:21.210 --> 12:26.910]  chain, it was not accepted by the network. So they wasted all their money on NiceHash and all
[12:26.910 --> 12:34.630]  their efforts. Bitcoin Gold published their report about what happened, what they did to defend the
[12:34.630 --> 12:42.810]  network. This is concerning and this is interesting also in two ways. On one side,
[12:42.810 --> 12:48.270]  it's great that they were able to catch it, but this was only done because one of the NiceHash
[12:48.270 --> 12:53.410]  miners was vigilant enough to be able to notify them. So this could have been just as easily
[12:53.410 --> 13:00.270]  missed. Depending on how you view those networks introducing checkpoints into your protocol,
[13:00.270 --> 13:06.650]  secretly communicating with miners, it depends on your specific looks and on decentralization,
[13:06.650 --> 13:12.610]  that may be considered by some as something that we don't want to see. But it worked in this case
[13:12.610 --> 13:17.490]  and we'll in fact see later on when we talk about Vertcoin, it is once again something that repeated
[13:17.490 --> 13:23.890]  where developers of Node software are communicating with miners in order to help secure the network.
[13:24.270 --> 13:29.130]  Another interesting trend about this particular attack is that the reorg was massive. It was
[13:29.130 --> 13:36.370]  1300 blocks reorg. So the attackers are willing to spend and invest significant funds into their
[13:36.370 --> 13:43.970]  attacks. In fact, the most recent incident, which is still ongoing, is starting August 1st,
[13:43.970 --> 13:53.030]  is a massive 3500 block reorg, the first of two, where an attacker apparently spent more than 200k
[13:53.030 --> 14:00.030]  on NiceHash to rent capacity in order to double spend and exchange. So in this, in the slide,
[14:00.030 --> 14:05.330]  I'm only listing the first incident. There was in fact yet another reorg attempt, successful reorg
[14:05.330 --> 14:12.270]  attack on the Ethereum Plastic Network with another massive 4000 block reorg.
[14:13.350 --> 14:18.970]  So some of the insights in this is that these types of attacks will continue. Any coin which
[14:18.970 --> 14:25.630]  has easily rentable GPU capacity that you can rent on NiceHash or something that you can
[14:25.630 --> 14:34.530]  repurpose from another coin, they will be attacked. They're under a risk of getting attacked.
[14:36.310 --> 14:41.590]  What's another interesting observation, what Bitcoin Gold did with working with miners and
[14:41.590 --> 14:47.650]  kind of trolling the attackers by not saying to everyone, like, hey, we know there's an attacker
[14:47.650 --> 14:55.250]  and they're about to release their secret chain anytime now. They actually waited for the attacker
[14:55.250 --> 15:01.790]  to waste their capacity and their funds until they found out, like, wow, okay, this was all
[15:01.790 --> 15:09.790]  wasted effort. So what I covered before were traditional 51% attacks against proof of work
[15:09.790 --> 15:17.610]  networks. What's interesting happening on the blockchain networks today are, is that there's
[15:17.750 --> 15:24.710]  a trend towards shifting into proof of stake consensus algorithms. So what I'll cover are
[15:24.710 --> 15:29.630]  two different coins, so Steemit incident and the Ethereum incident, and explain how they're
[15:29.630 --> 15:35.010]  potentially trend setting and something that we may see more in the future rather than just more
[15:35.010 --> 15:44.050]  and more 51% attacks. So on the Steemit side, I guess just to summarize the incident, Justin Sun
[15:44.050 --> 15:53.370]  from Tron purchased the Steemit coin. There was a disagreement over how to manage vast assets of
[15:53.370 --> 15:59.490]  frozen funds that were initially pre-mined since the beginning of Steemit. The way that this
[15:59.490 --> 16:04.630]  disagreement was addressed was not through negotiation and trying to find some kind of
[16:04.630 --> 16:14.690]  agreement, but in fact it was on the Tron side, they decided to attack the coin by taking over
[16:14.690 --> 16:21.130]  its delegated proof of staking algorithm. So if you're familiar with proof of stake algorithm,
[16:21.130 --> 16:26.650]  the more coins you have, you can take those coins, you can lock them up somehow to give you some
[16:26.650 --> 16:33.930]  voting power. So you can, this is what's called staking, in order to produce blocks or vote for
[16:33.930 --> 16:41.430]  whatever unchained action. So some coins use governance for that. In the delegated proof
[16:41.430 --> 16:49.950]  of stake systems, you don't vote for blocks yourself directly. Something, for example,
[16:49.950 --> 16:56.050]  in ETH 2.0, you need to lock up 32 ETH and you can vote on blocks and can validate blocks.
[16:56.050 --> 17:03.690]  With delegation, you in fact delegate a set of validators and you empower them and you entrust
[17:03.690 --> 17:10.270]  them to validate and produce blocks. So this is the system used in Steemit, EOS, and other coins.
[17:10.790 --> 17:17.330]  So what happened in this particular incident is that Tron colluded with a number of large
[17:17.330 --> 17:22.110]  exchanges which were holding vast amounts of Steemit coin in order to gain the controlling
[17:22.110 --> 17:28.410]  package of the asset. Once they got that, they were able to vote in a controlling set of
[17:28.410 --> 17:33.250]  validators, which allowed them to basically control the network. They were empowered to
[17:33.250 --> 17:38.690]  set what are the consensus rules. Once they gained that right, they were able to push an
[17:38.690 --> 17:45.610]  updated node software, which unfroze through basically a hard fork, unfroze those funds,
[17:45.610 --> 17:52.930]  which were from the initial pre-mine, which absolutely gave Tron a controlling package of
[17:52.930 --> 17:57.790]  the asset in the system where no one could really challenge them and they were able to hold on to
[17:57.790 --> 18:07.620]  their power indefinitely. Taking the ethics aside, there are arguments on both sides that, you know,
[18:07.620 --> 18:12.320]  why did this have to break down into a technical attack when something that could have been agreed
[18:12.320 --> 18:18.900]  upon just by dialogue? What's interesting about this, this is the first case of a proof-of-stake
[18:18.900 --> 18:26.220]  attack and we could see how it played out. The way that it played out was very quickly.
[18:26.220 --> 18:32.140]  Between the time that Tron was able to get the controlling package of Steemit coins, to
[18:33.080 --> 18:39.260]  pushing their own set of validators, to pushing a hard fork, to unfreeze funds, to taking those
[18:39.260 --> 18:45.680]  funds and, you know, multiplying how much voting power they have, it didn't take months or even
[18:45.680 --> 18:52.020]  weeks, it took hours. So it was a highly coordinated attack. It was executed very precisely and
[18:52.020 --> 19:03.240]  effectively. So this was a fascinating example. On the Ethereum side, we're, again, Ethereum is
[19:03.240 --> 19:06.800]  something that has massive hash power, so we're not going to see, highly unlikely we're going to
[19:06.800 --> 19:13.180]  see 51% attacks, but there's still a variety of things that people do, such as mempool manipulation.
[19:13.360 --> 19:19.860]  When there was a black swan event, when the price of Ethereum crashed and a bunch of
[19:19.860 --> 19:25.640]  MakerDAO auctions were starting to get liquidated, there was apparently a mempool attack where they
[19:25.640 --> 19:33.860]  tried to cause a high degree of congestion so that some individuals were able to create a number of
[19:33.860 --> 19:40.500]  liquidation bids for nothing, zero bid liquidations, and be able to win them because
[19:40.500 --> 19:45.000]  they essentially did not have any competition because the network was congested. This is
[19:45.420 --> 19:50.480]  a very interesting approach. We've seen mempool attacks before, but this is interesting how we are
[19:51.360 --> 19:55.420]  manipulating the underlying protocol, underlying Ethereum network, in order to attack
[19:56.260 --> 20:00.260]  higher level smart contracts and DeFi projects as well.
[20:01.100 --> 20:07.400]  So some network security insights from what we've seen is that Steemit, that opens up a new era of
[20:07.400 --> 20:12.000]  proof-of-stake attacks and governance attacks. Instead of being worried that someone will
[20:12.000 --> 20:18.880]  buy up a whole bunch of miners or mining capacity, hash power capacity on NiceHash, now the power is
[20:18.880 --> 20:24.560]  in the exchanges. So exchanges control the most coins, exchanges colluding together may decide to
[20:24.560 --> 20:32.920]  attack a chain. So this is something that we have to be on the lookout for now. Attackers are getting
[20:32.920 --> 20:40.060]  more creative as well, so mempool manipulation in order to attack a DeFi project is something
[20:40.060 --> 20:47.470]  interesting that we'll likely see as well. Let's switch gears a little bit and instead of
[20:47.470 --> 20:53.190]  talking about asset security on the protocol side, let's talk about the underlying software itself.
[20:53.190 --> 20:58.830]  In the end, it's all abstract, it all works in the cloud, but what's actually working,
[20:58.830 --> 21:05.810]  the actual logic and code that runs is a node software itself. Nodes are complex
[21:07.190 --> 21:13.830]  pieces of software and the inevitable that they will have bugs and vulnerabilities. So a few
[21:13.830 --> 21:19.950]  interesting incidents that I want to cover so far this year, two of them happen on the testnet,
[21:19.950 --> 21:25.450]  so I'll start from left to right. So the Solana network, there were no issues in the protocol
[21:25.450 --> 21:34.110]  itself. So the design, I believe it uses a BFT-like system. The issue was in the implementation,
[21:34.110 --> 21:39.570]  there was a flaw, there was a vulnerability in the way that it failed to, the node software
[21:39.570 --> 21:46.150]  failed to validate transactions, which essentially allowed somebody to print 500 million Solana coins.
[21:48.190 --> 21:53.850]  On the mainnet project, so the Tendermint, this is the underlying consensus library used
[21:53.850 --> 22:00.510]  by projects like Cosmos and others, a denial of service vulnerability was discovered, which
[22:00.510 --> 22:07.470]  essentially allowed someone to halt the entire network. And again, this was done not because
[22:07.470 --> 22:14.570]  of some flaw in the protocol, it was because of nodes failing to validate specially crafted
[22:14.570 --> 22:21.410]  blocks. The last example is the inflation bug. Those are particularly dangerous because they
[22:21.410 --> 22:27.470]  affect the entire ecosystem. Luckily, this one was discovered again on the testnet where 9 billion
[22:27.470 --> 22:35.130]  file coins were minted. This was patched and did not affect the mainnet. But you can see like the
[22:35.130 --> 22:39.530]  vulnerability, there are only three examples that I'm listing here, but the vulnerabilities in node
[22:39.530 --> 22:47.570]  software can have severe implications for the market. On the wallet side, again, any piece of
[22:47.570 --> 22:54.890]  software will have vulnerabilities. Monero wallet failed to validate specially crafted coinbase
[22:54.890 --> 23:01.710]  transactions to be specific, which resulted in it appearing as if you received more of Monero than
[23:01.710 --> 23:06.870]  was actually sent. This is something similar to, if you recall, there were a whole bunch of
[23:06.870 --> 23:13.910]  exchanges compromised with the ripple. There was a special flag which is basically telling you
[23:13.910 --> 23:20.650]  how much you are vouching to send as opposed to how much you actually are going to send. So there's
[23:20.750 --> 23:31.510]  a potential for exchanges or individual wallet owners to incorrectly credit whoever is sending
[23:31.510 --> 23:36.670]  them funds. Lightning network, it's still very much alpha system, so it continues to have
[23:36.670 --> 23:40.790]  vulnerabilities discovered and patched. There are a lot of papers getting published,
[23:40.790 --> 23:46.050]  so this is actually a good sign that people are looking into it and finding flaws early on.
[23:46.490 --> 23:51.510]  Now Argent wallet, that was an interesting bug that was responsibly disclosed by OpenZeppelin
[23:51.510 --> 23:58.370]  and effectively patched by the Argent folks, is that it allowed users to basically
[23:58.370 --> 24:06.210]  create a kind of recovery mechanism using specialized guardian nodes. And in rare occasions
[24:06.210 --> 24:11.290]  when such nodes were not properly defined, it allowed anyone to take over those wallets.
[24:11.410 --> 24:15.850]  Once again, this was patched, but an example of vulnerabilities in wallets.
[24:17.490 --> 24:22.090]  What's more interesting are not the vulnerabilities that are discovered and patched.
[24:22.650 --> 24:28.050]  This is normal. What's more interesting are intentional backdoors that are introduced in
[24:28.050 --> 24:33.390]  both wallets and node software. So the first incident I'm going to cover happened in the
[24:33.390 --> 24:41.610]  Trinity wallet. We've seen backdoored wallets for a while. Last year I talked a lot about
[24:41.610 --> 24:48.630]  the Electrum wallets getting backdoored. The way they attacked the Trinity wallet was not directly,
[24:48.630 --> 24:56.010]  after the main repository itself. Instead, they were going after the third-party dependency.
[24:56.010 --> 25:00.110]  So the third-party dependency on which Trinity wallet was relying to was patched to steal
[25:00.110 --> 25:05.770]  users' keys. That was included in the main repository, and any user downloading and
[25:05.770 --> 25:13.510]  using this was heading at this asset stolen. Ravencoin incident was even more vicious.
[25:13.510 --> 25:19.950]  On July 4th, an inflation bug was discovered, and an emergency patch was issued to a variety
[25:19.950 --> 25:29.710]  of nodes and distributed to miners. And this is something that initially maybe was just a
[25:29.710 --> 25:34.910]  vulnerability. Every once in a while you discover those things, until the point they realized that
[25:34.910 --> 25:40.340]  the bug was intentionally introduced. It was introduced back early in the year, in January,
[25:41.100 --> 25:47.380]  by an account which was a throwaway GitHub account. The patch appeared to be a very
[25:48.580 --> 25:55.000]  innocent-looking commit, which allowed you to be more verbose about the type of errors
[25:55.000 --> 26:02.780]  that you're getting. So it snuck by the core maintainer's eyes. They were not able to detect
[26:02.780 --> 26:09.960]  that. And for months now, they were slowly minting. There was a script running that was slowly minting
[26:10.340 --> 26:16.820]  RVN coins. So in total, 300 million RVN coins were minted over time, and unfortunately also
[26:16.820 --> 26:23.920]  sold on exchanges. So this was a successful inflation bug that was maliciously introduced
[26:23.920 --> 26:30.820]  and exploited. These are particularly scary, and I'm sure we'll see this again and again,
[26:30.820 --> 26:35.340]  because they attack the whole ecosystem rather than individual user or piece of software.
[26:37.880 --> 26:45.780]  So some insights on node and wallet software security. Vulnerabilities are still very rare.
[26:45.780 --> 26:52.080]  We only talked about four flaws here, and one was introduced intentionally. The question and
[26:52.080 --> 26:57.940]  challenge to you, do we really have enough eyes looking at nodes, looking for the vulnerabilities,
[26:57.940 --> 27:03.500]  and being able to patch them? There are bug bounties which are available, but I wonder if
[27:03.500 --> 27:07.900]  there are enough participants and enough folks which are really pushing the limits of how secure
[27:07.900 --> 27:13.900]  that software is. Ravencoin stealth commit and Trinity supply chain threats. This will likely
[27:13.900 --> 27:19.280]  happen again. Attackers are highly motivated. There's a direct financial profit in attacking
[27:19.280 --> 27:29.440]  these pieces of software. So this will likely repeat. So switching gears a little bit on the
[27:29.440 --> 27:36.020]  layer two issues, which is smart contracts, that's even more concerning. There were, I mean,
[27:36.020 --> 27:40.880]  I'm listing here 10 incidents. There was one more that happened in the last few days, which is not
[27:40.880 --> 27:48.660]  included here. As DeFi projects are getting more and more popular, this is complex software,
[27:48.660 --> 27:52.780]  which once again has a lot of different vulnerabilities which are constantly getting
[27:52.780 --> 27:58.000]  discovered. I'm not going to cover all of these, just it would take a whole hour on its own,
[27:58.000 --> 28:04.960]  but I'll focus on just three of these. So we'll start left to right. The first incident that
[28:04.960 --> 28:12.840]  basically opened the year was the VZX DeFi project back in February. And the way that it started out
[28:12.840 --> 28:18.880]  was there was a margin trading vulnerability that was exploited. 1 million worth of ETH was stolen.
[28:19.000 --> 28:24.380]  What was interesting about this particular incident is that the attacker used flash loans
[28:24.380 --> 28:30.540]  in order to amplify the attack. Flash loans is basically a mechanism where you can borrow
[28:30.540 --> 28:39.240]  X amount of an asset and return it back to the initial point all within the same transaction.
[28:39.240 --> 28:45.200]  So you're paying non-existent or minimal fees for doing that and allows you to execute an attack
[28:45.200 --> 28:50.380]  in between since you have all these assets available to you in order to execute the attack.
[28:50.380 --> 28:57.640]  So this kind of defeats a kind of a paradigm that we had before where we think that if it costs so
[28:57.640 --> 29:04.540]  much money to attack something, that it makes it less likely that someone will actually execute
[29:04.540 --> 29:11.480]  the attack. But with flash loans, attackers have really minimal risk to basically the transaction
[29:11.480 --> 29:17.740]  reverting, then so be it, they don't lose anything. And they can return those funds and whatever they
[29:17.740 --> 29:23.620]  loaned and they don't really lose anything. But if they win, then they win big. So in this case,
[29:23.620 --> 29:29.720]  they won one million dollars worth of ETH. And we start seeing this flash loans approach happen
[29:29.720 --> 29:35.720]  again and again throughout the year from this point on. Another incident which is interesting
[29:35.720 --> 29:42.680]  to note is the balancer project. So again, 500k was drained from multi-token pools. This one is
[29:42.680 --> 29:50.000]  interesting because it wasn't the vulnerability in the balancer smart contract itself, it was in
[29:50.000 --> 29:54.900]  the way that one complex project was interacting with another complex project. In this case, the
[29:54.900 --> 30:02.440]  developers could not predict that you could use deflationary tokens which change the logic to
[30:02.440 --> 30:09.180]  the attacker's advantage. So when on its own, like in all their testing with traditional token
[30:09.180 --> 30:15.680]  systems, then it works as expected. So this is something that is well known in the traditional
[30:16.220 --> 30:20.880]  computer security practice and something that needs to be applied to DeFi projects as well.
[30:20.960 --> 30:27.080]  Another gotcha in this one is that the vulnerability was reported in a bug bounty report.
[30:27.080 --> 30:32.300]  So the good news is bug bounties work. I think a lot of the projects in the DeFi space do have
[30:32.300 --> 30:38.100]  bug bounties. It's just, it's very hard to triage those things, very hard to find the ones which are
[30:39.640 --> 30:46.020]  real examples of an attack and or which ones are not as good quality. So this is something
[30:46.020 --> 30:53.420]  to keep in mind when running your own bug bounties. The last example, and again this is something that
[30:53.980 --> 31:01.720]  example here repeated in other incidents, is a Bancor project where developers were notified
[31:02.800 --> 31:08.740]  that they had a vulnerability, so they learned there was an issue. And the way that they
[31:08.740 --> 31:16.800]  approached to protect their users is by attacking their own coin, their own smart contract,
[31:16.800 --> 31:21.080]  with the same ways that an attacker would, it's just that with the purpose of actually
[31:21.080 --> 31:26.200]  preserving users funds. But what was interesting here is that arbitrage bots, apparently
[31:26.760 --> 31:31.840]  they're a piece of software constantly monitoring the Ethereum network, seeing that
[31:31.840 --> 31:38.940]  if there's some large activity happening and it started automatically replaying it, trying to
[31:40.140 --> 31:44.420]  make arbitrage opportunities, exploit arbitrage opportunities there,
[31:44.420 --> 31:49.920]  picked up on developers trying to secure users funds and were automatically able to exploit
[31:49.920 --> 31:55.300]  the project in the same way that the developers were doing it. So it's fascinating to see those
[31:55.300 --> 32:02.280]  automated pieces of software that just piggyback off existing attacks.
[32:04.120 --> 32:10.360]  So some insights on the Layer 2 smart contract security. This is going to be the year of DeFi
[32:10.360 --> 32:18.560]  hacks. Both in the amount lost, the number of vulnerabilities discovered, unfortunately
[32:20.120 --> 32:26.140]  the number of incidents is on the rise. So it will likely continue seeing that this year.
[32:27.740 --> 32:33.500]  The bug bounty programs, they work and developers are catching bugs early, which is a good sign.
[32:33.520 --> 32:38.320]  And I'll explain to you why in a bit when we talk about tooling and guidelines.
[32:39.800 --> 32:45.080]  But the interesting trend is by Bancor is that we often have to hack ourselves to secure funds.
[32:45.920 --> 32:52.740]  Complex code will continue having bugs and complex interactions between different projects
[32:52.740 --> 32:57.740]  are also something that we need to think about as this is the whole point of DeFi is that you're
[32:58.600 --> 33:02.780]  creating links between vast smart contract projects out there.
[33:04.990 --> 33:10.750]  So I promised to talk about user security and we had a few major incidents that we're going to cover
[33:10.750 --> 33:20.630]  shortly from Twitter and so on. But this is sometimes not as exciting of a field to look at,
[33:20.630 --> 33:27.950]  but just as critical as any other discipline. So we're going to talk about cryptocurrency malware,
[33:29.010 --> 33:34.310]  variety of scam and fraud schemes, as well as just talk a little bit like who are the
[33:34.310 --> 33:38.550]  bad actors? Who is doing that? Who are the new players in this arena now?
[33:39.650 --> 33:46.120]  So first, let's talk about the crypto mining malware. And this is how I got into partially
[33:46.470 --> 33:52.950]  into cryptocurrencies is that essentially for a year, I was reversing nothing but ransomware
[33:53.650 --> 34:02.010]  and crypto mining samples. For on the crypto mining side, it was always the Monero folks,
[34:02.010 --> 34:08.530]  they are setting up their miners XM rig into anything that can possibly run XM rigs.
[34:08.530 --> 34:13.650]  If they can run it on toasters, they probably would run it on toasters. So far this year,
[34:13.650 --> 34:22.130]  it's not as bad as Russian scientists mining on nuclear stations. But still,
[34:22.130 --> 34:28.430]  five EU supercomputers were hacked in order to run Monero miners. We had multiple issues with
[34:28.430 --> 34:35.170]  Docker where attackers were scanning vulnerable API endpoints to take over existing Docker images
[34:35.170 --> 34:40.790]  or just publishing their own backdoored Docker images on the Docker hub, which would also
[34:41.410 --> 34:46.470]  mine Monero in the background. And of course, there's just never ending stream of
[34:48.130 --> 34:55.790]  Windows desktop malware. One example is Lucifer, which is just, it's an arsenal of,
[34:55.790 --> 34:58.030]  it was a whole exploit kit built into it,
[34:58.030 --> 35:01.910]  which can self propagate attack other Windows machines and spread on its own.
[35:03.990 --> 35:11.710]  So on the ransomware side, it seems like this is an ongoing threat. I'm not sure yet if the
[35:12.430 --> 35:19.330]  trend is going down yet, but so far we had UCSF, which was attacked for 100 Bitcoin or so,
[35:19.330 --> 35:25.350]  Travelex earlier this year, 285. Just a few days ago, we learned that Canon was attacked
[35:25.350 --> 35:32.290]  with ransomware by, I believe, the Maze crew. We don't know. They're known to ask for Bitcoin
[35:32.290 --> 35:40.130]  as a compensation, as a ransom. So we'll find out when the incident concludes. And of course,
[35:40.130 --> 35:46.090]  it seems like every city in Florida is getting ransomware on their machines. So an example of
[35:46.090 --> 35:54.290]  city Riviera had to pay 65 Bitcoins to get their systems back online. Yeah, so this sucks. This is
[35:54.290 --> 35:59.930]  unfortunate. This is a threat that we have to worry about, especially on systems like UCSF
[36:00.870 --> 36:06.350]  in the time of COVID. But this is something we'll continue seeing. Monero miners will
[36:06.350 --> 36:15.170]  hack anything available to them to install the crypto mining malware. Ransomware appears to be
[36:15.170 --> 36:20.030]  on the decline, but it's too early to say we're still only halfway through the year to establish
[36:20.210 --> 36:27.870]  a trend. Crypto giveaways. Well, I mean, we all talked about the Twitter hack, which was
[36:27.870 --> 36:36.170]  absolutely epic. I don't want to steal Victor's keynote presentation tomorrow, but he'll dive into
[36:36.170 --> 36:43.890]  more details. But just to summarize, 130 accounts were hijacked on Twitter from exchanges to
[36:43.890 --> 36:49.070]  celebrities to corporate accounts. The way they were hijacked is that the attackers were able to
[36:49.070 --> 36:54.950]  basically get access to the internal tools through social engineering of Twitter employees.
[36:55.470 --> 36:58.730]  And that's kind of fascinating. The best thing they could think of doing it
[36:59.670 --> 37:05.930]  was running a BTC giveaway scam. So on one side, this is really bad. On the other side,
[37:05.930 --> 37:13.830]  it could have been much worse. Elon Musk is getting no break from YouTube scammers. So
[37:13.830 --> 37:21.090]  anytime you see a SpaceX feed, there's likely going to be send BTC notes everywhere. So sorry,
[37:21.090 --> 37:31.850]  Elon. MLM scams are still continuing on as before. So we started with the BitConnect and moved on to
[37:31.850 --> 37:37.250]  $4 billion enterprise plus token. And now the latest and greatest is Chinese police just busted
[37:37.910 --> 37:46.350]  wall token scammers who managed to get $1 billion worth of crypto from 700,000 victims.
[37:49.120 --> 37:56.660]  What's more interesting is not just the existing scams or the ones that I covered before, but the
[37:56.660 --> 38:02.520]  trends of what are we going to see attackers experimenting with, which may become something
[38:02.520 --> 38:09.800]  more prevalent. So one example is the MakerDAO phishing attack. And that is the first example
[38:09.800 --> 38:16.960]  of a Web3 phishing scam. So you think that you are exchanging side to die.
[38:19.980 --> 38:25.880]  You are interacting with MetaMask or so you think you're putting in your keys and then bam,
[38:25.880 --> 38:30.840]  all your coin is stolen. So this is something that was reported early in the year and something
[38:30.840 --> 38:39.060]  potentially we'll see in the future. The Justin Sun deepfake scam, that was fascinating. Someone
[38:39.060 --> 38:47.300]  essentially recorded a video of Justin Sun doing some kind of investor scam, trying to get people
[38:47.300 --> 38:54.700]  to send money to this unknown entity. And they played that video on a Skype call complete with
[38:54.700 --> 39:01.280]  Justin cuffing and it looked very real and also very fake and strange at the same time. They
[39:01.280 --> 39:07.160]  faked his passport to show for some reason. If you want to search that on YouTube, it's a
[39:07.160 --> 39:12.120]  fascinating video to watch. It's still not something that was successful, but
[39:12.120 --> 39:16.860]  it's kind of fascinating that scammers are even exploring deepfakes for that purpose.
[39:17.320 --> 39:25.820]  The last example is the trust wallet scam. So we see just a barrage of backdoored fake wallet
[39:25.820 --> 39:32.540]  software everywhere. If you search on Google, if you search in the app stores, what's
[39:32.540 --> 39:39.460]  interesting about this case is not the wallet itself, it's how it was addressed, which is a
[39:39.460 --> 39:45.660]  security researcher was able to actually attack the infrastructure, a fairly broken infrastructure
[39:45.660 --> 39:49.820]  on the attacker side to start recovering the funds. And this is an interesting trend of
[39:50.460 --> 39:54.960]  basically folks taking things into their own hands to help users.
[39:56.420 --> 40:01.260]  So a quick note about the bad actors. So we already talked about the individual attackers,
[40:01.260 --> 40:06.680]  so the Twitter folks, three were already arrested, one in Florida, one in UK.
[40:07.820 --> 40:10.640]  So we'll call them lone wolf type attackers.
[40:11.560 --> 40:17.700]  Insider threats such as Kasha employee who got malware in their machine and unfortunately
[40:18.900 --> 40:25.980]  resulted in funds loss. Let's talk about APTs. So we're familiar with Lazarus Group,
[40:25.980 --> 40:32.220]  so that's a North Korean APT, and a whole variety of financial ransomware groups who
[40:32.220 --> 40:36.660]  basically attack anything with financial gain. What's interesting this year is the CryptoCore
[40:36.660 --> 40:45.280]  APT, which is our very own dedicated cryptocurrency exchange advanced persistent threat.
[40:45.940 --> 40:54.380]  So with a bull market maybe happening sometime in the future and the renewed interest,
[40:55.220 --> 40:59.300]  we're probably going to see more dedicated groups like this as this becomes highly profitable
[40:59.300 --> 41:08.400]  enterprise. So some insights. One is that users are taking things into their own hands.
[41:08.660 --> 41:13.960]  So we have Woz who's suing YouTube for being too slow at taking down the giveaway scams.
[41:14.020 --> 41:21.680]  We have Michael Turpin suing AT&T to basically compensate him for allowing the sim swap to happen
[41:21.680 --> 41:27.540]  in the first place. We have researchers like Harry Denley reverse hacking scammers to get
[41:27.540 --> 41:34.160]  users' funds back. While it does sound good on one hand that people are really pushing their
[41:35.060 --> 41:40.880]  fighting back against the scammers, I really wish the industry was more mature and we had enough
[41:41.700 --> 41:48.760]  tools on one side, but also user education and guidelines and other security controls available
[41:49.620 --> 41:53.320]  that not as many people would get compromised in the first place.
[41:54.040 --> 42:00.520]  MLM schemes are incredibly profitable. So this year out of all cryptocurrency scams,
[42:01.080 --> 42:08.260]  basically 99% of the take was the Wo token $1 billion scam. In the past,
[42:08.260 --> 42:16.740]  plus token with their $4 billion take, I think controlled a whole 1% of the total Bitcoin supply.
[42:16.740 --> 42:20.320]  So these things are incredibly profitable and will definitely continue.
[42:21.280 --> 42:25.380]  An interesting trend that exchanges are proactively blocking bad addresses to protect
[42:25.380 --> 42:30.220]  their users. So there's always debate of centralized storage versus decentralized storage.
[42:30.280 --> 42:36.540]  That's something that was interesting to observe this year is that exchanges like Coinbase,
[42:36.540 --> 42:43.560]  they were basically blacklisting the attacker addresses immediately to save their internal
[42:43.560 --> 42:48.580]  customers' funds. This is something that could be decentralized as well if you're looking for a
[42:48.580 --> 42:56.120]  project to be able to alert users of doing some kind of unsafe action. And I believe a few
[42:56.120 --> 43:02.600]  projects like MyCrypto are in fact doing that already. Scammers are getting more creative. So
[43:03.300 --> 43:10.540]  the Web3 phishing sites and the deepfake scams, this is fascinating to see. I'm not sure how
[43:10.540 --> 43:16.000]  profitable they are yet, but if they do become profitable at one point, we'll see a very rapid
[43:16.000 --> 43:26.700]  rise of them. So to summarize the state of blockchain security insights that we've seen so
[43:26.700 --> 43:33.280]  far, we talked about the exchange security, the number of hacks and financial damage is decreasing.
[43:33.280 --> 43:38.820]  That's great. On the other side, existing incidents could have been easily prevented.
[43:39.240 --> 43:44.040]  Attackers are going after more than just coins. They're going after PII. They're getting creative.
[43:44.570 --> 43:50.500]  On the asset side, low hash rate GPU mineable proof-of-work coins are getting 51% attack,
[43:50.500 --> 43:55.980]  will continue getting 51% attacked. There was a first example of a proof-of-stake attack,
[43:55.980 --> 44:02.380]  and it was very efficiently executed. We're not finding nearly enough node wallet vulnerabilities.
[44:02.380 --> 44:06.980]  I think there's an opportunity there for independent security researchers to really
[44:06.980 --> 44:13.380]  start looking at that. Nasty backdoors and supply chain attacks against nodes and wallets
[44:14.220 --> 44:19.620]  Again, if you can backdoor a node, you can attack the whole coin as the whole ecosystem.
[44:19.620 --> 44:24.260]  You don't have to go after individual people and you can take basically the whole asset down.
[44:24.260 --> 44:29.920]  So this is highly dangerous, highly critical to start looking at. D5 vulnerabilities are
[44:29.920 --> 44:36.260]  unfortunately on the rise and so are the attacks as the whole ecosystem is becoming more popular.
[44:36.580 --> 44:42.960]  On the user side, I don't see any new threats which are suddenly popped up. It's just a
[44:42.960 --> 44:50.080]  consistent threat from miners, ransomware, fake software, and scammers are still sticking to
[44:50.080 --> 44:54.560]  giveaway scams and MLM schemes. They're getting more creative here and there, but
[44:54.560 --> 45:00.840]  they, I mean, the giveaway scams unfortunately still work. So an opportunity here is to work
[45:00.840 --> 45:07.540]  on more user education to see if we can make users a little bit more secure.
[45:08.720 --> 45:12.360]  So we've seen what the issues are. We've seen what the problems are. Here and there,
[45:12.360 --> 45:16.880]  I dropped some ideas of what you can do to contribute to the field, make it more secure,
[45:16.880 --> 45:23.680]  but really we can look at it more holistically and think of the blockchain security as just a
[45:23.680 --> 45:29.760]  standalone industry that we can build up together. We can grow in terms of maturity, education,
[45:29.760 --> 45:35.580]  projects, and so on. So some things, some ideas that I'm going to cover of what we can do is we
[45:35.580 --> 45:40.500]  can talk about the guidelines and tools, how we can develop those. We can talk about growing the
[45:40.500 --> 45:47.040]  community and specifically you, what is it that you can do today to start applying and contributing
[45:47.040 --> 45:55.680]  to this field? So on the guidelines and tools side, there are a few amazing projects that are
[45:55.680 --> 46:01.280]  available. So on the consensus diligent folks there, they keep on publishing a variety of
[46:01.280 --> 46:07.000]  software to test smart contracts. They publish the SWC, smart contracts, weakness classification
[46:07.000 --> 46:13.760]  registry, where you have a listing of top vulnerabilities, give you a good understanding
[46:13.760 --> 46:18.500]  like what they are, how to prevent them. Trail of bits folks, they're publishing tools one after
[46:18.500 --> 46:23.920]  another. They have the slither echidna. They published a document basically summarizing
[46:23.920 --> 46:30.580]  findings from all of their smart contract security assessments. What are the trends? What are the top
[46:30.580 --> 46:36.180]  issues to look out for? Open zeppelin essentially defined the field of how to write secure smart
[46:36.180 --> 46:40.600]  contracts. I'm seeing a lot of the newer projects, they're just basically verbatim
[46:40.600 --> 46:46.160]  adopting open zeppelin, open zeppelin templates, and they're very secure as a result.
[46:46.320 --> 46:52.360]  Other projects like securing, they published the smart contract security verification standard.
[46:52.520 --> 47:00.360]  NCC group published an OWASP style list top 10 list back in 2018. But unfortunately,
[47:01.260 --> 47:04.960]  it wasn't really maintained for a while. So it would be interesting for them to
[47:05.520 --> 47:10.340]  give new life to this project. Another one is the cryptocurrency security standard.
[47:10.340 --> 47:15.100]  And this one is interesting because if you notice all the previous things that I mentioned,
[47:15.100 --> 47:20.840]  they have to do with smart contracts and Ethereum. This is the only standard and project out there,
[47:20.840 --> 47:27.560]  which attempts to talk more about how to securely generate keys, how to securely store
[47:27.560 --> 47:32.780]  keys in the cold storage. I would love to see this project growing and having a larger impact
[47:32.780 --> 47:38.280]  on the security of exchanges and nodes and wallets and so on.
[47:40.820 --> 47:45.160]  Guidelines and tools are important. If we are to grow this industry, we need to have
[47:45.160 --> 47:50.160]  large collections readily available for anyone who wants to contribute to this field
[47:50.160 --> 47:55.140]  to be able to quickly learn from the mistakes of the past. On the smart contract side,
[47:55.140 --> 47:59.460]  I think we're pretty solid. We have great tooling, we have methodology,
[47:59.460 --> 48:04.260]  we have a variety of companies and consultants who are available to test your smart contracts.
[48:04.260 --> 48:08.260]  So even though there are a lot of DeFi issues which are getting discovered,
[48:08.260 --> 48:13.540]  but there's enough tools and folks that are experts in this field that can address this
[48:13.540 --> 48:21.120]  trend very quickly. On the other hand, we're missing core guidelines, core methodology,
[48:21.120 --> 48:27.960]  and practically no tools to address standalone blockchains. If someone wants to build a new
[48:27.960 --> 48:34.040]  project, what is a good resource that they can read and learn about the failings of the past
[48:34.040 --> 48:38.840]  and how they can learn and correct whatever future designs that they're building?
[48:39.920 --> 48:45.900]  Node configuration operation. Nodes are at the core of any blockchain project. If nodes at some
[48:45.900 --> 48:50.080]  point start having more and more vulnerabilities discovered, then this breaks down everything that
[48:50.080 --> 48:55.660]  is built on top of them. Hot and cold storage security, key management, protocol design,
[48:55.660 --> 49:03.160]  wallet design, innovations in blockchain forensics, and also user security, how to educate users and
[49:03.160 --> 49:08.980]  give them simple guides on how to avoid scams, how to give them tools to quickly protect them
[49:08.980 --> 49:14.140]  against going to bad websites like Google browser style. Like this is dangerous, don't send to this
[49:14.140 --> 49:20.860]  address. One thing that I will be covering later in a separate talk on attacking and defending
[49:20.860 --> 49:26.440]  blockchain nodes is I'm trying to create an OWASP top 10 style listing of what you can do to secure
[49:26.440 --> 49:32.940]  your node infrastructure. But I invite all of you to pick out any one of those items in the list,
[49:32.940 --> 49:40.420]  or if you imagine that you have more things to contribute to this field, and start writing
[49:40.420 --> 49:45.820]  documentation, start writing tools. There's an entire field available that you can develop and
[49:45.820 --> 49:52.800]  work with. On the community side, well, here we are at the Blockchain Village. There are three other
[49:52.800 --> 49:58.080]  conferences which are also available that you can attend, hopefully virtually, throughout the year.
[49:59.000 --> 50:05.040]  But I wonder if there should be more. I imagine that as the community grows and this field grows,
[50:05.040 --> 50:11.780]  we're going to see more and more of these. We have our own competitions. So we have this year,
[50:11.780 --> 50:18.780]  I believe, Victor is hosting a blockchain investigation competition. Last year, we had the
[50:18.780 --> 50:24.080]  Capture the Coin and Chain Heist. There are some challenges which are ongoing, such as OpenZeppelin's
[50:24.080 --> 50:30.280]  excellent EtherNOT. So this is great. On the knowledge sharing side, we have a variety of
[50:30.280 --> 50:36.040]  resources. So you can go on Telegram, Reddit, Discord here for DEF CON, and you can talk about
[50:36.040 --> 50:42.060]  blockchain security. Some newsletters that are also working on distributing, disseminating
[50:42.060 --> 50:47.540]  knowledge. So the one that I'm running is Blockchain Threat Intelligence, where I try to
[50:47.540 --> 50:53.000]  cover every piece of news that is related to this field. Not just related to smart contracts,
[50:53.000 --> 51:00.280]  but just holistically. Exchange security, malware, user scams, and all of that. Consensus Diligence,
[51:00.280 --> 51:04.200]  they're running an excellent smart contract security newsletter. So if you want to raise
[51:04.200 --> 51:11.680]  focus on Ethereum and Layer 2 security, this is the resource to subscribe to immediately.
[51:12.600 --> 51:18.240]  We even have our own shitty movies. So we have Crypto, where we have an AML officer
[51:18.240 --> 51:23.700]  hunting down and investigating blockchains to bring down Russian mafia, and the Money Plane.
[51:23.700 --> 51:28.960]  I'm not sure exactly what's happening there. I think the plot is they're hacking crypto on a
[51:28.960 --> 51:34.620]  plane, which is a fortress and a casino. Point is, we have our movies, we have our media. We
[51:34.620 --> 51:41.520]  made it officially. This is great. So some community insights. We're still a very small,
[51:41.520 --> 51:47.420]  but growing community with unique competitions, gatherings, chat rooms, challenges, tools,
[51:47.420 --> 51:53.800]  projects, and so on. Our community should and will continue growing. What's exciting to see is
[51:53.800 --> 51:59.520]  blockchain security or BlockSec becoming a career option. Even today, you can look on the internet,
[51:59.520 --> 52:04.400]  you can find jobs to do smart contract security testing if you want to. You can do blockchain
[52:04.400 --> 52:10.120]  security engineering, so building projects, securing projects. Cryptocurrency forensic
[52:10.120 --> 52:15.880]  analysis is going to be even more in demand after the Twitter hack. More people will try to
[52:16.900 --> 52:22.440]  exercise this new skill set. So I'm hoping this will grow in the future.
[52:23.800 --> 52:28.540]  The point is, I want to invite you. I want to invite you to contribute to this field.
[52:28.720 --> 52:33.500]  So if you enjoy learning about the nitty gritty technical details, consensus negatives, smart
[52:33.500 --> 52:38.600]  contracts, great. Join BlockSec, contribute to this field. There's plenty of things to explore
[52:38.600 --> 52:43.920]  and do here. If you're a security professional, and you're just tired of finding yet another XSS
[52:43.920 --> 52:50.800]  or SQL injection bug, you want to find some cool new things which are just not fully explored yet,
[52:50.800 --> 52:55.020]  basically be able to define the field. Great, join BlockSec. There are plenty of bugs that
[52:55.020 --> 53:01.200]  need to be found and patched by you. Are you an investigator who is trying to hunt down the
[53:01.200 --> 53:07.240]  fraudsters, wants to understand how the hell do we track down fraud and bad guys on the blockchains?
[53:07.240 --> 53:11.840]  Great, join BlockSec. There are plenty of blockchain analytics companies out there.
[53:12.460 --> 53:17.800]  There's a growing body of investigators who are now capable of doing those tasks.
[53:17.800 --> 53:23.340]  Join them. This is very interesting. Finally, if you're a developer, and you're just looking for
[53:23.340 --> 53:28.040]  an exciting new project, and you really want to make an impact on the open financial system,
[53:28.040 --> 53:34.820]  making that system more secure, contributing it to be more trustworthy by the people using it,
[53:34.820 --> 53:42.580]  is a good way to help bring it about. So with that, join BlockSec, and thank you very much for your time.