Active Boosts

34053 - [BC - Critical] Malicious HTTP responses allow systemic applica...

Malicious HTTP responses allow systemic application level denial-of-service attack against multiple Shardeum components

Submitted on Aug 5th 2024 at 01:25:02 UTC by @rootrescue for Boost | Shardeum: Core

Report ID: #34053

Report type: Blockchain/DLT

Report severity: Critical

Target: https://immunefi.com

Impacts:

  • Hey team! As discussed on Discord, this bundled report includes systemic application level Denial-of-Service vulnerabilities mainly touching Shardeum Core nodes, Archivers and JSON-RPC services as "Primacy-of-Impact" rather than opening individual reports.

  • Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

  • RPC API crash affecting projects with greater than or equal to 25% of the market capitalization on top of the respective layer

Description

Preword

Hey team! As discussed on Ancillaries Discord channel, this report is a bundled set of systemic vulnerabilities touching components from both Shardeum: Core boost as well as Shardeum: Ancillaries boost reported with "Primacy-of-Impact" rather than opening individual reports for each affected repository to ease your teams internal discussion around the root cause of the issue.

The section for "Impact, likelihood & severity" outlines individual "Immunefi scale" impact and severity for each component respectively. In total, this report contains details for 5 individual in-scope components: Core nodes, Archiver service, JSON-RPC service, Explorer server and Relayer collector. Severity of the identified issue ranges from low to high (even critical..?) depending on the affected component.

Intro

A systemic issue across Shardeum code bases allow an attacker to perform varying severity of application level denial-of-service attacks against Shardeum consensus nodes, Archiver server, and JSON-RPC server. This issue arises as components across repositories do not enable proper safeguards when performing external HTTP API calls and accepts arbitrary HTTP responses returned from the external calls. The attacker can deploy modified components, such as a consensus node, force or wait the targeted service to connect to it and make the received HTTP API call return a very large or a very slow response (directly or by redirecting it to a 3rd-party service), which will consume varying levels of computer resources from the target.

The impact effects range between full CPU, RAM and network bandwidth consumption leading to undefined behaviour and application crashes, to exhausting targeted services download bandwidth and/or available connection threads.

Vulnerability Details

The Shardeum components utilize three different libraries to manage external HTTP requests:

  • Axios

  • Node-Fetch

  • Got

The used Axios library defaults are lacking safeguards against malicious request manipulation, namely it does not restrict accepted response sizes, does not introduce request round-trip timeouts and follows arbitrary redirect responses. Practically ALL Axios utilizing down stream HTTP request calls are vulnerable with only individual exceptions. Axios will attempt to read and parse all data from the response, storing it in systems RAM until it's exhausted. At the same time, the system does not limit the download speed of the data and parsing will use excessive amounts of CPU cycles for the affected thread.

Similarly, the used Node-Fetch library is vulnerable to arbitrary response sizes, is lacking RTT timeouts and follows arbitrary redirects. Difference between Axios and Node-Fetch is, that Node-Fetch will ignore the data itself if it's too large, but will not close the connection and continues to download the response data at full capacity until the stream is closed. Worth noting, that if the targeted service opens more than one exploiting connection at once, Node-Fetch too can exhaust all CPU and RAM of the target.

The vulnerability can be exploited with two methods:

  • By actively initiating an API call to a vulnerable component, which will trigger an external call to the attacker controlled malicious service responding with non-expected data

    • For example: Transaction injects, block queries, transaction debugs

  • By passively listening for and answering to any external calls initiated by a vulnerable component and responding with non-expected response or data

    • For example components querying for: node information, known archivers, node lists, network configs

Of the used libraries, only Got is assessed NOT to be vulnerable to malicious arbitrary responses by default.

Per component

NOTE: This will be non-exhaustive listing of locations and actions using vulnerable libraries as there are a lot of them, but I'll provide my best attempt to cover everything.

JSON-RPC

JSON-RPC service has it worst of all components assessed. JSON-RPC service uses only Axios. Either directly, or abstracted away in axiosWithRetry, requestWithRetry and other single purpose methods.

JSON-RPC service initiated requests with Axios:

