Epic fail of the month: rsync как «вектор» на утянуть данные

от автора

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

Речь пойдет совсем не про уязвимость в прямом смысле этого слова, а про то как по недосмотру (халатности или лени) выстрелить в ногу сразу длинной очередью.

Что собственно случилось

Команда UpGuard Cyber Risk нашла «дыру», где многия документы, в том числе и секретные, валялись (другого слова не подберу) в прямом публичном доступе.
Чтобы оценить серьёзность — среди компаний накрытых той «дырой» подразделения VW, Chrysler, Ford, Toyota, GM, Tesla и ThyssenKrupp.

Данные у всех разного типа, степени конфиденциальности и «грифа» секретности, но…

Где утащили нашли

На публично доступных серверах, принадлежащих к группе Level One Robotics, «провайдера инженерных услуг, специализирующегося на процессе автоматизации и сборки для OEM-производителей»…
Список собственно пострадавших компаний-производителей, см. выше.

Что утащили нашли

Порядка 157GB добра, включающего в себя схемы сборочных линий (за более чем 10 лет), планы расположения фабричных помещений, робототехническую конфигурацию и документация, формы запросов с ID сотрудников, формы запросов доступа по VPN, соглашения о неразглашении (тут смеяться), и т.д. и т.п. Это то что касается почти всех вышеупомянутых компаний. Кроме того персональные данные сотрудников (Level One и другие), включая сканы водительских лицензий и паспортов, бизнес-данные Level One (счета-фактуры, договора и реквизиты банковских счетов). Но то так, для разминки.

И наконец, видимо чтобы уже совсем добить, уровень доступа (permissions set), установленный на сервере, на момент открытия «дыры» внезапно обнаружился как writable, т.е. кто угодно мог потенциально изменить лежащие там документы, например изменив номер банковского счета в инструкции бухгалтеру на прямой перевод, мог зачислить себя любимого в штат сотрудников, мог воткнуть вредоносную программу и т.п. радости.

Как утащили зашли

А тут (как я уже намекал выше) всё очень просто — сервер был (или внезапно когда-то стал) доступен через rsync. Rsync-сервер не был ограничен не по IP (не на уровне пользователей, ключей и т.д.), т.е. все данные могли быть списаны любым rsync-клиентом, соединенным с rsync-портом.

Еще раз — rsync тупо торчал открытым портом наружу, без какой либо дополнительной проверки.

Вероятно просто — неправильная настройка (эффект нескольких поваров на одной кухне и т.п.).
Я не знаю (а UpGuard умалчивает), что там было конкретно — открытый ли ssh (что вряд ли), легаси rsh в качестве transport layer, прямой unison или какой другой socket-метод, rdiff или csync по HTTP, и т.д. Вариантов много, но — смысл в том, что в любом случае «вектор атаки» был бы сведен на нет простейшим firewall-правилом, разрешающим коннект только строго определенным портам и от 127.0.0.1, [::1] и еще пары «знакомых» адресов, aka белым списком.

Что имеем

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

А на вашей VPS-ке (а может где еще, где трафик завтра могут пробросить туннелем или как-то завернуть до «снаружи») закройте всё от греха подальше белым списком (whitelisting), чтобы завтра какой-нибудь сервис внезапно получивший доступ наружу (или новый появившийся вектор атаки) не уронил вашу безопасность ниже плинтуса.

Ну и натравите знакомого аудитора на вашего «провайдера инженерных и других услуг»…

Вдруг там тоже rsync портами наружу торчит — рыльце в пушку.


ссылка на оригинал статьи https://habr.com/post/418119/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *