СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Хостер FirstVDS оставил бэкдоры в поставляемых клиентам VDS в черновиках

Хостинг, Информационная безопасность
Хостер FirstVDS (у них есть блог на хабре) поставляет VDS своим пользователям с вот таким вот содержимым файла /root/.ssh/authorized_keys:



Т.е. это даёт возможность получать доступ через SSH к арендуемым пользователями VDS тем личностям, которые установили этот ключ. Комментарий в файле гласит, что этот ключ — для доступа техподдержки. При этом никакого оповещения пользователю не выдаётся. Решил написать в техподдержку для разъеснения этой ситуации и получил вот такой ответ





После последнего сообщения переписка была переведена в архив. Т.е., как я понял, была заблокирована для ответа. Вот такие у них отзывчивые менеджеры отдела Заботы о клиентах.

Т.е. мне предлагают стать клиентом (т.е. заплатить за продукт с бекдором), а потом ответят зачем его ставят мне и другим клиентам.

Насколько я могу видеть, бэкдор содержат образы виртуалок. И переустановка ОС из предоставляемого провайдером образа ситуацию не исправляет. Замечено как минимум на образах с Ubuntu.

Один из вариантов решения — удаление файла /root/.ssh/authorized_keys
FirstVDS, backdoor, лазейка, закладка
~9800
  shanker

комментарии (46)

+8
barker ,  
Одно непонятно: почему юзер сам не написал, зачем он пожелал не раскрываться?
+7
+9 –2
DVORYAN ,  
Некоторые беспричинно скрываются, у кого-то жизненный опыт был негативный.

В любом случаи, тех.поддержка поступила неправильно. Если он знает о подобной лазейки, то доступ у него есть. Таким образом тех.поддержка просто посчитала, что на вопрос отвечать не надо.
Да и даже если доступа нет и инфа пришла от третьих лиц или бывших клиентов, разве не надо объективно объяснить человеку данную причину?
+7
+22 –15
creker ,  
Менеджер по работе с клиентами справедливо послал непонятно откуда взявшегося человека, который даже этим клиентом и не является. Поступили правильно. Хорошо хоть после такого тона не послали прямо конкретно по-русски. Скорее всего есть четкие правила, что и кому можно сообщать. Не клиент — до свидания, мало ли чего ты там выдумал. Если найдена реальная уязвимость, а статья явно на это не походит, по крайней мере в текущем желтеньком виде, то я уверен, что есть куда более уместные каналы связи, через которые об этом можно сообщить.
+11
+13 –2
igordata ,  
Нет, не правильно. Пишет человек узнать об услуге. Никакой конкретной информации о конкретном клиенте он не спросил. Его должны были переключить с саппорта на продажников, а там он бы уже пробивался к кому-то уполномоченному или должен был бы указать клиентский аккаунт, от лица которого он говорит.

