Предисловие

Давным-давно в начале 2000-х многие развлекались тем, что регулярно «сканировали» сети своего провайдера, а иногда и более далекие цели на предмет обнаружения Windows машин и ресурсов на них (SMB), доступных на чтение (запись). Процесс поиска был примитивен: задавался диапазон IP-адресов или маска сети и посредством различных инструментов — LANguard Network Scanner, xIntruder и подобных — сканировались адреса и находились сервера. Зачастую на обнаруженных машинах оказывались доступными на чтение, реже на запись, различные сетевые ресурсы (диски, принтеры, директории). Через анонимную сессию посредством IPC$ и пользователя «Guest» удавалось перечислять ресурсы на машине, иногда находились члены «Administrators» без паролей, а иногда, после более «активного» воздействия в отношении обнаруженных машин, удавалось найти сервера с ОС Windows NT 4.0 или Windows 2000 Server. Если удача соблаговолила обнаружить машины с распространенной тогда Windows 98, то становилось проще — в те времена в указанной ОС содержалось множество разных уязвимостей, в том числе в реализации работы с SMB, брутфорс для получения доступа к ресурсу осуществлялся за считанные минуты даже на dial-up соединениях. Для желающих окунуться в старину здесь подробно написано про «доступ» к Windows 9x — Hacking Exposed: Network Security Secrets & Solutions. Chapter 4: Hacking Windows 95/98 and Me. Но далее в статье речь не об этом.

Никогда бы не подумал, что в 2019 году возможно подобное «развлечение». Подобие же заключается в легкости поиска чужих доступных ресурсов для всех любопытствующих. Далее речь пойдет не о популярном в последние 2 года тренде — поиске открытых для доступа баз данных MongoDB или Elasticsearch — а о несколько более приземленном сервисе.

Далее весь порядок действий, их этическую норму предлагаю не оценивать, отмечаю, что настоящий пост не призыв к действиям, которые возможно отнести к некоторым статьям Уголовного кодекса РФ или подобным нормам из законодательств других государств.

Network File System (NFS)

Network File System (NFS) — протокол сетевого доступа к файловым системам, позволяет подключать (монтировать) удалённые файловые системы через сеть, обеспечивает пользователям доступ к файлам, позволяет работать с этими файлами точно так же, как и с локальными.

Большинство представленных на рынке Network-attached storage (NAS), конечно же, поддерживают NFS, и предоставляют доступ к локальным ресурсам равно как и на любом сервере с операционной системой, в которой возможно развернуть службу NFS.

Настройки доступа к ресурсам сервера с какой-нибудь ОС Ubuntu и IP-адресом 192.168.1.1 содержатся в файле /etc/exports и представляют собой записи вида:

• /data/place1 192.168.1.0/255.255.255.0(rw,no_subtree_check,nohide,async) 192.168.101.0/255.255.255.0(rw,no_subtree_check,nohide,async)
• data/place2 192.168.1.0/255.255.255.0(rw,no_subtree_check,nohide,async) 192.168.101.0/255.255.255.0(rw,no_subtree_check,nohide,async)

В данном случае доступ по NFS к серверу и его ресурсу /data/place1 возможен для клиентов с IP-адресами из сетей 192.168.1.0/255.255.255.0, 192.168.101.0/255.255.255.0.

Смонтировать удаленный ресурс в локальную директорию, например, /home/user/example, если клиент в разрешенной подсети, и установлен клиент для NFS, возможно через команду(Ubuntu):
mount -t nfs 192.168.1.1:/data/place1 /home/user/example

В случае, если вместо IP-адресов указано * или (everyone) — то, зачастую, любой клиент может смонтировать удаленный ресурс себе в систему.

