- Регистрация
- 21.05.14
- Сообщения
- 903
- Сделки (гарант)
- 3
Всех приветствую!
Редко лично захожу на форум, но сейчас, в этот редкий, случай хочу поделится одной занимательной страшилкой.
Ко мне обратился человек, который сообщил что нашел меня на ДМ, задача у него была простая - провести аудит безопасности сервера.
Что конкретно нужно найти мне не сообщили, просто сказали "проверить максимально тщательно".
Аудит был проведен но его результат был неожиданным даже для меня, и вот что произошло...
Чать 1 - Предистория
На одном из профильных форумов (ДМ или нет - увы неизвестно) пользователь наткнулся на объявление о настройке «безопасных удалённых серверов». Автор объявления предлагал услуги по созданию и администрированию серверной инфраструктуры, позиционируя их как максимально защищённые решения для работы с конфиденциальными данными.
Потенциальный клиент заинтересовался предложением: ему требовался удалённый сервер, который можно было бы использовать для хранения криптовалютных активов и выполнения рабочих операций, недоступных на стационарном ПК. Основным требованием была мобильность: доступ к серверу должен был быть возможен из любой точки мира.
Исполнитель согласился выполнить заказ, и поначалу всё выглядело безупречно. Сервер был развернут и функционировал стабильно. Однако спустя примерно два месяца произошло непоправимое: с криптовалютного кошелька клиента исчезли средства.
Попытки найти причину не дали результата. Несмотря на тщательную проверку удалённого сервера, никаких признаков кейлоггеров, вредоносных модулей или систем скрытого мониторинга обнаружить не удалось. Среда выглядела «чистой», что только усиливало недоумение и подозрения...
Часть 2 - Неожиданный поворот событий
После того как средства исчезли, клиент начал самостоятельно проводить всевозможные проверки. Были задействованы системы аудита, различные бенчмарки, тесты производительности и анализ сетевых соединений. Однако все результаты указывали на одно: сервер был абсолютно «чистым». Это окончательно убедило пострадавшего, что проблема кроется не в сервере.
В поисках ответа пользователь обратился ко мне, задача тревиальная - "проверить максимально тщательно сервер"
Аудит занял всего пару часов и в результате было выявлено что сервер не физический а виртуальный ("у него там не закрытый, а открытый перелом" (С))
Пользователь недоумевая прислал скриншоты панели управления, где четко было видно, что сервер физический. Полная неразбериха!
Но с помощью доступа через консоль я выявил, что на самом деле используется следующая технология:
Часть 3 - Техническая
Злоумышленник действительно арендовал Dedicated Server — физический сервер у крупного и известного хостинг-провайдера. Но внутри этого сервера он запустил виртуальную машину, настроив проброс портов таким образом, что IP-адрес, отображаемый в панели управления хостера, совпадал с IP-адресом виртуальной машины.
На основной системе порт RDP был переназначен на 54545, а внутри виртуальной машины использовался стандартный порт 3389. В итоге, когда клиент в панели управления видел реальный IP-адрес и подключался по нему через порт 3389, он фактически попадал не на физический сервер, а внутрь виртуальной машины.
Тем временем злоумышленник грамотно использовал возможности VirtualBox: настроил систему перехвата буфера обмена и отслеживания нажатий клавиш вне виртуальной машины. Более того, он добавил автоматический запуск виртуальной машины при старте основной операционной системы. Это означало, что даже если клиент выполнял перезагрузку через панель управления хостера, вместе с основной системой автоматически перезапускалась и виртуальная среда. Для пользователя это выглядело как нормальная перезагрузка «его» сервера.
Проще говоря: внешне в панели всё было правильно — «мой» IP и «мой» сервер. А внутри того, куда подключался клиент — виртуальная машина, полностью под контролем злоумышленника на хосте. При этом внутри VM никаких следов компрометации не было — никакие внутриресурсные антивирусы или сканеры не показывали проблем, потому что фактический механизм перехвата действовал вне VM, на уровне хоста.
Это и объясняло, почему все проверки клиента были бесплодны: проверялось только то, что VM позволяла увидеть. Хозяин хоста оставался невидим, а отладочные инструменты внутри гостевой системы не могли зафиксировать то, что происходило вне неё.
Итог и напоминание
Сценарий прост и смертельно эффективен: взять контролируемый физический сервер, запустить внутри VM и аккуратно сделать так, чтобы внешние признаки совпадали с интерфейсом, который видит жертва. Для пользователя — всё выглядит «чисто», для злоумышленника — открытая дверь к вводу чувствительных данных. Ситуация становится еще проще, если клиент не хочет тратить деньги на физический сервер а сам просит ВПС.
Надо повторять об этом регулярно: люди, которые работают с финансами, далеко не всегда досконально понимают нюансы инфобезопасности. Иногда кажется, что решение — «взять и арендовать сервер у чувака с форума» — гарантирует безопасность. На практике же элементарная хитрость с виртуальной машиной и пробросом портов может обернуться крупными потерями.
Этот случай — именно про такую «детскую» и неприметную ловушку, которая стоит денег: доверие к панели хостера, слепое принятие того, что «IP совпадает», и отсутствие понимания разницы между хостом и гостевой системой. Люди забывают, пренебрегают вопросами контроля хоста, и платят за это реальными средствами.
Вариантов обезопастить себя есть масса, быть может стоит не лениться, и если хочется воспользоваться услугами спецов с форума - купите сервер сами, а "настройщику" дайти лишь доступ во внутрь, не 100% гарантия но 99% точно.
Всем добра! Берегите себя.
PS А если взять и на сервер загрузить EFIGuard, тогда даже svchost.exe можно превратить в шпиона, но это уже совсем другая история...
Редко лично захожу на форум, но сейчас, в этот редкий, случай хочу поделится одной занимательной страшилкой.
Ко мне обратился человек, который сообщил что нашел меня на ДМ, задача у него была простая - провести аудит безопасности сервера.
Что конкретно нужно найти мне не сообщили, просто сказали "проверить максимально тщательно".
Аудит был проведен но его результат был неожиданным даже для меня, и вот что произошло...
Чать 1 - Предистория
На одном из профильных форумов (ДМ или нет - увы неизвестно) пользователь наткнулся на объявление о настройке «безопасных удалённых серверов». Автор объявления предлагал услуги по созданию и администрированию серверной инфраструктуры, позиционируя их как максимально защищённые решения для работы с конфиденциальными данными.
Потенциальный клиент заинтересовался предложением: ему требовался удалённый сервер, который можно было бы использовать для хранения криптовалютных активов и выполнения рабочих операций, недоступных на стационарном ПК. Основным требованием была мобильность: доступ к серверу должен был быть возможен из любой точки мира.
Исполнитель согласился выполнить заказ, и поначалу всё выглядело безупречно. Сервер был развернут и функционировал стабильно. Однако спустя примерно два месяца произошло непоправимое: с криптовалютного кошелька клиента исчезли средства.
Попытки найти причину не дали результата. Несмотря на тщательную проверку удалённого сервера, никаких признаков кейлоггеров, вредоносных модулей или систем скрытого мониторинга обнаружить не удалось. Среда выглядела «чистой», что только усиливало недоумение и подозрения...
Часть 2 - Неожиданный поворот событий
После того как средства исчезли, клиент начал самостоятельно проводить всевозможные проверки. Были задействованы системы аудита, различные бенчмарки, тесты производительности и анализ сетевых соединений. Однако все результаты указывали на одно: сервер был абсолютно «чистым». Это окончательно убедило пострадавшего, что проблема кроется не в сервере.
В поисках ответа пользователь обратился ко мне, задача тревиальная - "проверить максимально тщательно сервер"
Аудит занял всего пару часов и в результате было выявлено что сервер не физический а виртуальный ("у него там не закрытый, а открытый перелом" (С))
Пользователь недоумевая прислал скриншоты панели управления, где четко было видно, что сервер физический. Полная неразбериха!
Но с помощью доступа через консоль я выявил, что на самом деле используется следующая технология:
Часть 3 - Техническая
Злоумышленник действительно арендовал Dedicated Server — физический сервер у крупного и известного хостинг-провайдера. Но внутри этого сервера он запустил виртуальную машину, настроив проброс портов таким образом, что IP-адрес, отображаемый в панели управления хостера, совпадал с IP-адресом виртуальной машины.
На основной системе порт RDP был переназначен на 54545, а внутри виртуальной машины использовался стандартный порт 3389. В итоге, когда клиент в панели управления видел реальный IP-адрес и подключался по нему через порт 3389, он фактически попадал не на физический сервер, а внутрь виртуальной машины.
Тем временем злоумышленник грамотно использовал возможности VirtualBox: настроил систему перехвата буфера обмена и отслеживания нажатий клавиш вне виртуальной машины. Более того, он добавил автоматический запуск виртуальной машины при старте основной операционной системы. Это означало, что даже если клиент выполнял перезагрузку через панель управления хостера, вместе с основной системой автоматически перезапускалась и виртуальная среда. Для пользователя это выглядело как нормальная перезагрузка «его» сервера.
Проще говоря: внешне в панели всё было правильно — «мой» IP и «мой» сервер. А внутри того, куда подключался клиент — виртуальная машина, полностью под контролем злоумышленника на хосте. При этом внутри VM никаких следов компрометации не было — никакие внутриресурсные антивирусы или сканеры не показывали проблем, потому что фактический механизм перехвата действовал вне VM, на уровне хоста.
Это и объясняло, почему все проверки клиента были бесплодны: проверялось только то, что VM позволяла увидеть. Хозяин хоста оставался невидим, а отладочные инструменты внутри гостевой системы не могли зафиксировать то, что происходило вне неё.
Итог и напоминание
Сценарий прост и смертельно эффективен: взять контролируемый физический сервер, запустить внутри VM и аккуратно сделать так, чтобы внешние признаки совпадали с интерфейсом, который видит жертва. Для пользователя — всё выглядит «чисто», для злоумышленника — открытая дверь к вводу чувствительных данных. Ситуация становится еще проще, если клиент не хочет тратить деньги на физический сервер а сам просит ВПС.
Надо повторять об этом регулярно: люди, которые работают с финансами, далеко не всегда досконально понимают нюансы инфобезопасности. Иногда кажется, что решение — «взять и арендовать сервер у чувака с форума» — гарантирует безопасность. На практике же элементарная хитрость с виртуальной машиной и пробросом портов может обернуться крупными потерями.
Этот случай — именно про такую «детскую» и неприметную ловушку, которая стоит денег: доверие к панели хостера, слепое принятие того, что «IP совпадает», и отсутствие понимания разницы между хостом и гостевой системой. Люди забывают, пренебрегают вопросами контроля хоста, и платят за это реальными средствами.
Вариантов обезопастить себя есть масса, быть может стоит не лениться, и если хочется воспользоваться услугами спецов с форума - купите сервер сами, а "настройщику" дайти лишь доступ во внутрь, не 100% гарантия но 99% точно.
Всем добра! Берегите себя.
PS А если взять и на сервер загрузить EFIGuard, тогда даже svchost.exe можно превратить в шпиона, но это уже совсем другая история...
