Get Into The Attacker's Mindset

Summary

In this video, the speaker delves into the essence of the 'attacker's mindset,' a crucial perspective for uncovering vulnerabilities and bugs in smart contracts. By adopting an offensive approach and actively seeking to disprove security protocols, auditors can significantly boost their success rate in identifying critical flaws. The speaker outlines four key steps to cultivate this mindset, including incentivizing oneself appropriately, believing vulnerabilities exist, collecting 'knobs' or potential vulnerabilities, and combining them to construct exploits. Emphasizing the importance of avoiding pitfalls that undermine this mindset, the speaker provides a real-world example demonstrating how this approach uncovered a critical risk-free trade vulnerability in a perpetuals exchange protocol.

Takeaways

• 😎 Adopting an attacker's mindset is crucial for uncovering vulnerabilities and bugs in smart contracts. Think offensively to find what developers, thinking defensively, may have missed.
• 💰 Incentivize yourself properly to find bugs by structuring your compensation based on the number and criticality of vulnerabilities discovered.
• 🧠 Mentally prepare yourself to believe that bugs and vulnerabilities exist in the codebase you're auditing.
• 📝 While auditing, collect and note down interesting behaviors, missing lines, or any peculiarities in the code ('knobs').
• 🧩 Combine these 'knobs' to construct unique and critical attack vectors, like puzzle pieces.
• ⚠️ Avoid charging upfront fees that remove the incentive to find vulnerabilities, as it may subconsciously convince you of the protocol's security.
• 🚫 Never assume the codebase is secure or agree with the developers' assumptions. Question everything from the ground up.
• 🔍 The example exploit involved delaying order execution by reverting with an 'empty position' error, then toggling the revert condition to execute the order at a favorable price.
• 🤖 Leverage the two-step order execution system by executing orders with outdated prices from when the order was created.
• 🗃️ Join communities like lab.guardianaudits.com to learn from other auditors, collaborate on audits, and access comprehensive smart contract security training.

Q & A

What is the attacker's mindset, and why is it important for smart contract auditing?

The attacker's mindset is a way of looking at code with the intent of breaking as many things as possible, rather than verifying or proving its security. It's important because adopting this mindset makes an auditor more likely to uncover vulnerabilities by actively trying to disprove the protocol's security.

What are the four key steps to get into the attacker's mindset?

1) Incentivize yourself correctly by structuring compensation based on the number and criticality of vulnerabilities found. 2) Personally believe that there are bugs and vulnerabilities in the codebase. 3) Collect 'knobs' or interesting pieces of behavior as you go through the code. 4) Combine the knobs to construct potential exploits.

What are the two critical mistakes that can prevent an auditor from getting into the attacker's mindset?

1) Not getting the incentives right, such as charging all the money upfront regardless of findings, which incentivizes spending as little time as possible on the audit. 2) Not believing that vulnerabilities exist in the codebase, leading to a mindset of verifying rather than attacking.

In the GMX V2 example, what was the first 'knob' or interesting behavior noticed?

The first knob was the two-step execution process, where a keeper executes orders using prices from the block when the order was created. This opened up the potential for a risk-free trade if the execution could be delayed until a more favorable price movement.

What was the second knob discovered, and how did it contribute to the potential exploit?

The second knob was that limit orders that reverted with an 'empty position' error would be retried instead of canceled. This allowed for delaying the execution of the order.

What was the third knob, and how did it enable the risk-free trade?

The third knob was the ability to set the remaining collateral amount to zero while still having non-zero size in USD and tokens. This allowed the order to revert with the 'empty position' error, delaying execution until a favorable price movement occurred.

What was the final knob that allowed toggling the exploit on and off?

The final knob was an if statement that set the initial collateral delta amount to zero if the order size matched the position size. By decreasing the position size to match the order size, this condition could be met, allowing the order to execute without reverting.

How does the provided example demonstrate the importance of combining multiple 'knobs' to construct a successful exploit?

