Update

Добавлен модуль для подвязки клейм кошелька к вашим eligible кошелькам

Если вы проверяли дроп прошлой версией этого чекера, то !обязательно! используйте новый модуль для привязки клейм кошелька, поскольку в прошлой версии для этого использовался случайный приватный ключ. На это у вас есть время до 9 декабря 16:00 МСК.

Канал / Чат / Fragment Monitors / Discord

История одного антидрейна [part 1]

В один из дней мне написал человек, которому нужна была услуга антидрейна. Ситуация была следующая:

Человек застейкал SOL, однако доступ к приватному кошельку был не только у него, но и у другого человека, который с помощью скрипта выводил застейканую SOL на свой кошелек.

Изучив прошлые транзакции, в которых скамер выводил деньги, я понял, что нужно было просто вызвать инструкцию withdraw в момент разлока. Из интересного: SOL можно было вывести на любой адрес, указав нужный to_pubkey. Обсудив условия, я решил взяться за эту задачу. На подготовку было около пяти дней, поэтому я начал искать способ гарантированно обойти соперника.

Смена owner'а у аккаунта
Многие знают, что в Solana можно сменить owner (владельца) кошелька. Я никогда не углублялся в детали, но слышал, что таким образом даже при наличии приватного ключа кошелек превращается в "кирпич". Поэтому я начал изучать, как это можно сделать.

После некоторого времени я нашел способ сменить owner аккаунта на другую программу. Программы в Solana не имеют приватных ключей — они контролируются upgrade authority (обычно это аккаунт, который деплоил программу).

План был прост:

1. Задеплоить программу с единственной функцией — передачей owner любой другой программе.

2. Перевести owner всех скомпрометированных кошельков на свою программу.

3. Когда нужно — вызвать инструкцию смены owner на System Program, выполнить нужные операции (например, клейм SOL со стейк-аккаунтов), а затем вернуть owner обратно на свою программу.

Получался своеобразный "сэндвич", и я был уверен, что это гарантирует успех.

Проверка гипотезы
Написав реализацию такой программы, я убедился, что это работает с переводом SOL: после смены owner действительно ничего нельзя было сделать. Но затем я решил проверить это с SPL-токенами — и у меня получилось. Почему?

Как устроен аккаунт в Solana
Чтобы понять причину, нужно разобраться в структуре аккаунта в Solana. У каждого аккаунта есть следующие поля: data, executable, lamports, owner, rent_epoch

Если внимательно изучить документацию, становится ясно, что owner может изменять только поле data или уменьшать значение lamports (баланс SOL).

То есть, если в транзакции указать fee payer (тот, кто оплачивает комиссию) — другой кошелек, то стейк без проблем уходит к мошеннику, несмотря на смену owner.

История одного антидрейна [part 2]

Смена authority у стейк-аккаунта
Отбросив вариант со сменой owner у кошельков, я начал искать альтернативу. Для этого я углубился в изучение исходного кода Stake Program и обнаружил интересную функцию authorize, которая принимает следующие параметры:

/// Authorize a key to manage stake or withdrawal  
///  
/// # Account references  
///   0. `[WRITE]` Stake account to be updated  
///   1. `[]` Clock sysvar  
///   2. `[SIGNER]` The stake or withdraw authority  
///   3. Optional: `[SIGNER]` Lockup authority, if updating StakeAuthorize::Withdrawer before  
///      lockup expiration  
Authorize(Pubkey, StakeAuthorize)

Когда вы стейкаете SOL, создается отдельный стейк-аккаунт — специальный аккаунт для безопасного хранения и делегирования средств. У него есть два важных поля:

• staker — отвечает за деактивацию стейкинга (да, перед выводом средств стейк нужно сначала деактивировать).

• withdrawer — отвечает за вывод средств из стейк-аккаунта.

По умолчанию оба этих поля указывают на кошелек, с которого был активирован стейкинг.