В любом случае разговаривать в чатике это бессмысленная затея. Максимум на что можно рассчитывать, это что вопрос передадут кому-то. Проще было сразу написать на несколько имейлов и подождать объяснений.
+3
+4 –1
shanker ,  
Из общедоступных каналов связи на сайте — почта отдела продаж и телефон в Москве. Можно, конечно, было звонить по межгороду. Но вот тогда не сделать скрина переписки. Саппорт как раз в личном кабинете после регистрации. Из-за чего я и зарегистрировался. Но от чего-то решили меня свести с отделом Заботы о клиентах
+3
+5 –2
wholeman ,  
Это — не инфа, а наезд. Ответ вполне соответствует вопросу.
+11
+13 –2
Nikon_NLG ,  
Не хочу вас расстраивать, но если есть доступ к хост-системе, к гостевой виртуалке можно достучаться и без ключа.
Если бы они вам патченый ssh ставили, тогда другое дело.
0
+2 –2
kekekeks ,  
В случае с KVM/Xen немного сложнее, т. к. виртуализация не контейнерная, а фс виртуалке обычно предоставляют блочное устройство, а не кусок файловой системы хоста.
+1
Nikon_NLG ,  
Понятно что есть нюансы, но в целом задачу решить можно.
Хотя, насколько я помню, они и dedicated с того же образа разворачивают, по крайней мере я ключи эти сразу вычищал, и добавлял только по мере необходимости.
–6
+2 –8
shanker ,  
Технически да. Но, насколько я знаю от людей исследовавших этот вопрос, в зависимости от типа виртуализации это может быть как не очень сложно так и не очень легко. Например, с OpenVZ — легко. KVM или XEN — существенно легче.
Да и одно дело — сам хостер при оказании техподдержки имеет доступ к внутренностям виртуалок. Другое дело — если этот ключ попадёт в нехорошие руки. Уволенный сотрудник утащит с собой и кому-нибудь передаст или ещё что
+2
Nikon_NLG ,  
Ключи — дело тонкое. Может они их каждый месяц меняют. В любом случае я их сразу удалял.
+1
hyperwolf ,  
Зайти с хоста в контейнер OVZ очень просто, в Xen — сложнее, но не более того.
–1
shanker ,  
Ошибка в моём комментарии выше. Имелось ввиду, что с OpenVZ — легко. KVM или XEN — существенно сложнее.
0
ProstoTyoma ,   * (был изменён)
deleted
+2
+4 –2
shanker ,  
Nikon_NLG
а какая разница в каком виде оставили доступ техподдержке (или кому-то ещё): в виде ключа или как патченные бинари? И о том, и о другом пользователю не сообщалось. И то, и другое позволяет получать не согласованный с конечным пользователем доступ. Вас устроит секретный ключ от двери Вашей квартиры от производителя? Ну, якобы для саппорта или «ой, после дебага забыли убрать»
0
+1 –1
wholeman ,  
Очень большая. Чтобы найти и убрать ключ достаточно пары простых команд, если знать, где искать, а чтобы найти патченый бинарник придётся сравнивать с оригинальным, что сложнее на порядки.
0
merlin-vrn ,  
А как же sudo debsums -c, rpm -V и аналоги?
0
wholeman ,  
Честно говоря, не разбирался с этим вопросом. Их сложно пропатчить/перенастроить, чтобы не ругались на изменённые бинарники? (Установка своих версий уже намного сложнее обнаружения и удаления /root/.ssh/autorized_keys.)
0
merlin-vrn ,  
Ну, можно впендюрить свои репозитории, но в целом — это гораздо больше работы, чем просто вставить ключ.
+4
vsb ,  
Вы арендуете номер в гостинице. От вашего номера ключи есть и у администратора, и у уборщицы. Это правильная аналогия.
0
merlin-vrn ,  
… и при этом все полагаются на эти ключи, а не на специально спроектированную уязвимость замка номера. Замок хороший.
+1
+2 –1
zabbius ,   * (был изменён)
Только надо учесть, что двери гостиницы выходят на улицу и попробовать открыть дверь ключом может любой посторонний человек, при этом у всех номеров одинаковые ключи.
При правильной аналогии с гостиницей должно быть ограничение на доступ только из сети саппорта. И обязательное логирование. Ну и, конечно же, ключи должны отличаться.
+1
shanker ,  
Сотрудники гостиницы это скрывают? И на уточняющие вопросы реагируют отговорками?
+1
botaniQQQ ,  
VM Manager -> SSH Keys
Наверняка там этот ключ есть. И при каждой переустановке он будет автоматически добавляться.
Попробуйте сгенерировать свой ключ, вставить туда и переустановить сервер. Если он не изменится, то вероятно у них какие-то неполадки и он не подхватывается.
+18
+21 –3
gtbear ,  
Если человек не меняет сразу ключи авторизации то процентов на 90 ему в дальнейшем понадобится помощь технической поддержки. А раздавать направо и налево пароли это плохой вариант. Вобщем нехорошо конечно что не уведомляют пользователей, но заголовок слишком желтый.
+14
SilverFire ,   * (был изменён)
Само наличие ключа — не проблема. Проблема в том, что он один на всех суппортов и не ограничен по IP. Что в этом плохого:
  • раз нет ограничения по IP, нет и единого access-сервера, откуда суппорты имеют право ходить на клиентские сервера, при чем желательно по локальным management IP адресам;
  • невозможно быстро лишить сотрудника прав доступа. Придется обходить все сервера и менять публичный ключ, плюс раздавать всем действующим сорудникам новый приватный ключ;
  • все сотрудники ходят под одним ключом и логинятся рутом. Если кто-то налажал и не признается — почти нереально выяснить, кто именно это был;
  • сотрудники имеют на руках приватный ключ и могут случайно (или неслучайно) его скомпрометировать. Так как нет ограничения по IP, кто угодно может им воспользоваться и, снова таки, будет непонятно кто из сотрудников стал виновником.
