Smart Contract Security for Pentesters | Hacker News Reader

Smart Contract Security for Pentesters

iosiro.com

63 pointsdyates38 comments

I would highly recommend anyone interested in pentesting smart contracts look at the work Trail of Bits has been putting out: https://blog.trailofbits.com/?s=smart+contract&submit=Search

Start with "246 Findings From our Smart Contract Audits: An Executive Summary" [1]

[1] https://blog.trailofbits.com/2019/08/08/246-findings-from-ou...

I'd like to add that there is a critical shortage of security auditors for smart contracts and blockchain protocols.

Projects are willing to spend up to millions to squash away vulnerabilities. For example Balancer opened a bug bounty for their v2 with $2M USD for 1 critical bug:

https://docs-v2.balancer.finance/core-concepts-1/security/bu...

Do they have any interest in hiring regular employees? Most of the people I know who go after bounties barely make $30,000/yr. If I see bounties I see people who aren't really willing to pay.

You should apply to auditing firms (Trail of Bits, Open Zeppelin, Quantstamp, ...). They are all booked 3 months in advance at the very least and would love to onboard new blood.

What’s the comp look like?

High - solid blockchain devs can pull a lot of money. Let me underline _solid_, there are a lot of people who took a tutorial and try to sell themselves as experts.

Yes! Please do apply. We have a tight-knit team of experts, industry leading tools, and a work environment that promotes continued learning. You'll get paid well and quickly become a leading industry expert. Here's our job req for a blockchain security analyst: https://jobs.lever.co/trailofbits/4f459855-3299-462f-9e73-29...

Note the difference between "I could not find any bugs" and "I proved there are no bugs". I would assume only the latter are hired. Yet, program proving as in formal verification is a very academic specialisation. The reluctance to hire these people seems partly a) unawareness these methods exist and b) capability to evaluate whether someone knows enough. To my anecdotal experience founders of DeFi applications are not that tech savvy, so instead of trying to understand Solidity (untrivial) they instead place bug bounties or hire a special firm to give a stamp of approval for a product launch.

My take on formal verification was that we are still not close to being able to usefully prove the validity of the types of nontrivial programs that make up DeFi contracts. It can help, sure, but companies serious about security need to invest in internal auditing (that may not seem to be generating obvious returns) instead of hoping for a bug bounty Hail Mary.

If these firms are out there and are being hired I suppose that counts.

Naive question: how is looting vulnerable smart contracts even illegal?

Without a legal framework of smart contract enforcement, recognition of literally-hypothetical assets as valuable, the public nature of blockchains that would preclude "unauthorized access," and unlike an exchange holding assets on behalf of customers - smart contracts are effectively leaving money on the ground for anyone clever enough to pick it up.

Clearly I haven't given it as much thought as the people involved, but it seems like if I'm not using my abilities full-time to hack and loot smart contracts, I'm missing the most direct and best possible effort/reward application of that kind of skill.

IANAL, but I'd imagine that for US folks, violating the intent of the code -- namely, doing something while lacking the authorization to do so -- is illegal, even if the code lets you do it. Otherwise, basically all forms of criminal hacking would be legal.

Of course, if the smart contract expressly permitted anyone to take tokens out of it via any means allowed by the platform, that's a different story.

Except in the US you can't sue on just intent, the letter of the law still needs to agree. So if the smart contract permits something, by not forbidding it, that something is entirely legal.

That can't be right. That would mean that all forms of hacking are legal, since after all, the remote server permitted you to run your shell code.

The law you're thinking of is CFAA, and it's not clear that this violates the CFAA. The requisite element is "accesses [...] without authorization or exceeds authorized access."

Given the general enthusiasm of blockchain proponents to believe that "the code is law", it's a pretty easy argument to make that taking advantage of poorly-written code is well within the user's authorized capabilities. Will it win in court? shrug

Again IANAL, but I think there's more to it than "the code is law." If we accept that hacking is illegal, then we must also accept that the law recognizes a difference between what the code does and what the code intended to do. I would think that this means that the courts would recognize a faulty but good-faith attempt at an authorization check on token movements to be evidence of the developer's intent to prevent tokens from being moved without authorization. If so, then they would further conclude that token movement that doesn't follow the intended authorization code paths is a violation of the CFAA.

IANAL either, but from my following of SCOTUS and other law cases, it does seem that the actual judicial interpretation of CFAA's authorization requirements is kind of vague and unsettled. There's a pending case before SCOTUS this term about CFAA (although it's not directly related to what the question in this thread, it's possible the opinion weighs in on it). Reading the amici, I'm not sure I'd find any consensus as to whether or not people believe this kind of access violates or doesn't violate the CFAA.

That's why I ended with shrug--there's not enough clarity to answer if it is or isn't legal with any degree of certainty.

