# 32942 - \[BC - Low] The ChainID and URL parameters that can modify ... Submitted on Jul 8th 2024 at 15:54:16 UTC by @infosec\_us\_team for [Boost | Shardeum: Core](https://immunefi.com/bounty/shardeum-core-boost/) Report ID: #32942 Report type: Blockchain/DLT Report severity: Low Target: Impacts: * Network not being able to confirm new transactions (total network shutdown) ## Description ## Brief/Intro Shardus server provides two modes; **Debug**, which omits signature checks in sensitive endpoints for an easier developer experience, and **Release** which enforces them for security reasons. In this report, we'll demonstrate how the authentication check on `shardus-core/src/network/debugMiddleware.ts` can be bypassed, allowing several behaviors, for example: unauthorized modifications to the server configuration of a Shardus Validator making it unable to confirm new transactions. ## Vulnerability Details As a reference, below is the code of the flagged function that checks if requests to sensitive endpoints are authorized when running in `release` mode - the original version is extensive so only the parts relevant to this report were kept. ```javascript // This function is used to check if the request is authorized to access the debug endpoint function handleDebugAuth(_req, res, next, authLevel) { try { //auth with a signature if (_req.query.sig != null && _req.query.sig_counter != null) { const devPublicKeys = getDevPublicKeys() // This should return list of public keys const requestSig = _req.query.sig // Check if signature is valid for any of the public keys for (const ownerPk in devPublicKeys) { let sigObj = { route: _req.route.path, count: String(_req.query.sig_counter), sign: { owner: ownerPk, sig: requestSig }, } // ........... let verified = Context.crypto.verify(sigObj, ownerPk) if (verified === true) { const authorized = ensureKeySecurity(ownerPk, authLevel) if (authorized) { lastCounter = currentCounter next() return } else { // ........... } ``` > Snippet of code from: The address with the correct authorization level must sign an object with the route of the request and a counter that prevents replay attacks. ``` let sigObj = { route: _req.route.path, count: String(_req.query.sig_counter), } ``` The counter is provided as a param in the URL (`& sig_counter=`) and the route is taken from the value of the `_req.route.path` variable. ### The problem: Signing only the path to the endpoint, instead of the full URL including the parameters Let's use the URL that modifies the configuration of a running validator to demonstrate the bug. In this URL: ** The `_req.route.path` is: */debug-set-shardeum-flag* The authorized address intends to set the value of **debugTraceLogs** to **false**, and sends the request with a signature of the route path (`_req.route.path`) and a `sig_counter`. Unfortunately, because the `key` and `value` parameters of the URL were not signed a malicious actor can use the same signature and sig\_counter to change any shardeum flag in the server, like the `ChainID` which would render the server unable to process new transactions due to a ChainID mismatch. The reason is that this malicious URL ** which includes the same `_req.route.path`, `sig_counter` and `sig`, passes all checks even though it modifies a value that was not intended to be touched. > Up to this point in the report, for the reader will seem like the "*replay attack check*" will prevent the same `sig_counter` value from being used twice, forcing the malicious actor to intercept, modify, and send his malicious HTTP request before the legit one is processed. > > In the next section we'll talk about one of the ways to deal with the replay attack check, making attacks more feasible. ### Reusing signatures from "testnet"/"devnets" in "mainnet" The ChainID should be required to be signed in every request to a sensitive Validator endpoint, assuring that signatures from testnets and development setups running the "Release" mode for testing purposes can't be re-used in mainnet. Currently, the only requirement for the signature to be valid is to be signed with the route path and a sig\_counter bigger than the previous one, therefore a request to a non-mainnet Validator in "Release" mode can have its parameters **modified** to cause unauthorized behaviors, and be used in mainnet against the same Validator. ## Impact Details There are many potential impacts, depending on the type of signature the attacker malleates, for example, using a signature to the path `/debug-set-shardeum-flag` will render a validator unable to process new transactions. ## Proof of Concept As a proof of concept, create a Node JS project and use express to log the value of the `req.route.path`. The output of the console shows it only includes the exact defined route, but no query params. > We don't believe that using `req.route.path` in the Shardus Core is a problem by itself, the problem is to not check any of the params sent within the transaction when calculating the signature, which allows for unintended results. ``` const router = (require('express')).Router(); router.get('/some/:long/:path', (req, res) => { console.log(req.route.path); // exact defined route res.sendStatus(200); }); module.exports = router; ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reports.immunefi.com/shardeum-core/32942-bc-low-the-chainid-and-url-parameters-that-can-modify-....md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.