Address: ALessioRJeVFrDBD2tckrT3fTvsZzESocA
Rank 49
Voters 98
Vote Weight 1,322,010 Ѧ
Shares Rewards
Payout 0%
Payout min 0 Ѧ
Payout Max 0 Ѧ
Payout Interval 0h
Core-SV-061 Created on: 2020-09-23 15:23:22

Not yet disclosed

Core-SV-060 Created on: 2020-09-23 15:23:17

Not yet disclosed

Core-SV-059 Created on: 2020-09-17 22:16:57

Not yet disclosed

Core-SV-058 Created on: 2020-09-17 22:16:53

Not yet disclosed

Core-SV-057 Created on: 2020-09-10 11:41:54

HTTP header manipulation caused out of memory crashes: It was possible to coerce ARK Core to download any arbitrary file from a remote server by transmitting a HTTP 303 header response to the peer communicator. If the downloaded file was gzip compressed, it was automatically decompressed and stored in memory, potentially expanding to many times its original size. A specially crafted compressed file could grow too large, triggering an out of memory error which would crash the node.

Core-SV-056 Created on: 2020-08-11 16:20:51

Prepending zeros in the hex representation of a signature would change its ID: For the purpose of cryptographic verification, R and S components of ECDSA signatures are integers, but the hashing process used by Core to calculate the ID of a transaction or block uses their byte sequence instead. Core did not check for the presence of extra zeros at the start of either the R or S components of a signature, so prepending extra zeros to either component would change the ID of any block or transaction since this would modify the byte sequence, while remaining cryptographically verified as the extra zeros were ignored during verification since that process uses the integer values instead. This meant transactions could have been replayed on non-AIP11 networks since they would have had new IDs, and it could have also led to forking of the network if multiple blocks were propagated at the same height with different block IDs.

Core-SV-055 Created on: 2020-07-22 11:37:56

Negative values were erroneously accepted in ECDSA signatures: Core did not check for negative values in the R or S components of ECDSA signatures, which are not allowed in the specification. This meant that it was possible to maliciously modify an existing valid signature to include negative values for either R or S and this signature would still erroneously verify as true, since the values were internally normalised as positive integers. However, by doing so, the block or transaction would have a different ID, potentially leading to transaction replay on non-AIP11 networks or network forks due to conflicting blocks being propagated at the same height.

Core-SV-054 Created on: 2020-07-22 11:37:53

DER signature manipulation could fork the network, roll back and replay transactions: Blocks and transactions signed with DER encoded signatures could be manipulated by appending extra data to the end of the signature outside of the R and S values. This meant the transactions and blocks were still cryptographically valid but would have a different ID, allowing for transaction replay on non-AIP11 networks and to persistently fork the network by propagating different blocks at the same height.

Core-SV-053 Created on: 2020-07-22 11:37:49

Pool poisoning could stop delegates forging any transactions: There was a low limit on the number of transactions returned from the transaction pool for inclusion in a new block prior to filtering them. A bad actor could repeatedly spam the pool with hundreds or thousands of invalid transactions with a very high fee - which, as they were invalid, would never be forged, so the actual cost was zero - but the high fee meant they would take precedence over all genuine transactions in the pool, so after filtering, the block would be empty.

Core-SV-052 Created on: 2020-07-22 11:37:45

Port ping payload sizes were unchecked and could cause bandwidth flood attacks: It was possible to craft a malicious HTTP GET response to the peer communicator to redirect traffic to a third party server. This could have been used, among other possibilities, to download very large multi-gigabyte files to consume all the bandwidth of a node.

Core-SV-051 Created on: 2020-07-22 11:37:41

Slow PostgreSQL query attack could have caused delegates to miss blocks: Filling enough blocks with transactions to make a large cumulative payload and then repeatedly calling p2p.peer.getBlocks to download that set of blocks from multiple IP addresses at the same time every second could make any forging node miss blocks. This was because of a slow query which took too long to complete in those circumstances, which caused significantly elevated CPU usage on the main process. This could quickly amplify as new requests could be made before all the previous ones were completed, continually stacking more requests on top of the existing ones until the database was overwhelmed.

