Русский
Русский
English
Статистика
Реклама

Поиск уязвимостей

Из песочницы Мамкины хацкеры или мой путь в CTF

18.09.2020 18:11:01 | Автор: admin
Это был далекий 2014 год, когда еще зеленые, недавно поступившие в универ, парни, услышали, что есть какие-то соревнования с завлекающим названием Capture the flag (сокр. CTF, в переводе Захват флага).


Фото с сайта securitylab.ru к новости про Facebook CTF 2016

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

Итак, давайте теперь я вам немножко поведаю:

1. CTF (Capture the flag или Захват флага) командные соревнования (изредка бывают личными) в области компьютерной (информационной) безопасности.

2. Формат проведения :

2.1. Task-based (или jeopardy) игрокам предоставляется набор тасков (заданий), к которым требуется найти ответ (флаг) и отправить его.
Пока все более чем просто, обычные правила, но только все задания в этом формате разделены на категории (расскажу про основные):

Криптография задания связаны с расшифровкой сообщений, защищенных различными алгоритмами (от самых простейших до современных шифров);
Стеганография наука о тайной передаче информации путем сокрытия самого факта передачи. Следовательно, вам нужно найти, как именно и какую информацию передали (очень интересная тема, позже накатаю статей);
Web поиск уязвимостей на серверах и сайтах (используются специально развернутые сервера и сайты на них, не ведется взлом открытых платформ);
Реверс-инжиниринг исследование кода программного обеспечения, дальше методы зависят от задания (очень муторная тема, для усидчивых);
Recon моя любимая тема поиска информации по открытым источникам (OSINT, разведка). Тема, которой тоже будет посвящен отдельный блок статей;
Joy развлекательные задачи разнообразной тематики.
2.2. Attack-Defense (или classic) каждая команда получает выделенный сервер или небольшую сеть для поддержания её функционирования и защиты. Во время игры команды получают очки за корректную работу сервисов своего сервера, защиту своей информации и за украденную информацию (она же флаги) с серверов соперников.

3. Уровень соревнований
Международный уровень: самое престижное соревнование DEF CON CTF, которое ежегодно проходит в Лас-Вегасе и собирает сильнейшие команды мира (берет свое начало с девяностых годов).

Россия: имеет активное развитие с 2009 года. Проводятся множество локальных соревнований (в ВУЗах, городах, округах) в различных режимах.
Самый масштабный CTF в России RuCTFE, победа в котором даёт возможность попасть на DEF CON CTF.
Интересный факт: В 2014 году в RuCTFE сражалось уже 322 команды из различных стран мира!

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

Следом, мы начали изучать сайт ctftime.org тут размещено расписание всех соревнований (по всему миру) и рейтинг команд-участников (зарегистрированных на сайте).

Мы адекватно понимали, что Attack-Defense нам пока не светит, но порешать какие-нибудь задания в формате Task-based, чтобы набраться опыта, мы были готовы.

Первый в жизни CTF


Нам несказанно повезло, что один из ближайших CTF'ов был русский, а именно School CTF (организатор команда SiBears), в котором было разделение между школьниками и не школьниками и указано время проведения 8 часов (кажется это было именно так).

Конечно же, было очень важно зарегистрироваться Но как? Какое название команды?

Как-то так получилось, что именно я организовал наше участие и стал негласным капитаном команды.

Это же был первый раз, а мы понимали, что морское ДНО это как раз мы в этих соревнованиях Собственно, не долго думая, я предложил и здравствуйте, Мы команда DnO.

Мы вооружились ноутбуками, ручками, блокнотами и переживали, что нам еще может понадобиться.

Итак, началось Мы открыли задания и для нас это были иероглифы, которые никак не складывались в предложения (тем более в задания).

Но, спасибо Google, мы постепенно начали разбираться что означает то или иное слово и наконец начали гуглить не просто слова, а уже пытаться решать задания и, стоит отметить, у нас это даже получалось


Предварительные результаты