+5
thunderspb ,  
На всех сервера первым дело закрываю логин по ssh для рута…
+3
achekalin ,  
А кто мешает, вообще говоря, свежеполученную машину проверять на подобные вещи просто на автомате? Не надо весь файл удалять, просто убираем из него ненужные ключи, и нет проблемы.

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

Другой вопрос, что а) предупреждать надо все же, и б) немного топорный метод оставить один и тот же ключ во всех VPS-ках. Как справедливо подметили, сотрудник ТП, унесший с собой ключ, может много что натворить на сотнях машин. Не то чтобы ТП любит подобное делать, но люди разные, а если еще это уволенный, обиженный на начальство — мало ли что? Приделали бы авторизацию по LDAP какому-нибудь, чем не вариант?
0
+1 –1
khim ,  
Почему не сделать как у людей? У Linode проблема решается просто: в случае необходимости грузится другой Linux, куда основаня файловая система монтрируется в chroot и, если нужно, меняется пароль и делаются любые другие манипуляции.

Да, для этого виртуалку придётся «погасить» и перезагрузить. Что, если вы немного подумаете — является скорее плюсом, чем минусом.
0
merlin-vrn ,   * (был изменён)
Одна контора меня так удивила. В арендованном сервере меняли сдохший винт. Ну, вырубили машину, поменяли, врубили (хотя вообще AHCI можно было и в горячую поменять), она поднялась, стала запускаться основная система, запустила свои виртуалки. Казалось бы, молодцы, отчитайтесь клиенту, и свободны.

Нет, они снова перезагрузили машину в rescue-систему только для того, чтобы включить новый диск в soft-raid и запустить процесс синхронизации. На вопрос «зачем, это можно ведь было сделать из работающей системы, и даунтайм был бы 15 минут вместо 2 часов» не смогли ответить (ответ был в духе «ну да, это мы зря»). У них даже доступ был чтобы это сделать, не говоря уже о том, что мне было нужно только чтобы физически поменяли винт, уж раид-то починил бы сам.

Нет уж, лучше без rescue-систем, если они будут использоваться так.
+4
symbix ,  
Да ладно, это мелочи. Бывают поразительные случаи заботы о клиентах. Припоминаю два.

Первый (было года три назад). У меня есть привычка перевешивать ssh на нестандартный порт — просто чтобы в логах любители сканирования и перебора по словарю не мешались (про fail2ban знаю, одно другому не мешает). У одних молодцов сработал мониторинг, они не поняли, что произошло, решили, что все накрылось (!), сняли бэкап виртуалки и переустановили (!!), после чего написали письмо о своем отважном подвиге. Попросил больше никогда ничего не трогать и убрать свои кривые руки подальше. :) Унес бы от них подальше, да клиент не захотел, у него там скидки были.

Другой случай был с выделенным сервером, в давние времена еще, когда про nginx в основном было известно только в ex-USSR. У других молодцов был мониторинг, который зачем-то проверял наличие заголовка Server: Apache* в ответе. Эти молодцы зашли на сервер с консоли, обнаружили отсутствие апача, после чего его поставили обратно, обнаружили, что он запуститься не может (80-й порт немножко занят), после чего догадались написать мне на емейл и спросить. От них сразу унес. :)
+1
achekalin ,  
Ответ один — «квалификация». И тех, кто систему управления ВМ-ками делает, и арендаторов самих ВМ-ок.

