Lotus domino console настройка

Обновлено: 04.02.2025

Привет всем читателям. На этот раз я немного уйду в сторону от Oracle и расскажу про другое, не менее распространенное в корпоративной среде приложение – Lotus Domino. Domino – это такое огромное клиент-серверное приложение, совмещающее в себе и почтовую систему, и систему документооборота, и LDAP-хранилище, и еще множество всего, где может храниться полезная информация. Данная система может хранить огромное количество критичных данных, и сперва мы рассмотрим способы получения административного доступа в эту систему, а потом – варианты распространения своих привилегий на сам сервер, где установлено это приложение. Особенно важным является тот факт, что система довольно часто имеет внешние интерфейсы подключения доступные из интернета, что позволяет, используя представленные в статье методики, получить полный доступ к внутренним серверам компании через уязвимости системы Lotus Domino. Интересно? Тогда поехали!

Описание

Где обитают лотусы?

Nmap –sV 172.212.13.0.24 –p 80

На самом деле гораздо эффективнее будет воспользоваться методикой Google Hack и найти множество Lotus-серверов в интернете, используя простейший запрос inurl:homepage.nsf. В результате этого запроса нам откроются ссылки на тысячи потенциальных серверов Lotus. Сразу предупрежу тебя, чтоб ты даже не пытался тренироваться на этих серверах, так как у Лотуса очень навороченная и удобная система протоколирования всех запросов, и вычислить злоумышленника не составит труда.

Осмотр пациента

Итак, начнем анализ подопытного. Обычно при попытке обращения к корневой директории Lotus-сервера мы получаем окошко с запросом аутентификации, что сразу же отпугивает неопытных хакеров. Очень вероятно, что администратор установил запрос аутентификации только на обращение к корневой папке, а все остальные ресурсы остались открыты. Что же там за ресурсы могут быть, и чем они нам полезны?

Загадочный .nsf

Если кратко, то Lotus хранит всю информацию в контейнерах собственного формата с расширением nsf. Данный контейнер представляет собой набор данных и формат их представления. Если говорить проще, то каждый nsf ресурс – это небольшой отдельный сайт со своей базой данных. Собственно, этих самых nsf-файлов может быть на сервере огромное количество, причем как стандартных, так и разработанных специально под нужды компании. Вот список наиболее популярных nsf-файлов, которые могут присутствовать:

/names.nsf
/admin4.nsf
/admin.nsf
/alog.nsf
/domlog.nsf
/catalog.nsf
/certlog.nsf
/dba4.nsf
/homepage.nsf
/log.nsf

Про остальные файлы ты можешь узнать, скачав, к примеру, утилиту dominohunter, к которой прилагается список стандартных nsf-файлов. Ко всем этим файлам есть описания, и во многих из них есть интересные нам данные, но начнем мы с самого главного файла – names.nsf. Данный ресурс представляет собой полную базу данных по сотрудникам, их почтовым адресам и по множеству другой полезнейшей информации, такой как: версии ОС пользователей, версии программного обеспечения Lotus Notes и прочие данные. А знаешь, что самое интересное? Этот ресурс на большинстве серверов доступен анонимному пользователю!

Векторов дальнейшей атаки на самом деле огромное множество, учитывая то, что у нас есть такая интересная информация. Вот лишь часть из них.

Повышение привилегий

Итак, как я уже говорил, хэши в Lotus бывают двух видов:

1. Обычные (32 символа в HEX) пример:

2. C использованием случайных значений (22 символа начинающиеся с G) пример:

Для расшифровки обычных хэшей необходимо на вход программе JohnTheRipper подать файл HASH.txt вида:

Имя пользователя:хэш
Имя пользователя:хэш
.
.
Имя пользователя:хэш

Запускать переборщик необходимо со следующими параметрами:

./john HASH.txt --format=lotus5

Имя пользователя:(хэш)
Имя пользователя:(хэш)
.
.
Имя пользователя:(хэш)

Запускать переборщик необходимо со следующими параметрами:

./john HASH.txt --format=dominosec

