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

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

| сохранено

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

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



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



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

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

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

Один из вариантов решения — удаление файла /root/.ssh/authorized_keys

UPD
Привожу справиедливые слова SilverFire из комментариев относительно того чем плохи такие ключи:

Само наличие ключа — не проблема. Проблема в том, что он один на всех суппортов и не ограничен по IP. Что в этом плохого:

  1. раз нет ограничения по IP, нет и единого access-сервера, откуда суппорты имеют право ходить на клиентские сервера, причем желательно по локальным management IP адресам;
  2. невозможно быстро лишить сотрудника прав доступа. Придется обходить все сервера и менять публичный ключ, плюс раздавать всем действующим сорудникам новый приватный ключ;
  3. все сотрудники ходят под одним ключом и логинятся рутом. Если кто-то налажал и не признается — почти нереально выяснить, кто именно это был;
  4. сотрудники имеют на руках приватный ключ и могут случайно (или неслучайно) его скомпрометировать. Так как нет ограничения по IP, кто угодно может им воспользоваться и, снова таки, будет непонятно кто из сотрудников стал виновником.
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.