logos-storage/logos-storage-research
1
0
Fork 0
mirror of https://github.com/logos-storage/logos-storage-research.git synced 2026-01-02 13:33:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Wrap text content

Browse Source
This commit is contained in:
Arnaud 2025-04-17 10:02:32 +02:00
parent 12497badb0
commit 168ab47e3b
No known key found for this signature in database
GPG Key ID: 69D6CE281FCAE663
1 changed files with 100 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
evaluations/threat-modeling.md
View File

@ -2,16 +2,25 @@
## Introduction
The goal of this threat modeling is to identify potential security vulnerabilities in the Codex protocol, enabling us to take actions to mitigate them. Additionally, it can serve as a starting point for directives in a security audit. The scope includes the [Nim codebase](https://github.com/codex-storage/nim-codex) and the [marketplace smart contracts](https://github.com/codex-storage/codex-contracts-eth).
The goal of this threat modeling is to identify potential security vulnerabilities in
the Codex protocol, enabling us to take actions to mitigate them. Additionally, it can
serve as a starting point for directives in a security audit. The scope includes the
[Nim codebase](https://github.com/codex-storage/nim-codex) and the
[marketplace smart contracts](https://github.com/codex-storage/codex-contracts-eth).
## Methodology
The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build an analysis.
The [PASTA][2] framework was considered but is more business-oriented and suited for mature projects. Additionally, its process is heavier than STRIDE's.
The [STRIDE][1] framework is used due to its simplicity and the ability to quickly build
an analysis.
The [PASTA][2] framework was considered but is more business-oriented and suited for mature
projects. Additionally, its process is heavier than STRIDE's.
Threat modeling is an iterative process, requiring constant updates as features are added or modified in the codebase. Documenting potential security vulnerabilities helps developers to keep them in mind during the code implementation.
Threat modeling is an iterative process, requiring constant updates as features are added or
modified in the codebase. Documenting potential security vulnerabilities helps developers to
keep them in mind during the code implementation.
Anyone is invited to contribute to this document, as it is a [collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task.
Anyone is invited to contribute to this document, as it is a
[collective effort](https://www.threatmodelingmanifesto.org) rather than a one-person task.
## Analysis
@ -29,13 +38,18 @@ Anyone is invited to contribute to this document, as it is a [collective effort]
## Spoofing
Threat action aimed at impersonating users or storage providers to access or manipulate files and contracts in the network.
Threat action aimed at impersonating users or storage providers to access or manipulate
files and contracts in the network.
### Phishing-Induced spoofing
#### Scenario
When starting a Codex node, the user must load his private key to pay for initiating new storage requests. This private key is loaded into memory, and there is no authentication process to use the REST API. An attacker could reach the user via email phishing, pretending to be from Codex. The email might redirect to a malicious website or include a form that, upon the user's click, triggers a request to the Codex node to create a new storage request.
When starting a Codex node, the user must load his private key to pay for initiating new
storage requests. This private key is loaded into memory, and there is no authentication
process to use the REST API. An attacker could reach the user via email phishing,
pretending to be from Codex. The email might redirect to a malicious website or include a
form that, upon the user's click, triggers a request to the Codex node to create a new storage request.
```
──────
@ -96,23 +110,34 @@ Edit/view: https://cascii.app/437bc
This could lead to two issues:
- **Financial Loss**: Malicious requests drain user wallet funds
- **Unwanted Content**: Attackers force storage of insecure or illegal files via malicious CIDs, risking legal or reputational harm.
- **Unwanted Content**: Attackers force storage of insecure or illegal files via
malicious CIDs, risking legal or reputational harm.
#### Mitigation
Typically, such web phishing attacks are mitigated by authentication or a [custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy.
Typically, such web phishing attacks are mitigated by authentication or a
[custom header](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#employing-custom-request-headers-for-ajaxapi) to verify the request’s legitimacy.
However, Codex does not have an authentication mechanism, making options like CSRF tokens impractical and using a custom header would provide a poor user experience in Codex, as users would need to set the header manually, which is cumbersome and error-prone.
However, Codex does not have an authentication mechanism, making options like CSRF
tokens impractical and using a custom header would provide a poor user experience
in Codex, as users would need to set the header manually, which is cumbersome and error-prone.
Users can reduce the risk of significant fund drainage by employing a hot wallet with a small amount of tokens designated for storage requests, while keeping the majority of their funds in a cold wallet. This limits the exposure to phishing attacks, as only the tokens in the hot wallet are at risk. For example, a user might allocate just enough tokens to cover typical storage needs, minimizing potential losses.
Users can reduce the risk of significant fund drainage by employing a hot wallet with
a small amount of tokens designated for storage requests, while keeping the majority
of their funds in a cold wallet. This limits the exposure to phishing attacks, as only
the tokens in the hot wallet are at risk. For example, a user might allocate just enough
tokens to cover typical storage needs, minimizing potential losses.
While this strategy mitigates the financial impact of unwanted storage requests, it does not address the storage of unwanted or illegal content. An attacker could still trick the user into storing harmful files via phishing.
While this strategy mitigates the financial impact of unwanted storage requests, it does
not address the storage of unwanted or illegal content. An attacker could still trick the
user into storing harmful files via phishing.
### Same-Chain attack replays
#### Scenario
An attacker reuses a user’s signed transaction on the same chain to spoof additional requests, attempting to drain funds.
An attacker reuses a user’s signed transaction on the same chain to spoof additional
requests, attempting to drain funds.
```
──────
@ -171,13 +196,17 @@ Edit/view: https://cascii.app/b28b7
#### Mitigation
Include a unique, random `nonce` in the request data. This ensures signatures are unique per request, preventing reuse on the same chain. Codex’s current implementation includes this, fully mitigating the threat.
Include a unique, random `nonce` in the request data. This ensures signatures are unique
per request, preventing reuse on the same chain. Codex’s current implementation includes
this, fully mitigating the threat.
### Cross-Chain attack replays
#### Scenario
An attacker captures a user’s signed transaction from one chain and replays it on another with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain, validates without needing the user’s private key, spoofing their intent.
An attacker captures a user’s signed transaction from one chain and replays it on another
with an identical `Marketplace.sol` contract. The signature, publicly visible in blockchain,
validates without needing the user’s private key, spoofing their intent.
```
──────
@ -242,13 +271,16 @@ Edit/view: https://cascii.app/9951e
#### Mitigation
Implement EIP-712 to include chain-specific data in signed transaction, ensuring signatures are valid only on the intended chain and preventing unauthorized replays on other chains.
Implement EIP-712 to include chain-specific data in signed transaction, ensuring
signatures are valid only on the intended chain and preventing unauthorized replays
on other chains.
### Client spoofing via API
#### Scenario
A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`. Worse, he confuses port forwarding and enable it for the REST API as well.
A user starts a node locally and uses `api-bindaddr` with the value `0.0.0.0`.
Worse, he confuses port forwarding and enable it for the REST API as well.
```
──────
@ -291,21 +323,26 @@ Edit/view: https://cascii.app/b762d
#### Impacts
- **Node full control**: Attackers can send unauthorized API requests, draining funds or storing illegal content.
- **Node full control**: Attackers can send unauthorized API requests, draining funds
or storing illegal content.
#### Mitigation
Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he is doing and not enabling the port forwarding for the REST API. A warning during the startup could be displayed if `api-bindaddr` is not bound to localhost.
Educate the user to not use `0.0.0.0` for `api-bindaddr` unless he really knows what he
is doing and not enabling the port forwarding for the REST API. A warning during the
startup could be displayed if `api-bindaddr` is not bound to localhost.
## Tempering
Threat action aimed at altering stored files, proofs, or smart contracts to disrupt the network.
Threat action aimed at altering stored files, proofs, or smart contracts to disrupt
the network.
### Fake proofs
#### Scenario
After the Codex contract starts, a storage provider stops storing the data and attempts to send fake proofs, claiming they are still hosting the content, using initial data received.
After the Codex contract starts, a storage provider stops storing the data and attempts
to send fake proofs, claiming they are still hosting the content, using initial data received.
```
──────
@ -356,18 +393,25 @@ Edit/view: https://cascii.app/9de0e
#### Impacts
- **Financial**: Attackers attempt to earn contract rewards at the end of the contract without storing the file.
- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability.
- **Financial**: Attackers attempt to earn contract rewards at the end of the contract
without storing the file.
- **Availability**: The slot becomes unavailable from that storage provider, reducing
network reliability.
#### Mitigation
Codex issues periodic random challenges based on blockchain randomness to verify that storage providers hold the data. Each failed challenge slashes the provider’s collateral. After multiple failed proofs, the provider is removed from the contract, freeing the slot for another provider.
Codex issues periodic random challenges based on blockchain randomness to verify that
storage providers hold the data. Each failed challenge slashes the provider’s collateral.
After multiple failed proofs, the provider is removed from the contract, freeing the
slot for another provider.
### markProofAsMissing re-entrency
#### Scenario
A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering the function during an external token transfer, allowing multiple slashes and rewards for a single missed proof within one transaction.
A validator could exploit a reentrancy vulnerability in `markProofAsMissing` by re-entering
the function during an external token transfer, allowing multiple slashes and rewards
for a single missed proof within one transaction.
```js
// Generated from slither report
@ -420,12 +464,15 @@ Edit/view: https://cascii.app/0e182
#### Impacts
- **Financial**: Attackers could earn multiple validation rewards and excessively slash the host’s collateral for a single missed proof, draining funds unfairly.
- **Validation**: Repeated slashing disrupts PoR verification, potentially marking valid proofs as missing and undermining trust.
- **Financial**: Attackers could earn multiple validation rewards and excessively
slash the host’s collateral for a single missed proof, draining funds unfairly.
- **Validation**: Repeated slashing disrupts PoR verification, potentially marking
valid proofs as missing and undermining trust.
#### Mitigation
Apply the `Checks-Effects-Interactions` pattern by updating state before the external `_token.transfer` call.
Apply the `Checks-Effects-Interactions` pattern by updating state before the external
`_token.transfer` call.
Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls.
[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride
@ -433,13 +480,15 @@ Use OpenZeppelin’s `ReentrancyGuard` to block reentrant calls.
## Repudiation
Threat action aimed at denying responsibility for uploading files or agreeing to storage contracts in the network.
Threat action aimed at denying responsibility for uploading files or agreeing to storage
contracts in the network.
### Denial of file upload
#### Scenario
A user uploads illegal content to Codex and later denies initiating the request, attempting to evade responsibility.
A user uploads illegal content to Codex and later denies initiating the request,
attempting to escape responsibility.
```
──────
@ -475,7 +524,8 @@ Edit/view: https://cascii.app/5b9a9
#### Impacts
- **Reputation**: Codex could be used to distribute illegal content, leading to a loss of trust in the protocol.
- **Reputation**: Codex could be used to distribute illegal content, leading to a
loss of trust in the protocol.
#### Mitigation
@ -534,7 +584,8 @@ Edit/view: https://cascii.app/db2da
#### Impacts
- **Availability**: The slot becomes unavailable from that storage provider, reducing network reliability.
- **Availability**: The slot becomes unavailable from that storage provider,
reducing network reliability.
#### Mitigation
@ -546,13 +597,16 @@ provider to abandon the slot.
## Information disclosure
Information disclosure occurs when private or sensitive information such as user data, file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties.
Information disclosure occurs when private or sensitive information such as user data,
file contents, or system secrets is unintentionally or maliciously revealed to unauthorized parties.
### Uploaded files exposed
#### Scenario
A user uploads a confidential file to Codex. Storage providers store encrypted slots of the file. Without encryption, storage providers could agree to gather slots and reassemble the full content.
A user uploads a confidential file to Codex. Storage providers store encrypted slots
of the file. Without encryption, storage providers could agree to gather slots and
reassemble the full content.
```
──────
@ -599,8 +653,10 @@ Edit/view: https://cascii.app/ef5ab
#### Impacts
- **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of trust in the protocol.
- **Privacy**: Exposure of sensitive user data could violate privacy, potentially resulting in legal or regulatory consequences.
- **Reputation**: Codex cannot guarantee confidentiality, leading to a loss of
trust in the protocol.
- **Privacy**: Exposure of sensitive user data could violate privacy, potentially
resulting in legal or regulatory consequences.
#### Mitigation
@ -612,7 +668,9 @@ Implement encryption to ensure that only authorized users can decrypt and access
#### Scenario
A storage provider reserves a slot, but waits to fill the slot hoping a better opportunity will arise, in which the reward earned in the new opportunity would be greater than the reward earned in the original slot.
A storage provider reserves a slot, but waits to fill the slot hoping a better
opportunity will arise, in which the reward earned in the new opportunity would be
greater than the reward earned in the original slot.
```
────── ──────
@ -661,4 +719,8 @@ Edit/view: https://cascii.app/6144e
#### Mitigation
This attack is mitigated by allowing for multiple reservations per slot. All storage providers that have secured a reservation (capped at three) will race to fill the slot. Thus, if one or more storage providers that have reserved the slot decide to pursue other opportunities, the other storage providers that have reserved the slot will still be able to fill the slot.
This attack is mitigated by allowing for multiple reservations per slot.
All storage providers that have secured a reservation (capped at three) will race to fill the slot.
Thus, if one or more storage providers that have reserved the slot decide to
pursue other opportunities, the other storage providers that have reserved the slot will
still be able to fill the slot.