Core-SV-050 Created on: 2020-07-22 11:37:37

Consecutive big blocks could exceed the maximum payload limit: By repeatedly sending large transactions to fill consecutive blocks, it was possible to exceed the maximum permitted client-side payload limit for any WebSocket connection. This would trigger peer bans when trying to download a batch of blocks that exceeded this payload size and meant no new nodes could ever join the network as they would not be able to download a batch of blocks exceeding this limit, thus preventing any new relays from syncing with the network.

Core-SV-049 Created on: 2020-06-18 08:40:47

ECDSA-signed block and transaction signatures were malleable: Transactions and blocks signed using ECDSA could have their signatures recalculated to generate new IDs for the transactions or blocks, while still remaining cryptographically verified. This could have been used to replay existing transactions on networks where AIP11 was not active, and in all cases, could have been used to repeatedly cause forks by recalculating the signatures of incoming blocks and broadcasting the recalculated blocks onwards, since this would lead to multiple different but valid blocks at the same height on the network.

Core-SV-048 Created on: 2020-06-18 08:40:43

Delayed completion of peer verification stopped nodes forging: It was possible to stop delegates from forging by delaying the peer verification process when a node was due to forge. As a forging node enters its slot, it re-verifies its peers by sending a p2p.peer.getStatus request to all of its peers. If a peer responds with a higher height than its own height, the node will query that peer further via p2p.peer.getBlocks to fetch the block(s) at the higher height to verify they are not forked. A malicious peer could respond with a deliberately higher height and then delay the ensuing response to p2p.peer.getBlocks until the forging slot was over, so the peer verification would not complete and the delegate would miss its slot.

Core-SV-047 Created on: 2020-06-18 08:40:39

Block ID-based exceptions were vulnerable to preimage attacks and blockchain poisoning: Block IDs can be added as exceptions which are accepted even if they fail verification but there was no check to ensure the correct transactions were inside the excepted blocks. This meant that transactions could be mutated or changed entirely inside of excepted blocks and the node would still accept them since it no longer mattered that the block would not pass verification checks.

Core-SV-046 Created on: 2020-06-18 08:40:31

Block schema violations could halt the blockchain: It was possible to stop a node from receiving new blocks by sending a single block to it via p2p.peer.postBlock which contained a chained block header with a numberOfTransactions value greater than 0 but where no transactions were included in the block. This caused an error to be thrown which stopped the processing queue indefinitely.

Core-SV-045 Created on: 2020-05-27 11:59:53

Induced slow block propagation forked the network: Specially crafted payloads could be constructed to target either the public API or the peer-to-peer layer which would cause a delegate to delay sending its newly forged block until the next forging slot. This could cause a whole network fork since it would result in two conflicting blocks being propagated at the same height.

Core-SV-044 Created on: 2020-05-12 10:41:48

Marshalled block payloads using the peer-to-peer transport codec were not sanitised: Core 2.6 introduced a new p2p transport codec for blocks, but any payload using this codec was not sanitised properly. The end result was that additional objects could be added to the payload data if the new transport codec was used, which could have been exploited to stop delegates forging by overwhelming their servers with too many concurrent objects.

Core-SV-043 Created on: 2020-05-12 10:41:43

Tree memory structure exceeded maximum call stack size when fetching unconfirmed transactions to forge: By continually filling the transaction pool with valid transactions with an increasing fee of one arktoshi each time, the call to getUnconfirmedTransactions when forging would error out as the maximum call stack size would quickly be exceeded. At that point the network would stall as nobody would be able to forge any new blocks since the call to request the transactions to forge would always fail.

Core-SV-042 Created on: 2020-04-28 21:19:27

Nonce comparison took too long to complete when fetching unconfirmed transactions to forge: By continually filling the transaction pool with valid transactions, it will grow at a rate faster than the transactions in the pool can be consumed by forging blocks on the network. When it reached a certain threshold (amount varies depending on node specification, but always before reaching the upper limit even on the most powerful nodes), the call to getUnconfirmedTransactions would time out due to the nonce comparison in the transaction pool.

