mirror of
https://github.com/logos-storage/logos-storage-research.git
synced 2026-01-03 22:13:08 +00:00
Add tempering threats
This commit is contained in:
Arnaud
parent
3632049a4d
commit
bb4cc01b47
@ -15,13 +15,15 @@ Anyone is invited to contribute to this document, as it is a [collective effort]
|
||||
|
||||
## Analysis
|
||||
|
||||
| Category | Threat | Description | Impact | Mitigation |
|
||||
|-----------|--------------------------|-----------------------------------------------------------------------------|----------------------------------|-------------------------------------------------------------|
|
||||
| Spoofing | Phishing-Induced Spoofing| Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. |
|
||||
| | Same-Chain Replay | Reuses a signed request on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. |
|
||||
| | Cross-Chain Replay | Replays a signed request on another chain. | Drained wallet funds. | Implement EIP-712. |
|
||||
| | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users.
|
||||
|
|
||||
| Category | Threat | Description | Impact | Mitigation |
|
||||
| --------- | -------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------ |
|
||||
| Spoofing | Phishing-Induced Spoofing | Exploits the private key loaded directly into the app via phishing to send unwanted requests. | Draining the user's wallet funds, store unwanted content. | Use cold wallet. |
|
||||
| Spoofing | Same-Chain Replay | Reuses a signed transaction on the same chain to spoof user actions. | Drained wallet funds. | Include a unique nonce in request data. |
|
||||
| Spoofing | Cross-Chain Replay | Replays a signed transaction on another chain. | Drained wallet funds. | Implement EIP-712. |
|
||||
| Spoofing | Client Spoofing via API | Access to the exposed node to use the API. | Node full access. | Educate users. |
|
||||
| Tempering | Fake proofs | The storage provider sends fake proofs. | Contracts reward without actual data storage, reducing network reliability. | Require random challenges periodically. |
|
||||
| Tempering | `markProofAsMissing` re-entrancy | The validator uses re-entrancy to slash multiple times. | Excessive collateral slashing of the host, proof validation failure. | Apply the `Checks-Effects-Interactions` pattern. |
|
||||
|
||||
## Spoofing
|
||||
|
||||
### Phishing-Induced Spoofing
|
||||
@ -31,63 +33,63 @@ Anyone is invited to contribute to this document, as it is a [collective effort]
|
||||
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.
|
||||
|
||||
```
|
||||
──────
|
||||
─│ ─│ ┌────────────────┐
|
||||
│ │ │ │
|
||||
│ Attacker │───────────▶│ Email phishing │
|
||||
│ │ │ │
|
||||
─│ ─│ └────────────────┘
|
||||
────── │
|
||||
• │
|
||||
• │
|
||||
• ▼
|
||||
• ──────
|
||||
• ─│ ─│
|
||||
• │ │
|
||||
• │ User │
|
||||
• │ │
|
||||
• ─│ ─│
|
||||
• ──────
|
||||
• │
|
||||
• │
|
||||
• │ Clicks on the phishing email
|
||||
• │
|
||||
• │
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
• │ Unsecure form │
|
||||
• │ │
|
||||
• └────────────────┘
|
||||
• │
|
||||
• │ Submits the form
|
||||
• │
|
||||
• │ action=/storage/request/CIDMalicious method=POST
|
||||
──────
|
||||
─│ ─│ ┌────────────────┐
|
||||
│ │ │ │
|
||||
│ Attacker │───────────▶│ Email phishing │
|
||||
│ │ │ │
|
||||
─│ ─│ └────────────────┘
|
||||
────── │
|
||||
• │
|
||||
• │
|
||||
• ▼
|
||||
• ──────
|
||||
• ─│ ─│
|
||||
• │ │
|
||||
• │ User │
|
||||
• │ │
|
||||
• ─│ ─│
|
||||
• ──────
|
||||
• │
|
||||
• │
|
||||
• │ Clicks on the phishing email
|
||||
• │
|
||||
• │
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
• │ Unsecure form │
|
||||
• │ │
|
||||
• └────────────────┘
|
||||
• │
|
||||
• │ Submits the form
|
||||
• │
|
||||
• │ action=/storage/request/CIDMalicious method=POST
|
||||
• │ input name="pricePerBytePerSecond" value="100000"
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
• │ Codex node │
|
||||
• │ │
|
||||
• └────────────────┘
|
||||
• │
|
||||
• │ POST /storage/request/CIDMalicious
|
||||
• │ pricePerBytePerSecond: 1000000
|
||||
• │
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
•••••••••••••••••••│ Contract done │
|
||||
│ │
|
||||
└────────────────┘
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
• │ Codex node │
|
||||
• │ │
|
||||
• └────────────────┘
|
||||
• │
|
||||
• │ POST /storage/request/CIDMalicious
|
||||
• │ pricePerBytePerSecond: 1000000
|
||||
• │
|
||||
• ▼
|
||||
• ┌────────────────┐
|
||||
• │ │
|
||||
•••••••••••••••••••│ Contract done │
|
||||
│ │
|
||||
└────────────────┘
|
||||
```
|
||||
|
||||
Edit/view: https://cascii.app/437bc
|
||||
|
||||
Edit/view: https://cascii.app/437bc
|
||||
|
||||
#### Impacts
|
||||
|
||||
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.
|
||||
|
||||
@ -105,54 +107,56 @@ While this strategy mitigates the financial impact of unwanted storage requests,
|
||||
|
||||
#### Scenario
|
||||
|
||||
An attacker reuses a user’s signed `StorageRequest` 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.
|
||||
|
||||
```
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
│ │
|
||||
─│── ───│
|
||||
──────
|
||||
│
|
||||
│
|
||||
│
|
||||
│ Storage request
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Codex node │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Request signature │••••••••••••
|
||||
│ │ • ──────
|
||||
└──────────────────────┘ • ─│ ─│
|
||||
│ •│ │
|
||||
│ •│ Attacker │
|
||||
│ │ │
|
||||
│ ─│ ─│
|
||||
▼ ──────
|
||||
┌──────────────────────┐ │
|
||||
│ │ │
|
||||
│ Smart contract │ ◀────────────────┘
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
│ │
|
||||
─│── ───│
|
||||
──────
|
||||
│
|
||||
│
|
||||
│
|
||||
│ Storage request
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Codex node │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Request signature │••••••••••••••
|
||||
│ │ •
|
||||
└──────────────────────┘ •
|
||||
│ •
|
||||
│ ──────
|
||||
│ ─│ ─│
|
||||
│ │ │
|
||||
│ │ Attacker │
|
||||
│ │ │
|
||||
│ ─│ ─│
|
||||
▼ ──────
|
||||
┌──────────────────────┐ │
|
||||
│ │ │
|
||||
│ Smart contract │◀────────────┘
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
Edit/view: https://cascii.app/8edc1
|
||||
|
||||
Edit/view: https://cascii.app/3577b
|
||||
|
||||
#### Impacts
|
||||
|
||||
@ -166,55 +170,55 @@ Include a unique, random `nonce` in the request data. This ensures signatures ar
|
||||
|
||||
#### Scenario
|
||||
|
||||
An attacker captures a user’s signed `StorageRequest` 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.
|
||||
|
||||
```
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
│ │
|
||||
─│── ───│
|
||||
──────
|
||||
│
|
||||
│
|
||||
│
|
||||
│ Storage request
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Codex node │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Request signature │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Smart contract │ ──────
|
||||
│ │ ─│ ─│
|
||||
└──────────────────────┘ │ │
|
||||
│ ••••••••••│ Attacker │───────
|
||||
│ • │ │ │
|
||||
│ • ─│ ─│ │
|
||||
│ • ────── │
|
||||
│ • │
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
│ │
|
||||
─│── ───│
|
||||
──────
|
||||
│
|
||||
│
|
||||
│
|
||||
│ Storage request
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Codex node │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Request signature │
|
||||
│ │
|
||||
└──────────────────────┘
|
||||
│
|
||||
│
|
||||
│
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ │
|
||||
│ Smart contract │ ──────
|
||||
│ │ ─│ ─│
|
||||
└──────────────────────┘ │ │
|
||||
│ ••••••••••│ Attacker │───────
|
||||
│ • │ │ │
|
||||
│ • ─│ ─│ │
|
||||
│ • ────── │
|
||||
▼ • │
|
||||
┌──────────────────────┐ • │ ┌──────────────────────┐
|
||||
│ │ • │ │ │
|
||||
│ Chain 1001 │••••••••••• └───────│ Chain 1002 │
|
||||
@ -227,11 +231,11 @@ Edit/view: https://cascii.app/d312b
|
||||
|
||||
#### Impacts
|
||||
|
||||
- **Financial Loss**: Replayed requests on another chain drain user funds
|
||||
- **Financial Loss**: Replayed requests on another chain drain user funds
|
||||
|
||||
#### Mitigation
|
||||
|
||||
Implement EIP-712 to include chain-specific data in signed storage requests, 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
|
||||
|
||||
@ -240,41 +244,40 @@ Implement EIP-712 to include chain-specific data in signed storage requests, ens
|
||||
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.
|
||||
|
||||
```
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
││ User │──────────────────┐
|
||||
││ │ │
|
||||
│ │ │ │
|
||||
│ ─│── ───│ │
|
||||
Starts with 0:0:0:0 │ ────── │ Enables port forwarding for REST api
|
||||
│ │
|
||||
┌───────────────────┘ │
|
||||
│ │
|
||||
│ │
|
||||
│ │
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────────┐ ┌──────────────────────┐
|
||||
│ │ │ │
|
||||
│ Codex node │ │ Codex node │
|
||||
│ │ │ │
|
||||
└──────────────────────┘ └──────────────────────┘
|
||||
▲ ▲
|
||||
│ │
|
||||
│ │
|
||||
────── │ │ ──────
|
||||
─│ ─│ │ │ ─│ ─│
|
||||
│ Attacker │ │ │ │ │
|
||||
│ on same │────────────┘ └─────────────────│ Attacker │
|
||||
│ network │ │ │
|
||||
─│ ─│ ─│ ─│
|
||||
────── ──────
|
||||
|
||||
──────
|
||||
─│── ───│
|
||||
│ │
|
||||
│ │
|
||||
┌────────────────────│ User │──────────────────┐
|
||||
│ │ │ │
|
||||
│ │ │ │
|
||||
│ ─│── ───│ │
|
||||
│ ────── │
|
||||
│ │
|
||||
│ Starts with 0:0:0:0 │ Enables port forwarding for REST api
|
||||
│ │
|
||||
│ │
|
||||
│ │
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────────┐ ┌──────────────────────┐
|
||||
│ │ │ │
|
||||
│ Codex node │ │ Codex node │
|
||||
│ │ │ │
|
||||
└──────────────────────┘ └──────────────────────┘
|
||||
▲ ▲
|
||||
│ │
|
||||
│ │
|
||||
────── │ │ ──────
|
||||
─│ ─│ │ │ ─│ ─│
|
||||
│ Attacker │ │ │ │ │
|
||||
│ on same │────────────┘ └─────────────────│ Attacker │
|
||||
│ network │ │ │
|
||||
─│ ─│ ─│ ─│
|
||||
────── ──────
|
||||
```
|
||||
|
||||
Edit/view: https://cascii.app/1cca0
|
||||
Edit/view: https://cascii.app/28692
|
||||
|
||||
#### Impacts
|
||||
|
||||
@ -284,5 +287,134 @@ Edit/view: https://cascii.app/1cca0
|
||||
|
||||
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.
|
||||
|
||||
[1]: https://owasp.org/www-community/Threat_Modeling_Process#stride
|
||||
[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf
|
||||
## Tempering
|
||||
|
||||
### 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.
|
||||
|
||||
```
|
||||
──────
|
||||
─│ ─│
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
─│ ─│
|
||||
──────
|
||||
│
|
||||
Storage │
|
||||
Request │
|
||||
│
|
||||
▼
|
||||
┌────────────────────────┐
|
||||
│ │
|
||||
│ Codex network │──────────────┐
|
||||
│ │ │
|
||||
└────────────────────────┘ │
|
||||
│ │
|
||||
│ │
|
||||
│ Delete the file │
|
||||
│ Submit fake proof │
|
||||
│ │
|
||||
│ │
|
||||
│ │
|
||||
│ ──────
|
||||
│ ─│ ─│
|
||||
│ │ Storage │
|
||||
│ │ Provider │
|
||||
│ │ │
|
||||
│ ─│ ─│
|
||||
│ ──────
|
||||
│ ▲
|
||||
│ •
|
||||
│ •
|
||||
│ •
|
||||
│ •
|
||||
│ •
|
||||
│ •
|
||||
▼ •
|
||||
┌────────────────────┐ •
|
||||
│Slot 1│Slot 2│Slot 3│••••••••••••••••••
|
||||
└────────────────────┘
|
||||
```
|
||||
|
||||
Edit/view: https://cascii.app/629b5
|
||||
|
||||
#### Impacts
|
||||
|
||||
- **Financial**: Attackers attempt to earn contract rewards at the end of the contract without storing the file.
|
||||
- **Availability**: The file 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.
|
||||
|
||||
### 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.
|
||||
|
||||
```js
|
||||
// Generated from slither report
|
||||
Reentrancy in Marketplace.markProofAsMissing(SlotId,Periods.Period) (contracts/Marketplace.sol#338-360):
|
||||
External calls:
|
||||
- assert(bool)(_token.transfer(msg.sender,validatorRewardAmount)) (contracts/Marketplace.sol#352)
|
||||
Event emitted after the call(s):
|
||||
- RequestFailed(requestId) (contracts/Marketplace.sol#396)
|
||||
- _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358)
|
||||
- SlotFreed(requestId,slot.slotIndex) (contracts/Marketplace.sol#385)
|
||||
- _forciblyFreeSlot(slotId) (contracts/Marketplace.sol#358)
|
||||
```
|
||||
|
||||
```
|
||||
──────
|
||||
─│ ─│
|
||||
│ │
|
||||
│ User │
|
||||
│ │
|
||||
─│ ─│
|
||||
──────
|
||||
│
|
||||
Storage │
|
||||
Request │
|
||||
▼
|
||||
┌───────────────────────────┐
|
||||
Re-entrency │ │
|
||||
│ │
|
||||
┌╶╶╶╶╶╶╶╶╶╶▶│ Codex network │
|
||||
╷ │ │
|
||||
╷ │ │
|
||||
╷ ▲───────────────────────────┘
|
||||
╷ ╷ │
|
||||
╷ ╷ │
|
||||
────── ╷ │ ──────
|
||||
─│ ─│ ╷ │ ─│ ─│
|
||||
│ │ ╷ │ │ │
|
||||
│ Validator │╶╶╶╶╶┘ │ │ SP │
|
||||
│ │ │ │ │
|
||||
─│ ─│ │ ─│ ─│
|
||||
────── │ ──────
|
||||
│ │ ▲
|
||||
│ ▼ •
|
||||
│ ┌────────────────────┐ •
|
||||
└──────────────│Slot 1│Slot 2│Slot 3│•••••••••••••••
|
||||
└────────────────────┘
|
||||
```
|
||||
|
||||
Edit/view: https://cascii.app/5ead7
|
||||
|
||||
#### 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.
|
||||
|
||||
#### Mitigation
|
||||
|
||||
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
|
||||
[2]: https://cdn2.hubspot.net/hubfs/4598121/Content%20PDFs/VerSprite-PASTA-Threat-Modeling-Process-for-Attack-Simulation-Threat-Analysis.pdf
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user