Python, Java, C++, Delphi, PHP — именно эти разные языки программирования использовались в этот раз для создания виртуальной машины криптомата-банкомата, которую должны были испытать на прочность участники в рамках конкурса $NATCH, проходившего на Positive Hack Days 12, чтобы победить. Весь код от начала и до конца был написан с помощью ChatGPT и показал себя исключительно хорошо. Мы пересмотрели концепцию конкурса и использовали систему репортов. Помимо стандартных задач (обхода киоска, повышения привилегий и обхода AppLocker), в этом году участников ждали новые нестандартные задания, о которых читайте в этой статье.

В мае в центральном парке Москвы — в Парке Горького — отшумели яркие Positive Hack Days. Впервые за 12 лет форум по практической кибербезопасности, ранее объединявший только экспертов по ИБ и этичных хакеров со всего мира, превратился в открытый киберфестиваль. Мы построили современный кибергород с интересными заданиями и квестами, проходя которые, посетители знакомились с тем, как устроен цифровой мир, проверяли свою киберграмотность и учились доверять новым технологиям, усваивая принципы кибербезопасности. 

Помимо серьезных докладов по информационной безопасности и грандиозной кибербитвы Standoff, ежегодный Positive Hack Days полюбился техническим энтузиастам за конкурсы, в ходе которых они испытывают на прочность различные IT-системы и устройства, оттачивают навыки по их защите и получают памятные призы. На прошлогоднем PHDays исследователи безопасности с азартом искали слабые места в нашем онлайн-банке, банкоматах и POS-терминалах, пытались обойти IDS и сломать ИИ. В этот раз мы отдали участникам на растерзание обновленные традиционные мишени, а также приготовили новинку — уязвимое банковское мобильное приложение. Итоги этого конкурса (как и отчеты участников ?) не оставили нас равнодушными, поэтому мы подготовили его райтап.

Надеемся, наш пост поможет специалистам по ИБ лучше понять, какие уязвимости характерны для этой ОС, как их могут эксплуатировать злоумышленники, а главное — как с ними бороться. Всех, кто хочет лучше ориентироваться в мире мобильных угроз, приглашаем под кат.

В прошлый раз мы рассказали о том, что такое платформы и программы багбаунти, какой базовый инструментарий может использовать багхантер, чтобы облегчить или автоматизировать поиск, привели реальные примеры уязвимостей из старых версий приложений с открытым исходным кодом и посоветовали хорошую литературу для самостоятельного изучения.

В этой статье поговорим о том, что такое скоуп (scope) — устанавливаемые программой границы, в рамках которых разрешается проводить багхантинг, — как работать со скоупом и какие инструменты могут быть полезны. Кроме того, покажем несколько реальных примеров уязвимостей других классов, а в конце вас ждет небольшой бонусный раздел.

Информационная безопасность — постоянная борьба между атакующими и защитниками. По мере того, как эволюционируют инструменты атаки, вторые могут быть реализованы хакерами за считанные минуты, образовав неприемлемые бизнес-риски для “хакнутого” предприятия – особенно сегодня. Спрос есть: должно родиться и предложение. Не так давно наша команда провела ряд пилотов решения PT Network Attack Discovery в инфраструктурах заказчика. Делюсь результатами в этой статье.

Перед тем, как я расскажу о своем исследовании, объясню, чем оно было обусловлено. В мае мы запустили альфа-версию сканера интернета – Netlas.io. Этот сервис – наша собственная разработка, которой мы занимались последние месяцы.  

В двух словах о том, что это. Netlas.io — это своеобразный технический атлас всей сети Интернет, который включает сертификаты, данные по доменам и поддоменам, ответы серверов по популярным портам и много другой полезной информации для исследователей безопасности. Иными словами — это российский аналог Shodan или Censys.

Альфа-тестирование продлится еще несколько месяцев, поэтому, кому интересно – ждем. На этот период сервис полностью бесплатный, но уже содержит много «плюшек» для тех, кто решит продолжить его использовать после альфы. Например, доступ к платному аккаунту на несколько месяцев.

 На этой ноте вступительную часть объявляю закрытой, переходим к исследованию.

В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.

Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.

Использование TLS само по себе благо, так как с его помощью шифруются данные. Но с обратной стороны создатели вредоносов используют его же, чтобы скрываться в шифрованном трафике (в данной статье как раз будет уклон в эту сторону) и затруднять их обнаружение и нейтрализацию.

Чтобы инициировать сеанс TLS, клиент отправляет «пакет» приветствия серверу после трёхстороннего установления связи TCP. Этот «пакет» и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.

В этой статье пойдет речь про I2P — некоммерческую сингулярность сетевой приватности и анонимности, где никто кроме вас не знает куда и кто передает вашу информацию. Сеть I2P (расшифровывается как «Invisible Internet Project», Проект невидимого интернета) — это оверлейная децентрализованная одноранговая сеть. Оверлейная — значит работает поверх других сетей, например, обычного интернета; децентрализованная — распределенная, не имеющая единой точки отказа: упадет один узел, полсети, или во всей сети останется 3 пользователя — I2P все равно будет функционировать. I2P является одноранговой сетью, так как все участники имеют равные права и возможности: каждый пользователь скрытой сети строит свои туннели через других участников и сам является потенциальным звеном в цепочке другого пользователя. При этом естественная сетевая активность никак не компрометирует абонента перед домашним провайдером или участниками скрытой сети.

Привет, наш дорогой читатель!

Как обещали, продолжаем наш цикл статей про участие нашей команды The Codeby в кибербитве на полигоне The Standoff. Начало нашего приключения можно почитать здесь. В этот раз вы узнаете технические подробности реализованных бизнес-рисков, уязвимостей в веб-приложениях и некоторые хитрости, которые в какой-то мере помогли нам стать победителями.

Мы уже писали, что разбились на две команды и разделили цели. При этом в каждой команде был инфраструктурщик, вебер, фишер. Несмотря на то, что это дало свои плоды, оглядываясь назад, мы понимаем, что таким образом у нас уменьшилась коллаборация между специалистами одной категории. Например, для вебера со знаниями PHP попадался ресурс на Ruby, и наоборот. Из-за этого в некоторых моментах мы потеряли время, что непростительно в конкурсе, где каждая команда пытается быстрее эксплуатировать уязвимость и закрыть ее. В следующем году возможно стоит сделать разделение именно по специализациям для более быстрого захвата входных точек.

Привет, наш дорогой читатель!

Хочу представиться: меня зовут Станислав (@clevergod), я являюсь вице-капитаном команды Codeby.net, и этой статьей мы начинаем цикл из 3х-4х материалов, посвящённых нашему участию в киберполигоне The Standoff.

По своей старой привычке, постараемся без эмоционально описать всю боль, слезы и радость прошедшего для нашей команды удивительного 123-часового марафона под названием The Standoff 2020.

В этой статье мы расскажем, почему грамотная подготовка - это больше половины успеха и почему так важно организовать взаимодействие ни разу не пентест-команды в рамках одного отдельно взятого проекта.

Попробуем передать по шагам атмосферу, но поверьте 5 суток безудержного веселья можно описывать в бесконечном цикле статей или даже снять экшн-сериал…

Кто такие Codeby - форум энтузиастов, неравнодушных ребят, проживающих в различных странах и регионах, которых объединяет желание к саморазвитию и безвозмездному обучению молодого поколения специалистов в различных областях деятельности как ИТ, так и информационной безопасности.

P.S. - Хочу сказать, что мы с кэпом (BadBlackHat) очень долго шли к этой победе, преодолевая один барьер за другим, отдавая все силы и ресурсы для того, чтобы наша общая мечта сбылась.

Внимание, статья содержит много скринов!

Решили продолжить перевод шпаргалок по безопасности от OWASP на фоне массовых восстановлений паролей после утечки базы данных у сервиса rzd-bonus.ru.

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

Сейчас же на авансцену выходит ГОСТ Р 57580.1-2017, соответствовать которому уже с начала следующего года должны информационные системы многих компаний финансового сектора. Документ дает весомый повод в очередной раз погрузиться в чтение многостраничного текста, чтобы понять, а требуются ли сертифицированные СЗИ и СКЗИ?

Получая большое количество аналогичных вопросов, мы решили рассмотреть эту тему комплексно, как в рамках ГОСТа, так и иных применимых правовых документов. И, конечно же, поделиться полученным результатом с вами.

Несмотря на то, что выводы, представленные в данной статье, подаются как применимые для финансовых организаций, они абсолютно свободно могут быть распространены и на любые иные компании. В конце концов, кто из нас не оператор персональных данных?

Cookie-файлы как персональные данные

• Overpass The Hash/Pass The Key (PTK);
• Pass The Ticket;
• Unconstrained Delegation;
• Constrained Delegation.

• Безопасность при разработке приложения;
• Безопасность сервера;
• Безопасность платформы;