Вот, собственно, и все, напоследок могу только порекомендовать набрать разных словарей и запустить перебор параллельно брутом и словарями для большей эффективности. В случае успеха, что встречается довольно часто, так как парольные политики в Domino по умолчанию отключены, мы получим список расшифрованных паролей пользователей системы Lotus Domino на Web-доступ. Пусть там будут и не все пользователи, но все же шансы, что из тысячи хоть кто-нибудь расшифруется, достаточно велики.

Администрирование

Итак, предположим, что мы расшифровали пароль администратора (если нет, сидим и перебираем дальше :)) – это есть очень хорошо. Теперь перед нами открываются просторы доступа ко всем находящимся на сервере nsf-файлам, которых, как я уже говорил, предостаточно. Интересный ресурс – log.nsf, на нем можно найти и посмотреть все логи доступа к серверу по различным критериям и узнать, к примеру, каким браузером пользуются пользователи. Также интерес представляет catalog.nsf. Доступ к почте каждого сотрудника можно получить, обратившись к директории /mail/логинсотрудника.nsf.

Но самый большой интерес для нас представляет ресурс webadmin.nsf (servername/webadmin.nsf). Это админка Web-сервером Lotus Domino со всеми вытекающими последствиями. Имея доступ к ней, можно создавать изменять и удалять пользователей, назначать для них группы и выполнять всевозможные административные задачи. Получение административного доступа к системе Lotus Domino практически всегда означает получение доступа к ОС, если не используются расширенные настройки безопасности, такие как: пароль на консоль (иногда встречается) или ограничение прав учетной записи в ОС (на практике крайне редко). Стоит отметить, что в ОС Windows по умолчанию доступ будет получен под учетной записью Local System, так как служба запущена от имени Local System, а в Unix доступ будет получен от имени непривилегированной учетной записи.

Итак, что же предоставляет нам webadmin.nsf? В этом приложении есть различные опции по управлению сервером, в том числе и ряд оболочек для выполнения сервисных команд для репликации и прочих административных задач. Для выполнения сервисных команд можно использовать две различные консоли: Quick Console и Live Console. Но не тут-то было. Эти консоли – не то же самое, что консоль в ОС, так как набор команд там строго определен и заточен под задачи LOTUS.

Оболочка Live Console

Наиболее удобная оболочка для выполнения называется Live Console, но, к сожалению, ее использование обусловлено двумя проблемами. Первая проблема заключается в том, что данная консоль не включена по умолчанию и для ее включения необходимо перезагружать сервер, что не очень хорошо. Вторая особенность – данная оболочка работает по своему протоколу с использованием порта 2050, и с большой вероятностью в случае подключения через интернет данный порт будет зафильтрован. Таким образом, данный вариант не является универсальным, так что идем дальше.

Оболочка Quick Console

Второй вариант – это использование урезанной версии консоли – Quick Console. Данная консоль имеет неприятную особенность – результат выполнения команды не отображается, таким образом, мы можем выполнять команды только вслепую. Ладно если нам нужно просто выполнить команду, в которой мы уверены, но если нам захочется прочитать содержимое файлов – тут без трюков не обойтись. На самом деле проблема очень похожа на Blind SQL Injection, так что и методы надо применять похожие, только с учетом особенностей.

Получение данных

Давай проанализируем, что мы вообще можем делать в административном интерфейсе, чтобы понять, что из этого нам поможет для получения результатов команд. Первое, что бросается в глаза – это меню Files, где, как хотелось бы верить, мы сможем читать файлы, но и тут нас поджидает неприятная участь. Читать файлы нельзя, можно только делать листинг директорий и видеть имена файлов. И только если у них расширение .nsf.

Первая сумасшедшая идея, которая приходит в голову – это разбивать на строки вывод результата выполнения команды и создавать файлы, в названии которых будет кусок результата выполнения команды, а расширением будет .nsf. Таким хитрым и довольно извращенным способом мы будем получать информацию о результате работы команды. Для этого необходимо последовательно запустить две команды (спасибо Алексею Синцову за набросанный скрипт):