Стоит отметить, что мы были на кураже, у нас многое получалось и мы чувствовали, что старт был более чем идеален. Как вы можете увидеть на предварительных результатах, мы держали 6 место, но потом сместились примерно на 10 (но с учетом количества команд, мы уже не думали об этом, а отмечали успешный старт).

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

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

Что за команда DnO?


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

Вдруг, произошло интересное событие, мы собрались на очный CTF (до этого всегда выступали только online), кажется это был QCTF и проходил он в Москве, а точнее в МИРЭА. Естественно, это совсем другая энергетика, вокруг все давит, потому что ты не сидишь себе на диване спокойно, но ощутить это тоже хочется.


Фото одного из заданий QCTF

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

Как итог, команда DnO из 20 команд заняла почетное 4 место (ну вы понимаете как было обидно), но когда мы вернулись в универ, нам сказали, что это обязательно надо рассказать всем, как там называется ваша команда?

Этот вопрос поставил нас в тупик Конечно, парни особо не загонялись и такие: Ну ты же предлагал DnO, теперь давай придумывай расшифровку, чтобы весь ВУЗ над нами не ржал в голос.

После часа штудирования словаря, придумал единственную адекватную расшифровку как Destroy Network of Opponent, что переводится как Уничтожить сеть противника (спасибо, что предлоги не учитываются в сокращениях).

С тех самых пор мы следовали старой поговорке про судно Как назвали, так и поплыло.

Первая победа пополам


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

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


Команда DnO в Волгограде

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

Финальный свисток и мы Вторые? Как? Но ведь У нас одинаковое количество очков, но команда Life сдала последний флаг раньше нас по времени, из-за чего мы заняли второе место Команда DnO впервые была близка к победе, но упустила её в последний момент.


Финальный скорборд соревнований VolSUCTF

Первый Кубок CTF России


Прошло пару месяцев, мы не оставляли попытки добиться высоких результатов в различных online CTF'ах, но всё было тщетно, а тут мы еще узнали, что идёт набор на ПЕРВЙ Кубок CTF России, а отбор на него идет по результатам отдельно выбранных организаторами CTF, проходивших с начала года.

Естественно, среди них был и VolSU CTF, в котором мы успешно заняли 2 место и, по сути не проходили на этот безумно интригующий ПЕРВЙ Кубок

Однако, после мониторинга обстановки, нам стало известно, что команда Life, с которой мы поделили 1 место, участвует в данном мероприятии как организатор Ииииииииии, да, команда DnO приглашается на I Кубок CTF России, как призер VolSU CTF.

Естественно, не было известно абсолютно ничего про данное мероприятие и все, что нам оставалось, это усиленно готовиться.

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


I Кубок CTF России. День первый. Task-based.

Нас встречают, выдают приколюхи (наклейки, футболки и самое главное, ФЛАЖКИ!)


Тот самый, заветный флаг команды DnO

Быстрая жеребьёвка и мы узнаём какой у нас номер стола, ушли готовиться. Оперативно развернув свои печатные машинки, выступление организаторов мероприятия, где мы узнаём интересные новости, а именно:

1. Кубок проходит в 3 этапа за 2 дня;
2. Этап 1 Task-based (участвует 20 команд, проходят в следующий этап 10 лучших);
3. Этап 2 Attack-Defense (участвует 10 оставшихся команд, в следующий этап проходят 4 лучших);
4. Этап 3 Финал. (участвуют 4 команды, что будет происходить тайна, покрытая мраком...).

Не заглядывая вперед, начали готовиться к первому этапу сие мероприятия, которое обещало быть увлекательным

Итак, ЭТАП 1, начали.

Изнурительные 8 часов работы с приостановкой соревнований на обед. Мы выкладывались на полную, показывали лучшую командную работу, которая была когда-либо и за это получали заветные флаги, очки, которые могли вывести нас в следующий раунд.

Забыв про Scoreboard (таблицу результатов), мы работали до последней секунды данного этапа и, не без везения, мы занимаем 6 строчку в таблице.


Scoreboard после 1 тура Кубка CTF России