Core-SV-041 Created on: 2020-04-09 23:46:29

Overloading the public API could stop the transaction and block processing on a node: The public API could have been overloaded to stop a node from processing any incoming transactions or blocks by opening simultaneous requests to the /api/blocks or /api/transactions endpoints.

Core-SV-040 Created on: 2020-04-09 23:45:35

Long-lived HTTP requests via the P2P layer could crash the node: It was possible to bombard a peer with long-lived HTTP requests by opening a connection to the correct /socketcluster/ path, but never upgrading the connection to a WebSocket. This connection could have been kept alive by sending a HTTP header every second (e.g. Host: X.X.X.X over and over again in a 1 second loop) and never sending the Upgrade: websocket or Connection: upgrade headers. The consequence of this was the ability to overload the server with open TCP sockets that are never established as WebSockets (so rate limit protections never kick in), once again leading to a situation where an attacker could spawn thousands of connections to use up all the node's file descriptors to crash the underlying operating system.

Core-SV-039 Created on: 2020-04-09 23:45:06

Pool wallet manager could lock up funds by not updating multipayment balances: The transaction pool wallet manager balance did not always increase when receiving a multipayment transaction. This was because transactionHandler.applyToRecipient in acceptChainedBlock was only called if there was a matching recipientId already in the pool wallet manager. Multipayments could have been manipulated to lock the amount of the multipayment to prevent the recipient from accessing the funds as their pool wallet manager balance did not increase if the recipient's address was present in the pool wallet manager but the sender's address was not. This prevented the recipient from sending a transaction for an amount that is greater than the sum of non-multipayment transactions in their account.

Core-SV-038 Created on: 2020-03-11 16:19:41

Plain HTTP connections to the p2p port could crash the node's operating system: Core did not block any connections to any invalid HTTP paths accessed via the p2p layer's underlying HTTP server, so a user could send thousands of plain HTTP connections to invalid paths and these connections would remain open. It was possible crash a server by using a cluster of attack nodes to establish hundreds of thousands of connections to use all available file descriptors.

Core-SV-037 Created on: 2020-02-04 13:18:22

A malicious block containing thousands of transactions could take down a node: A malicious user could keep sending bad blocks containing thousands of transactions inside them. As all the transactions inside the blocks were verified and validated, this maxed out the CPU usage and prevented nodes from operating correctly.

Core-SV-036 Created on: 2020-02-04 13:18:14

Opening thousands of sockets caused high CPU/memory usage and full server crashes: It was possible for an attacker to open thousands of connections to a node because there was no filtering to prevent multiple connections per originating IP address. Each active connection used a file descriptor in the operating system, and the number of available file descriptors is limited. An attacker could open enough simultaneous connections to use all the available open file descriptors on a node, which would crash it completely, since the operating system was no longer able to open any files.

Core-SV-035 Created on: 2020-02-04 13:18:07

Broadcasting invalid WebSocket opcodes caused significant network degradation and missed blocks: Sending malformed WebSocket packets with reserved or unimplemented opcodes would trigger the socket's onerror event handler, but Core did not listen for this event and the connection was not blocked. The process of repeatedly throwing the error was sufficiently computationally expensive that it was possible to take down a node and stop it forging by sending a constant stream of malformed packets.

Core-SV-034 Created on: 2020-02-04 13:17:52

Unhandled unemitted events could trigger high CPU spikes and propagation delays: Core only incremented the rate limiter when the SocketCluster emit event was fired, but there were some circumstances where specially crafted payloads would not trigger this event. This meant that anyone could flood a node with such messages which did not increment the rate limiter.

Core-SV-033 Created on: 2020-02-04 13:17:36

JSON payloads with too many key-value pairs were too CPU intensive to parse: There was a Denial of Service security vulnerability inside the P2P layer which could be triggered by sending valid JSON strings to valid endpoints, but where the JSON string contained too many key-value pairs. This was too time consuming to parse, so a node was unable to process other business, leading to missed blocks and an inability to forge.

