Когда читаешь о крупном взломе, обычно представляешь что‑нибудь технически сложное. Уязвимость нулевого дня, хитро устроенный вредонос или долгую подготовку к очень точному персональному фишингу. Иногда все именно так и происходит. Но чаще всего процесс гораздо более простой. Например, несложный пароль входа в служебную админку налоговой службы или коммерческой компании.
И ведь сочетания вроде admin/admin или там admin/123456 давно стали поводом для шуток. Тем не менее подобные настройки еще встречаются — чаще, чем хотелось бы спецам по инфобезу. И не только у небольших фирм без своего сисадмина. У крупных организаций тоже находятся забытые служебные страницы, старое оборудование и подключения подрядчиков, которые никто толком не проверяет. Давайте посмотрим на несколько историй, где подобные мелочи привели к крупным неприятностям.
Дания: скомпрометировано 8,8 млн записей
Совсем недавний случай. В октябре 2 026 года появилась новость о незаконном доступе к датскому реестру населения CPR. Администрация сообщила, что взломщики получили имена, адреса, идентификационные номера и другие сведения примерно о 8,8 млн человек. В реестре есть умершие и эмигранты, поэтому число записей превышает население страны. Для сбора данных использовали подключение некой частной фирмы.
Вскоре выяснилось, что речь о субподрядной организации Pays ApS, которая занимается обработкой информации. Ее руководитель подтвердила, что чужие запросы шли через предоставленный предприятию доступ. А человек, назвавшийся автором атаки, рассказал журналистам о пароле 123456. Это сочетание использовалось минимум в трех учетных записях, включая административную.
Не менее любопытно, как все обнаружили. Так, с 10 по 20 сентября было выполнено около 14 млн автоматических поисковых запросов. Неладное заметили лишь 2 октября (!), когда сотрудник ведомства обратил внимание на счет с необычно большим объемом операций. Подключение Pays затем заблокировали, но сделанного не воротишь — персональная информация граждан Дании стала достоянием злоумышленников. Что там дальше будет с этими данными — неясно. Вроде бы взломщики пообещали ничего никуда не выкладывать, но…
Equifax: admin/admin и пароли под точками
В сентябре 2 017 года специалисты Hold Security изучили инфраструктура сервиса кредитного бюро Equifax в Аргентине. Для входа в административную часть подошла та самая связка admin/admin. Войдя в сервис, специалисты по инфобезу увидели не только сведения более чем о ста сотрудниках компании, но и возможность управлять их учетными записями. Посторонний мог добавлять пользователей, менять их настройки и удалять.
Но и это не все. В форме редактирования символы заменили точками, но это только на экране. Браузеру передавался plain text без какой‑либо защиты. Причем пароли совпадали с логинами: для входа использовали фамилию сотрудника, иногда добавляя к ней первую букву имени. Там же специалисты получили доступ к примерно 14 тысячам обращений с идентификационными номерами граждан. В общем, приложение само выдавало то, что интерфейс пытался спрятать. После запроса Брайана Кребса — а именно он изучал защиту этого сервиса — его отключили для разбирательства (портал, а не Кребса, ага).
В том же году произошла гораздо более масштабная американская утечка Equifax. Но взлом был более сложным: злоумышленники воспользовались незакрытой уязвимостью Apache Struts. Так что и там пришлось проводить разбирательство, тратить время и деньги на решение проблем с информационной безопасностью.
Гостиницы Wyndham: очень много денег
У сети Wyndham последствия были не только репутационными — обернулось все это очень ощутимыми убытками. После трех крупных взломов в 2008–2009 годах злоумышленники похитили реквизиты карт более 619 тысяч клиентов. Связанные с этим мошеннические списания оценивались как минимум в 10,6 млн долларов. В одной из гостиничных систем и логином, и паролем служило слово micros. Это название компании‑разработчика — очевидно, что после первых тестов пароль никто не сменил. При первом проникновении атакующие попали в локальную сеть, а затем перебором получили все необходимое для общей инфраструктуры.
Но и это не все. Через сеть одного отеля можно было попасть на серверы других гостиниц и забрать реквизиты новых банковских карт. Их хранили без шифрования (!), текстом, так что похищенное было сразу пригодно для мошеннических списаний. После первого взлома компания ничего не сделала… Поэтому преступники возвращались снова и снова, о чем сотрудники узнавали лишь спустя какое‑то время — его было вполне достаточно для новых списаний с карт клиентов.
В общем, эпопея продолжалась вплоть до 2 015 года. Тогда Wyndham заключила соглашение с американским регулятором. Оно предусматривало программу защиты клиентских реквизитов и ежегодные независимые проверки. Разбирательство обернулось долгосрочным надзором, за инфобезом гостиничной сети наблюдают до сих пор.
Mirai: мощный ботнет из крохотных устройств
В 2 016 году вредонос Mirai показал, сколько неприятностей могут принести дефолтные пароли. Он находила в интернете камеры, роутеры и видеорегистраторы, после чего пытался войти с комбинациями из заранее составленного списка. Если владелец ничего не менял при настройке, этого часто хватало для заражения. Никакого сложного подбора не требовалось: на десятках и сотнях тысячах девайсов стояли одинаковые логины и пароли. По подсчетам исследователей, на пике Mirai заразил более 600 тысяч устройств.
Зараженной техникой злоумышленники управляли удаленно, заставляя бонет ддосить что‑либо. По отдельности домашние аппараты особой угрозы не представляли, но вместе могли обрушить даже крупный сервис. Так и произошло 21 октября 2 016 года, когда под удар попал DNS‑провайдер Dyn. Как только его «уронили», браузеры перестали получать нужные ответы и страницы не открывались.
На этом история не закончилась. Осенью 2 016 года исходный код Mirai выложили в открытый доступ, так что и другие злоумышленники стали использовать его для своих атак. Создатели первоначальной программы признали свою вину в декабре 2 017 года, но остановить распространение уже разошедшихся копий было невозможно. До тех пор пока в интернете оставались устройства с заводскими паролями по умолчанию, их продолжали заражать и использовать для атак.
Детские ошибки и огромные убытки
Объяснение «сотрудник придумал слабый пароль» — не оправдание. Если пароль типа 12 345 или vasya98 вообще удалось установить, а служебная страница оказалась доступна из интернета, то проблема в системном провале всей инфраструктуры.
Компания может потратиться на железо и дорогой софт, но при подключении всего этого забыть отключить тестовую сеть. В итоге система безопасности просто не увидит атаку через эту «слепую зону». Любые средства защиты бесполезны, пока они не настроены и не обслуживаются регулярно.
Работу со своей инфраструктурой стоит начинать со скучной базовой гигиены (вы об этом не раз слышали, но лучше повторить):
Во‑первых, необходима тотальная инвентаризация: нужно четко знать все, что смотрит «наружу» из интранета — сервисы, железо, порты и учетные записи.
Во‑вторых, для любого админского входа необходима многофакторная аутентификация. Если старое оборудование не поддерживает смену паролей или MFA, его нужно изолировать и спрятать за защищенный узел. В CISA не просто так рекомендуют вендорам изначально задавать уникальный пароль на каждом устройстве или принудительно требовать его смену при первом входе.
Наконец, важно заранее ограничить права и внедрить автоматику. Инженеру поддержки, например, не нужна возможность выгружать всю базу клиентов, а аномальный объем запросов к БД пользователей должен блокировать сессию.
Что еще? Защитить систему от человеческих ошибок на 100% нельзя, но грамотная архитектура гарантирует, что слитый пароль станет лишь мелким инцидентом для дежурного админа, а не катастрофой для всей компании.