The example shows how several individual behaviors or 'knobs' had to be pieced together strategically to enable the risk-free trade exploit. Each knob on its own was not sufficient, but by combining them in a specific way, a critical vulnerability was revealed.

What advice does the speaker give for finding interesting vulnerabilities and adopting the attacker's mindset?

The speaker advises auditors to be malicious in their approach, actively trying to break things and keeping track of interesting behaviors (knobs) as they go through the code. These knobs can then be combined to construct unique and critical attack vectors.

What resources does the speaker recommend for aspiring smart contract auditors?

The speaker recommends joining the Guardian Audits community (lab.guardianaudits.com) to connect with other auditors and participate in team audits. He also mentions a paid training resource he collaborated on, which aims to provide thorough training in smart contract security auditing.

Outlines

00:00

🧠 Embracing the Attacker's Mindset for Effective Vulnerability Discovery

Owen, founder of Guardian Audits, emphasizes the importance of adopting an attacker's mindset for uncovering vulnerabilities and bugs in smart contracts. This mindset involves thinking offensively to find issues that defensive-minded developers may overlook. Owen outlines four key steps to adopt this mindset: incentivizing oneself appropriately, believing in the presence of bugs, noting down peculiar behaviors or 'knobs' in the code, and combining these knobs to identify unique vulnerabilities. He contrasts this approach with the typical defensive stance of developers, who aim to secure protocols rather than break them. The goal is to shift focus from proving security to disproving it, thus uncovering potential vulnerabilities more effectively.

05:01

🚫 Avoiding Common Mistakes that Hinder Adopting an Attacker's Mindset

Owen highlights two critical mistakes that can prevent one from effectively adopting the attacker's mindset. The first mistake involves incorrect incentives; auditors should be rewarded based on the vulnerabilities they discover, rather than being paid a flat fee. This aligns their incentives with finding more bugs. The second mistake is failing to believe that vulnerabilities exist in the code being audited. Auditors should always be skeptical and question the security of the code, avoiding the trap of automatically agreeing with developers. This skepticism is vital for maintaining an offensive perspective and effectively identifying vulnerabilities.

10:02

🔍 Practical Application of Attacker's Mindset in Smart Contract Auditing

Owen applies the attacker's mindset to uncover a vulnerability in the GMX V2 smart contract. He identifies a unique attack vector arising from a two-step execution process, which allows for a potential risk-free trade by exploiting the delay in order execution. By observing how limit orders can be manipulated to delay executions, Owen pieces together various components ('knobs') of the contract to construct a potential exploit. This includes exploiting the price range validation in orders and manipulating the collateral amount in positions. The exercise demonstrates the practicality of the attacker's mindset in identifying complex vulnerabilities that might be overlooked in a traditional audit approach.

Keywords

💡Attacker's mindset

The attacker's mindset refers to the mental approach of looking at code or a system from an offensive perspective with the intent of breaking or finding vulnerabilities in it. This is in contrast to the defensive mindset of developers who aim to secure the protocol. The video emphasizes the importance of adopting this mindset to effectively uncover bugs and vulnerabilities that developers may have missed. For example, the script states, 'getting into the attacker's mindset is, probably the number one thing that you, can do to immediately boost the amount, of findings vulnerabilities and bugs, that you uncover.'

💡Incentives

Incentives refer to the motivations or rewards that drive an auditor's approach to finding vulnerabilities. The video suggests structuring incentives in a way that encourages the auditor to actively seek and uncover vulnerabilities, such as being compensated based on the number and criticality of findings. As stated in the script, 'you want to ensure that before you even, go into the audit you have the correct, incentives that are setting you up for, Success where you really want to find, vulnerabilities.'

💡Knobs

Knobs are the individual pieces of code or behavior that an auditor identifies as interesting or potentially exploitable. The video advises collecting these knobs during the initial code review and then combining them to construct more complex exploits or attack vectors. As the script states, 'you want to, note down everything interesting every, interesting piece of behavior anything, that's off any line that's missing you, want to note that down and save it for, later because as you're going to see, things like this can be combined with, other knobs in order to yield really, unique and critical attack vectors.'

💡Risk-free trade

A risk-free trade is a type of vulnerability or exploit that allows an attacker to execute a trade or transaction with the knowledge of future price movements, effectively enabling them to profit without any risk. The video discusses an example where the attacker can delay the execution of an order and then execute it with outdated prices, resulting in a risk-free trade. As stated, 'essentially there's a unique attack, Vector here where if I can delay the, execution of the keepers transaction I, can get a risk free trade.'

💡Empty position error

The empty position error is a specific error condition mentioned in the video that, when triggered, allows the attacker to delay the execution of an order. By exploiting this error and then toggling it off at the right time, the attacker can execute a risk-free trade. As the script explains, 'if I can get get a, limit order to revert with the empty, position error then I can delay the, execution of the Keeper's transaction.'

💡Keeper

In the context of the video, a keeper refers to the entity responsible for executing orders on the exchange. The exchange uses a two-step execution process where users create orders, and then keepers execute those orders in a separate transaction. This is done to mitigate front-running attacks. The attacker's goal is to manipulate the keeper's execution to enable a risk-free trade. As stated in the script, 'GMX has a, two-step execution system where you, create an order it's it's sort of like a, request to have an order executed and, then a keeper comes in and executes your, order.'

💡Limit order

A limit order is a type of order used in trading where the trader specifies a specific price at which they want to buy or sell an asset. In the context of the video, the attacker exploits the logic around limit decrease orders (a type of limit order used to close a position at a profitable price) to set up the risk-free trade. The script mentions, 'particularly for a limit order we can, see that in the set exact order price, function which is used to essentially, set the prices that are going to be used, to execute this order for a limit, decreased order.'

💡Oracle

An oracle is a third-party service that provides external data, such as asset prices, to smart contracts or decentralized applications. In the context of the video, the attacker manipulates the logic around how the oracle's price ranges are used to execute limit orders, enabling the risk-free trade. As mentioned in the script, 'we're going to validate that price is, ascending and so essentially this is, going to take the earlier price in the, range of prices that are provided by the, Oracle and the later price and the range, of prices provided by the Oracle.'

💡Proof of Concept (PoC)

A Proof of Concept (PoC) is a demonstration or implementation of an idea or vulnerability to prove its feasibility. In the video, the narrator mentions writing a PoC to verify that they could set the remaining collateral amount to zero, which is a crucial step in the risk-free trade exploit. As stated, 'we wrote a POC and it's actually, true you can essentially have an initial, collateral Delta amount that will allow, you to set the remaining collateral, amount to zero.'

💡Lego bricks

The term 'Lego bricks' is used as a metaphor in the video to describe the individual knobs or pieces of code that the attacker combines to construct the final exploit or attack vector. By piecing together these Lego bricks (knobs) in a specific way, the attacker can create a 'masterpiece' exploit, in this case, the risk-free trade. The script states, 'we have successfully found a way to, essentially make an order revert And, Delay that success here's what we've, done if we can use this as a timeline of, price action here's what we'll use as a, timeline of order execution, let's say before this we have a position, that has let's say we have two thousand, two thousand USD of size so this is the, size of our position and let's say we, have just 10 collateral tokens 10, collateral tokens of collateral maybe, this is ether let's say it's ether it, doesn't matter right so we have that and, then we have an order in the store and, let's say the order is for 10 collateral, tokens and only 1500 size, so now what we've got so far is we see, that if this order is to be executed at, this point in time right so let's say, you know the order would be executed, tried it would be normally attempted to, be executed at this point in time what, would happen is this order this 10, initial collateral Delta amount would, negate the collateral on the position we, would end up with zero collateral tokens, we would end up reverting on this, validate position function when we check, validate non-empty position the, remaining collateral Mount is zero and, we revert with the empty position the, empty position up in the older order, Handler is ultimately causing a top, level revert which means that the keeper, will not execute the order so as long as, this order lives in this collateral, amount here is 10 and the collateral the, initial collateral Delta amount on the, order is 10 then this will continue to, revert revert revert until let's say at, this point right here now we see that, prices moved in a favorable Direction, meaning that if we were to be executed, with prices from over here on the left, at this point in time on the right, we would make risk-free money we would, be able to buy ether at cheaper than the, the market rate or you'd sell ether at a, higher price than the market rate you, know something like this so now exactly, what we need is the knob to twist to be, able to toggle this off and be able to, make the empty position error not get, raised and so after scanning and looking, and looking for exactly that thing to, twist we can find that exactly here on, this if statement right here this is the, last Lego Brick of our attack Vector.'

