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

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

Кейс 1. Как я взломал сеть АБС-Банка

Привет друзья! Я не белый и не черный хакер, но выполнил просьбу — ни много ни мало — взломать сервер банка. Дело в том, что мой знакомый, работающий в службе безопасности «АБС‑банка» (название изменено), получил от управляющего задание проверить ИТ‑систему на устойчивость. Знакомый — ни разу не программист, а службист‑силовик, поэтому ни сисадмины, ни даже ИТ‑директор не догадывались о планах руководства зайти, так скажем, с черного входа и проверить сеть на «вандалоустойчивость».

Я думал над стратегией взлома 5 минут. Честно‑честно. План был такой: найти уволившихся сотрудников, которые расстались с этим банком не на хорошей ноте, и переговорить с ними. Для начала я прошелся по отзывам об этом банке в сети. Нашлось аж шесть негативных. Трое из них оставили свои имена (именно имена, а не фамилии). Кроме того, у меня был доступ к аккаунту кадровика своей компании на Хедхантере, и я мог просматривать резюме соискателей. По ключевику «АБС‑банк» я нашел двух человек с именами, совпадающими с именами авторов отзывов. Получив контакты соискателей, я заделался Пинкертоном и переговорил с ними по телефону. Я сказал: «Мошенники увели у меня деньги из банка, да еще и взяли на мое имя кредит. Никаких пин‑кодов никому не передавал, но банк попросту меня послал. Теперь хочу отомстить и взломать его сеть». Моей целью было узнать доступ к WiFi бек‑офиса. Мне повезло — один из собеседников сообщил мне логин/пароль. Это, конечно же, здорово, но не «протух» ли он? Пароль, а не собеседник. Оставалось только проверить. Я пошел в головной офис банка и — бинго! — зашел со смартфона в сеть.

Задача решена — провел, так сказать, социотехническое тестирование. Тут же звоню знакомому службисту‑силовику. «Спускайся, — говорю, — вниз и зови с собой шефа: я твою сеть шатал».

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

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

Кейс 2. Вход в дата-центр через туалет

Люблю проводить pen‑тесты (penetration test) и делюсь результатами одного из них, связанного с физическим проникновением в центр обработки данных через … туалет. Задачей было пройти из публичной зоны здания во внутреннее офисное помещение дата‑центра, которое, естественно, защищено от посетителей.

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

А теперь самое главное. Данный туалет был разделен поперек стеной на две равные части. Первая — публичная, в нее мог зайти любой посетитель. Вторая — только для персонала ЦОДа.

В публичной зоне я вошел в туалеты. Далее через ближайшую кабинку, в которой была скрытая дверь, вошел в вышеназванный «мочеиспускательный коридор» (мне даже не пришлось разбирать панели). Открыл ее, прошел дальше до зоны служебных кабинок. Убедившись, что в аналогичной кабинке на противоположной стороне никого нет, я вышел в «защищённую» зону дата‑центра.

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

Кейс 3. Как баги помогли проникнуть в ЦОД

Меня наняла компания, проверяющая объекты на физическую уязвимость. Необходимо было проникнуть в хорошо охраняемый ЦОД: карманы‑ловушки, ридеры бейджей, двери‑шлюзы и даже сканеры сетчатки глаза. Плюс, конечно же, видеонаблюдение и «кожаные» охранники. На проникновение была дана неделя.

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

Пришлось идти традиционным путем: сбор данных о посетителях, поиск офисной документации, сбор электронной почты. Для этого используются поисковики, LinkedIn и иные ресурсы. Плюс к этому — наружное наблюдение за объектом моими коллегами с фиксацией посетителей дата‑центра.

Правда, заказчик чуть облегчил задачу, сообщив фамилии сотрудников и поставщиков, предоставив образцы e‑mail и бланка компании, а также используемую терминологию. Самостоятельный сбор этой информации растянулся бы на несколько недель.

В результате анализа стало ясно, что дата‑центр много лет пользуется одной и той же фирмой по борьбе с насекомыми. Более того, один мой коллега тоже делал у них заказ, и у него даже осталась переписка. Взяв реальный e‑mail, я подготовил поддельное письмо — якобы от одного сотрудника ЦОДа другому. В нем сообщалось, что травля тараканов назначена на ближайшую пятницу, просьба подготовиться к приезду дезинсекторов.

Схема сработала, на письмо был получен ответ: «Отлично, звучит хорошо, приходите».

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

Утром в пятницу мы, неотличимые от настоящих борцов с насекомыми, заехали на объект. Служба безопасности о визите была предупреждена и проверила лишь наши настоящие удостоверения личности. После сотрудник, ответивший на переписку, проводил нас, собственно, в сам ЦОД. Открывать телекоммуникационные шкафы, даже для травли насекомых, естественно, не стали и серверам нас не допустили, но дали доступ к потолочным нишам и фальшполу для обследования их на предмет физических багов.

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

Кейс 4. Как я хакнул свой же умный дом

Я провел эксперимент — легко ли взломать свой же умный дом? Причем сфокусировался не на ноутах и смартфонах, а на других девайсах домашней сети: смарт‑ТВ, спутниковом ресивере, двух устройствах хранения данных (NAS), игровых консолях, принтере, маршрутизаторе моего провайдера и еще нескольких девайсах.

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

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

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

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

А еще я обнаружил интересную закономерность URL‑адресов у маршрутизатора от моего интернет‑провайдера. Каждому пункту меню соответствовала индивидуальная цифра URL‑адреса. Сначала цифры увеличивались от нуля и далее на единицу, но были и пропуски. Подставив в адресную строку недостающие цифры, я выходил на «скрытые» функции, такие как «Веб‑камеры», «Телефоны», «Доступ», «WAN» и «Обновление».

Далее я обнаружил проблему безопасности в смарт‑телевизоре: он не использовал никакой аутентификации или шифрования при загрузке контента. В этом случае злоумышленник может изменить изображения в административном интерфейсе и загрузить любой файл JavaScript.

В качестве вывода: мы не контролируем множество вещей и в значительной степени находимся в руках поставщиков ПО и оборудования.

Тема взлома, безусловно, интересна. А практика защиты обыденна, прозаична и порой скучна. Но без нее никак. Мы, как разработчики систем управления ИТ, можем сказать, что немалая доля успехав области киберзащиты кроется в грамотно построенной инфраструктуре. Поэтому надеемся, что нелишним будет ознакомиться с продуктами ISPsystem — все они доступны для бесплатного тестирования. Скачайте триал, получите доступ к демостенду или закажите демонстрацию интересующих платформ:

• DCImanager — управление физической ИТ‑инфраструктурой

• VMmanager — управление виртуализацией

• BILLmanager — автоматизация продаж хостинга и блачных сервисов

• DNSmanager — управление серверами доменных имен