Web2.5 Security

This is an article about pentesting blockchain infrastructure, wallets, and custodial apps. We did numerous security reviews of such “web2.5” systems and wanted to share our experience.

Web2.5

What is web2? Many would agree that in one phrase you can define it as “centralized (web) applications”.

What is web3? Conversely, we’ll define web3 as “decentralized applications”, such as L1 or L2 nodes, decentralized relayers, smart contracts, etc.

Now what the hell is web2.5? I defined anything between web2 and web3 as “web2 applications integrated with web3", such as on- and off-ramp solutions, CEX’s, wallets, deployment infrastructure, crypto payment gateways, etc.

What’s special?

Web2.5 is technically same as web2: centralized applications running on a single or a distributed infrastructure without any DLT, blockchain, or consensus.

However, there’s a Web2<>Web3 integration part which is crucial for the security of the whole system, and you need to know how to deal with the blockchain to be able to test it.

The attack surface of web2.5 is potentially bigger than in normal web2 because there’re more untrusted inputs and more execution flows to consider.

Data Flow Diagram

Looking at the data flows of the web2.5 systems, what are the untrusted inputs in web2.5 vs web2?

The inputs in web2 are:

• L3-L6 attributes: IP address, SSL certificate fields, etc
• HTTP attributes: headers, parameters, files
• gRPC, WebSockets, or other protocols: custom formats
• 3rd parties: external API’s, others microservices, DNS, etc.

The inputs in web2.5 include all above and also:

• Transaction calldata
• Data from the RPC providers, mempool, etc
• Other external API’s or oracles.

Pentest checklists

Let’s list some attack vector ideas that you can include in your penetration testing pipeline for various types of the web2.5 projects. This is not a full checklist but rather a list of a few partly non-obvious ideas that you can use during the engagements.

Pentesting off-ramp

Off-ramp is a solution that allows people to exchange their crypto for the fiat money. Therefore, there should be a deposit component that has to correctly process the blockchain transactions to ensure that a user actually paid the required crypto amount.

This procedure is quite different from the normal fiat card transactions, so there’re a few specific attack scenarios.

Check the following test cases:

1. Partial payments  — Init 1 ETH payment, send only 1 wei
2. Reverted transactions  — E.g. internal ETH transfer with revert
3. Fake tokens  — Sounds implausible but who knows? Maybe the application parses balances instead of events and matches the token symbols
4. Low number of confirmations  — Possible reorgs  — Replace-By-Fee transactions in BTC

Pentesting on-ramp

On-ramp is a solution that allows people to exchange their fiat money for crypto. Therefore, there should be a withdrawal component that sends crypto to a user.

If done without taking into account the blockchain peculiarities, this component could be vulnerable.

Check the following test cases:

1. Gas griefing  — E.g. withdraw ETH to a contract with a reverting fallback  — Spend significant amount of gas in the contract by writing to storage in a loop
2. Double spending  — Race conditions are possible because the withdrawal wallets are not individual

Pentesting custody

Custody, as its name indicates, is a core component of any custodial system: it’s responsible for generating the keys, signing transactions, processing deposits and withdrawals.

If the custody is compromised, the whole product can go bankrupt, so it’s crucial to carefully audit it. For maximum coverage, we’d recommend taking a white-box approach additionally to black-box penetration testing.

Check the following test cases:

1. Crypto bugs  — Insecure HD wallet generation, weak PRNG  — Transaction nonce reuse
2. Insecure key storage  — Misconfigured nodes  — Exposed RPC endpoints  — Bad service network design, such as storing the API tokens or crypto private keys in a DB adjacent to user-facing applications
3. Insecure Direct Object Reference (IDOR)  — Account takeover attack can be used to access someone else’s keys  — IDOR might be used to leak the keys or sign arbitrary transaction
4. Insecure callback hook implementation  — Insufficient signature and IP address verification when receiving the custody’s callbacks on the client side (e.g. CEX web app receives callbacks from custody)  — Bad signature design, such as unsafe parameter serialization making it possible to juggle the parameter values to spoof them without changing the signature.

Pentesting client apps

The client apps are mobile and desktop wallets, dApps, explorers, various frontends.

The security of such applications is often downplayed and boiled down to the developers’ trust level because the biggest problem could be backdoors. However, apart from intentional backdoors, there’re many other threats.

Check the following test cases:

1. Web frontend attacks  — Try our tool for pentesting the NFT frontends: https://github.com/Raz0r/evil-nft  — Try our tool for pentesting the ENS frontends that we used to exploit XSS on https://etherscan.io/ 2 times: https://github.com/Raz0r/ens-xss
2. Client app attacks  — Electron code execution via tabnabbing (old) or XSS  — Attacks on WebView and deeplinks in mobile wallets
3. UI redressing  — Misleading the wallet users with the UI quirks  — Redirects, clickjacking, and other phishing vectors

Pentesting infrastructure

All the components of a web2.5 system together form a web2.5 infrastructure. It could be a CEX, a custodial staking product, a trading solution, etc.

Check the following test cases:

1. RPC key abuse  — RPC keys could be rate-limited, they also can be leaked on the client side  — This can lead to DoS and Sybil attacks in some cases: what happens if the app’s integration with blockchain stops working because the RPC key is exhausted?
2. 3rd party DoS  — What happens if a price oracle becomes inaccessible globally?  — What if the price feeds/oracles rate limit the app and ban it’s outbound IP address?
3. Other stuff  — BGP hijacking, DNS spoofing, and other common network attacks  — SOP violation: frontends served from a common IPFS endpoint such as cloudflare-ipfs.com share the origin with other IPFS apps

Pentesting backends

There’re other server-side components of the web2.5 services that somehow interact with the blockchains. These could be, for example, analytic tools or deployment tools.

Check the following test cases:

1. Data processing vulnerabilities  — Injection insertion points in the contract’s public fields: NFT metadata, ERC20 name and symbol, etc  — Short address attack (ancient)
2. Other stuff  — Injecting code in the centralized contract factories

Conclusion

Doing security reviews for web2.5 systems requires on one hand strong experience in the application security assessment, penetration testing, and on the other hand — understanding of the blockchains, smart contracts, and web3 in general.

It’s useful to take a bird view and try to think what kind of new data flows and new invariants does the integration with web3 add to a system.

Web2.5 Security was originally published in Decurity on Medium, where people are continuing the conversation by highlighting and responding to this story.