Core-SV-032 Created on: 2020-01-07 20:59:49

Multiple disconnect JSON packets caused high CPU utilisation: A user could maliciously craft a disconnect JSON packet and constantly send it in a loop to overwhelm a node. As it was a perfectly valid packet, it did not get caught by any of the sanitisation checks that were in place, which had the effect of stalling nodes so they could not handle genuine traffic.

Core-SV-031 Created on: 2020-01-07 20:59:12

Sending HyBi WebSocket headers with no data could stop nodes forging: It was possible to stop a node forging or miss its slot by continually sending payloads containing only a HyBi WebSocket header that signals a data frame, but one that actually contained no data. The effect was that the worker processes hit 100% CPU usage and could not complete their tasks fast enough to keep up with the network.

Core-SV-030 Created on: 2019-11-24 03:50:09

Ping control frame bombardment could prevent block propagation: Every time a node's WebSocket received a ping control frame, it would reply with a pong control frame. If a node was spammed with ping control frames, the node workers would reach 100% CPU usage by continually sending pong control frames back to the client, so they would struggle to cope with genuine requests. This meant that delegates were too resource-starved to forge in time, leading to either missed blocks or delayed blocks on the network.

Core-SV-029 Created on: 2019-10-02 11:16:38

Externally hitting internal P2P endpoints could stop a node handling requests: Accessing an internal endpoint from an external unauthorised connection would send an Unauthorised error message to the client, but the socket would still be connected. As the connection remained open, in certain circumstances it was possible to trigger a node to continually send Unauthorised messages to block its workers so they could no longer process legitimate requests.

Core-SV-028 Created on: 2019-09-25 11:58:10

Rate limiting was ineffective due to inappropriate disconnection methods: Connections that exceeded the rate limit were gracefully disconnected by sending a Forbidden error message to the client, along with a close WebSocket frame. If a node was spammed with requests exceeding the limit, the node workers would reach 100% CPU usage by continually sending these messages and frames back to the client, so they would struggle to cope with genuine requests. This meant that delegates were too resource-starved to forge in time, leading to either missed blocks or delayed blocks on the network.

Core-SV-027 Created on: 2019-09-25 11:57:45

Malformed messages on the P2P layer could hang up a node and stop delegates forging: It was possible to take down a node and either stop it forging or delay its block propagation to fork the network by exploiting a weakness in SocketCluster by sending raw payloads to the node that did not conform to the SocketCluster JSON format.

Core-SV-026 Created on: 2019-08-28 17:07:32

P2P endpoint request events were not sanitised: Spamming nodes with multiple simultaneous requests to invalid websocket endpoints on the peer-to-peer layer with large payload sizes created a memory leak. This killed the socket workers and prevented delegates from forging.

Core-SV-025 Created on: 2019-08-28 17:06:55

Core plugin names were not length restricted so could cause DoS in peer lists: There was no limit to the length of plugin names returned in peer lists. This could have been used to conduct a bandwidth flood attack by setting up a malicious node to send massive strings as plugin names resulting in overlength peer list responses that could not be processed in time due to their excessive size.

Core-SV-024 Created on: 2019-08-02 12:10:09

Peer lists could become too large and be manipulated to become a DDoS network: There was no limit to the number of peers that could be added to peer lists. This could lead to extremely large peer lists being shared across peers which could not be processed in sufficient time, leading to delegates being unable for forge blocks as their nodes would be too busy processing the large amount of peers. Furthermore, if IP addresses of non-Core peers were maliciously added in bulk, this could lead to all legitimate peers being used as an unintentional DDoS network.

Core-SV-023 Created on: 2019-08-02 12:09:59

Peer-to-peer postTransactions endpoint could be spammed to overwhelm nodes: The postTransactions peer-to-peer websocket endpoint could be spammed with bundles of invalid or expired transactions. The cryptographic process of verifying all those transactions would overwhelm a node to prevent it from being able to keep up with the network. It would stop receiving blocks and delegates would be unable to forge. Since the spam transactions were invalid or expired, they would never be forged.

