Все наслышаны про нашумевшие хакерские атаки на финансовые организации. Злоумышленники воруют миллионы долларов, их действия детально разбираются исследователями, целая индустрия кормится на средствах защиты от них. В мире офлайновой преступности тоже широко обсуждаются громкие убийства, а не мелкие кражи. Маленькие компании не представляют интереса для серьезного киберкриминала, но подвергаются они атакам не реже крупных банков. Обычно это различное вредоносное ПО, в частности вирусы-шифровальщики, вымогающие деньги за расшифровку файлов. Но встречаются и реальные «хакеры», которые хотят поживиться за счет незадачливых бизнесменов.
Недавно нам удалось изучить две скомпрометированные системы, на которые были осуществлены схожие атаки. На их примере рассмотрим, как действуют злоумышленники, и какие ошибки позволили им успешно проникнуть на серверы организаций.
Жертва 1
Небольшая компания (менее 50 сотрудников). 1 сервер под управлением Win 2008. На сервере установлена 1С Бухгалтерия, развернуты файловые шары. Домен не развернут, на АРМ и сервере используются локальные учетные записи для сотрудников. Бухгалтеры могут заходить из дома по RDP на сервер для удаленной работы в 1С. Администратор приходящий. В целом, картина довольно характерная.
В понедельник утром у бухгалтеров не стартует 1С. Такое бывает. По инструкции администратора бухгалтер заходит в папку с базами 1С, чтобы их «передернуть». Не знаю, что это за режим работы 1С, который требует «передергивать» базы, и что это вообще значит, но баз в папке не обнаруживается. Вместо них лежит файл «ЧИТАТЬ!!!!!!.txt». В нем написано (без всякого уважения к орфографии и пунктуации), что базы похищены. При желании вернуть базы предлагается обратиться по указанному email-адресу (в стиле vasyanpetrov2001@mail.ru).
Начинается паника. Администратор вызван в компанию и безуспешно пытается разобраться, что случилось, и восстановить работу системы. Директор пишет письмо хакеру. Хакер лаконично запрашивает IP-адрес сервера и требует затем 30 000 руб. за возврат баз. Честно говоря, мы полагали, что требовать должны на порядок больше, но злоумышленники, очевидно, лучше знают своих жертв.
Нашего специалиста попросили помочь. Администратор вернул сервер в офис из дома, куда он увозил его для анализа, и сам присоединился к нашему специалисту. Анализ жесткого диска показал, что восстановить удаленные базы уже затруднительно. Из-за многократного включения сервера, попыток восстановления бекапов и прочих манипуляций, удаленные файлы перезаписались новыми. Никаких следов заражения системы, руткитов и т.п. обнаружено не было. В логах (их не почистили) было ясно видно, что в пятницу вечером стартовал перебор логинов/паролей на RDP. В воскресенье незамысловатый пароль одного из бухгалтеров был подобран. Перебор продолжился и закончился только после логина злоумышленника на машину в ночь на понедельник.
Здравый смысл подсказывал, что логика «бизнеса» злоумышленника не предполагала возврата баз, да и вообще их копирования на удаленный сервер. Вирусам-шифровальщикам нужна хорошая репутация для роста платежей, так как они работают массово и жертвы могут почитать о них в интернете. Здесь же логично было на месте хакера просто потребовать еще денег после получения первого транша. Для проверки этой версии были запрошены данные из биллинга провайдера. Действительно, базы никто не скачивал. Их просто удалили. Общение с не уважающим Розенталя хакером, соответственно, было свернуто.
Дальнейшее исследование показало, что в панике все почему-то решили, что последний бекап был пару месяцев назад. Причем базы бекапа лежали на том же жестком диске, что и боевые базы, и были доступны хакеру, но он не удосужился их поискать. На самом же деле бекап был сделан за 1 рабочий день до взлома и информацию можно быстро восстановить. Все мысленно пожелали хакеру мучительной смерти и радостные разошлись.
Рекомендации, которые можно было бы дать пострадавшей компании (с учетом ее скромного размера):
- бекапы должны делаться регулярно и храниться отдельно;
- права пользователей должны быть минимизированы (все бухгалтеры имели полный доступ ко всему на сервере);
- удаленный доступ лучше организовать по VPN и использовать токен дополнительно к паролю. Затрат это практически не потребует, а защищенность вырастет порядочно.
Жертва 2
Крупная компания, располагающая серверы на коллокации в одном из коммерческих ЦОДов Москвы. От ЦОДа поступает информация, что с одного из белых IP компании фиксируется поток вредоносного трафика (подробностей не предоставили). Нас попросили помочь администраторам разобраться, что происходит.
Анализ показал, что трафик идет с виртуального сервера с консолью управления Антивирусом Касперского. Те, кто работал с этим продуктом, знают, что чаще всего контроль над консолью дает администраторские права на всех машинах, где установлен антивирус. Ясно, что седых волос от такой новости у группы администрирования сильно прибавилось. Немедленно был создан снимок виртуальной машины с сохранением данных оперативной памяти. После этого машину в рабочей сети погасили и начался анализ копии в изолированном сегменте.
Каково же было наше удивление, когда мы обнаружили, что взлом был также осуществлен через перебор пароля на RDP из интернета. Администраторы уверяли, что сервер в интернет не публиковался. Параллельно стали изучать последствия взлома и то, как RDP оказался доступен из внешней сети.
Второе выяснилось быстро. Оказалось, что сетевой администратор редактировал листы доступа (ACL) на граничном маршрутизаторе Cisco через консоль. После окончания работ он накатил ACL на интерфейс… наоборот. То есть входящий и исходящий были перепутаны местами, открыв полный доступ к набору серверов из интернета. Этого никто не заметил.
Пароль был подобран очень быстро. В компании была принята парольная политика, но тут про нее почему-то забыли. Затем на сервере были созданы 4 учетные записи с правами локального администратора (Adm1n, Default User, Register, ASPNET). Через какое-то время злоумышленник зашел под учеткой ASPNET. Не обнаружив баз 1С (далее станет ясно, как мы поняли, что здесь также орудовали охотники на 1С), хакер вручную открыл браузер, запустил speedtest.net для понимания пропускной способности канала к серверу, и залил на сервер утилиту для перебора паролей на RDP. Вручную пошаманив с настройками, хакер запустил атаку на внешние серверы. Никаких следов попыток развить атаку на внутреннюю сеть или воспользоваться консолью Касперского не было. Если бы злоумышленник хоть немного пораскинул мозгами, он бы смог в итоге вымогать у жертвы куда больше, чем 30 000 руб.
Для брута паролей использовалась утилита, скаченная с популярного «хакерского» форума. Хакер вручную загрузил словари для перебора и стартовал атаку. Перебор шел для учеток с говорящими именами: Администратор, User1, User2, Buh, Buh1, Buh2, Buhgalter, Glbuh.
Можно посмеяться над примитивностью подходов, полным отсутствием автоматизации и слабыми техническими знаниями взломщика, но все это оказалось достаточно эффективным. За время работы утилиты были взломаны 4 реальных сервера российских компаний (с паролями вроде 12345). Злоумышленник вручную заходил на взломанный сервер, с которого шла атака, и проверял улов, который складывался в файл в папке с утилитой.
В целом, компания сделала выводы после инцидента:
- Стало вполне очевидно, что наличие политик не гарантирует их выполнение. Необходимо вводить контрольные процедуры.
- Начался процесс зачистки внутренней сети от незащищенных машин. Все убедились в том, что злоумышленник может добраться и до них при определенных обстоятельствах.
- Была введена процедура автоматического контроля сетевых изменений на периметре сети (автоматическое сканирование 2 раза в сутки).
- Были дополнены процедуры контроля изменений.
- Было введено регулярное сканирование на уязвимости снаружи и внутри сети.
- В целом не помешала бы и какая-то система обнаружения вторжений, которая бы пресекла перебор пароля во время атаки.
Заключение
Причиной обоих взломов являются скорее не жадные до легких денег скрипткидди, а безалаберность или ошибки самих администраторов. Будет возможность поживиться, найдутся и желающие. Особенно, если для этого не требуется особых усилий. Да и поверхностный подход к взломам можно объяснить не ленью и непрофессионализмом хакеров, а потоковым подходом к атакам: проще перебрать лишнюю сотню серверов, чем копаться с одним.
В любом случае, даже такие простые атаки могут стоить компании любого размера очень дорого. В оффлайне банки строят подземные сейфы, а на ларек на ночь вешают амбарный замок. Нараспашку двери никто не оставляет. В интернете же до сих пор все несколько иначе. На радость злоумышленникам всех мастей и уровней профессионализма.
Янкин Андрей, itsecurity
Автор: Инфосистемы Джет
