Зануды от информационной безопасности

Слабые пароли. Проблема состоит в том, что пользователи заводят себе легко подбираемые пароли, где ТОП 5 самых популярных из них: qwe123, P@ssw0rd, Qwerty1, gfhjkm, 1q2w3e.

Рекомендации:

• Нужно повысить осведомленность пользователей, научить их создавать надежные пароли, например DvbnDybph-DhnD42 (пароль составлен из первых букв детской считалки, буквы в английской раскладке, D – заглавные, 42 – произвольное число).
• На регулярной основе проверять пароли от различных систем по словарям. Необходимо снять dump хешей и прогнать их через специальное ПО, которое позволит их дешифровать.

Сервисные учетные записи

Системные администраторы (или те, у кого есть права) создают для некоторых систем сервисные учетные записи (например, для резервного копирования) с максимальными правами, в случае доменной инфраструктуры на базе операционной системы Windows это права уровня доменного администратора. К сожалению, такая ситуация характерна для большинства проверяемых нами компаний. Многие объясняют это тем, что «у нас по-другому не работает». Помимо того, что такая учетная запись обладает максимальными правами, есть еще пара опасных моментов. Во-первых, в сервисных учетных записях часто стоят не очень стойкие пароли (встречается даже P@ssw0rd и производные). Во-вторых, у таких записей не меняют пароль с момента создания.

Рекомендации:

• В 99,9% случаев необходимости в добавлении сервисной учетной записи в группу доменных администраторов нет, это можно уточнить, ознакомившись с документацией по продукту или задав вопрос производителю.
• Если добавление учетной записи в группу доменных администраторов все-таки потребовалось, не реже чем раз в квартал рекомендуется менять пароль. Он должен содержать не менее 10 символов, обязательно использование символов и букв различного регистра. Естественно, он не должен быть словарным.

Сетевые папки пользователей

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

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

Это лишь небольшой список того, к чему пользователи дают доступ, в большинстве случаев его имеют все сотрудники, включенные в группу Users. В старых и непропатченных пользовательских операционных системах Windows нам встречался полный доступ абсолютно любого пользователя к системному диску через «C$».

Рекомендации:

• Внедрить контроль над обменом данными пользователями.
• Запретить пользователям открывать общий доступ к папкам на своих компьютерах.
• Проводить инвентаризацию данных, находящихся в общем доступе, для этого достаточно написать скрипт, который бы искал в названиях и содержаниях файлов информацию типа «пароль, конфиденциально» или по расширению файла *.key и т.п.
• В зависимости от типа организации и внутренних правил создать жесткую раздачу прав, это означает, например, что информацией владеет бизнес-подразделение, но права выдаются ИТ-отделом с согласования отдела ИБ и владельца информации. Как показывает практика, такой вариант наиболее оптимален, ответственность за предоставление доступа к информации полностью ложится на владельца информации.

Сетевой доступ

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

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

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

Рекомендации:

• Пользовательский сетевой сегмент можно разграничивать между отделами, подразделениями и т.д., но доступ к сетевому сегменту системных администраторов, сотрудников ИБ, топ-менеджеров должен быть изолирован. Это позволит предотвратить дальнейшее развитие атаки, если злоумышленник получил доступ к пользовательскому сегменту.
• Нужно ограничить доступ к управляющим портам (22/tcp, 23/tcp, 3389/tcp и т.п.), возможность управления серверами и сервисами должна быть только у сотрудников, непосредственно администрирующих их.
• Не реже чем раз в три месяца необходимо проверять внешний периметр на наличие избыточных возможностей в перечне открытых портов.

Неподдерживаемые операционные системы и отсутствие средств защиты.

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

В качестве примера здесь можно привести банковские организации, в которых по-прежнему используются операционные системы типа Windows XP/2000. Доступ к ним можно получить, эксплуатируя известные уязвимости, используя средства, публично доступные в сети Интернет.

Помимо этого, отсутствие средств защиты (антивирусы, IDS/IPS и т.п.) позволяет злоумышленникам беспрепятственно атаковать системы и оставаться незамеченными долгое время.

Рекомендации:

• Не использовать в информационной инфраструктуре ПО, которое уже не поддерживается производителем.
• Внедрить в организации политику «патч-менеджмента» и четко следить за ее выполнением.
• Внедрить антивирусные средства защиты.
• Внедрить IDS (внутри) и IPS (снаружи) для получения оперативной информации о возможных нарушениях безопасности.

«Без профи не обойтись»

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

Сетевые атаки

Некорректная настройка сетевого оборудования, клиентских ПК, а также отсутствие средств защиты приводят к возможности осуществления атак типа Poisoning (ARP, LLMNR/NBT-NS) Spoofing. Они обычно являются частью атаки MitM («человек посередине»), ставящей своей целью перехват и/или подмену информации.

Уязвимости веб-приложений

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

Социальная инженерия

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

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

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