I think regardless of the circuit split on the meaning of "authorization", it seems fairly well settled that the meaning is not "what the computer system allows you to do".

e.g. Van Buren is about resolving the question of whether someone who is given access to a computer system for their job can be considered to have used it in an "unauthorized" way if they use that system in ways that are unrelated to that job.

The circuit-level decisions both start from the position "authorized" means something like "the owner of the computer has decided to grant access", which is more rather than less.

i.e. X intended to give Y access (this is the part of "authorized" on which there is consensus) but Y used it for purposes that X did not approve of (this is the subject matter of the disagreement)

Adding on to that. If you need real life contracts (the law) to enforce consequences of breaching or exploiting a smart contract: why do you need a smart contract at all?

Whether the law to enforce consequences exists or not, smart contracts will still provide value. Some of those contracts will be exploited, and the law will not help in 99% of cases.

Do you care to elaborate on that? How does it add value?

Do you not think permissionless money systems are valuable?

Are you talking about cryptocurrencies?

If so, what does that have to do with smart contracts?

What do you think smart contracts are?

Well according to this article it's code that is executed once a requirement is met.

If the requirement is trivial like in the Bitcoin blockchain, sure, maybe there is some value in it.

But no one in the comments is talking about that. What everyone here seems to be talking about is non-trivial code that is supposed to enforce policies.

Or at least that's what I'm asking about. Where is the value in that?

Uniswap facilitates trading through smart contracts without a trusted middleman or custodian. That is an example of useful smart contracts.

I think they are confused about what a smart contract is

It seems like you're the only one who actually knows what a smart contract is...

As smart contracts are supposedly open source, it will probably trivial for you to link to a code snippet that qualifies as a smart contract.

Can you do that? Otherwise, stop trolling.

here you go: https://etherscan.io/address/0x7a250d5630b4cf539739df2c5dacb...

Thank you

Indeed. It seems redundant if smart contracts are just another expression of the “real”, legally enforceable contract. When not implement it in legalese directly and eliminate the possibility of a scam in the code?

Isn't the point that the smart contract is self-executing? The fact that third parties can meddle with it if it's poorly implemented is somewhat orthogonal.

Most contract disputes are about disagreements between the parties, not about how the contract just became impossible because a cat burglar stole the property that was the subject matter of the contract.

I don't think it's orthogonal; no traditional contract actually facilitates the burglary, whereas poorly-implemented smart contracts do.

If the "real" contract is the one enforced by law, and the "smart" contract is the one that might facilitate a burglary, why not dispense with the latter?

If the "smart" contract resolves settlements automatically most of the time and most of the disputes get resolved without escalating to the actual legal process (which is relatively expensive and slow) then that can save some money.

I would treat it essentially as arbitration on steroids; just as in arbitration, you make up an alternative process for deciding who pays whom and how disputes are resolved, so that in most cases you can use the alternate process, however, in unusual cases or boundary cases or outright fraud by one party you can escalate to the full legal system.

I've been interested in any smart contract languages/VMs that are somehow more capable of being provably correct/secure. The only one I've come across is Kadena, which internally uses the Z3 prover, but I haven't looked into the source code in depth or if it's able to be applied to custom smart contracts (dApp) as well.

Are there other blockchains that are similar? Is there a strict subset and prover for Solidity or other languages? Or things like proven smart contract kernels that can be built on top of? Eg, OpenZeppelin Contracts, but with provers rather than only audits.

Disclaimer: I work on this.

You should check out Clarity (clarity-lang.org). It's an on-chain interpreted language, so what you see is what will run. It's statically typed and decidable, such that you can reason about all the halting states of the program as well as the upper bounds on the amount of computing resources used. It's used by the Stacks blockchain and Algorand.

Ugh, I have been advocating "Solidity--" for years and can't get funding to build it (Trail of Bits).

We use two tools to offer quick turnaround automated testing and verification for Solidity: Echidna (like QuickCheck for Solidity) and Manticore (a symbolic verifier). They each let you write high level properties in the span of 1-2 weeks that cover a large amount of potential use cases.

Here's an example of what that looks like: https://github.com/trailofbits/publications/blob/master/revi...

Here's Echidna: https://github.com/crytic/echidna

and Manticore: https://github.com/trailofbits/manticore

Sometimes we also use custom static analyses built around Slither's IR during projects too: https://github.com/crytic/slither/wiki/SlithIR

Was the issue with Fei actually a bug?

I hate the term "pentest", but apparently people who want lingo over the ability to do anything have won out over the decades. Besides being a meaningless inaccurate shortening of the phrase, an actually "pen test" would be part of putting a pen register on a phone. It just indicates that the newbies who created the term didn't know anything before.

Reply on news.ycombinator.com