За нашим столом гробовое молчание Никто не верит, что мы не просто прошли во второй этап, мы прошли уверенно.

Только после того, когда нас пришел поздравить наш куратор, мы осознали, что происходит и с нашего лица больше не сходила улыбка.

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

Да, мы понимали, что очень слабы в Attack-Defense, но всё равно были заряжены трудиться до последнего.

Итак, ЭТАП 2, начали.

Когда мы сели за стол и снова развернули наши печатные машинки, удивлению не было предела


Наше задание второго этапа. Своя криптоферма.

Мы увидели эту, не сказать что огромную, коробку и сколько в ней всего, как там всё устроено и осознали, что попали по самое небалуй

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

Стоит отметить, что наши старания не прошли мимо, мы все же подняли сервер и даже получили некоторую часть флагов, но, естественно, этого было мало, другие команды были куда более подготовлены

Итог, 9 место на втором этапе. Конечно, есть небольшое расстройство, но задачу минимум мы выполнили, чем стоило гордиться.


Scoreboard 2 этапа.

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

До такого уровня, нам явно было далековато

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

Но это уже совсем другая история...

Отдельно хочется поблагодарить организаторов таких соревнований (различные CTF-команды, а также организацию АРСИБ), наставникам, кураторам, моим друзьям, выступавшим за эту команду, и ребятам, выступающим за другие команды.

Никто не забыт, огромное спасибо за это превосходное время!

То, что описано в этой статье, определенно развернуло мою жизнь градусов на 60 минимум:D
А успехи команды вы можете посмотреть вот тут.

P.S. Флаг до сих пор стоит на рабочем месте возле монитора и греет душу
Подробнее..

Leak-Search как и зачем QIWI создала сервис, который ищет утечки исходных кодов компаний

24.09.2020 14:19:46 | Автор: admin

Искать утечки и уязвимости в своих продуктах не только интересно и полезно, но и необходимо. Еще полезнее подключать к таким поискам внешних специалистов и энтузиастов, у которых не настолько замылен глаз, как у сотрудников. Поэтому в свое время мы в QIWI запустили программу bug bounty исследователи писали нам об уязвимостях и получали вознаграждение, а мы закрывали эти уязвимости.

Несколько раз нам присылали выложенный в публичный доступ код в виде ссылок на репозитории с чувствительной информацией. Причины утечек могли быть такими:

  • разработчик писал тестовый пример кода для себя, используя конфигурации боевого сервиса не тестовую среду;

  • админ выкладывал скрипты автоматизации и миграции базы данных потенциально чувствительной информации;

  • стажер неосознанно размещал код в своем публичном репозитории, считая, что это не несет рисков.

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

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

И в целом безопасность компаний не абсолютна: хорошо защищая свой периметр и информационные системы с помощью с помощью Firewall, SOC, IDS/IPS и сканеров безопасности, компании все равно подвержены многим источникам утечек от внешней разработки и аудиторов до вендорских решений. Конечно, невозможно отвечать за безопасность других компаний, но мониторить случаи утечки вашей информации с их стороны можно и нужно.

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

Так появился QIWI Leak-Search сервис, который ищет утечки вашего кода на Github и не только.

Как мы его делали и что он умеет читайте в посте.

Предыстория

Сначала мы пошли в рынок и посмотрели, как там дела с такими продуктами: вдруг можно купить что-то работающее, проблема-то, прямо скажем, не только у нас такая. Рынок уверенного ответа не дал, и мы поняли надо делать самим.

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

Тестировали Leak-Search мы прежде всего на себе, но затем решили посмотреть, есть ли проблемы с утечками у компаний, которые явно тратят на информационную безопасность немало средств и времени. Мы взяли компании из рейтинга Fortune и проверили их с помощью нашего сервиса. Тогда мы удостоверились, что вне зависимости от того, сколько ресурсов компания вкладывает в ИБ, подобного рода утечки встречаются и у нее.

