- PVSM.RU - https://www.pvsm.ru -
Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!
Сейчас все бегают в панике и пытаются организовать «удалёнку», совершая простейшие ошибки, собирая все возможные грабли, поэтому я решил поделиться некоторыми драматическими историями с участием цыганских хакеров, незакрытых CVE и профессиональных, но немного наивных девопсов. Конечно, какие-то детали мне пришлось опустить или даже намеренно исказить, чтобы не расстраивать заказчиков. По большей части это практика не с текущей работы в Техносерве, но пусть этот пост будет небольшой памяткой о том, как делать не надо, даже если очень хочется.
Стоял сервер в дата-центре. Олдскульный такой, железный, безо всяких модных контейнеров и виртуализации. Несколько поколений сотрудников назад кто-то из разработчиков сконфигурировал его «временно, чтобы только несколько крупных файлов для проекта принять». Компания при этом на самом деле очень заботилась об информационной безопасности, но, как это часто бывает, коллеги из ИБ пошли навстречу нуждам бизнеса и согласовали временный вариант с полноценным выходом в интернет.
К счастью, сервер находился в серой зоне DMZ и не мог подключаться напрямую к критичным сервисам внутреннего контура. Наружу выставили 22-й порт, а внутри просто добавили несколько локальных пользователей с индивидуальными паролями для входа по ssh/sftp. Доступ по сертификатам посчитали слишком неудобным. Потом прибежали разработчики из другого проекта и попросили помочь автоматизировать регулярные выгрузки с сервера контрагентов, ведь «у вас есть удобный сервер с согласованным выходом в сеть». Потом ещё.
В итоге получилась крайне жизнерадостная ситуация, когда сервер, вроде как временный, обновлений не получал ни разу, но на него завязана уже куча бизнес-процессов, и прокачивается несколько терабайт данных в месяц.
Решили поставить на мониторинг, раз уж сервер такой важный, и в графиках CPU сразу полкой на 100 %. Полезли разбираться: а там куча процессов rand от имени подозрительного пользователя test и куча сожранной ими памяти, а в логах непрерывный брутфорс со всего света.
Перед преданием сервера забвению потыкали в процессы палочкой: lsof сразу показал удалённые, но незакрытые файлы, которые ещё висели в оперативной памяти. К сожалению, точно понять, что делал злоумышленник не получилось, но поведение было похоже скорее на человека, чем на отработку скрипта. При обследовании висевшего в RAM скрипта очень порадовали вставки вроде scanez clasa (сканирую класс) на румынском языке:
#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done
Насколько мне известно, ничего серьёзного не утекло (или мне про это не рассказали) и во внутренний периметр атакующему попасть не получилось, но с тех пор в компании ходит история о цыганских хакерах-конокрадах.
Я прекрасно понимаю, что NAT был необходимым костылём, который портил жизнь разработчикам и не давал реализовывать варианты быстрого подключения узлов между собой. Тем не менее его побочный эффект от сокрытия внутренней структуры сети весьма полезен с точки зрения усложнения обычной автоматизированной атаки. И да, я отлично понимаю, что наиболее правильным вариантом является использование firewall, работающего по белому списку, чтобы явно разрешить только необходимые соединения. Проблема в том, что в мире непрерывного аджайла на такие мелочи как жёсткое конфигурирование firewall или не дай бог SELinux никогда нет времени и бюджета. И вообще, они мешают отладке, снижают критический показатель time-to-market и не дают спокойно жить разработчикам и девопсам.
Ситуация стала ещё интереснее, когда облачная инфраструктура, развёртываемая автоматически по требованию, стала отраслевым стандартом. Дело в том, что большинство облачных решений предполагают, что защита вороха из поднятых контейнеров и виртуальных машин лежит на конечном пользователе. Как правило, вам предоставляют инфраструктуру, выделяют белые IP-адреса и на этом всё, по сути, дают набор возможностей, а не готовые решения. По умолчанию всё закрыто, но это же неудобно и так мешает разработке. Поэтому давайте всё откроем и будем спокойно тестировать, а на продакшене уже сделаем как положено.
Часто это приводит к забавным случаям. Наблюдал одну немного пиратскую копию сервера известной MMORPG. Кланы, донат, непрерывные обсуждения матерей друг друга и прочие радости. Все удивлялись, почему некоторые персонажи так быстро прокачиваются, и вообще всемогущи. Пробежался nmap-ом по диапазону адресов ближайших к игровому серверу.
Оказалось, что вся инфраструктура, включая фронтенд, бэкенд и базу данных, просто торчали открытыми портами во внешний мир. А какой самый вероятный пароль у пользователя sa если БД доступна всему интернету? Правильно, тоже sa! В итоге самое сложное это разобраться со структурой таблиц.
Похожая история была с одним заказчиком, который открыл себе удалённый доступ к админской панели для домашней машины, на время пока работает из дома. Естественно, что админская панель была без авторизации, так как считалась безопасным внутренним ресурсом. А заказчик не стал заморачиваться и просто открыл порт для всего интернета сразу.
А открытые всему миру ELK-серверы всплывают каждую неделю. Чего только не находят в их содержимом. Начиная от личных данных, заканчивая номерами кредиток.
Особенно часто меня радует Samba-сервер, который традиционно используется для организации совместного доступа к ресурсам. Почему бы не настроить гостевой доступ для коллег из соседнего отдела, чтобы удобно меняться файлами?
В небольшой компании всё шло неплохо, пока отделов не стало больше. Через какое-то время потребовалось настроить доступ к удалённым филиалам. И вполне «разумным» решением было открыть доступ к samba извне. Ну у всех же свои пароли, что может пойти не так? Про гостевой доступ никто не вспоминал, пока не выяснилось, что ощутимая часть HDD забита чьими-то данными. Автоматические сканеры быстро нащупали бесплатное файлохранилище, и HDD начали быстро забиваться чьими-то шифрованными архивами. А ещё в одном из каталогов мы обнаружили при аудите коллекцию отборных фильмов для взрослых с участием актрис 60+ (и повезло ещё что не 18-, а то бы прилетело от правоохранительных органов).
У меня был один заказчик, который совершенно не понимал, зачем ему нужно тратить дополнительные суммы на резервное копирование, если у него всё работает. Это же дорого. А ещё у него всё отлично настроено. В итоге сотрудники, которые открывают и запускают всё подряд, что им присылают на почту, благополучно поймали вирус-шифровальщик. Базу 1С потеряли и восстановить смогли только благодаря бумажному архиву и одному подрядчику, который когда-то копировал базу себе.
Я пообщался с руководителем, объяснил ключевые моменты, которые нужно изменить в компании, чтобы устранить риски потери базы. Он кивал в течение всей беседы и в итоге выдал замечательную фразу: «Снаряд не попадает в одну лунку дважды. Теперь-то уже нечего бояться». От бэкапов снова отказался и закономерно потерял все данные по тому же сценарию через полгода.
По моему опыту маленькие и средние компании обычно начинают с полностью ручного управления учётными записями пользователей. В смысле новый менеджер по продажам топает в логово к бородатым админам, где ему торжественно выдают логин, пароль и навешивают доступы. Всё это неплохо работает, пока компания не начинает разрастаться.
Вот люди, продававшие композитные цистерны. У них недавно сменилось руководство и было принято решение провести полный аудит безопасности. Даже привели на экскурсию, чтобы показать производство. Зрелище весьма впечатляющее: в огромном цеху вращались большие заготовки, на которые наматывали стеклоткань, пока рабочие бегали с ведром эпоксидной смолы, тщательно размазывая её по заготовке.
В отдельном здании у них было административное крыло, где мы закопались уже непосредственно в организацию информационной части производства. На первый взгляд у них была организована довольно логичная схема, когда доступ к базе данных клиентов предоставлялся только по внутренней учётной записи в AD с согласованием руководителя. Когда человек увольнялся — он пробегал с чек-листом, сдавал оборудование, карточки и ему деактивировали учётку. Всё это делалось вручную, так как средства на полноценный Identity management не выделялись.
В процессе аудита мы обнаружили, что у них много лет назад был реализован самописный портал для того, чтобы продажники могли удалённо получать нужные им данные по клиентам. Они даже начали миграцию своей инфраструктуры в облако, но в итоге остановились на полпути из-за каких-то внутренних сложностей. Причём AD интегрировать туда не смогли и учётные записи удалялись точно так же по чек-листу при увольнении. Вроде бы всё нормально, но в логах мы обнаружили активный аккаунт некоего Василия, который был уволен несколько лет назад и сейчас благополучно работал в конкурирующей компании. Причём, судя по логам, он минимум раз в месяц выгружал почти полную клиентскую базу.
Учётную запись тут же заблокировали и начали смотреть, как человек смог обойти внутренние регламенты. Оказалось, что Василий вначале получил доступы к порталу как менеджер по продажам, а затем перевёлся на управляющую должность непосредственно в цех, после чего уволился. А чек-лист при увольнении в цеху совсем другой и деактивация учётки от портала там не числилась. Хотя, казалось бы, сделать общий чек-лист на проверку доступа во всех системах и проблему можно было бы избежать.
Почему-то ИБ традиционно воспринимают как недружелюбных личностей, которые бегают за всеми со своими скучными регламентами и мешают работать. На самом деле при всей гротескности примеров выше — они довольно часто встречаются в реальных кейсах и именно безопасники и параноидальность админов помогают их избежать.
Просто постарайтесь найти общий язык. В первую очередь сами сотрудники ИБ не должны становиться вахтёрами, которые занимаются только вынесением
А девопсам хочется пожелать быть иногда хоть чуть-чуть параноиками.
Текст подготовлен Владимиром Чикиным, руководителем направления ИБ Техносерв Cloud [2].
Автор: Техносерв Cloud
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/bezopasnost/350647
Ссылки в тексте:
[1] мозга: http://www.braintools.ru
[2] Техносерв Cloud: https://ts-cloud.ru/?utm_source=habrahabr&utm_medium=referral&utm_campaign=Kak_my_pobezhdali_bardak_s_zhelezom_i_stanovilis_byurokratami_s_nulya
[3] Источник: https://habr.com/ru/post/493730/?utm_source=habrahabr&utm_medium=rss&utm_campaign=493730
Нажмите здесь для печати.