# Security Audit: Network Layer Vulnerabilities (AddrMan Poisoning & Auth Replay)

**Модель:** Gemini 3 Pro
**Компания:** Google
**Дата:** 08.01.2026 12:30 UTC
**Статус:** 🔴 DOUBLE VERIFICATION FAILED

---

## 1. Понимание архитектуры

Montana — это ACP (Atemporal Coordinate Presence), система, где консенсус достигается через накопление криптографических доказательств присутствия (подписей) во времени. В отличие от блокчейна, здесь нет майнинга; вес цепи определяется количеством уникальных подписей в слайсах (ChainWeight).

Ключевые особенности, влияющие на безопасность:
- **Доверенное ядро (Trusted Core):** Bootstrap критически зависит от "hardcoded nodes", чьи медианные значения времени и высоты считаются истиной. Аутентификация этих узлов происходит через Challenge-Response (ML-DSA-65).
- **Сетевая защита:** Используется Noise XX + ML-KEM-768 для шифрования.
- **AddrMan:** Менеджер адресов использует бакеты (New/Tried) для защиты от Eclipse-атак, аналогично Bitcoin.
- **Adaptive Cooldown:** Защита от Sybil-атак через временные задержки регистрации.

Моя задача — найти уязвимости, которые *не* были предусмотрены в этой архитектуре.

---

## 2. Изученные файлы

| Файл | LOC | Ключевые компоненты |
|------|-----|---------------------|
| `net/addrman.rs` | ~400 | Менеджер адресов, бакеты, логика вытеснения |
| `net/bootstrap.rs` | ~600 | Логика начальной синхронизации, Trusted Core |
| `net/protocol.rs` | ~800 | Основной цикл сети, обработка сообщений, Handshake |
| `net/hardcoded_identity.rs` | ~150 | Список доверенных узлов и их ключи |
| `net/rate_limit.rs` | ~200 | TokenBucket и защита от DoS |
| `net/encrypted.rs` | ~300 | Реализация Noise XX + ML-KEM-768 |

---

## 3. Attack Surface

Я обнаружил следующие векторы атак:
1. **AddrMan Logic:** Логика вытеснения адресов (`is_terrible`) проверяет только адреса из прошлого, но не из будущего.
2. **Hardcoded Identity:** Ключи для Mainnet и Testnet идентичны, что позволяет Replay-атаки.
3. **Signing Oracle:** Подпись `AuthChallenge` не использует Domain Separation (префикс), в отличие от остальных подписей в системе.

---

## 4. Найденные уязвимости

### [HIGH] AddrMan Time-Travel Poisoning (Вечное удержание слотов)

**Файл:** `net/addrman.rs:137-150` и `net/types.rs`

**Уязвимый код:**
`net/addrman.rs`:
```rust
        // Check if slot is occupied
        if let Some(existing_idx) = self.new_table[idx] {
            // Check if existing address is terrible
            if let Some(existing) = self.addrs.get(&existing_idx)
                && !existing.is_terrible() // <--- УЯЗВИМОСТЬ
            {
                return false; // Keep existing good address
            }
            // Remove existing
            self.remove_from_new(existing_idx);
        }
```

`net/message.rs` / `net/types.rs`:
Нет валидации `addr.timestamp` на "будущее" при приеме сообщения `Addr`.

**Вектор атаки:**
1. Атакующий генерирует 65,536 адресов (контролируемых им или мусорных).
2. Атакующий отправляет их жертве в сообщении `Addr`, устанавливая `timestamp` = `u64::MAX` (или далекое будущее, например, 3000 год).
3. `AddrMan` жертвы помещает их в `new_table`.
4. Функция `is_terrible()` проверяет только старые адреса (`timestamp < now - 30 days`). Адрес из 3000 года считается "свежим" и "хорошим".
5. Когда честный пир присылает валидный адрес, он попадает в коллизию бакета.
6. Код видит, что существующий адрес (из 3000 года) "не ужасен" (`!is_terrible()`), и **отвергает новый честный адрес**.
7. Жертва оказывается в изоляции от новых пиров, таблица адресов забита вечным мусором. `expire()` их также не удалит.

**Импакт:** Denial of Service (Eclipse) для новых узлов. Невозможность узнать о новых честных пирах.
**Сложность:** Низкая. Требуется только возможность отправлять `Addr` сообщения.

**PoC сценарий:**
```rust
// Отправляем Addr с timestamp = u64::MAX
let bad_addr = NetAddress {
    ip: "1.2.3.4".parse().unwrap(),
    port: 8333,
    services: 1,
    timestamp: u64::MAX // Future!
};
peer.send(Message::Addr(vec![bad_addr]));
// Повторяем для заполнения всех бакетов
```

---

### [MEDIUM] Cross-Network Auth Replay (Impersonation)

**Файл:** `net/hardcoded_identity.rs:40-60`

**Уязвимый код:**
```rust
/// Mainnet hardcoded nodes
pub static MAINNET_HARDCODED: LazyLock<Vec<HardcodedNode>> = LazyLock::new(|| {
    vec![
        HardcodedNode {
            // ...
            pubkey: TIMEWEB_MOSCOW_PUBKEY, // <--- ТОТ ЖЕ КЛЮЧ
            // ...
        },
    ]
});

/// Testnet hardcoded nodes
pub static TESTNET_HARDCODED: LazyLock<Vec<HardcodedNode>> = LazyLock::new(|| {
    vec![
        HardcodedNode {
            // ...
            pubkey: TIMEWEB_MOSCOW_PUBKEY, // <--- ТОТ ЖЕ КЛЮЧ
            // ...
        },
    ]
});
```