- GET /account/[accountId]
- GET /api/log
- GET /api/originalTx
- GET /api/transaction
- GET /api/receipt
- GET /api/blocks
- GET /api/v2/logs
- GET /archivers
- GET /cycleinfo/[ID]
- GET /faucet-claims/count
- GET /full-nodelist?activeOnly=[true|false]
- GET /eth_gasPrice
- GET /eth_blockNumber
- GET /eth_getBlockByNumber
- GET /eth_getBlockByHash
- GET /eth_getCode
- GET /nodeinfo
- GET /transaction
- GET /tx/[txId]
- POST /contract/accesslist
- POST /contract/estimateGas
- POST /contract/call
- POST /inject

Limiting factors: Not many. JSON-RPC service often calls other known components within the network in randomized manner and the attacker can trigger the external call on-demand. Worst situation of the assessed components - any external call is a potential source for full application level Denial-of-Service attack.

Archiver

Archive server uses primarly Node-Fetch and Got, with exception of Axios within configuration update scripts. The Node-Fetch is used directly and via exports introduced in ./src/P2P.ts and ./src/sync-v2/queries.ts:

./src/sync-v2/queries.ts:
function makeRobustQueryCall
function attemptSimpleFetch
export function robustQueryForCycleRecordHash
export function robustQueryForValidatorListHash
export function robustQueryForArchiverListHash
export function robustQueryForStandbyNodeListHash
export function getCurrentCycleDataFromNode
export function getValidatorListFromNode
export function getArchiverListFromNode
export function getStandbyNodeListFromNode

./src/P2P.ts
export async function getJson
export async function postJson

Archiver initiated requests with Node-Fetch:

- GET /netconfig
- GET /sync-newest-cycle
- GET /nodeinfo
- GET /nodelist
- GET /cycleinfo/[ID]
- GET /standby-list
- GET /validator-list
- GET /cycle-by-marker
- GET /standby-list-hash
- GET /archiver-list-hash
- GET /current-cycle-hash
- GET /validator-list-hash
- GET /leavingarchivers
- GET /activearchiver
- GET /statehashes
- GET /joinedArchiver/[publicKey]
- GET /genesis_accounts?start=[startAccount]
- GET /get-network-account?hash=[true|false]
- POST /joinarchiver
- POST /requestdata
- POST /cycleinfo
- POST /lost-archiver-refute
- POST /querydata
- POST /gossip
- POST /get-tx-receipt
- POST /originalTx
- POST /receipt
- POST /get_globalaccountreport_archiver
- POST /cycleinfo
- POST /account
- POST /transaction
- POST /totalData

Limiting factors: Not many. Archivers periodically call other known components within the network, for example the /netconfig endpoint on core ndoes. While the Node-Fetch will not exhaust CPU or RAM initially, filling the download bandwidth and available networking threads can lead to nasty consequences too. If the target can be successfully made to make more connections to the exploit server, the attack can consume all CPU and RAM and crash the service similarly to Axios.

Shardeum Core nodes

Shardeum nodes primarly uses Got library to perform external requests. Core nodes use Axios library with possibility of triggering the vulnearbility during node startup, network joins and certificate manipulations. The Axios requests target both Archivers and Consensus nodes providing avenue of exploitation using described passive method. Core nodes startups archiver discovery also utilizes lib-archiver-discovery, which uses Axios in a vulnerable way.

Shardeum repository has a dedicated utility for Axios requests located at ./src/utils/requests.ts, which exports vulnerable request methods:

./src/utils/requests.ts
export const shardusGet
export const shardusPost
export const shardusPut
export const shardusGetFromNode
export const shardusPostToNode
export const shardusPutToNode

Core node initiated requests with Axios:

- GET /account/[address]
- GET /api/account?accountId=[accountId]&blockNumber=[blockNrHex]
- GET /archivers
- GET /get-network-account?hash=[true|false]
- PUT /query-certificate
- POST /inject

Limiting factors:

  • During the startup, the Archivers to be connected should be setup in the archivers-config.json and have probably more trust upon them than other, permissionless network components.

  • Certificate query doesn't appear to be triggered very often. Receiving the request with malicious node can be hard.

  • Network account is often (not neccessarily always) fetched from one of these "trusted" archivers, lowering the probability of successful exploitation by a bad actor.

Explorer server

Explorer uses Axios via queryFromDistributor and fetcher methods:

queryFromDistributor:

- POST /cycleinfo
- POST /receipt
- POST /originalTx
- POST /account
- POST /transaction