Пользователю (например, под Ubuntu) достаточно набрать в терминале: showmount -e ip-target и получить информацию о доступных ресурсах на сервере (server's export list).

Например:
showmount -e 81.24.ХХХ.ХХХ
Export list for 81.24.ХХХ.ХХХ:
/home/admin 192.168.52.1/24

Таким образом формируется следующий сценарий: детектировать сервера с работающей службой NFS, определить доступные ресурсы на серверах, консолидировать результат в единую форму вывода, и дальше действовать по ситуации.

Что может быть на ресурсах — очевидно, что угодно:

• личные файлы пользователей Интернет, например, в случаях «открытых» NAS устройств;
• директории с файлами целых предприятий, баз данных, архивы баз данных;
• часто директории с адресами /home/* (иногда с ключами в .ssh и доступные на запись);
• директории с файлами систем видеонаблюдения;
• прочее...

Получение IP-адресов

В отношении обнаружения серверов со службой NFS в глобальном Интернете возможны 2 способа: самостоятельно, используя различные инструменты, и готовые сторонние результаты сканирования, базы данных и сервисы. Фактически всё сводится к получению списка IP-адресов. В локальной сети, полагаю, вариант очевиден — действовать самостоятельно.

Свидетельством функционирования сервиса NFS могут выступать открытые TCP-порты 111, 2049.
Для самостоятельного получения списка IP-адресов серверов достаточно просканировать диапазон адресов или целиком подсети на наличие указанных открытых портов. Для этого подойдет любой инструмент: nmap, masscan и так далее.

Например, командой masscan -p111,2049 200.26.1XX.0/24 —rate=10000 будет за несколько секунд сканирована сеть 200.26.1XX.0/24 на предмет открытых портов 111, 2049:
Scanning 256 hosts [2 ports/host]
Discovered open port 2049/tcp on 200.26.1XX.28
Discovered open port 111/tcp on 200.26.1XX.15
Discovered open port 111/tcp on 200.26.1XX.20
Discovered open port 111/tcp on 200.26.1XX.28
Дальше к каждому из обнаруженных IP-адресов возможно применить команду:
showmount --no-headers -e 200.26.1XX.28
Результат:
/usr/common *
Очевидно, что самому сканировать миллионы IP-адресов пространства Интернет возможно, но это не самый быстрый путь и тогда решением подзадачи может выступить замечательный сервис Shodan, есть конечно и другие, но этот с очень удобным синтаксисом и API. Углубляться в описание возможностей сервиса не является целью статьи. Кратко — сервис предоставляет расширенный поиск по устройствам, подключенным к сети Интернет. Критериями поиска могут выступать сетевые идентификаторы и другие метаданные: серийные номера сертификатов и тому подобное. В Shodan много возможностей целевого поиска, но отдельного поиска по NFS я не нашел, как, например, есть по критерию product с указанием названия продукта: mongodb, elastic или apache. Поэтому через Web NFS возможно искать по следующим запросам: nfs, tcp 2049, tcp 111, Portmap:2049 и так далее, как угодно.

Или установить клиент Shodan(CLI), инициализировать свой API KEY к сервису и из командной строки вызвать поиск, например:

1. shodan search --fields ip_str,port Portmap:2049
2. shodan search --fields ip_str,port --separator, nfs
   Результат:
   139.196.154.23,111,
   198.27.116.37,111,
   95.211.192.96,111,
   80.23.66.122,111,
   210.116.82.97,111,
   192.198.82.3,111,
   165.227.67.242,111,
   116.12.48.9,111,
   85.34.250.102,111,
   182.75.249.197,111,
   192.151.212.175,111,
   119.216.107.127,111,
   217.59.68.2,111,
   178.159.12.97,111,
   ...

Итак, как получить списки IP-адресов устройств с действующей службой NFS – понятно.

Получение информации о доступных ресурсах службы NFS на конкретных серверах.

Для решения этой задачи массово есть множество путей: написать bash-скрипты, организовать хитрый pipeline из цепочки команд с вызовом showmount и другие варианты — кому что нравится.

Я же в своих изысканиях решил эту задачу на Python, причем двумя разными способами. Первый — с подключением посредством ssh к своему личному серверу на Ubuntu с NFS-клиентом и последующим вызовом на нем команды showmount с искомым пулом IP-адресов. Второй вариант решения — на чистом Python.

Предполагаю, что может возникнуть вопрос: почему так сложно, почему на Python?

Потому что, как и в предыдущей своей статье на Хабр, я буду использовать инструмент Lampyre, к которому 26 февраля опубликовали API, позволяющий писать на Python свои модули к платформе.

Я решил протестировать возможности API. Ключевой момент — в Lampyre уже есть несколько «requests» к Shodan, тем более что иметь свой API KEY от сервиса пользователю не надо. Таким образом, одним запросом можно получить списки IP-адресов с поднятым NFS сервисом, а вторым запросом, написанный мной модуль будет проверять доступные ресурсы и визуализировать результат с характеристиками ресурсов на том же графе.

Причем тут Корея

В ходе поиска из Shodan и тестирования модуля стало интересно посмотреть обстановку с качеством и количеством результатов сканирования сервисом Shodan стран Азии, как обстоят дела с незащищенными ресурсами. Выбор пал на Республику Корея, думаю нет нужды говорить о том, что Южная Корея очень технологически развитая страна, и я предположил, что в ее сетях можно найти что-нибудь интересное.

Поиск по Shodan, в Query: nfs, в Country: код Республики Kорея, kr

Результат не заставил себя долго ждать (на изображении ниже только часть общей схемы).

Список хостов:

• psi.kaist.ac.kr
• hulk.kaist.ac.kr
• messi.kaist.ac.kr
• marvel.kaist.ac.kr
• kaist.ac.kr
• ai1.kaist.ac.kr
• jarvis3.kaist.ac.kr
• baraddur.kaist.ac.kr
• rho.kaist.ac.kr
• jarvis.kaist.ac.kr

Все они, как это видно и на графе, и по названиям — числятся за AS1781 — Korea Advanced Institute of Science and Technology

Корейский институт передовых технологий — ведущий учебный и исследовательский университет Южной Кореи, расположенный в Тэджоне, находится на второй строчке национального рейтинга в Южной Корее. Университет стабильно входит в 5% топовых учебных заведений Южной Кореи.

Указанные IP-адреса используем как входные аргументы к написанному модулю «Explore: NFS(SSH)» и в результате:

Я быстро составил такую схему отображения результатов таблицы в граф (о схемах и принципах построения графов дальше по тексту статьи).

Результат объединения со схемой Shodan

При анализе вершин и связей графа становится очевидно на каких адресах расположен ресурс /home, доступный всем (*).

Для лучшего визуального восприятия изменим свойства объектов графа и другие настройки схемы:

Конечно же, я по очереди смонтировал часть ресурсов на один из своих серверов и стал изучать. Везде оказывалось почти одно и тоже — директории пользователей: asm, hoo, hyshin, jay, jiwon, jkhee110, jokangjin, kmh603, ksm782, lee, linus, lost+found, marvel_guest, pie, qwe, scloud, seokmin, sgim, thrlek, yoosj, ysha, zinnia7.

Почти все директории с файлами были доступны на чтение и запись. У некоторых пользователей в .ssh были доступны файлы authorized_keys с возможностью записи в них.

Я сгенерировал свой ключ, скопировал его в authorized_keys одного из пользователей и подключился к серверу по ssh на порт 2222, номер порта получил из данных от Shodan.

Пользователи, настройки сети:

Хосты в сети:

Файл /etc/exports и диски:

Файл /etc/fstab и OS:

Полагаю, что это сеть какой-то кафедры для аспирантов или студентов, а на серверах производят какие-то свои вычисления, потому как там много различных исходников на Python, что-то связанное с GPU и дистрибутив Anaconda, тому прочее. Я не стал всё изучать и стал думать, что с этим всем делать, понятно, я мог «ходить» по большей части нод(может быть придумать что-нить более экзотическое), но интереса особенного у меня это не вызывало. И надумал я следующее: раз институт научный и передовой, должны быть направления по информационной безопасности. Действительно, даже целая лаборатория: Software Security Lab и ее руководитель Sang Kil Cha
Ему я и решил написать письмо, так мол и так, дозволять всем в Интернет подключать ресурсы NFS с правами чтения и записи очень опасно, видимо вам надо что-то исправить, прикрепил скриншоты и отправил.

Вскоре мне ответили, вольный перевод: спасибо, перешлём кому положено.

Перед публикацией настоящей статьи я решил проверить, посмотреть что изменилось:

Действительно, доступ к ресурсам разрешили только от машин во внутренней сети, но как быть с сервером 143.248.247.251. Согласно записям в таблице к ресурсам хоста в настройках NFS так и осталось *. Я набросал еще один вариант «мэпинга» таблицы в граф:

В чем изменения «мэпинга»: объекты NFS теперь «склеиваются» при 2 одинаковых атрибутах — IP и NFS path. Объект Status создается лишь тогда, когда в атрибуте Value, в который попадает содержимое колонки raw record, содержится значение "*"
И граф по таблице предстает в новом виде:

Теперь, кстати, стала отчетлива видна адресация внутренней сети, причём на сервере 143.248.247.251 также возможно редактирование содержания пользовательских директорий, файлов; в принципе — возможности остались те же самые, что и ранее.

И вот я пишу второе письмо мистеру Sang Kil Cha, с подобным первому содержанием, отмечая, что часть событий будут изложены в статье на популярном ресурсе habr.com:

Как использовать API Lampyre и написать свой модуль

От модуля будет требоваться принимать на вход список из IP-адресов или список из подсетей в виде 192.168.0/24 — на данном этапе, необходимо будет самостоятельно в коде осуществлять валидацию корректности входных данных на причастность строк к IP-адресам, в случае подсети — преобразовать в список IP.

Следующим шагом, посредством библиотеки Python paramiko будет осуществляться обращение к личному ssh серверу и последовательный (попытка асинхронности в коде концепта модуля присутствует) вызов команды:
timeout {timeouts} showmount --no-headers -e {ip}
Вывод результата будет разбираться посредством кода на Python в выводную структуру, таблицу: список из словарей в Python.
Ключи в словаре:

• current_day – дата запроса пользователя
• host_query — IP, в отношении которого получаем информацию
• shared_path — ресурс NFS
• status_ip — информация о возможностях доступа к ресурсу, если перечисляются IP-адреса через «,», то строка-словарь дублируется в рамках списка.

Далее, по замыслу концепта, осуществляется примитивная попытка разобрать значение ключа status_ip на предмет: IP-адрес, запись хоста, значения «*» или «everyone»

Согласно документации к API и пояснениях от support Lampyre.io — каждый модуль должен возвращать данные в таблицу, одну или несколько, но таблица должна быть описана в рамках API (Task headers, table header). Фактически — это основной результат работы модуля.
Таким образом, конечный результат с учетом ключей словаря будет таблицей:

class NFSHeader(metaclass=Header):
    display_name = 'Search data from NFS services'

    current_day = Field('Date', ValueType.Datetime)
    host_query = Field('Search ip', ValueType.String)
    shared_path = Field('NFS path', ValueType.String)
    ip = Field('ip address', ValueType.String)
    network = Field('network address', ValueType.String)
    host = Field('host', ValueType.String)
    status = Field('raw record', ValueType.String)

В таблицу будут записываться значения (несколько модифицированные) от разбора результата исполнения команды showmount на сервере. Названия полей класса говорят сами за себя, в колонке raw record будет храниться информация о возможностях доступа к ресурсу. Такой разбор данных о ресурсах NFS можно в некотором смысле считать и OSINT-ом, информация о возможном доступе с различных IP-адресов дает какое-то представление о собственниках ресурса или адресации внутри сети ресурса. Например, IP-адрес сервера со службой NFS расположен в Украине, а IP-адрес, разрешенный на доступ — в Германии:

А если расширить изучение данного примера, то тут же находится подтверждение связи серверов не только через NFS, но и через один сертификат на адресах: 77.120.103.9, 138.201.202.135 и домен *.aniart.com.ua:

Как передавать данные в модуль и писать в таблицу:
создается собственный класс SearchDataNFS от класса Task:

class SearchDataNFS(Task)

В методе get_id возвращаем уникальный рандомный UUID:

def get_id(self):
    return 'bf51fd57-3fec-4416-9d07-905935a484b4'

В методе get_display_name указываем как будет называться Task, а в методе get_description, соответственно названию, описание Task:

def get_display_name(self):
    return 'Explore: NFS(SSH)'

def get_description(self):
    return 'Explore NFS resourses'

В методе get_headers указываем какие таблицы будем использовать:

def get_headers(self):
    return NFSHeader

Метод get_enter_params будет определять вид окна ввода входных данных. Из кода очевидно, что на вход подается список строк, который позже самостоятельно будет преобразован в IP-адреса:

def get_enter_params(self):
    ep_coll = EnterParamCollection()
    ep_coll.add_enter_param('ips', 'IP', ValueType.String, is_array=True, 
                            value_sources=[Attributes.System.IPAddress], 
                            description='IPs, networks')
    return ep_coll

В методе execute происходит основное исполнение задачи:

ips = []
for input_ip in set(map(lambda z: z.strip(), enter_params.ips)):
    ips.extend(reparse_ip_hosts(input_ip))

К входным параметрам осуществляется обращение через enter_params.ips. В методе reparse_ip_hosts — происходит самостоятельно реализованная валидация строк в IP-адреса.

targets = ((ip, port) for ip in ips for port in ports)
lines = thread_async_nfs_one_client(targets)
info = reparse_result_rows(lines)
fields_table = NFSHeader.get_fields()
for data_id in info:
    tmp = NFSHeader.create_empty()
    for field in fields_table:
        if field in data_id:
            tmp[fields_table[field]] = data_id[field]
            result_writer.write_line(tmp, header_class=NFSHeader)

В функции thread_async_nfs_one_client происходит подключение к серверу с ssh (IP-адрес, логин и пароль заданы hardcode) и исполняется showmount, так как ранее указывал, результат разбирается, потом в функции reparse_result_rows он еще раз модифицируется. Важно отметить, info — список, состоящий из словарей, в каждом словаре ключи названы как поля класса NFSHeader. То есть словарь выглядит так:

{
    'current_day': datetime.datetime(2019, 3, 6, 16, 48, 17), 
    'host_query': '192.168.1.1',
    'shared_path': '/volume1/workspace',
    'ip': '192.168.10.10',
    'network': '',
    'host': '',
    'status': '192.168.10.10'
}

Важно соблюдать типы данных в словаре, они должны быть такими же, как в описании таблицы.
Далее в цикле происходит итерация по элементам списка и их запись через метод API (result_writer.write_line) в конкретную таблицу NFSHeader.
Для более подробного описания необходимо ознакомиться с документацией.
В принципе, модуль уже готов для добавления в Lampyre.

Использование своего модуля в Lampyre

В связи с тем, что используется ssh и исполнение команды showmount, конечно же, необходимо иметь доступ к своему серверу по ssh. У меня для тестов такую роль выполняла виртуальная машина в Virtualbox c Ubuntu и установленным на ней NFS-клиентом.

Для работы с собственными модулями на машине пользователя необходим Python 3.6, путь к интерпретатору должен быть в системных переменных, либо указан путь до него в файле Lampyre\config\appSettings.config. По умолчанию ключ pythonPath в настройках закомментирован.

Загрузка модуля в Lampyre осуществляется следующими шагами:

1. В окне Scripts загрузить файл Lampyre\user_tasks\ontology.py (поставляется с приложением)
2. В том же окне загрузить свой модуль, в данном случае nfs_via_ssh.py. Если что-то пошло не так, то должна помочь кнопка Details
3. После загрузки в окне List of requests на вкладке Tasks появится раздел Local tasks (в коде модуля можно было назвать иначе), в нем название Explore:NFS(SSH):
   
   
   Обновленное окно List of requests:
   
   
4. IP-адреса серверов с NFS, как я говорил ранее, лучше получить предварительно исполнив запрос Shodan search с параметрами Query: tcp 2049 (можно и просто указать nfs). Параметр Page or range, установленный по умолчанию в 1, означает, что вернется 1 страница ответов от сервиса Shodan, на 1 странице обычно 100 результатов(строк).
   Результат исполнения Shodan:
   
   
5. Скопировать в буфер обмена IP-адреса из таблицы или со схемы и вставить его в окно модуля IP Explore:NFS(SSH). Запустить и ожидать результата:
   
   

Конечно необходимо учитывать и пропускную способность от своего и чужого серверов, и timeout, заданные жестко в коде модуля.

Результат получен в виде таблицы, но можно продолжить и совместить результат таблицы с графом результатов от исполнения Shodan search. Это будет несколько сложно для восприятия сначала.

Визуализация таблицы с результатом

Приступим. Есть таблица с набором колонок со значениями от исполнения модуля пользователя. Но если обратить внимание на кнопку Sсhema окна Requests – она неактивна. Потому как не задано отображение таблицы в граф и его необходимо задать.

Схема 1 (не самая лучшая)
При открытой таблице от результата модуля внизу в правом углу есть элемент интерфейса «Add creation template», нажав на который появляется окно «Creation template». В нём-то и можно задавать отображение строк таблицы в объекты графа, подробно описывать процесс в рамках статьи не буду, по ссылке на канале платформы в Youtube показано как такое осуществить, в рамках статьи я ограничусь изображениями того что должно получиться:

Шаблон для графа:

Важно отметить, объекты IP, Domain — имеются в Lampyre, а объекты NFS и Network – я создал. У каждого объекта есть атрибуты, в которые пользователь «мэпит» колонки таблицы. Причем, у объекта может быть несколько атрибутов, часть из которых — по которым вершины должны «склеиться» на графе — ключевые, другие — для вывода названия вершин-объектов графа, это могут одни и те же атрибуты или совсем другие. Например, для объекта NFS – созданы 2 атрибута, NFS path и Status, ключевой атрибут — NFS path. Объекту можно назначить свою иконку — кликнув на изображение объекта справа. По завершении «мэпинга» колонок в атрибуты объектов можно строить схему — упомянутая выше кнопка Schema станет активной.
Шаблон отсутствует:

Шаблон для графа по таблице составлен:

В целом такой подход к «мэпингу» значений из колонок и строк таблицы в объекты графа существует и в другом приложении — i2 (IBM i2 Analyst's Notebook):

После визуализации графа от такого «мэпинга» становится понятно, что это не лучший вариант: видно отношение IP-адреса сервера к IP-адресам и хостам, с которых возможны доступы, и имеющиеся ресурсы NFS на сервере, но ведь к разным ресурсам возможны доступы с разных IP. Поэтому создаём другую схему (для любой таблицы можно создать множество схем).

Схема 2

Уже лучше. Всё становится на свои места — на каком сервере есть ресурсы, и с каких IP-адресов к ним возможен доступ:

Такой вариант создания шаблона схемы графа по таблице удобен лишь тогда, когда не так часто приходится работать с собственным модулем, или в случае импорта текстовых файлов (csv) в приложение. Дело в том, что созданный подобным образом «мэпинг» сохраняется лишь в рамках текущего расследования. После создания нового «расследования» модуль будет сохранен и будет исполнятся с результирующей таблицей, но схема не сохранится и её придется строить заново.

Для объединения результатов от поиска по Shodan и NFS необходимо открыть схему Shodan search, активировать кнопку add to active tab и нанести на ту же вкладку результат нашего модуля — схемы объединятся:

Объединенные схемы:

Код модулей для Lampyre доступен, там же вторая версия модуля без использования подключения по ssh.

Вместо заключения — коллеги, регулярно проверяйте корректность настроек своих NFS и не только.