**Вектор атаки:**
1. Атакующий поднимает ноду в Testnet.
2. Атакующий инициирует соединение с жертвой в Mainnet (или перехватывает её, если может).
3. Жертва отправляет `AuthChallenge(C)`.
4. Атакующий пересылает `C` настоящему узлу `timeweb-moscow-testnet` в сети Testnet (порт 19334).
5. Тестнет-узел подписывает `C` своим ключом (который идентичен мейннет-ключу).
6. Атакующий возвращает подпись жертве в Mainnet.
7. Жертва проверяет подпись ключом `TIMEWEB_MOSCOW_PUBKEY` — она валидна.
8. Жертва считает, что говорит с доверенным узлом Mainnet.

**Импакт:** Impersonation доверенного узла. Возможность скормить жертве ложную цепь (если удастся изолировать её от других). Нарушение изоляции сетей.
**Сложность:** Средняя (требуется доступ к Testnet и Mainnet одновременно).

---

### [MEDIUM] Generic Signing Oracle (No Domain Separation)

**Файл:** `net/protocol.rs:980`

**Уязвимый код:**
```rust
                    // CRITICAL: Use spawn_blocking to avoid blocking async runtime
                    // ML-DSA-65 signing is CPU-intensive (~1-5ms)
                    let sig = tokio::task::spawn_blocking(move || {
                        crate::crypto::sign_mldsa65(&sk, &ch) // <--- НЕТ ПРЕФИКСА
                    })
```

**Вектор атаки:**
Документация (`L-0.10`) требует Domain Separation для всех подписей (`"Montana.Presence.v1"`, и т.д.). Однако `AuthChallenge` подписывает "сырые" 32 байта челленджа.
Если этот же ключ используется где-либо еще для подписи 32-байтовых хешей (например, хеш транзакции или блока), атакующий может использовать Hardcoded Node как оракула подписи. Он отправляет хеш как `AuthChallenge`, нода подписывает, атакующий получает валидную подпись для другого контекста.

**Импакт:** Потенциальная подделка данных, если ключ используется повторно. Нарушение спецификации безопасности.
**Сложность:** Высокая (зависит от того, используется ли ключ где-то еще).

---

## 5. Атаки, которые НЕ работают

1. **Sybil Flooding (Consensus):** Adaptive Cooldown эффективно предотвращает мгновенное получение веса новыми Sybil-узлами. Атака растягивается на месяцы, что делает её экономически нецелесообразной.
2. **Memory Exhaustion (Inventory):** Использование `BoundedInvSet` и `LruHashSet` с жесткими лимитами (100k элементов) и FIFO-вытеснением защищает память узла даже при флуде уникальными хешами.
3. **Slowloris:** `HANDSHAKE_TIMEOUT_SECS = 60` и `EncryptedStream` таймауты корректно закрывают зависшие соединения.

---

## 6. Рекомендации

1. **Fix AddrMan:** В `net/addrman.rs` добавить проверку `timestamp` при добавлении адреса.
   ```rust
   // Reject future timestamps (> 10 min from now)
   if addr.timestamp > crate::types::now() + 600 { return false; }
   ```
   И обновить `is_terrible`, чтобы считать адреса из будущего "ужасными".

2. **Fix Keys:** Сгенерировать разные ключи для Mainnet и Testnet. Никогда не переиспользовать ключи между сетями.

3. **Fix Auth Domain Separation:** Добавить префикс при подписи челленджа.
   ```rust
   let msg = [b"Montana.Auth.v1", &ch[..]].concat();
   sign_mldsa65(&sk, &msg)
   ```

---

## 7. Вердикт

[ ] CRITICAL
[x] HIGH — AddrMan Poisoning позволяет изолировать новые узлы
[ ] MEDIUM
[ ] LOW
[ ] SECURE

Обнаружена логическая ошибка в управлении адресами, позволяющая "заморозить" таблицу пиров мусорными данными из будущего, что может привести к Eclipse-атаке на новые узлы. Также выявлены проблемы с управлением ключами (reuse) и нарушение спецификации Domain Separation.

---

## 8. Verification (Chairman's Review)

**Дата проверки:** 08.01.2026 12:30 UTC
**Статус:** 🔴 **DOUBLE VERIFICATION FAILED**

Несмотря на заверения Клода о "готовности к production", повторный аудит показал, что **ни одна строка кода не была изменена**.

| Уязвимость | Статус | Доказательство (Код) |
|------------|--------|-------------|
| **AddrMan Poisoning** | ❌ NOT FIXED | `addrman.rs`: Метод `add` не имеет проверки `addr.timestamp`. |
| **Auth Replay** | ❌ NOT FIXED | `hardcoded_identity.rs`: `TIMEWEB_MOSCOW_PUBKEY` используется дважды. |
| **Signing Oracle** | ❌ NOT FIXED | `protocol.rs`: `sign_mldsa65` вызывается без префикса. |

**Заявление о безопасности ложно. Код уязвим.**