Core-SV-022 Created on: 2019-07-02 19:28:50

Delegates could be forced to forge empty blocks and genuine transactions could be evicted from the pool: Unforgeable transactions could fill the transaction pool to prevent genuine transactions being forged as the forging process would retrieve transactions up to the maximum transactions per block size, filter away the invalid ones and return the result. This could possibly return zero valid transactions after filtering if the transaction pool contained more than the maximum number of transactions per block of unforgeable transactions with a higher fee than the genuine transactions. Additionally, sending a high volume of these invalid transactions could evict genuine transactions from the transaction pool at zero cost to an attacker.

Core-SV-021 Created on: 2019-06-28 13:57:14

Unverified transactions in bad blocks could purge genuine transactions from the pool: When a block was rejected for failing verification, any transactions from the sender(s) of any transactions in the block were purged from the transaction pool, even if they failed verification. This meant anybody could create a bad unverified block containing fake transactions to delete genuine transactions from that wallet from the transaction pool.

Core-SV-020 Created on: 2019-06-11 16:21:51

Race condition resulted in blocks containing already forged transactions: If a node received a high volume of transactions entering the transaction pool in a short time period, it would not filter out all the recently forged transactions from incoming blocks. This meant that when a delegate tried to forge, it may have included already forged transactions in its block, which would then be rejected by the network, causing the affected delegates to miss blocks until their pools were cleaned.

Core-SV-019 Created on: 2019-06-06 10:47:49

Block header manipulation in quorum calculations prevented nodes forging: Forging nodes could be tricked into thinking they were double forging, even when they were not. This activated the automatic protection which stopped the nodes from forging. As the delegates were not actually double forging in the first place, they did not produce any blocks. If all delegates were targeted, the chain completely stopped.

Core-SV-018 Created on: 2019-05-28 19:38:15

A forged second signature registration did not invalidate existing transactions from the same sender in the transaction pool: It was possible to stall the blockchain by manipulating second signature registrations. It involved broadcasting a transaction from a wallet without a second signature, then registering a second signature for that wallet which was forged prior to the initial transaction being forged.

Core-SV-017 Created on: 2019-04-22 14:07:07

Transactions signed with a second signature prior to the second signature registration being forged halt the blockchain: A node that received a second signature registration, immediately followed by a transaction signed with that second signature prior to the second signature registration being forged in a block, would be unable to forge a new block as the second transaction was accepted by the node and added to its transaction pool but would not validate in a block since the second signature registration was not forged yet. As transactions are broadcasted to all nodes, this would stop the chain until the pools were cleared as nobody would be able to forge a block.

Core-SV-016 Created on: 2019-04-22 14:07:01

Receiving a block containing non-valid transactions causes peers to roll back: A received block containing a transaction that cannot be applied causes all peers to roll back. The accept block handler triggered a rollback if a block contained a transaction that cannot be applied, which was unnecessary when it was a case that the current block could not be applied due to the transactions within it.

Core-SV-015 Created on: 2019-04-22 14:06:57

Delayed block propagation causes the next delegate to miss its block: If a delegate forged a block but was late broadcasting it, the next delegate in line would forge at the wrong height as it would not have received the previous block. By the time it attempted to broadcast the block, the previous delegate's delayed block would have been received by most (or all) of the network, meaning the newly forged block at the same height would be rejected and thus the delegate would miss its slot.

Core-SV-014 Created on: 2019-03-19 18:59:29

Public API endpoint open to possible DDOS attack: Endpoint /api/v2/delegates/{delegate}/voters/balances did not paginate its results. This was a vector for DDoS as anyone could request the vote balances of every voter of a delegate in one API call. For delegates with large number of voters (>5000) this could overload the server even before the HTTP rate limiting kicked in.

Core-SV-013 Created on: 2019-02-14 15:42:16