Highlights

Getting into the attacker's mindset is probably the number one thing that you can do to immediately boost the amount of findings vulnerabilities and bugs that you uncover.

You need to start thinking offensively to uncover the bugs and vulnerabilities that the developers, who are thinking defensively did not uncover.

The attacker's mindset is very simply boiled down just a way of looking at a code base where you're trying to break as many things as possible and there's an optimal way to do this.

The attacker's mindset is going to benefit us because if we set out looking to disprove the security of a protocol by finding a valid vulnerability in it then we're going to be a lot more likely to uncover that vulnerability than if we were to set out to verify or essentially convince ourselves of the security of the protocol.

Incentivize yourself accordingly by structuring the way you get paid or rewarded by the amount of vulnerabilities and criticality of vulnerabilities you uncover.

You have to personally believe that there are bugs and vulnerabilities in the code base itself.

Collect knobs as you're going through the code base - note down everything interesting, every interesting piece of behavior, anything that's off, any line that's missing.

Combine your knobs - take the list you've compiled and piece them together, find each individual knob that can fit with another to create exploits.

Not getting your incentives right by charging all the money for an audit upfront no matter how many findings and vulnerabilities are uncovered can prevent you from getting into the attacker's mindset.

Not believing that vulnerabilities exist in the code you're auditing and subconsciously agreeing with the developers can prevent you from getting into the attacker's mindset.

GMX has a two-step execution system where you create an order and then a keeper comes in and executes your order in two independent transactions to avoid front-running attack vectors.

If you can delay the execution of the keeper's transaction, you can get a risk-free trade by executing your order at a later block with the prices from the block you created the order.

Discovered that if a limit order reverts with an empty position error, it will be retried, allowing potential to delay execution.

Combined the price execution logic with the empty position error delay to construct an exploit for a risk-free trade.

Pieced together multiple code intricacies to toggle off the empty position error at a favorable time and execute the risk-free trade.

Transcripts

getting into the attacker's mindset is

probably the number one thing that you

can do to immediately boost the amount

of findings vulnerabilities and bugs

that you uncover you need to start

thinking offensively to uncover the bugs

and vulnerabilities that the developers

who are thinking defensively did not

uncover in this video we're going to

cover exactly the four things that you

need to do to get into the attacker's

mindset and then we're going to cover

two things that will prevent you from

getting into the attacker's mindset and

then we're going to cover a particular

finding that required me to really get

into the attacker's mindset and pull a

few knobs in order to pull it off and

actually have a valid finding and so

this way you're going to see exactly how

the attacker's mindset comes into play

and how it is actually applied in

practice all right but first of all who

am I and why should you listen to me

talk about out the attacker's mindset

well my name is Owen and over a year and

a half ago I founded Guardian Audits and

ever since then we've uncovered dozens

and dozens of critical and high

vulnerabilities in over a hundred

different smart contracts and over a

thousand different hours spent auditing

smart contracts and so my goal is to

take down everything that I've learned

along the way and give it to you so that

you can ultimately become a much better

smart contract auditor than I ever could

be in a fraction of the time alright so

without further Ado let's get right into

the attacker's mindset

[Music]

okay so we are talking about the

attacker's mindset but first of all what

really is it and why will it benefit us

the attacker's mindset is very simply

boiled down just a way of looking at a

code base where you're trying to break

as many things as possible and there's

an optimal way to do this this is of

