На Хабре уже есть несколько статей, касающихся безопасности различных устройств из сферы так называемых «Вещей-интернета»: домашние роутеры, «умные» телевизоры, NAS-устройства и т.д.
Данная статья поведает об особенностях NAS модели ReadyNAS. Статья о том, как мне удалось выгнать чужака из NAS-устройства, который там очень неплохо закрепился. Забегая вперёд скажу, что собранной информации было недостаточно, чтоб утверждать кто был этим чужаком: взломщик с человеческим лицом и корыстью или бесчувственный вирус. Поэтому в названии данной статьи фигурирует обезличенное слово «нечисть».
В один прекрасный день мой товарищ позвонил мне и попросил: «посмотри что не так с этой железякой? ну, я на ней фильмы храню… ну, ты понял о чём я!» И далее следовали описания симптомов. Был обычный рабочий вечер, и голова уже соображала не супер. Конечно, из телефонного разговора я толком ничего не понял. Но решил не производить допросов по телефону и приехать на место происшествия, лично посмотреть что и как. Я попросил отключить устройство от интернета до моего приезда.
Приехав к нему домой, я так и не понял что за симптомы он мне описывал. Но на всякий случай решил глянуть железку. Это оказался ReadyNAS. На вид устройство работало вполне нормально, особых тормозов или неадекватного поведения замечено не было. Неопознанных пользователей в списке на устройстве не обнаружено. После чего я решил всё же поглядеть логи. Так, для очистки совести. Поводов для беспокойства у меня пока не было. Так что моя мотивация была скорее в том, чтоб успокоить моего товарища. Мол, я провозился с железкой, в логах всё хорошо, тормозов не вижу, ложная тревога. Уходить сразу, не изобразив даже попытку реально разобраться было некрасиво. Но логи оказались не столь успокаивающими. И я понял, что вечер выдастся с борьбой.
И что же логи?
В логах обнаружилась строчка «Enabled root SSH access»
Поиск в гугле выдал страничку с описанием утилиты. Судя по описанию, утилита предназначалась для предоставления root доступа к устройству через SSH. Причём пароль на root должен быть такой же, как на пользователя admin. Пользователь admin использовался нами для доступа к устройству через веб-интерфейс. Товарищ клялся, что он не ставил этот плагин.
Сделаю небольшое отступление. ReadyNAS устройства делятся на те, где установлена ОС ReadyOS и RAIDiator.
В случае ReadyOS включённый SSH-сервер можно увидеть среди прочих служб через веб-интерфейс
А вот у RAIDiator SSH-сервер доступен после установки плагина enable root. Причём после этой процедуры ни в списках плагинов нет самого enable root, ни в списке сервисов не появляется информации о включённом SSH-сервере:
Т.о. на системах под управлением RAIDiator выявить, что в устройстве непрошеный гость несколько проблемнее.
Выполнив банальное telnet 192.168.0.1 22 я убедился, что SSH-сервер действительно работает. Но вот авторизоваться под root не удалось — предполагаемый пароль от admin не подходил. Авторизация от admin приводила к сбросу сессии. Как выяснилось далее, кроме пользователя root у остальных в устройстве в /etc/passwd было прописано /bin/false
Можно предположить, что злоумышленник поменял пароль. Я подумал: «Отлично! У негодника нет физического доступа к устройству, но зато есть есть root доступ. А у меня есть физический доступ… но вот толку? Ведь нет root доступа. И как же решать проблему?» Первое, что приходит на ум — сброс устройства к заводским настройкам. Но я меньше всего хотел это делать: надо было куда-то слить терабайты фильмов. Процедура небыстрая. А приезжать второй раз мне не очень хотелось. И я начал искать альтернативные варианты.
Решение
Дальнейшее описание решения занимает совсем мало текста, но это заняло много времени и нервов. Первое, что я попробовал — залить на устройство этот плагин enable root в надежде, что это приведёт к сбросу пароля рута. Надеялся, что плагин просто перезаписывает /etc/shadow для root с дефолтным паролем. Плагин успешно залился, устройство перезагрузилось. Но вот проблемы это не решило.
Следующим шагом я решил попробовать обновить прошивку устройства, если она не последней версии. Вдруг это перезапишет системные файлы и проблема чудным образом решится?
Прошивка оказалась не последней версии, было доступно обновление. Я нажал заветную кнопку. Система предупредила, что процедура займёт время и мне будет сообщен результат по окончании. Однако, результат выдался отрицательный: несовпадение контрольных сумм. Я начал чувствовать, что вряд ли смогу рано лечь спать… А даже если и смогу -то меня во сне будут мучить мысли вроде: «ну как же этого негодника выкинуть из системы?» И о хорошем сне можно забыть в любом случае. Голова уже совсем отказывалась работать, и я не нашёл ничего лучше, чем просто тыкать кнопку «Update», в надежде, что устройство перестанет капризничать и обновится… Верил ли я, что это закончится хорошо? Вряд ли. Я уже не знал что делать, от былого боевого духа оставалось не так уж и много. Но каким-то чудом система раза с 5-ого действительно обновилась и пошла на перезагрузку. Это было настоящим чудом! После чего мы успешно залогинились в систему от рута с паролем от админа.
Попав на устройство я пробежался по файловой системе и логам, в надежде найти следы присуствия чужака. Но их обнаружить не смог: команда last показала информацию только о моём собственном визите. Файл с историей команд (.bash_history) вообще отсутствовал. А в файле /var/log/auth.log также была информация только о моём визите. Т.о. не удалось выяснить когда произошла компрометация устройства, с какого IP-адреса и какие команды выполнялись. Единственной уликой было дата и время первоначальной установки плагина enable SSH root в логах веб интерфейса. Да, можно говорить о том, что в устройстве остался какой-то незамеченный код, который работает с привилегиями рута. Но принимать решение о переустановки системы — не мне, а моему товарищу. А он пока решил этим не заниматься. К тому же, как выяснилось после допроса с пристрастием, товарища напрягала именно перезагрузка устройства во время просмотра фильма. Что необходимо было сделать атакующему для активации плагина enable SSH root. Время внезапной перезагрузки совпадало со временем, найденным в логах веб интерфейса относительно установки enable SSH root. Значит, возможно, мы действительно оперативно отреагировали и злоумышленник не успел ничего натворить.
Заключение
Многим своим друзьям и знакомым я советую не выдавать «белые» IP своим устройствам из «интернета вещей». Можно «забить» (или не желать) менять заводские пароли на устройстве. Но спрятавши их от общедоступности через интернет, можно избавить себя от таких вот неприятных историй. Тогда как смена заводского пароля не факт, что решит проблемы. Я говорю им: «ставьте их за маршрутизатором. Тем паче, что не придётся платить за ещё один статический адрес. Нужен доступ удалённо? Настройте проброс порта маршрутизатор правильно. По технологии port knoking (статья раз, статья два)» Замучившись объяснять подробно как это делать, написал статью Пример безопасной настройки домашней локальной сети. Надеюсь, кому-то из читателей тоже будет полезно
А те немногочисленные товарищи, для которых проблемно настраивать по статье в виду малых знаний в сфере сетевых технологий… Я просто прошу их раскошелиться на роутер Mikrotik и приезжаю с заранее подготовленными настройками, в которых мне остаётся поменять только настройки для интерфейса, куда втыкается кабель от провайдера
UPD: Mikrotik может быть полезен и в плане анализа проходящего трафика от изучаемого устройства в сеть. Mikrotik позволяет перехватывать и анализировать трафик очень удобно: в конфиге задаётся адрес компа, где будет анализироваться лог, правило сбора трафика. Далее на компе запускаем Wikeshark, настраиваем его и в режиме реального времени видим трафик. Более подробно об этом тут. Т.е. трафик можно анализировать не отрывая попы от своего стула, нет необходимости собирать тестовые сети.
Хотя, на самом устройстве можно было бы попробовать посниферить трафик через tcpdump (если он там есть, надо будет глянуть).
Автор: shanker