Затем мы решили проверить отечественные крупные компании, которые своими силами борются с утечками. У них тоже нашлись подобные ИБ-сложности: доступы к базам данных, почтовым серверам, к управлению гипервизорами и многое другое. В общем, если вы представите себе какую-то известную компанию, знайте: скорее всего, у нее ситуация с утечками примерно такая же есть над чем работать.

Вот несколько примеров, которые мы нашли с помощью Leak-Search. Крупная российская компания из сферы ритейла дает доступ к ERP-системам для управления деталями заказов кто хотел бы бесплатно перенаправлять себе чужие заказы на технику и одежду? Один из международных ИТ-гигантов предоставляет исходники операционной системы для IoT-устройств почему бы не поискать уязвимости, обладая максимальными правами доступа? Неназванное западное управление по исследованию космоса без проблем открывает информацию о потенциально опасных астероидах отличная возможность получить доказательства для создателей пугающего контента. Детали и названия этих компаний по понятным причинам мы не разглашаем.

Что и как ищет QIWI Leak-Search

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

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

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

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

Поэтому в Leak-Search мы ищем все, что может относиться к чувствительным данным. Например:

набор определенных ключевых слов smtp, Dockerfile, proxypass, Authorization;

названия пакетов com.qiwi.processing.common;

адреса серверов int.qiwi.com, 10.4.3.255;

названия переменных, характерных именно для внутренней разработки компании QIWISECRET_KEY, qiwiToken.

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

Особенности поиска системы

Репозиториев существует великое множество. А еще много как просто похожих репозиториев, так и форков. У нас тоже много вещей отдано в Open Source: мы поддерживаем это движение и рады делиться с ИТ-сообществом ценными наработками. Пользователи из наших исходных кодов уже успели сделать больше сотни разных форков.

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

Масла в огонь подольет еще и StackOverflow один разработчик придет на портал с вопросом, разместив часть кода, которую он не понял. Второй ответит в комментариях и даст другой отрывок кода в качестве ответа. Третий через пару месяцев найдет эту ветку обсуждения, потому что тоже не понял код, и заберет пример из комментария к себе на Github. И скорее всего, найдет ветку и возьмет код не он один.

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

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

Но сравнение результатов это не killer feature продукта. Leak-Search может больше: он позволяет пользователю персонализировать поиск и использовать механизм фильтрации, чтобы исключить ложные срабатывания. Во-первых, можно включить определенные репозитории в такой фильтр и не искать фрагменты утечки по ним. Во-вторых, фокусируясь только на конкретных, интересующих вас объектах, вы будете получать нужные результаты.

Разработка и поддержка

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

При этом мы активно добавляем публичные платформы для хранения исходных кодов в список источников, по которым осуществляется поиск. Начали мы с Github но теперь Leak-Search ищет утечки уже и в Gist. В бета-тесте у нас Pastebin и Gitlab, и еще планируем добавить BitBucket. А под каждый источник мы учитываем его специфику поиска и работы с API.

В рамках алгоритма, конечно, бывают и ложные срабатывания как false positive, так и false negative. Пока мы решаем это добавлением новых правил для фильтров, чтобы те работали все точнее.

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

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

Этическая сторона вопроса

Как и любой сервис, связанный с поиском утечек, Leak-Search можно использовать не только для защиты, но и для нападения. Скажем больше когда мы пилотировали продукт с некоторыми компаниями, сталкивались с тем, что их сотрудники вместо того, чтобы тщательно исследовать свои ИБ-проблемы, сканировали утечки конкурентов.

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

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

Если вам интересно что-то еще, о чем мы не упомянули в посте, спрашивайте, ответим.

Подробнее..

Перевод Ищем уязвимости в Python-коде с помощью open source инструмента Bandit

17.06.2021 16:13:58 | Автор: admin


Наверное, все разработчики слышали, что нужно писать чистый код. Но не менее важно писать и использовать безопасный код.

Python-разработчики обычно устанавливают модули и сторонние пакеты, чтобы не изобретать велосипеды, а использовать готовые и проверенные решения. Но проблема в том, что они не всегда тщательно проверены на уязвимости.