course in direct opposition to the sort

of mindset of a defender or a developer

where they're looking to secure a

protocol and essentially verify that it

is indeed secure at its core what this

boils down to is looking to disprove

rather than prove and of course the

attacker's mindset is going to benefit

us because if we set out looking to

disprove the security of a protocol by

finding a valid vulnerability in it then

we're going to be a lot more likely to

uncover that vulnerability than if we

were to set out to verify or essentially

convince ourselves of the security of

the protocol okay so now let's discuss

the four key steps to get into the

attacker's mindset and then we'll

discuss two critical mistakes that are

pulling you right out of the attacker's

mindset okay so first of all of course

is to incentivize yourself accordingly

you want to ensure that before you even

go into the audit you have the correct

incentives that are setting you up for

Success where you really want to find

vulnerabilities what does this mean this

means that you structure the way that

you get paid or rewarded or however

you're being compensated for this audit

by the amount of vulnerabilities and the

criticality of vulnerabilities that you

uncover and so obviously if you're

competing in a contest or maybe if

you're charging per vulnerability found

of course this is a fantastic way to

correctly incentivize yourself

and sort of change the structure of your

mind and make you think by default like

an attacker because you are literally

getting compensated like an attacker

would be okay then second of all after

we've gotten the incentives right we've

set the Baseline for how a good

incentivized audit can occur now we just

have to personally believe that there

are bugs and vulnerabilities in the code

base itself of course if an attacker did

not believe that there were

vulnerabilities in a code base they

would move on to a new one in order to

find as many bugs and vulnerabilities as

possible you simply have to be convinced

that many bugs and vulnerabilities exist

in the first place okay and then the

third step is to collect knobs as we're

going through the code base so as you're

going through the code base and you're

getting that initial context you want to

note down everything interesting every

interesting piece of behavior anything

that's off any line that's missing you

want to note that down and save it for

later because as you're going to see

things like this can be combined with

other knobs in order to yield really

unique and critical attack vectors which

leads us into the fourth step which is

of course to combine your knobs now what

you have to do is take this list that

you've compiled and piece them together

find each individual knob that can fit

with another to create one of these

really cool puzzle piece sort of

exploits each of these knobs is going to

be a Lego brick that you can use to

construct a more complicated exploit all

right now that we've discussed that

let's talk about two key mistakes that

you might be making right now that are

preventing you from getting into the

attacker's mindset and these are really

the flipped version of the earlier steps

and so first of all of course if you're

not getting your incentives right you're

going to be starting off on a bad foot

and setting yourself up for failure so

what does this mean this looks like

charging all of the money for an audit

up front no matter how many findings and

vulnerabilities are uncovered so if you

think about the Baseline incentive here

you are purely incentivized to spend as

little time on the audit as possible and

your mentality is going to be to

convince yourself of the security of the

protocol you're going to subconsciously

want to believe after a certain amount

of time that you've spent on the

protocol that the protocol is indeed

secure you might not notice this

consciously affecting your actions but

this is exactly what makes the

difference between spending an extra day

on a piece of functionality that's

really involved just to get that last

little tiny knob that ends up being a

full-blown critical exploit and versus

if you weren't incentivized to find that

little tiny knob and get that critical

exploit you might end up subconsciously

convincing yourself that that area of

functionality is actually secure and

there's no need to spend many many hours

digging into it okay and then second of

all is of course to not believe that

vulnerabilities exist of course we've

talked a lot about this but I cannot

iterate this enough you have to believe

that there are vulnerabilities in the

code you're auditing you have to

distrust the developers always otherwise

you start to get into the headspace of

verifying rather than attacking and you

start to agree with the developers if

you find yourself subconsciously

agreeing with the developers immediately

turn that on his head and start to

question everything from the ground up

okay now that we've explored what

exactly the attacker's mindset is let's

have a look at it in practice and see

how it can yield some really interesting

unique exploits that are even missed in

audit contests okay so before we hop

into this particular finding and walk

through it walk through the steps that

it took me to actually come across this

