1. Preventing the network from loading by disconnecting the socket connection between validators and archivers
The socket connection in a Validator listens to an UNSUBSCRIBE event and expects the ARCHIVER_PUBLIC_KEY of an Archiver Server that wishes to unsubscribe.
2. Forcing the new POQo system to fail, preventing the network's ability to process transactions
As soon as a transaction is received, a malicious node spreads to every single node in the network a fake and invalid vote from every node in the execution group.
As a result, when the nodes from the execution group attempt to gossip their votes, their request counts as voting twice for the same TX and is ignored.
At this point, the winner hash - the one with two-thirds of votes or more, which in the case of this attack will be a random and invalid hash distributed by a malicious node - is full of invalid signatures.
The network now enters a state where there are 2 hashes for the transaction:
Hash #1- The hash of a malicious object with only 1 vote (only the malicious node has voted for it) and the signature for that hash is valid.
Hash #2- An invalid hash, with a majority of votes ( "all nodes voted for it" ) but the signatures that verify their vote are invalid, which means they didn't sign that vote.
A chain of problems begins: the verifyAppliedReceipt(...) always returns false, which prevents the gossip route for the POQo poqo-receipt-gossip from succeeding, generateReceiptMapResults complains about an entry in with no receipt in newAcceptedTxQueue, etc.
When reproducing the attack in a running chain, the network stops processing new transactions after the malicious node bricks the consensus system, and it stays bricked (unable to process transactions) even after the malicious node leaves the active set, is kicked out of the network or shuts down himself.
3. Remove unused function getDebugString from core repo
The getDebugString in the VectorBufferStream does not handle the out-of-bounds access correctly, and this results in a TypeError when attempting to read beyond the buffer's limits. This vulnerability can be exploited by a malicious node to cause other nodes sharing the same buffer to crash, and as result disrupting network operations.
4. Double slashing of validators
Shardeum has the concept of a penalty, to slash nodes if they have malicious behavior. For example if a node goes offline while it is in active mode, and stops processing transactions, then other nodes confirm it is a lost node and apply a configurable penalty to that node's staked tokens. But there is a bug in the Shardeum repository which causes the network to apply a penalty 2x of configured value. So when the penalty of leaving the network early is configured to be 20% of staked value, if a validator leaves it loses 40% of its stake.
5. The signature used to Gossip an UnjoinRequest has not replay protection, allowing a malicious node to permanently prevent validators from joining the network again
A node that is in StandBy, can sign and gossip an UnjoinRequest for multiple reasons - for example, if he needs to restart its server before joining the network again.
6. DOS attack against JSON RPC SERVER due to CVE-2024-22019
JSON RPC SERVER uses NODE version 18.16.1 for Dockerfile, which is vulnerable to CVE-2024-22019 (http: Reading unprocessed HTTP request with unbounded chunk extension allows DoS attacks).
7. CSRF missing in validator-gui
CSRF token check is missing in validator-gui
8. Remove unused functions encrypt/decrypt from lib-crypto-utils
There is a presence of a bug in the decrypt function so When a node processes a malformed payload as an example one with improperly formatted or missing fields as the nonce here the decryption function is throws an error and This error is not properly handled, resulting the crash of the node and If multiple nodes receive such payloads, the failure is can lead to a total shutdown of the network, preventing it from confirming any new transactions.
9. DoS attack on peer nodes through gossip-valid-join-requests due to insufficient validations
A malicious node is able to perform DoS attack on peers through gossip-valid-join-requests gossip route due to lack of checks on resource consumption, lack of signature verification and insufficient duplication checks
10. Validator GUI password bruteforcing is possible using the proxies
The only password-bruteforce protection the Validator GUI has is the IP rate-limiting. This protection could be easily bypassed by using a pool of proxy-servers and, thus, the attacker can successfully guess the admin password in a very short time (depending of the password complexity).
11. Complete shutdown of the transaction processing queue by exploiting get_account_data_with_queue_hints handler
The handler of the internal message 'binary/get_account_data_with_queue_hints' is not setting correct bounds for length of the accounts list (Actually it is 2^32). For each account the handler is executing app.getAccountDataByList which is calling AccountStorage.getAccount -> getAccountEntry -> creates and runs SQL query for each account ID. Also the handler is creating fifoLock('accountModification') which is used in the following functions: preApplyTransaction and commitConsensedTransaction. Which are two critical functions for transaction processing. If this fifoLock is occupied by this handler, transaction processing will be slowed down or even stopped. So by sending a big list (2^32) of random accounts it can create a significant delay in transaction processing on the single node.
12. Network split due to the sync issue in P2P module by the sync-cycles handler
Incorrect and insufficient type validation for the sync-cycles P2P http response, leading to the sync issue and the network partition during the sync.
13. Archive-server can be killed by connected shardus-instance
Archive-server is using an outdated socket.io-client. The old implementation has issues with specially crafted packets.
Since Archive-server does not do any special error handling the error in the socket.io-client can bubble up "uncatched" and kill the process.
Since the archive-server tries to randomly connect to a shardus-instance, it might not be a terrifying issue. Otoh I saw references in the documentation that archive servers should be rewarded for their service in the future, so there would be incentive to try to kill archive servers that you don't run …
14. Failure to validate golden ticket admin cert
Failure to validate golden ticket admin cert leading to malicious nodes being able mark themselves golden to get into network bypassing selection algorithm altogether.
15. Cross-chain replay attacks are possible due to a missing 'chainId' check
The chainId transaction parameter is not checked before it's executed, which leads to cross-chain replay attacks.
16. Nodes can exploit an SQL injection vulnerability in the JSON RPC server to delete all data from the database, which would restrict some services
When a transaction is sent to a node using eth_sendRawTransaction in the JSON RPC server, the node returns a value with the field reason. This reason field is later used in an SQL query in die json rpc server without validation. As a result, a node could insert an SQL injection into the reason field to alter or delete data in the database of the JSON RPC server.
17. Sender is not verified in internal routes over binary protocol
The sender of a message received via the internal binary protocol in shardus-core routes is not verified by default, and verification is implemented adhoc only in 2 cases. Failure to verify the sender can break various consensus/voting mechanisms implemented in Shardeum validator nodes. With the currently implemented internal routes, however, I was unable to achieve any dangerous impact with this bug. As such, this report describes an Insight-severity vulnerability.
18. CSRF vulnerability due to missing SameSite=Strict attribute resulting blackhat to perform authenticated action
The access-token was missing SameSite=Strict attribute which leads to CSRF vulnerability resulting in allowing BlackHat to perform authenticated actions.
19. Reflected XSS in validator node endpoints leads to node shutdown via validator-gui
Validator GUI allows users to start running a Shardeum node, which means having the external endpoints be hosted using HTTP on a different port on the same server. This opens a door for client-side vulnerabilities which can be executed Same-Site (Same Origin vs Same Site info: https://web.dev/articles/same-site-same-origin#site). The only protection validator-gui has from attacks such as CSRF is Same-Site Strict cookies. As suggested from the name, they can't protect from attacks within the same site.
As such, achieving XSS on one of the validator node (Shardeum node) endpoints allows access to validator-gui cookies and authorized endpoints. Currently, this allows an attacker to leverage an XSS in order to shut down the node via validator-gui's API.
20. eth_feeHistory block range limit
The json rpc server allows the user to request the fee history however due to lacking limitations the user can potentially DOS the rpc server or the explorer.
21. Revise impact of corner case in DATASYNC robustQuery
The improper exception handling in the robust query logic introduces a vulnerability. Despite the internal comments suggesting exceptions should not be thrown when insufficient votes or responses prevent a robust result, the code contradicts this by throwing an error when isRobustResult is false. This issue could lead to unnecessary service interruptions or system restarts, potentially affecting data integrity and system availability.
22. XSS in json rpc server without CSP bypass
To send error information on the /log/tsx endpoint, the application uses res.send() function that returns HTML response. It's possible to cause an error in sqlite3 query by providing a query with null byte. The error message would return all the provided data so we have a reflected html injection.
23. Blocking the user from interacting with GUI via rate-limiting abuse
Since an exceeding of the Rate Limiting blocks any requests from the affected IP address to the Validator GUI API, an attacker can easily abuse this and temporary block user from interaction with the app.
Attacker can craft the malicious page sending at least 1500 request to the Validator API and lure a victim into visiting it. After just a few seconds, the victim's IP will be blacklisted and thus he won't be able to interact with the Validator GUI in the next 10 minutes.
Comments
0 comments
Article is closed for comments.