Ведь не секрет, что многие берут VPS из-за цены и возможности делать на машине то, что хочешь, да еще из-за выделенного IP, что позволяет по цене аренды shared-хостинга (который часто настроен во времена оные, и особо не поддерживается) получить и места побольше, и https нормально настроенный, и прочие плюшки.

При этом многие арендаторы таких VPS не особо сведущи, и многое выясняют методом тыка, заодно дергая ТП. И ответ «перезагрузитесь в rescue-систему, чтобы мы могли зайти и вам помочь» вроде бы и логичен, только и для этого от клиента нужна квалификация. Кроме того, мало ли какие у юзера проблемы, иногда они связаны именно с той ОС, которая на машине установлена, тут уже не ответишь в стиле «подцепил диск клиента — и ответил, что я ваши данные вижу, так что настройте ОС как надо».

В общем, возможность иметь кнопку «пустить на сервер специалистов ТП», которая бы видимым и понятным образом разрешала конкретным учеткам зайти на машину и что-то сделать — она не лишняя. При этом таким учеткам надо иметь возможность сменить пароль/ключ, и надо иметь возможность их включать.

Как вариант — ключ ТП в файлике, но приведенный в негодность. Если совсем задница, и надо звать ТП — приводим ключ в рабочее состояние (rescue как раз выручит), и тогда уже ТП подключаются. Остается решить проблему массовой замены этих ключей, если ключ скомпрометирован — и уже хоть какое-то решение у нас есть.
+2
+3 –1
silention ,   * (был изменён)
тоже не вижу проблем. Мне кажется вы драматизируете. Ключ в руте это не ахти какой бэкдор — тот кому он мешает(профессиональный админ), заметит это сразу и уберет, а для остальных такие ключи и подкладываются, потом пользователи которые взяли впс и не знают что с ним делать мучают ТП, с ключем удобно.
Поменять ключ на всех системах 2 минуты хоть for хоть puppet/ansible/chef.
0
+2 –2
shanker ,  
Если саппорт хочет облегчить себе жизнь и не желает переходить на более адекватные меры экстренного доступа (типа SolusVM ли аналоги), то пусть будет любезен:
1. Настроить доступ по ключу исходя из советов этого комментария
2. Оповестить пользователей о том, что такая штука внедрена. И уж тем более не закрывать тикет, если заводятся разговоры о вещах, которые пользователю не сообщили заранее. Не понимает о чём речь — пусть уточнит что конктерно пользователь имеет в виду. Не хватает компетенции — пусть переправляет более компетентным людям.
+1
merlin-vrn ,  
Ключ — это, пожалуй, наиболее адекватная мера экстренного достпа. Вот что вы там назвали — это как раз костыль и извращение. И к тому же, подобные извращения обычно всё равно используют ключи для выполнения функций… ну а потому что как ты ещё заберёшься в виртуалку, когда такая потребность возникла у клиента?
0
shanker ,  
Можете уточнить чем Вам не нравятся варианты типа SolusVM?
Я встречал такой вариант (не буду утверждать, что конкретно у SolusVM): через панель управления и тебе бекапы вируталки, и создание нового ключа рута (если вдруг забыл или взломали). И VNC — если виртуалка по сети недоступна. Забыл пасс на панель управления — ссылка на восстановление доступа приходит на почту. Почтовый акккаунт был на бесплатном почтовом сервисе и уже удалён — восстановление по коду СМС, на привязанный при регистрации телефон. Тем самым взаимодействие с поддержкой сведено к минимуму. Ну, а если забыл пароль и на панель управления, и на почту и телефон украли… Тогда это очень невезучий клиент, и вопросы с ним нужно решать в отдельном порядке. Правда, такому клиенту придётся ещё подтвердить, что он — это он. Если он ещё и паспорт потерял — то вряд ли любая техподдержка ему чем поможет.
0
pyrk2142 ,  
Некоторое время назад я столкнулся с куда более серьезной проблемой у хостинг-провайдеров: значительный процент (более 50%) хостеров используют панели управления, системы биллинга, которые либо сами содержат серьезные уязвимости (CSRF, XSS и т. д.), либо настроены неправильно. Еще больше хостеров подвержены менее серьезным уязвимостям. Получилось собрать достаточно много интересного материала, возможно напишу об этом статью, если это кому-то интересно.
+11
amarao ,  
Ох, как человек, работающий в хостинге — всё сложно.