Тестирование идеи
Я создал тестовый кошелек, застейкал SOL и написал скрипт, который менял withdrawer. Воодушевленный, я попробовал сделать то же самое на реальных аккаунтах, но столкнулся с проблемой:

Эти аккаунты отличались от тестового — на них стоял lockup (временная блокировка).

Для смены withdrawer до истечения lockup требовалась дополнительная подпись от custodian (хранителя блокировки), которой ни у кого не было.

Альтернативный план: смена staker
Тогда я решил пойти другим путем — сменить staker, чтобы злоумышленник не мог деактивировать стейкинг. Без деактивации он не смог бы вывести средства даже после lockup'а.

Я успешно изменил staker на всех аккаунтах, но, изучая код Stake Program, наткнулся на важный нюанс:

pub fn authorize(  
    &mut self,  
    signers: &HashSet<Pubkey>,  
    new_authorized: &Pubkey,  
    stake_authorize: StakeAuthorize,  
    lockup_custodian_args: Option<(&Lockup, &Clock, Option<&Pubkey>)>,  
) -> Result<(), InstructionError> {  
    match stake_authorize {  
        StakeAuthorize::Staker => {  
            // Allow either the staker or the withdrawer to change the staker key  
            if !signers.contains(&self.staker) && !signers.contains(&self.withdrawer) {  
                return Err(InstructionError::MissingRequiredSignature);  
            }  
... 

Вывод:
Для смены staker нужна подпись либо текущего staker, ЛИБО withdrawer.

Это означало, что злоумышленник, имея доступ к withdrawer, всё равно мог изменить staker и обойти мою "защиту".

Оставалось только надеяться, что он не разберётся в этом/не успеет подготовиться.

История одного антидрейна [part 3]

Подготовка к решающему моменту
Я предположил, что скамер не сразу разберётся в ситуации, и у меня будет шанс сменить withdrawer сразу после окончания lockup. Для этого я начал писать скрипт на Rust, который должен был:

Спамить транзакции в многопотоке и использовать skip_preflight = true (это означает, что транзакции будут отправляться без предварительной проверки, что увеличивает скорость)

Ключевые требования к скрипту:
1. Надёжный landing транзакций
• Арендовал ноду со staked-connection (выбрал Urban, так как с Deeznode был негативный опыт).

2. Уникальные сигнатуры транзакций
• Если отправлять одинаковые транзакции, нода будет их фильтровать как дубликаты.
• Решение: добавлял небольшой рандомный unit_price

let unit_price = rand::thread_rng().gen_range(3_500_000u64..=4_500_000u64);

Rust помог избежать глупых ошибок, но логику пришлось перепроверять несколько раз.

Момент истины
Lockup заканчивался в 00:00 UTC. Я настроил скрипт так, чтобы спам транзакций начинался за 2 секунды до разлока.

Обратный отсчёт: 3... 2... 1...

Проверяю результат — и вижу, что staker и withdrawer остались прежними. При этом, судя по истории транзакций, никто, кроме меня, не пытался ничего изменить. "Скамер сдался?" — подумал я.

Но через 7 минут появились новые транзакции — мой оппонент всё же действовал. Он сменил staker и withdrawer на другие адреса. Это означало моё поражение.

Разбор
На следующий день, несмотря на тильт, я решил разобраться, что пошло не так. Сравнивая свои транзакции с его, я не находил различий — они были идентичны, кроме адресов назначения.

Оказалось:
Последняя моя транзакция была отправлена в 23:59:59.
В 00:00 на кошельке, который оплачивал комиссии, закончился газ.
В решающий момент ни одна транзакция не ушла.

За ~2 секунды я:

• Сжёг ~1 SOL
• Залендил >700 транзакций

Вывод
Cкрипт был слишком эффективен и опустошил баланс раньше времени, я переиграл сам себя. Этот опыт стал для меня ценным уроком, надеюсь, эта история будет полезной (или хотя бы интересной). Всем gl!