Введение
При достаточном количестве наблюдателей ошибки выплывают на поверхность
(Закон Линуса)
При разработке безопасных и/или анонимных приложений всегда наступает такой момент, когда становится необходимым выйти из своих сугубо теоретических размышлений, выйти из скованного дебагом одиночества, выйти из затворничества программных реализаций в открытое общество, безжалостно указывающее на все неправильные, нелогичные, ошибочные, уязвимые части «итогового продукта». Это есть необходимый этап в разрушении ожиданий, идеалов, а также сомнений, чтобы вследствие своей закалки, продукт стал бы поистине безопасным.
К сожалению, я не компания, как например, ruvds, способная выдать действительно приличное количество средств в своём хакатоне для общего интереса. У меня есть только работа, благодаря которой я получаю средства, и мой pet-проект, на который я готов тратить как своё свободное время, так и эти же полученные средства.
О проекте HL
Hidden Lake (HL) — это одноранговая (P2P) децентрализованная friend-to-friend (F2F) анонимная сеть, основанная на принципе микросервисной архитектуры и написанная на языке Go. В ядре анонимной сети (Hidden Lake Service = HLS) содержится анонимизирующий алгоритм с доказуемой моделью на базе очередей. Он является теоретически доказуемым, в том простом плане, что любые действия пассивных атакующих, как апостериорные вероятности деанонимизации, становятся равны априорным вероятностям. Иными словами, качество анонимности не уменьшается вследствие ряда исследований со стороны пассивных атакующих (в том числе и со стороны глобального наблюдателя).
Помимо HLS, проект HIdden Lake также содержит другие сервисы, а именно: 1) Hidden Lake Traffic (HLT) - распределитель трафика, способный работать как в роли ретранслятора сообщений, так и в роли хранилища трафика; 2) Hidden Lake Messenger (HLM) - прикладное приложение, предоставляющее возможность отправления / получения сообщений и файлов. В приложениях: HLS, HLT, HLM, и в их комбинациях: HLS+HLM, HLS+HLT, HLS+HLT+HLM, выражается весь проект HL.
Для упрощения тестирования, запуска и адаптации к проекту, для последующего поиска уязвимостей, можно воспользоваться примерами, которые находятся в директории examples самой библиотеки go-peer. Некоторые примеры можно запускать в докере. В README присутствуют примеры запуска, как приложений, так и непосредственно самих примеров.
Хакатон
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда
(Закон Линуса)
Хакатон проводится онлайн. Допускается формирование команд. На хакатоне даётся в общей сложности 7 дней (без учёта сегодняшнего, неполного дня) дата завершения: 12.08.2023, включительно. За это время вам необходимо будет найти как можно больше уязвимостей, багов, неточностей и т.п. в проекте HL. Все результаты ваших исследований, а также призовые места, будут помещены и закреплены в комментариях к этой статье после окончания хакатона.
Я продолжительное время думал на счёт того, как я буду оценивать сам хакатон. По каким критериям я буду разделять уязвимости между собой? В какой пропорции N багов будут относиться к M уязвимостям? Что если два человека выдадут хорошо похожие результаты, кого выбрать в качестве победителя? Стоит ли делать одно место в 125.000 рублей или стоит разделить эти средства по местам? Чем ограничены рамки поиска уязвимостей?
На многие эти вопросы я не смогу дать ответ объективно, потому что таковой ответ может быть получен лишь постфактум, вследствие уже какого-то периода поиска уязвимостей. Давайте постараюсь дать на эти вопросы более точные ответы.
В хакатоне будет статично 125.000 рублей. Вне зависимости от количества призовых мест, данная сумма не пропадёт, а будет лишь распределяться. Максимум призовых мест = 3. Таковой исход благоприятен при высокой активности участников и качестве исследований. В таком случае, победителю (первое место) достанется 62.500 рублей, второму месту = 41.666 рублей, третьему месту = 20.834 рублей. Если активность участников или качество исследований будет низкое, где при этом будет выделяться лишь один или два человека, то и само призовое место снизведётся до одного или двух человек. И как следствие, награда будет равна либо 125.000 победителю, либо 73.334 рублей (первому месту) и 51.666 рублей (второму месту).
В хакатоне, все найденные, исследованные и доказанные уязвимости, надо отправлять в ближайшее время, не дожидаясь окончания сроков хакатона. В таком случае, я смогу точно по времени узнать, кто первый заметил данную уязвимость / баг / неточность, доказал её существование и указал способы её решения. Лишь в полной конкатенации: указать (на уязвимость) + доказать (уязвимость) + указать на решение (уязвимости), ответ считается зачтённым. Следовательно, если два участника отправят отчёт о похожей уязвимости, то таковой отчёт зачтётся только тому, кто первый и в полной мере описал её.
Пропорции между багами и уязвимостями я точно не смогу выяснить до тех пор, пока самолично не узнаю эти пропорции в проекте HL. Одно могу сказать точно — уязвимости являются наивысшими оценками, и если таковые будут найдены, то это точно сыграет больше в оценивании итогового результата, чем если бы вы нашли баг или какую-либо неточность.
Помните, что уязвимостью в хакатоне будет считаться не только её возможность осуществления, но также и возможность её практического решения. Иными словами, если вы скажете об уязвимости, но при этом не предложите способы её "изживания", то таковая уязвимость, даже будучи она реальной, не будет зачтена. Способы решения должны быть практическими, а не теоретическими.
Разделение уязвимостей будет происходить по их качеству, по реальной разрушительной способности. Чем серьёзнее будет уязвимость, тем больше виртуальных (абстрактных) баллов будет вам зачислено. Таким образом, уязвимость уязвимости рознь, ровно также, как и уязвимость не оценивается как баг. Но в отличие от багов, уязвимости могут быть примерно равны по своему потенциалу к деструкту системы.
Поиск уязвимостей, багов, неучтённых моментов не ограничивается исключительно программным кодом директории cmd/hidden_lake. Ограничение будет затрагивать только тот код, который не принадлежит к cmd/hidden_lake, или тот код, который не относится к библиотеке go-peer. Так например, даже если в директории cmd/micro_anon будет найдена уязвимость, она не будет зачтена, потому как cmd/micro_anon никак не принадлежит к cmd/hidden_lake. Такая же ситуация и с подключаемыми сторонними библиотеками. Если в одной из них будет найдена уязвимость, например в github.com/syndtr/goleveldb, то уязвимость также не будет учтена. С другой стороны, директории pkg/network или internal/api напротив, полностью относятся к области cmd/hidden_lake, т.к. наследуются ею.
Все отчёты отправляйте мне в личные сообщения ВК или в Telegram (рекомендую отправить и туда, и туда). И там, и там, ID = number571. Отправляйте отчёты, пожалуйста в одном из файловых форматов: «.txt», «.pdf». В файле укажите ссылки на профили участников, чтобы в случае выигрыша я знал кому надо переводить. Все участники должны быть согласны с участием и отнесением себя к команде. Команда делит итоговый результат поровну. То есть, если команда состоит из трёх человек заняла первое место при условии высокой активности участников (иными словами, существуют вторые и третьи места), и получила тем самым 62.500 рублей, то каждый участник индивидуально получит по 20.834 рублей. Аналогична ситуация со вторым и третьим местами.
При окончании хакатона и перед опубликованием результатов, я свяжусь с победителями и попрошу реквизиты. Сразу скажу, что я буду платить со Сбербанка. Если какой-либо банк не поддерживает перевод со Сбера на свой, то могу порекомендовать купить карту одного из поддерживающих банков. После перевода, будут подведены итоги хакатона уже в открытую.
Я бы мог действительно сделать хакатон открытым, это было бы как минимум честно в постфактуме, когда все результаты стали бы открыты. Но эта же открытость до окончания хакатона привела бы к возможным способам слежения за примерным вектором действий товарищей конкурентов, что приводило бы к опережению за счёт использования сторонних исследований.
Литература
При разборе уязвимостей, багов и прочего, на всякий случай лучше перепроверить, что таковые моменты я не описывал ещё в своих работах. Так например, возможность осуществления DDoS на сеть не является ни уязвимостью, ни багом на сеть HL. Спорно? Без сомнения спорно, но по данному нами ранее определению уязвимостью считается не только факт её существования, но также и способы её искоренения, не вредя при этом самой системе в степени большей, чем само "изживание" проблемы.
Подобная же ситуация присутствует и с теоретически, а в неком роде и практически, возможной MITM атакой на устройстве клиента между HLS и HLM в локальном окружении. Они обмениваются асимметричными ключами, чтобы исключить пассивные атаки на дальнейший перехват приватного ключа. Тем не менее, MITM атаки такой подход не искореняет, но и практического способа я не могу придумать, чтобы таковой был способен предотвращать MITM.
Если у вас действительно появятся возможные способы решения данной проблемы MITM или DDoS атаки, не требующие переусложнения системы, не прибавляющие противоречия децентрализации с централизацией и прочего, то это действительно можно будет засчитать за решение уязвимостей. Это есть те немногие проблемы (уязвимости), о которых я знаю, которые я разбирал, риски которых я учитывал, но адекватных решений которых так и не смог найти.
Что насчёт литературы, то список основной литературы такой (от наиболее основополагающих, к более частным):
Теория строения скрытых систем (60 стр.);
Абстрактные анонимные сети (22 стр.);
Монолитный криптографический протокол (9 стр.);
Также на хабре есть ряд более конкретных статей:
Hidden Lake Service — ядро скрытой сети с теоретически доказуемой анонимностью;
Тайные каналы связи или как централизованные сервисы способны разлагаться изнутри;
Заключение
На этом пожалуй всё. И всё, что я могу вам теперь сказать — удачи, и надеюсь вы найдёте очень много уязвимостей и неприятных моментов в проекте HL, неучтённых с моей стороны. Все найденные проблемы будут в будущем постепенно и планомерно мной исправляться.