Это одно из технических решений (куда более валидное, чем известный рутовый пароль, хранимый в БД панели управления). И это одно из решений проблемы, решения которой не существует — как предоставить сервис и свободу пользователю одновременно. В принципе, ключ никуда не спрятан и будет виден любому пользователю, настраивающему машину.

Рассчитывать же на приватность VDS'ки в объёме большем, чем добрые намерения поставщика не стоит. В большинстве сред виртуализации существует техническая возможность получить полный доступ к файловой системе клиента даже без остановки клиента (да, можно через loop/ro смонтировать уже смонтированный внутри виртуалки диск — не очень надёжно, зато незаметно).

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

Что касается «дурной практики» — зависит от того, как этот ключ используется. Если делать по совести — ssh-агент на access-сервере с pam-авторизацией. На практике никто заморачиваться не будет.

Для сравнения — kimisufi, например, вообще оставляет на виртуалках запущенный сервер статистики, который в т.ч. позволяет remote code execution с серверов самого kimisufi.
0
grossws ,  
Иногда такие ключи ещё используются для массовых обновлений уязвимых пакетов. Видел такое при shellshock и heartbleed: зашел робот, обновил, перезапустил nginx/apache.
+6
Xelonic ,  
На самом деле это только внешне выглядит что ключ один на всех, однако это совсем не так и в компании работают не дураки.
Приватный ключ находится в одном единственном месте, на так называемом сервере досупа, ни один сотрудник компании (кроме самых ответственных лиц), не имеет к нему прямого доступа. сотрудники попадают на сервер доступа по своему ключу, соответсвенно увольнение сотрудника влечет за собой просто удаление его ключа с сервера доступа. Доступ к этому серверу ограничен только из офиса компании. Далее с помощью специальной команды сотрудник может залогинится на сервер клиента.
Кроме того на сервер доступа ведется учет кто и куда логинился, а так же сколько провел времени на сервере клиента.

Более подробно о том как все устроено можно почитать в документации от ISPsystem — http://doc.ispsystem.ru/index.php/Установка_сервера_для_доступа_поддержки

PS
Если кого-то не устраивает сам факт наличия ключа, просто удалите его, тем более если не планируете пользоваться услугами поддержки, никаких проблем это не вызовет.
0
artemirk ,   * (был изменён)
Выводы в корне все не верные. На сколько я видел эту систему. Ни один сотрудник не имеет на руках приватного ключа. Сотрудник имеет доступ к сервису. Далее передается имя или ip сервера. И сервис пробрасывает ssh соединение до VDS.

При этом сам ключ защищен будь здоров. И получить его даже будучи сотрудником не возможно.

Права на доступ к этому сервису рулятся уже по честному кому и что дать. Кого и в какой vds пускать. Где то в ispsystem.

upd: пока отвлекся Xelonic все уже написал.
0
medved6216 ,   * (был изменён)
Один из вариантов решения — удаление файла /root/.ssh/authorized_keys

Только не делайте так, если вы используете свой ключ для входа. Можно просто удалить или закомментить ключ тех.поддержки — "#" перед ключом.
nano /root/.ssh/authorized_keys

На всякий случай отключил их ключ ;) При обращении в ТП, при надобности включу.
+3
+4 –1
artemirk ,  
Отключить это можно прямо в панели ISPmanager у вас на VDS.

image
0
WST ,   * (был изменён)
Не все её ставят, многие предпочитают содержать сервер в чистоте от таких штук.
Тогда проще убрать бэкдор, удалив нужную строку руками.
Но всё равно не очень хорошо, что хостер оставляет такой бэкдор, нигде об этом открыто не заявляя.
0
wholeman ,  
А если эту галочку снять, повторно включить уже не получится — доступа-то к /root/.ssh не будет?
–1
dmiceman ,  
У OVH точно такая же ерунда. Причем, там ключ у рута появляется при установке из их образа на дедике. Качественный обход проблемы прост — ставить дедик из своего образа, подключившись по IPMI.