finding we need to get some context on

the code base for so this is of course

from the GMX V2 code base from an

earlier audit as GMX was early on in the

development stage of the protocol before

it's released now if you want a full

Deep dive and breakdown of the GMX V2

code base and to really get enough

context and introduction to fully

understand this finding go ahead and

watch my intro to GMX V2 video on this

channel but to give some really really

quick high-level context just enough so

you can get the gist of this finding as

we go through it GMX is a perpetuals

exchange Traders can open positions and

they use orders to do that you can use

orders to increase positions and

decrease positions and you have all

sorts of market and limit orders as well

as stop losses and importantly GMX has a

two-step execution system where you

create an order it's it's sort of like a

request to have an order executed and

then a keeper comes in and executes your

order and these are in two independent

transactions and this is essentially

done to avoid a lot of front-running

attack vectors on the exchange so the

first knob here actually arises from

that two-step execution process the

keeper will essentially provide prices

from the Block in which you created your

order in order to execute your order so

what does this mean this means that

essentially there's a unique attack

Vector here where if I can delay the

execution of the keepers transaction I

can get a risk free trade let's have a

look at exactly what this looks like

right so if we have a timeline here and

let's say I simply created a straight up

Market order at this time here let's say

this is block 100 over here and then I'm

able to delay the Keeper's execution of

my order until this block over here

let's say it's block 110 essentially I

can execute have this order executed at

this time block 110 with the prices from

block 100. so in Block 100 the price of

ethereum might be a thousand dollars in

Block 110 the price of ethereum might be

eleven hundred dollars and so I could

see that the price of ethereum currently

in Block 110 is eleven hundred dollars

and then make a risk-free trade where I

say oh yes I would like my order that

was submitted here to be executed only

now at block 110 and end up getting an

Arbitrage of a hundred dollars per ether

risk free right I have the knowledge

that ether has appreciated 100 since

these prices here in Block 100 so that

is the most simple version of and a

risk-free trade that could occur and

that's essentially the first knob that

we're going to use in our list of knobs

right so as I'm going through the code

base this is something that I I just

know as a class of vulnerabilities that

exists on the exchange and so it's in my

list of knobs that I have to twist as

I'm going through the code base so let's

go into the first knob that I discovered

that essentially begetted what

ultimately became this vulnerability so

first of all I'm going to notice that

the empty position error is something

that gets reverted on so what does this

mean this means that when we revert here

this order is going to be retried

instead of ultimately Frozen or canceled

if it were a market order or something

like this so if we have a limit order

for example and it reverts with an empty

position error it's going to be retried

what does this mean this means that we

can delay the execution here so I'm

going to note that if I can get get a

limit order to revert with the empty

position error then I can delay the

execution of the Keeper's transaction so

I know it can delay it but I need

something to keep the prices that the

order is going to execute with outdated

so if the keeper has to keep making new

basically executions so the way the

keeper will work is they'll see that

this would revert with this error by

basically simulating this and they will

not execute this transaction until they

see that it doesn't revert and it

successfully goes through so how do I

get it such that the keeper will use

outdated prices when all of a sudden

they see that this no longer reverts

with an empty position error well

particularly for a limit order we can

see that in the set exact order price

function which is used to essentially

set the prices that are going to be used

to execute this order for a limit

decreased order we can see that we're

going to end up validating that the

price is ascending right so it is not a

limit increase it is not a stop loss

this is a limit decrease and let's say

it is for a long to make things simple

so we're going to validate that price is

ascending and so essentially this is

going to take the earlier price in the

range of prices that are provided by the

Oracle and the later price and the range

of prices provided by the Oracle and

assert essentially that price is

validating over this range and this

range must encapsulate my trigger price

so if we draw this out and we have a

look at what this looks like on a a

price graph so we'll say this is my

trigger price now what has to happen for

my limit decrease essentially like a

take profit to execute is price has to

be ascending right so now any arbitrary

range here is hypothetically a valid

range to execute this limit decrease

over as long as it's including my