load cmd /c "dir /D /B > sh2kerr.out"
load cmd /c "FOR /F "delims= " %i IN (sh2kerr.out) DO ECHO > C:\lotus\domino\sh2kerr\"%i".nsf"

Первая команда сохраняет результат команды (в нашем примере это команда DIR) в файл sh2kerr.out. Вторая команда разбивает результат вывода первой и создает необходимые файлы. В результате в папке C:\lotus\domino\sh2kerr\ мы увидим множество файлов, в именах которых будет результат выполнения команд.

На самом деле есть способ гораздо проще, но при этом будет вероятность, что он не заработает там, где безопасно расставлены права. На практике мне такого не встречалось, так что можно использовать этот метод практически везде. Метод очень прост и заключается в следующем – необходимо найти директорию, в которую мы можем писать, и которая будет доступна через Web-интерфейс. Такая директория есть по умолчанию в версиях 6.5 и 8.5 (в других она, скорее всего, тоже присутствует, но подтвердить нет возможности). В ОС Windows данная директория в результате установки по умолчанию выглядит следующим образом:

Альтернативный сценарий выполнения команд.

Кроме трюка с Load есть еще один способ выполнения команд – через так называемый планировщик. Находится он в меню Server->Status->Schedules->Programs. Используя этот планировщик, можно также запускать любые команды в ОС.

Клиент-серверное взаимодействие

Выше мы рассматривали вопросы безопасности Web-доступа к системе Lotus Domino, но есть еще и другой протокол (NRPC на 1352 порту), по которому можно подключиться к системе. Этот протокол позволяет подключаться к Lotus Domino серверу, используя клиентские программы Lotus Designer (разработчики), Lotus Notes (простые сметные) и Lotus Administrator (спасибо, кэп). Для подключения к серверу клиент должен иметь некое подобие сертификата, в системе Lotus Domino это файл с расширением ID. Помимо этого файла для подключения необходимо иметь и пароль к нему.

Данный пароль никогда не передается по сети и используется для расшифровки ID-файла, а аутентификация уже происходит при помощи расшифрованной информации. Итак, для того, чтобы подключиться к системе с использованием клиентского приложения, нам необходимо получить 2 вещи: ID-файл и пароль к нему. Выглядит сложнее, чем в случае с Web, но не безнадежно.

Для того, чтобы получить ID-файл, можно воспользоваться уязвимостью раскрытия информации в службе Lotus Domino. Уязвимость заключается в возможности получения ID-файла пользователя, в случае, если известен его логин. Логин можно либо подобрать, либо воспользоваться уязвимостью в names.nsf, описанной выше. Второй способ получения ID-файла – попытаться откопать его в том же names.nsf. Очень часто в профиле пользователя, доступном без аутентификации через Web-интерфейс, есть ссылка на скачку его ID-файла.

STEP BY STEP HOWTO

Итак, подведем итоги и создадим небольшой гайд по получению доступа к Lotus Domino.

Для получения доступа к серверу выполняем следующие действия:

Если есть Web-доступ:

1. Запускаем утилиту raptor_dominohash и собираем хэши паролей:
./raptor_dominohash 192.168.0.202

2. Сохраняем хэши в формате, приведенном в статье;

3. Запускаем JohnTheRipper и подаем на вход список имен пользователей и хэшей:
./john HASH.txt --format=lotus5

5. В Quick Console набираем команду, добавляющую в ОС нового пользователя:
load cmd /c net user hacker iamstupid /add

6. Чтобы проверить, выполнилась ли команда, выводим список текущих пользователей и сохраняем вывод команды в файл:
load cmd /c net user > C:\Lotus\Domino\data\domino\html\download\filesets\1.txt

7. Если не получилось, пробуем выполнить команду через Program.

Если есть NRPC-доступ:

Берем список пользователей из names.nsf (или подбираем) и пытаемся получить ID;
В случае получения ID пытаемся расшифровать пароль при помощи утилит указанных в статье;
В случае успеха пытаемся подключиться при помощи Lotus Administrator, а далее начинаем с пункта 5 предыдущего варианта.