Часто хакеры используют эти уязвимости, в известно каких целях. Поэтому мы должны иметь возможность хотя бы фиксировать факты вторжения в наш код. А ещё лучше заранее устранять уязвимости. Для этого нужно сначала самим найти их в коде, используя специальные инструменты.

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

Наиболее распространённые уязвимости в Python-коде


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

С наиболее распространёнными атаками более-менее справляются современные фреймворки и другие умные инструменты разработки ПО, имеющие встроенную защиту. Но понятно, что не со всеми и далеко не всегда.

Командная инъекция (внедрение команд)


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

В этом примере мы используем модуль subprocess, чтобы выполнить nslookup и получить информацию о домене:

# nslookup.pyimport subprocessdomain = input("Enter the Domain: ")output = subprocess.check_output(f"nslookup {domain}, shell=True, encoding='UTF-8')print(output)

Что здесь может пойти не так?

Конечный пользователь должен ввести домен, а скрипт должен вернуть результат выполнения команды nslookup. Но, если вместе с именем домена через точку с запятой ввести ещё и команду ls, будут запущены обе команды:

$ python3 nslookup.pyEnter the Domain: stackabuse.com ; lsServer:     218.248.112.65Address:    218.248.112.65#53Non-authoritative answer:Name:  stackabuse.comAddress: 172.67.136.166Name:  stackabuse.comAddress: 104.21.62.141Name:  stackabuse.comAddress: 2606:4700:3034::ac43:88a6Name:  stackabuse.comAddress: 2606:4700:3036::6815:3e8dconfig.ymlnslookup.py

Используя эту уязвимость, можно выполнять команды на уровне ОС (у нас ведь shell = true).

Представьте себе, что случится, если злоумышленник, например, отправит на выполнение команду cat/etc/passwd, которая раскроет пароли существующих пользователей. Так что использование модуля subprocess может быть очень рискованным.

SQL-инъекция


SQL-инъекция это атака, в ходе которой из пользовательского ввода конструируется SQL-выражение, содержащее вредоносные запросы.

Благодаря активному использованию ORM количество таких атак существенно снизилось. Но если в вашей кодовой базе по-прежнему есть фрагменты, написанные на чистом SQL, необходимо знать, как строятся эти SQL-запросы. Насколько безопасны аргументы, которые вы валидируете и подставляете в запрос?

Рассмотрим пример:

from django.db import connectiondef find_user(username):with connection.cursor() as cur:cur.execute(f ""select username from USERS where name = '%s'"" % username)output = cur.fetchone()return output

Тут всё просто: в качестве аргумента передадим, например, строку Foobar. Строка вставляется в SQL-запрос, в результате чего получается:

select username from USERS where name = 'Foobar'

Так же, как и в случае с командной инъекцией, если кто-то передаст символ ";, он сможет выполнять несколько команд. Например, добавим к нашему запросу вместо имени пользователя строку "'; DROP TABLE USERS; -- и получим:

select username from USERS where name = ' '; DROP TABLE USERS; --'

Этот запрос удалит всю таблицу USERS. Упс!

Обратите внимание, на двойной дефис в конце запроса. Это комментарий, который нейтрализует следующий за ним символ "'". В результате команда select отработает с аргументом "' '" вместо имени пользователя, а потом выполнится команда DROP, которая больше не является частью строки.

select username from USERS where name = ' ';DROP TABLE USERS;

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

Команда assert


Не применяйте команду assert, чтобы защитить те части кодовой базы, к которым пользователи не должны получить доступ. Простой пример:

def foo(request, user):assert user.is_admin, "user does not have access"

# далее идёт код с ограниченным доступом

По умолчанию __debug__ установлено в True. Однако на продакшне могут сделать ряд оптимизаций, в том числе установить для __debug__ значение False. В этом случае команды assert не сработают и злоумышленник добраться до кода с ограниченным доступом.

Используйте команду assertтолько для отправки сообщений о нюансах реализации другим разработчикам.