trigger price so now I can see that if I

combine this price execution logic with

the fact that you could potentially

delay this execution with an empty

position error then I could potentially

get some sort of benefit from a

risk-free trade if price did something

like this so let's talk about this if I

have my limit decrease order waiting to

get executed and then price enters this

range here but I do not allow it to be

executed by reverting with the empty

position error then essentially price is

going to continue time is going to

continue on we're still reverting with

the empty position error the keeper is

not trying to execute this yet as they

see that it's reverting until we see

price goes down down and now let's say

we're at this point here every time

before this we were reverting with the

empty position error now you'll notice

something if we look at the price option

here there has never been a valid price

range to execute this over after you

know

so you know something like this point

here now there's no valid range after

this point where you could execute this

there's no range that is increasing that

includes our trigger price and so now if

all of a sudden we're to stop reverting

with an empty position error and allow

the order to be executed at this point

in time now we're going to be forcing

the keeper to use prices from in this

range and so of course this is a classic

risk-free trade I can execute an order

at this time with knowledge of what the

current price is only I'm executing it

with old prices so I'll get a price

somewhere in this range here and of

course I can modify my acceptable price

to get any particular price that I might

want okay so we have the means to make a

risk-free trade happen but the question

is where can we get that empty position

error to end up delaying this and how

can we talk toggle it such that if I

decide at this point in time that I want

this order to go through and the

risk-free trade to be realized then How

Can I toggle that empty position error

off and allow the order to go through so

these are things that I'm immediately

looking for now in the attacker's

mindset right I am looking to

maliciously really maliciously find how

I can make this sort of risk-free trade

happen so I'll notice one key thing when

I'm looking at the decrease position

this if statement here if our position

was closed of course we remove the

position from the order store and we

don't do any extra validation and that's

if the size in USD or the size and

tokens are zero however if there's a

position left over then we're going to

go ahead and do this critical check here

which is to validate position and if we

click into this we'll see that we

validate non-empty position and which

revert do you think that gives it gives

the empty position revert and so we have

three different knobs here that we can

twist in order to get the empty position

revert and cause this initial sort of

delay so now here's my goal after

realizing that I can get the empty

position revert when a position is left

with size so we must have size in USD

and we must have size and tokens enabled

to to go into this else branch and

ultimately do this validation now I know

that this cannot be zero and I know that

this cannot be zero in this case so

we're left with one option here the

collateral amount we need to be able to

manipulate the collateral amount to be

zero here while the size and tokens and

the size in USD are non-zero and then

once we're able to get into that state

we need to be able to retroactively

toggle that state off without touching

the order in order to ensure that this

can be executed retroactively so what I

first notice is if I go into the process

collateral function if we scroll down

here there's actually no check that I

can't just set the remaining collateral

amount to zero I'm not going to go

through this whole 300 line function but

you can essentially take my word for it

that we wrote a POC and it's actually

true you can essentially have an initial

collateral Delta amount that will allow

you to set the remaining collateral

amount to zero and so that's exactly the

knob that we needed to make this attack

work to give us some Ray of Hope so now

after processing collateral and getting

these values we set the remaining

collateral to zero right so this

remaining collateral amount is now zero

from our initial collateral Delta which

is essentially the amount of collateral

we want to remove using our order so

this gets set to zero on the position

and then when we do this check here

we're going to have some size left over

so we go here and we validate and we get

the empty position error so we're

starting to piece together the Lego

building blocks and we've almost

finished our Masterpiece of an attack

here but we still need some more Lego

bricks to come in and help us out we

have successfully found a way to

essentially make an order revert And

Delay that success here's what we've

done if we can use this as a timeline of

price action here's what we'll use as a

timeline of order execution

let's say before this we have a position

that has let's say we have two thousand

two thousand USD of size so this is the

size of our position and let's say we

have just 10 collateral tokens 10

collateral tokens of collateral maybe

this is ether let's say it's ether it

doesn't matter right so we have that and

then we have an order in the store and

let's say the order is for 10 collateral