И что потом?

WARNING

Внимание! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несет!

В последнее время я часто рассказываю истории о том, как на обыкновенном пен-тесте удается выявить 0-day уязвимость в популярном ПО или разработать приватный эксплойт. На самом деле такого рода задачи решаются при пен-тесте редко и выборочно, и на это есть свои причины.

И всё же я хочу поделиться историей (ага, байкой) о том, как при решении именно таких задач пен-тест выходит за рамки монотонного сканирования, брутфорса и запихивания кавычек в параметры веб-приложения. А именно, в этом посте будет рассказано о простой баге в Lotus Domino Server Controller, о том, как был создан приватный эксплойт, а также найдена проблема нулевого дня, актуальная и на сегодняшний день.

Тест на проникновение

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

Любой пен-тестер решает множество подзадач с целью выполнения основной задачи – реализации атак на компоненты информационной системы. При этом я оставлю за скобками подробное описание и возможные вариации на тему основной задачи, так как это опять же сейчас неинтересно, а вот две-три подзадачи, что являются “state-of-art”, я выделю:

Поиск (и подтверждение) уязвимости
Разработка эксплойта
Эксплуатация уязвимости

Так случилось, что во время одного из пен-теcтов обнаружился целый набор уязвимостей без публично доступных эксплойтов, даже без PoC’ов или детальных описаний проблемы. Поэтому для одной такой уязвимости было решено узнать все самим и написать приватный эксплойт.

Обход аутентификации в Lotus Domino Server Controller

CVE-2011-0920

Данная уязвимость была найдена Патриком Карлссоном и продана с потрохами в ZDI. Так что описание с сайта ZDI — это единственная информация, что у нас есть. Краткий пересказ:

Описание хоть и не детальное, но говорит достаточно о том, что происходит. Значит, можно приконнектиться к порту под номером 2050, подсунуть по какому-то протоколу параметр COOKIEFILE, указывая путь типа \\ATTACKER_HOST\FILE. А в этом файле разместить логин и пароль и, используя эти же логин и пароль, войти в систему. Осталось совсем чуть-чуть – разобрать протокол и формат файла. По сканам Nmap можно определить, что вся работа происходит по SSL, а вот протокол общения в SSL-обертке предстоит выяснить. На самом деле это крайне просто: достаточно отметить, что сервис Lotus Domino Controller полностью написан на Java, причем как клиентская, так и серверная часть, все в одном файле:

Вот мы и встретили параметр COOKIEFILE. Однако одного его недостаточно. Рассмотрим основной цикл:

Теперь мы понимаем формат протокола, каков же формат самого файла? Рассмотрим функцию verifyAppletUserCookie:

Вот так выглядит эксплуатация уязвимости для ZDI-11-110

1. Создаем файл (cookie.xml):

2. Используем ncat

Казалось бы, и сказке конец. Более того, IBM сделала исправление для данной проблемы, и даже не одно! Вот эти новшества появились, начиная с версии 8.5.2FP3 и 8.5.3.

Исправление 1.

Теперь для соединения с портом 2050 необходим правильный клиентский сертификат. То есть Ncat и Nmap больше не работают с портом 2050.

Исправление 2.

Теперь перед именем файла добавляется “.\”, что означает, что UNC мы больше использовать не можем. Уязвимость исправлена. Патч кажется адекватным.

На самом деле это не так. Взглянем на строчки кода ещё раз (откомментированные как Point.6 и Point.7). Функция getStringToken – фактически substring. Отсюда вполне очевидный вопрос: зачем программисты при реализации этого модуля прибегли к написанию собственного XML-парсера? Очевидно, что данный парсер работает с любым файлом, в котором есть соответствующе строки: “

Но вот что можно подсунуть, и это так же благополучно распарсится:

Тут \r\n – это просто Enter!

2. Теперь лог-файл на сервере будет таким:

Отлично, почти все готово, осталось только научиться подсоединяться к 2050, ведь сертификата SSL у нас нет. Или есть? Вспомнив, что dconsole.jar ещё отвечает и за клиентскую часть, как апплет, очевидно, что там должен быть сертификат – и он там есть. И ключ там есть. Всё там есть. В принципе, можно выдернуть ключ и написать эксплойт, но если лень, то можно прямо этот апплет использовать:

Подгружаем этот апплет в любом браузере, добавляем редирект с локального порта 2050 на удалённый, и всё – эффект достигнут. Видеопример:

Выполнение команд из консоли. Вариант 1:

LOAD cmd.exe /c command

Выполнение команд из консоли. Вариант 2:

Защита:

Порт 2050 вообще-то надо фильтровать.
Запретить опасные команды в консоли с помощью установки дополнительного пароля консоли (защитит от выполнения команд из консоли в первом варианте).
Проверить файл admindata.xml. Для каждого пользователя надо проверить привилегии. Значения 4, 25 или 26 говорят о том, что у данного пользователя есть права на исполнение системных команд! Удалив их, мы защитимся от выполнения команд из консоли во втором варианте.

Примечание:

Атакующему во всех перечисленных вариантах для успешного обхода аутентификаций необходимо знать правильное значение логина. В любом случае, его можно перебрать, так как в случае несуществующего логина выдаётся ошибка NOT_REG_ADMIN, а если неверен пароль, то WRONG_PASSWORD (Point.9).

P.S. Атака из Интернет

Подсеть московского вуза:

Домен .gov, или Американские учёные не любят межсетевых экранов:

В этот раз мы решили разнообразить наш блог и внести элемент практики. Опубликованные ранее статьи касались различных технологий, теперь же пришло время рассказать, какие проекты мы реализуем. Первым станет проект по аутсорсингу IBM Lotus Domino/Notes инфраструктуры одного крупного европейского финансового холдинга с филиалами в разных частях света, который стартовал в 2010 году. Наша компания выполняла заказ на данный проект, получив в результате успешный кейс в портфолио. О том, как мы делаем свою работу, и какие знания и опыт в области аутсорсинга IBM Lotus Domino/Notes готовы применять в следующих проектах, расскажем далее.

Предпосылки к началу проекта

С продуктом Lotus Domino/Notes заказчик работал с начала 2000-х, а сопровождал его большой штат собственных администраторов и разработчиков. В течение нескольких лет после внедрения IBM Lotus Domino/Notes ИТ-службой заказчика были доработаны стандартные приложения Lotus Notes и разработаны новые, которые автоматизировали все основные бизнес-процессы, возлагаемые на Lotus. Такая идиллия продолжалась вплоть до известного всем экономического кризиса 2008 года, когда проблемы финансового характера подтолкнули менеджмент компании к необходимости оптимизировать финансовые показатели путем разгрузки своего ИТ-персонала от непрофильных и рутинных задач и концентрации их сил на главных для бизнеса процессах.

В результате, заказчик оставил за собой только задачи конфигурации в области информационной безопасности, аудит за деятельностью аутсорсера, доработку дизайна почтовых ящиков под особенности своих бизнес-процессов и отвечал за бизнес-логику приложений. Все остальное было передано на ИТ-аутсорсинг.

Первый этап. На старт. Что предстояло сделать?

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

Первый этап начался с ежедневных периодических задач, управления пользователями и группами, решения инцидентов второго уровня поддержки и предоставления сервиса в режиме 24х7. А уже через полгода после старта проекта мы стали оказывать все виды работ, оговорённых контрактом, в том числе третий уровень поддержки, включая общение с вендором.

Второй этап. Реализация проекта.

Практически сразу после получения доступа в инфраструктуру IBM Lotus Domino серверов мы обнаружили, что большинство ключевых для бизнеса кластеров из серверов Domino перегружены и работают на пределе своих возможностей. Малейший сбой на одном из членов кластера приводил к тому, что запросы пользователей автоматически перенаправлялись на другой сервер, который от этой дополнительной нагрузки скоро также становился недоступным.