Bandit


Bandit это инструмент с открытым исходным кодом, написанный на Python. Он помогает анализировать Python-код и находить в нём наиболее распространённые уязвимости. О некоторых из них я рассказал в предыдущем разделе. Используя менеджер пакетов pip, Bandit можно легко установить локально или на удалённую виртуалку например.

Устанавливается эта штука с помощью простой команды:

$ pip install bandit

Bandit нашёл применение в двух основных сферах:

  1. DevSecOps: как один из процессов Continuous Integration (CI).
  2. Разработка: как часть локального инструментария разработчика, используется для проверки кода на уязвимость до коммита.

Как использовать Bandit


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

Результаты проверки кода на уязвимость можно экспортировать в CSV, JSON и так далее.

Во многих компаниях существуют ограничения и запреты на использование некоторых модулей, потому что с ними связаны определённые, хорошо известные в узких кругах, уязвимости. Bandit может показать, какие модули можно использовать, а какие внесены в чёрный список: конфигурации тестов для соответствующих уязвимостей хранятся в специальном файле. Его можно создать с помощью Генератора конфигураций (bandit-config-generator):

$ bandit-config-generator -o config.yml


Сгенерированный файл config.yml содержит блоки конфигурации для всех тестов и чёрного списка. Эти данные можно удалить или отредактировать. Для указания списка идентификаторов тестов, которые должны быть включены или исключены из процедуры проверки, нужно использовать флаги -t и -s:

  • -t TESTS, --tests TESTS, где TESTS список идентификаторов тестов (в квадратных скобках, через запятую), которые нужно включить.

  • -s SKIPS, --skip SKIPS, где SKIPS список идентификаторов тестов (в квадратных скобках, через запятую), которые нужно исключить.

Проще всего использовать конфигурационный файл с настройками по умолчанию.

$ bandit -r code/ -f csv -o out.csv[main] INFO  profile include tests: None[main] INFO  profile exclude tests: None[main] INFO  cli include tests: None[main] INFO  cli exclude tests: None[main] INFO  running on Python 3.8.5434 [0.. 50.. 100.. 150.. 200.. 250.. 300.. 350.. 400.. ][csv]  INFO  CSV output written to file: out.csv

В команде выше после флага -r указан каталог проекта, после флага -f формат вывода, а после флага -o указан файл, в который нужно записать результаты проверки. Bandit проверяет весь python-код внутри каталога проекта и возвращает результат в формате CSV.

После проверки мы получим достаточно много информации:



Продолжение таблицы

Как упоминалось в предыдущем разделе, импорт модуля subprocess и использование аргумента shell = True в вызове функции subprocess.check_output несут серьёзную угрозу безопасности. Если использование этого модуля и аргумента неизбежно, их можно внести в белый список в файле конфигурации и заставить Banditа пропускать тесты, включив в список SKIPS идентификаторы B602 (subprocess_popen_with_shell_equals_true) и B404 (import_subprocess):

$ bandit-config-generator -s [B602, B404] -o config.yml

Если повторно запустить Bandit, используя новый файл конфигурации, на выходе получим пустой CSV-файл. Это означает, что все тесты были пройдены:

> bandit -c code/config.yml -r code/ -f csv -o out2.csv[main] INFO  profile include tests: None[main] INFO  profile exclude tests: B404,B602[main] INFO  cli include tests: None[main] INFO  cli exclude tests: None[main] INFO  using config: code/config.yml[main] INFO  running on Python 3.8.5434 [0.. 50.. 100.. 150.. 200.. 250.. 300.. 350.. 400.. ][csv]  INFO  CSV output written to file: out2.csv


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

Что важнее для вас?


Это был короткий туториал по основам работы с Bandit. Если вы используете в своих проектах модули, в которых сомневаетесь, их можно проверить на уязвимость прямо сейчас. Да и наш собственный код мы порой не успеваем довести до ума, жертвуя не только красивыми решениями, но и о безопасностью. Каковы ваши приоритеты?



VPS серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru