Какие ошибки в безопасности допускают IT-компании?

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

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

И это только RU-сегмент.

Почему так происходит?

Причин на самом деле не много, от плохой подготовки специалистов, которые администрируют сервис или вовсе их отсутствие, до наивных сотрудников, работающих в отделе.

Если малый и средний бизнес просто экономит на специалистах КБ (кибербезопасности) и просто не хочет переплачивать за качественную разработку сайта, то в большом все куда сложнее.

Большой бизнес, большие обороты, большой объем технической инфраструктуры и тысячи сотрудников, которых нужно подготавливать и раз в некоторое время устраивать инструктаж, и не "расписались – забыли", а так чтоб запомнили раз и на всегда, что почтовый домен компании example.com, а не example.co и прочее.

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

Обновлять ПО? Не, не слышали.

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

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

Вероятно компания даже не знает, что это ПО у нее есть. Лежит на давно забытом тестовом сервере и никто с 2016 года в глаза ее не видел, а потом внезапно во всех новостях: "Утекло N миллионов пользователей Example.Com"

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

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

На данный момент в Yota уведомлены о находке и все оперативно закрыли ✅

Политики контроля доступа

Очень болезненная тема большинства компаний, данные которых когда-либо утекали. Этим грешны все и фраза имеет довольно широкое значение: от контроля доступа сотрудников к каким либо объектам компании до банального ограничения доступа к .git для пользователей сайта.

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

Например, давайте возьмем сайт example.com, так как разработчики используют систему GIT для удобной кооперативной разработки, в корне сайта создается папка .git, которая содержит все изменения и последнюю версию проекта из репозитория.

Если вы зашли в каталог example.com/.git и наблюдаете список файлов и папочек вместо ошибки доступа (403), то могу вас порадовать, любым Git-дампером вы без проблем можете скачать исходники сайта и найти какую-либо важную информацию, например данные от базы данных и прочее.

Умный администратор правильно настроит конфигурацию веб-сервера и закроет доступ к example.com/.git, в том числе ко вложенным файлам и папкам.

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

Инъекции

Одни из наиболее распространенных и широких уязвимостей – инъекции.

Инъекцией может быть, как SQL-запрос (так называемая SQL injection), так и JavaScript-код (это уже XSS). Приведенные две уязвимости бывают совершенно разных видов и все они одинаково опасны и относятся к классу критических уязвимостей.

Обе уязвимости возникают из-за ошибок при разработке. Любые входящие данные на сайте должны экранироваться. При разработке на чистом PHP экранировать / фильтровать данные придется вручную, в случае с Python, любой фреймворк для работы с HTTP-севером дает этот функционал «из коробки».

SQLi (SQL injection)

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

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

Заходим на сайт и ищем формочку, например форма поиска. Набираем запрос, в конец ставим кавычку и.. отправляем.

На сайте появилась ошибка или просто пустой экран без результатов запроса? Вы нашли уязвимость! Остается только уведомить компанию о таком печальном событии или пойти дальше определять тип инъекции.

XSS (Cross-Site Scripting)

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

Чтобы узнать есть ли данная уязвимость в какой-либо форме ввода на сайте, например в комментариях, можно отправить туда <script>alert(1)</script>, если после публикация появится окошко с единичкой, то снова спешу вас обрадовать, вы нашли простенькую Stored XSS!

Конечно, методы эксплуатации данных уязвимостей бывают совершенно разные и простой Payload (в данном случае наши кавычки или <script>...</script>) может не сработать.

Вывод

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

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

@hashbin made it special for Antipov