Как показывает практика, при описании масштаба работ, передаваемого на аутсорсинг сервиса, заказчики склонны к приуменьшению объемов. Например, указывают только количество инцидентов, скромно забывая о запросах на обслуживание или регламентных работах. И к этому надо быть готовым. Переход в виртуальную среду был в планах заказчика, но постоянно растущие объемы информации требовали не только увеличения производительности серверов, но и изменения архитектуры существующей IBM Lotus Domino/Notes инфраструктуры при обеспечении бесперебойной работы бизнес-процессов заказчика, что и было нами сделано.

Для обеспечения высокой степени доступности, масштабируемости и балансировки нагрузки каждый филиал компании заказчика имеет один или два выделенных физических сервера, на которых располагаются почта, архивы и реплики критически важных приложений. Эти серверы объединены в кластеры с соответствующими серверами в разных дата-центрах. Таким образом, в случае локальных проблем с сервером в филиале, их Notes клиенты будет автоматически переключаться на сервер в одном из дата-центров.

Правильность концепции, заложенной в новую архитектуру, гарантирующую непрерывность предоставления сервиса, была подтверждена и регулярными DR (Disaster Recovery) тестами, проводимыми заказчиком.

В итоге после некоторого периода адаптации (отметим, что в целом все требования заказчика выполнялись поэтапно в течение 8 месяцев) количество серверных инцидентов с Domino серверами снизилось в 2,5 раза.

Третий этап. Неожиданный сюрприз.

Разобравшись с критическими серверными задачами и благополучно пережив переход на новую инфраструктуру в основных локациях, мы взялись за проактивную работу. По договору регламентные еженедельные и ежемесячные работы переходили в нашу зону ответственности в самом конце передачи нам сервиса. Это было связано с тем, что они содержали не только действия, рекомендованные IBM, но и специфические действия, направленные на поддержание работоспособности бизнес-процессов и целостности информации заказчика.

И здесь нас поджидал сюрприз. В связи с оптимизацией штатного персонала, у оставшихся админов заказчика работы стало столько, что они успевали делать только критически важные еженедельные и ежемесячные задачи. Таким образом, вся оставшаяся нагрузка легла на ~~хрупкие плечи~~ аутсорсера, то есть на нас.

Что же нам было делать с большим объемом дополнительной работы? Было решено срочно автоматизировать процессы. В кратчайшие сроки нами были написаны скрипты по дополнительному анализу логов, сравнению кластеров, квот почтовых файлов, анализу групп, предоставлению отчетности. Все это позволило за 3-4 месяца привести дела в порядок и, что самое главное, регулярное выполнение в полном объеме всех регламентных работ привело к сокращению не только количества серверных, но и нескольких видов пользовательских инцидентов.

Успеху нашей работы также способствовало наличие у заказчика зрелых бизнес-процессов администрирования и решения инцидентов, их управления и мониторинга исполнения. На первых порах специалистам приходилось тратить много времени на их изучение и понимание, но в дальнейшем мы смогли по достоинству оценить их несомненную пользу, самостоятельно создавая новые и оптимизируя старые.

Итоги проекта. Что получил заказчик?

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

предоставляли сервис качественно и в срок;
использовали средства автоматизации администрирования;
использовали сторонние программные средства мониторинга серверов Domino;
выстраивали хорошие отношения с представителями заказчика;
расставляли приоритеты задач, пути их решения и порядок взаимодействия с заказчиком, основываясь на его бизнес-процессах и миссии;
работали при максимально детализированном Service Level Agreement (соглашение об уровне предоставления услуг);
постоянно улучшали сервис, предлагая клиенту новые решения для оптимизации ИТ-процессов.

Все это позволило нашей компании значительно расширить объем предоставляемого заказчику сервиса и через пять лет работы продлить контракт.

При развертывании системы Notes/Domino необходимо определить одного или группу пользователей, которые будут ее администрировать.

Разграничение доступа к системе Notes/Domino для решения административных задач выполняется в зависимости от прав, необходимых администратору, например,