tokens and only 1500 size

so now what we've got so far is we see

that if this order is to be executed at

this point in time right so let's say

you know the order would be executed

tried it would be normally attempted to

be executed at this point in time what

would happen is this order this 10

initial collateral Delta amount would

negate the collateral on the position we

would end up with zero collateral tokens

we would end up reverting on this

validate position function when we check

validate non-empty position the

remaining collateral Mount is zero and

we revert with the empty position the

empty position up in the older order

Handler is ultimately causing a top

level revert which means that the keeper

will not execute the order so as long as

this order lives in this collateral

amount here is 10 and the collateral the

initial collateral Delta amount on the

order is 10 then this will continue to

revert revert revert until let's say at

this point right here now we see that

prices moved in a favorable Direction

meaning that if we were to be executed

with prices from over here on the left

at this point in time on the right

we would make risk-free money we would

be able to buy ether at cheaper than the

the market rate or you'd sell ether at a

higher price than the market rate you

know something like this so now exactly

what we need is the knob to twist to be

able to toggle this off and be able to

make the empty position error not get

raised and so after scanning and looking

and looking for exactly that thing to

twist we can find that exactly here on

this if statement right here this is the

last Lego Brick of our attack Vector

what is this doing right here we're

seeing if the size Delta USD on the

order is the same as the size and USD of

the position

then what we're doing is we're setting

the initial collateral Delta amount to

zero ladies and gentlemen this is

everything we need this is exactly the

toggle that we need so how are we going

to achieve it so let's remember this one

case this is literally the case we need

if the order size is the same as the

position size then we can toggle our

risk-free trade so what can we do we can

decrease the position size to match the

order size so we'll see the position

size is 2000 USD the order size is 1500

USD at this point in time when we want

to toggle it normal

Market decrease to decrease our position

by 500

USD so our position now becomes at this

point in time it is now 1500 USD size

and 10 tokens in collateral so what does

this match up with it matches up with

perfectly the 1500 from our order over

here so we're going to hit this exact if

statement right here we're going to set

the initial collateral Delta amount to

zero and in fact it doesn't even matter

because we're going to go into this if

statement here and so we're not even

going to have any position left over

because ultimately the size in USD is

now going to be equal to zero and we're

not even going to enter the branch where

it's possible to throw the empty

position error okay so now ladies and

gentlemen this is literally the entire

exploit this is everything we need to

pull off a critical risk-free trade on

the exchange so I hope that wasn't too

too in depth to understand how exactly

we go through and piece each of these

individual Lego bricks together I

recommend you go through and watch this

a few more times in order to fully

understand the attack vector and really

try to notice how we're going through

and as we uncover bits we just keep them

in our backlog until we match them up

with something else that's potentially

related and notice overall how we're

really being malicious about this and

we're really going for and trying to

break things intently this is the core

of the attacker's mindset okay so that

covers everything to do with the

attacker's mindset everything I know

about getting into the attacker's

mindset and finding those really

interesting vulnerabilities I hope that

this helps you find something really

interesting and if you learned anything

new go ahead and just pop it in the

comment section below alright and of

course if you're looking to grow as an

auditor and connect with a community of

growing aspiring Auditors to get to the

next level of auditing skills or

whatever and go check out lab.guardian

audits.com where you can join over 500

smart contract security Auditors and

learn from everybody in the community

share your thoughts get experiences from

others and even team up with others to

participate in team Audits and get

rewarded for findings that you uncover

and of course if you're not 100

confident in your web 3 auditing

abilities I collaborated with a number

of top tier Security Professionals in

the field to bring you exactly the most

thorough training on Smart contract

security this training will literally

take you from just understanding

solidity to a full-blown solidity

auditing Chad as efficiently as possible

if you are looking to go the paid route

then this is absolutely in my opinion

the best paid resource hands down out

there on smart contract auditing so if

you are indeed looking to go the paid

route then of course you can take fifty

dollars off in the link in the

description below alright guys that is

all for this time I can't wait to see

you in the next one

foreign