Transactions near to the HTTP POST payload size limit can stop delegates forging and halt the chain: The maximum HTTP POST payload is 1048576 bytes but there was no logic to ensure that blocks only contained transactions that would fit in a block below that size limit. It was possible for any network user to send deliberately oversized transactions that would approach (but not exceed) this limit. Although nodes would accept these larger transactions as valid, when it was time to forge them into a block, the additional block headers would make the block size larger than 1048576 bytes. This meant all nodes would reject the block with HTTP error 413 Request Entity Too Large, so the forging node would miss its block and the oversized transactions would remain in the transaction pool, meaning the node would be unable to forge until the oversized transactions expired (the default time being 6 hours).

Core-SV-012 Created on: 2019-02-11 22:58:25

Conflicting delegate registration transactions not detected by the transaction guard: A user could try registering the same delegate name using multiple wallets in a single block. It would result in a stalled network because no delegate would be able to forge a valid block as they would all try to forge blocks containing the conflicting transactions. If exploited maliciously, any bad actor could have stalled the network permanently by repeatedly sending conflicting transactions to ensure the transaction pools were never clean so the network could not recover.

Core-SV-011 Created on: 2019-02-01 01:37:50

Malicious delegate 0-ARK transaction spam: The transaction schema to prevent zero-amount transfer transactions was never enforced by consensus, so zero-amount transfer transactions could be sent by a malicious delegate to spam the blockchain.

Core-SV-010 Created on: 2019-02-01 01:35:55

Malicious delegate can cause peers to fork and roll back simultaneously: A malicious delegate could craft a block at the correct height but with a timestamp from a previous round that collided with a valid forging slot time for that delegate in the current round. This has the result that the block would be initially accepted, but, because the block was unchained due to the incorrect timestamp, it would cause the receiving node to immediately enter fork recovery mode and roll back the chain.

Core-SV-009 Created on: 2019-02-01 01:34:25

Fake peers can be added by using non-quad-dotted notation: Peers using non-quad-dotted notation representation could be added to peer lists, which provides a denial of service vector as millions of IPv4 loopback addresses could be added to the peer list which will all resolve to the local node which would overwhelm the server.

Core-SV-008 Created on: 2019-01-25 19:43:29

Forged blocks by anyone can cause the chain to stop/or start recovering: Anyone can broadcast signed blocks, and when receiving a forged block from a wrong generator, the chain would fork. This also applied to inactive (unknown) generators. If a malicious actor kept broadcasting such blocks, the chain would effectively cease operating.

Core-SV-007 Created on: 2019-01-25 19:43:17

Forging multiple blocks in a slot and rewards hijacking: Any active delegate could forge multiple blocks within their allocated 8 second slot time, as long as the block IDs were different and were all sent to the same node with an incrementing block height, as each block was considered to be valid and accepted on the chain. This had the effect of generating block rewards for each of the multiple blocks that were forged in the slot, resulting in inflated rewards per round for any delegate that carried out this exploit.

Core-SV-005 Created on: 2019-01-25 19:43:08

Double forging a block: A malicious forger could forge multiple distinct blocks and broadcast them to different peers causing instability in the network.

Core-SV-004 Created on: 2019-01-25 19:42:57

IP spoofing: The whitelist could be bypassed by IP spoofing due to the way Core determined the IP of a request. This could also be used to fill up the peer list with loopback IP addresses to cause a DoS attack and prevent block propagation.

Core-SV-002 Created on: 2019-01-25 19:42:46

Generating new ARK using multi signature transaction: In a multi-signature transaction, the transaction handler only verified the signatures and did not properly conduct balance checks. This made it possible to generate new ARK tokens on the network utilising a multi-signature transaction.

Core-SV-001 Created on: 2019-01-25 19:37:32

Invalid block received: The lastDownloadedBlock variable was not reset when discarding invalid blocks. This caused network nodes to continually attempt to download new blocks from the wrong height, effectively halting the network. This issue would have allowed a malicious user to disrupt network nodes and the network itself.

Copyright 2020 ItsANameToo