право администрирования одного или нескольких серверов Domino;
добавление и/или изменение информации о пользователях, группах и серверах;
добавление и/или изменение различных конфигурационных параметров сервера.

Средства администрирования системы Domino

В Notes/Domino 6 есть набор средств, позволяющих гибко администрировать систему.

В таблице представлены эти средства:

Использование клиента Domino Administrator

Клиент Lotus Domino Administrator является главным средством управления системой Notes/Domino.

Чтобы загрузить клиент Domino Administrator выполните следующие действия:

В системе Windows, выберите из меню Пуск > Программы > Lotus Applications (Приложения Lotus) пункт Lotus Notes.
Введите пароль и нажмите кнопку "OK".
На панели закладок выберите закладку Domino Administrator .

Чтобы загрузить клиент Domino Administrator из группы программ Lotus Applications (Приложения Lotus) выберите из меню Пуск > Программы > Lotus Applications (Приложения Lotus) пункт Lotus Domino Administrator.

Интерфейс клиента Domino Administrator

Навигация в клиенте администратора

Закладка "Пользователи и группы" (People and Groups)

Выбрав закладку "Пользователи и группы" ( People and Groups ), администраторы могут просматривать, добавлять и модифицировать:

учетные записи пользователей домена Domino;
группы домена Domino;
документы, описывающие общие почтовые базы данных ( mail-in databases ), ресурсы;
политики;
сертификаты, использующиеся для аутентификации.

Закладка "Файлы" (Files)

Выбрав закладку "Файлы" ( Files ), возможно:

просматривать информацию о файлах, расположенных на сервере Domino или локально;
добавлять, модифицировать, удалять папки или ссылки на базы данных ( database links );
выполнять сервисное обслуживание баз данных.

Закладка "Сервер" (Server)

При выборе закладки "Сервер" ( Server ), возможно:

выполнять различные действия на сервере Domino, например, загрузку сервисов;
получать информацию о производительности сервера;
осуществлять мониторинг сервера.

Закладка "Почта" (Messaging)

Выбрав закладку "Почта" ( Messaging ), возможно:

контролировать передачу электронной почты;
просматривать топологию маршрутизации почты;
генерировать отчеты.

Закладка "Репликация" (Replication)

Закладка "Репликация" ( Replication ), позволяет:

просматривать расписания репликации между серверами Domino;
просматривать события и топологию репликаций.

Закладка "Настройка" (Configuration Tab)

Выбрав закладку "Настройка" ( Configuration Tab ), администраторы могут управлять конфигурационными параметрами системы Notes/Domino, такими как, настройки маршрутизации электронной почты и репликаций, а также регистрировать учетные записи пользователей, серверов и заверителей.

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

IBM Lotus Domino Server — программное обеспечение компании IBM Lotus Software, серверная часть программного комплекса IBM Lotus Notes.

— ZDI; — IBM Lotus Software; — BugTraq; — DJ Java Decompiler.

Предыстория

Однажды я проверял надежность защиты очередного объекта. На этот раз вся инфраструктура была поднята за счет оборудования и софта IBM, что совершенно точно влетело заказчику в копеечку. Основную часть инфраструктуры, как это обычно бывает, составляли сервера Lotus. В данном случае их было много. Очень много. На Lotus была построена вся кухня компании: почта, совещания, управление контентом и т. п. Кстати, здесь вполне уместно вспомнить старую статью Александра Полякова, в которой он героически описывал свой опыт покорения этого ПО. Однако время беспощадно, и те трюки, которые ещё пару лет назад работали на ура, сегодня уже не дают абсолютно никакого профита. Обновленный монструозный Lotus смотрел на меня как на обычного пользователя безо всяких прав. 🙂 В такой ситуации любой начинающих взломщик полез бы на баг-трекеры и начал искать, к чему можно прицепиться, кроме устаревшего names.nsf в веб-сервисах.

Сказ про CVE-2011-1519

