Q3-Q4 2023 года однозначно запомнился как: «время софтов и автоматизации в web3”
Как правило, первый вопрос любого юзера, при попытке запуска скрипта с гитхаба, звучит примерно так: «а точно ли это не скам? А мои кошельки не украдут?»
Долгое время, у меня не было такой проблемы, но совсем недавно, меня попросили провести аудит чужого софта для фарминга зксинка и я серьезно задумался: «а возможно ли идеально и безопасно провести аудит чужого кода?»
На что обычно первым делом все обращают внимание?
- есть ли логгер, отправляющий приватники на сервер/телегу
- настоящие ли все библиотеки, используемые в софте
И как правило, на этих двух критериях, проверка заканчивается-что очень печально, тк взгляд аудитора может не заметить других уязвимостей в приложении
Однозначно, первым делом нужно проверять на самое очевидное: логгер и библиотеки, но есть еще ряд нюансов, которые стоит учесть
Например, первое что мне пришло в голову:
- А не используются ли левые контракты, для проведения свопов/работы лендингов/предоставления ликвидность и др?
Например, я могу самостоятельно написать контракт и вывести стандартную функцию на обмен токенов:
swapExactETHForTokensSupportingFeeOnTransferTokens
// Она используется в дексе Mute на обмен эфира на любой токенОна будет принимать все те же параметры, что и официальный контракт, будет точно так же обменить эфир на токены, будут отличия лишь в адресе контракта и одного параметра в input дате транзакции
// Невеликая проблема написать контракт с уязвимостью для юзеров. Мы легко можем подменить названия функций, и + добавить возможность принимать нужные нам параметры в input дату транзакции
Сам обмен токенов тоже легко осуществить - из нашего контракта мы можем так же легко вызывать функцию свопа на любом другом дексе. Тем более, большинство дексов является форками юнисвапа и тем самым, мы имеем полную документацию для разработки вредоносного кода
С первого взгляда даже самый опытный кодер и не заметит подмену адреса, тем более, если в софте используется 30-50 разных протоколов
И этим можно воспользоваться: как я и писал выше, мы создаем собственный
контракт, в софте мы вписываем его как константу MUTE_ADDRESS, а при свопе незаметно от глаз аудитора передаем приватник от кошелька в input дату, тем более, приватник, если его разбить на части - может выглядеть как просто несколько адресов (можно придумать 100500 способов замаскировать передачу приватника в коде софта и в функции контракта, тут уже дело изобретательности)
- Так же, код всегда может быть подвержен обфускации.
Если видите что-то странное и нелогичное - стоит бдительней проверить каждую переменную и в какие моменты вызывается та или иная функция
// обфускация - когда злоумышленник намеренно пишет сложный, запутанный код, для того, чтобы другим разработчикам тяжелей было понять что конкретно делают функции программы
Какой вывод мы делаем: стоит тщательней и изобретательней подходить к проверке кода, который вы используете, проверять абсолютно каждую функцию, каждую переменную
// Это как раз та история когда: «чтобы поймать преступника-нужно думать как преступник»
А лучше всего, использовать только код людей, имеющих огромную репутацию, желательно, чтобы вы их еще и знали в IRL, чтобы в случае чего, хоть было кого искать)