Бегло просмотрев различные уязвимости, я остановился на баге с обходом аутентификации, позволяющем выполнить произвольный код (а это как раз то, о чем мечтает каждый пентестер). Эта уязвимость, получившая на сайте ZDI код ZDI-11-110, на момент проведения пентеста числилась как 0day (сейчас уже имеется соответствующий патч). Приведу перевод описания указанной уязвимости с этого сайта:

Это описание вполне раскрывает всю суть проблемы: во время аутентификации атакующий может подменить параметр COOKIEFILE на параметр, содержащий путь к файлу \evilhost\password_cookie_file, который находится под контролем самого атакующего. В этот файл как раз и входит строка, сравниваемая с паролем, который вводится при аутентификации. Однако более подробная информация в описании уязвимости отсутствовала.

Протокол

Итак, мы знаем, что уязвимая служба висит на порте 2050. Это очевидно, так как контроллер Lotus всегда находится там. Однако протокол общения лично мне был неизвестен. Погуглив информацию об этом протоколе, я ничего не нашел. В то же самое время мой напарник Александр Миноженко заметил, что автор бага, достаточно известный пентестер и хакер из Швеции Патрик Карлсон, также является автором модулей для культового сканера nmap. Некоторые из этих модулей как раз работают с Lotus-контроллером, например модуль для брутфорса и выполнения кода, предназначенный для тех случаев, когда пароль известен.

Рассмотрим код этих модулей:

Другие статьи в выпуске:

Почти реверс-инжиниринг

После всех безуспешных попыток вникнуть в код алгоритма мне пришлось декомпильнуть код контроллера. Выяснилось, что контроллер полностью написан на Java, поэтому и IDA Pro, и Оля-дебаггер оказались не нужны. Пригодился обыкновенный DJ decompiler, который превратил jar-файл C:\Program Files\IBM\Lotus\Domino\Data\domino\java\dconsole.jar в кучу практически полностью читаемого Java-кода. Воспользовавшись поиском, я быстро нашел в полученных файлах класс NewClient.class, отвечающий за работу с консолью и аутентификацию. Давай взглянем на сам код:

Наши догадки о формате команд оказались верны. Теперь давай найдем интересующий нас процесс аутентификации:

Теперь рассмотрим функцию авторизации verifyAppletUserCookie:

Из кода видно, что если введенные при аутентификации значения username, password и address равны значениям username, password и address из cookiefile, который мы контролируем, то аутентификация пройдет успешно! Таким образом, мы можем составить примерный алгоритм атаки:

Скрипт ищет тег в указанном нами файле.
В этом теге считываются значения username, password, address.
Далее считанные параметры сравниваются с теми, которые ввел пользователь.
Так как путь к открываемому файлу не фильтруется при вводе, мы можем указать путь к произвольному файлу и обойти таким образом злосчастную аутентификацию.

Ранее приватный эксплойт для CVE-2011-1519

Теперь перейдем непосредственно к реализации нашей атаки.

Геологическая служба США

А что если?

аналогичен вот этому непотребству:

В результате мы вполне можем получить профит и без UNC, так как лог-файл может быть любым.

Правила выживания при пентесте

Защита

Стоит сказать несколько слов и о защите от разработанного нами способа атаки. Во-первых, атакуемый сервис используется сугубо для узких административных целей, поэтому он не должен быть доступен пользователям локальной сети, а также виден из интернета. Во-вторых, ни в коем случае не забывай про патчи и обновления. В-третьих, постарайся не забыть про сервисный пароль, который устанавливается один-единственный раз через ту же самую консоль (даже если сервер захватят, различные опасные команды вроде LOAD и TELL будут защищены). И последнее — время от времени проводи аудит файла admindata.xml. Здесь перечислены все пользователи контроллера с паролями в MD5. Кроме того, тут же прописаны их привилегии в виде десятичных значений. Значения 4, 25 и 26 говорят о том, что у этого пользователя есть привилегии на исполнение системных команд. Следи за тем, чтобы у незнакомых юзеров не было лишних полномочий, и да пребудет с тобой Сила!

Читайте также: