Remote control и обмен файлами.

Всем привет.

Звонит мне вчера коллега и просит показать как с помощью средства удаленного управления DameWare Mini Remote Tool у пользователя с его компьютера файлик стащить. А я вот помню что такая функция у DameWare Mini Remote Tool заявлена, но пользоваться ею до сих пор не доводилось.

Начинаем искать.  С помощью верхней панели DameWare находим две кнопки которые показывают папки для обмена файлами у пользователя и у меня соответственно. 

Отлично, пол дела сделано, а теперь как же перетащить сам файл? Перетаскиванием мышкой не получается. Через минуту был найден пункт на всплывающем меню, который касается любого файла "DameWare MRCS/Copy to remote host". Ну а сам файл после следует искать в тех папках что названы выше.

А как же функция обмена файлами в других тулзах remote control? В стандартном RDP это реализуется отметкой локального диска как общего ресурса для обмена в свойствах соединения.

А вот в SСCM RcCmViewer я такой возможности не нашел. Может плохо искал?

Успехов.

Реанимация SCCM-агента.

Всем привет. 

Время от времени агент SCCM теряет связь с SCCM-сервером и становится не активным после долгого простоя. Иногда включения хоста в сеть бывает достаточно, но не всегда. Сегодня мы рассмотрим варианты по восстановлению работоспобности агента SCCM. Первый способ восстановить агента Configuration Manager - использовать утилиту ccmrepair.exe. Ниже я упомяну и о некоторых дополнительных методах, с помощью которых вы можете легко исправить проблемы с агентом клиента SCCM.

Вариант 1.

Если у вас есть ccmrepair, вы можете легко восстановить агент клиента sccm с помощью командной строки:

cd C:\Windows\ccm

C:\Windows\CCM>ccmrepair.exe

Repairing product {88B420C9-C484-4E20-8D02-C25243A36B80}…

Done.

Вариант 2.

Не помогло? Используем Powershell. Удалим полностью агента, выполнив скрипт с админстративными правами.

cd C:\Windows\ccmsetup

.\ccmsetup.exe /uninstall

Start-Sleep -Seconds 10

while (Get-Process -Name ccmsetup -ErrorAction SilentlyContinue) {

    Start-Sleep -Seconds 180

}

Start-Sleep -Seconds 120

Место под солнцем.

Всем привет.

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

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

Теперь по сути, сцена №1 - нужные файлы в профиле пользователя или другом месте ПК, это его личная ответственность. Профиль пользователя, разумеется, находится на диске "С", на тот самый диск и весь прикладной софт ложится по умолчанию, и сама ОС, и все ее обновления. И, конечно, наступает момент Х когда Windows сигнализирует что места на диске совсем не осталось, а у пользователя все начинает жутко тормозить (и файлу подкачки наш привет). Хм, вот ведь, и так бывает. А что инфобез? Инфобез на этот  случай дает блестящий совет - в таком случае пользователь должен обратиться в сервис-деск. И то правда, как я забыл, это же сервис-деск, они же боги, они помогут...

И тут наступает сцена №2 - чем может помочь в этой ситуации сервис-деск? Я спрашиваю вполне серьезно, мне уже хочется заявку такую создать и посмотреть на предлагаемые решения. Возможно вы знаете что прозойдет, я - нет. Все эти кешы, корзины мы проходили  - не более 20% свободного места в результате. До следующего обновления.  Перенос софта на другой диск? А нельзя, его ставит SCCM. Перенос больших файлов? А кто скажет сервис-деску что можно переносить, а что нет. Удалить лишнее? Так пользователю все надо для работы, и сервис-деск не вправе за него решать. Ну что, перебиваем Windows? Упс, и наш пользователь уже сам не рад своему обращению.

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

Вопрос остается открытым.

Проводим пентест, часть 6 - пишем эксплоит.

Всем привет.

Сегодня 6-я часть из серии публикаций Андрея Бирюкова, посвященных проведению аудита и теста на проникновение (пентест). Оригинал статьи был опубликован в журнале "Системный администратор" №11(168), ноябрь 2016. Как пишет сам автор, эта часть является продолжением темы про кодирование приложений и в известной степени нудная. По своему опыту скажу что инструкции ассемблера сейчас знают единицы, потому как такой язык давно не в тренде. Тем не менее я решил сохранить серию публикаций автора полностью.

Часть 6. Пишем эксплоит.

Что собой представляет эксплоит? Как правильно внедрить шелл-код? Продолжаем тему самостоятельной разработки.

В этой статье мы продолжим обсуждение темы самостоятельной разработки эксплоитов к самописному программному обеспечению. В предыдущей статье цикла [1] был рассмотрен процесс поиска уязвимостей (фаззинг) в почтовом сервере SLMail. Мы выяснили значения адресов для регистров ESP и EIP, а также объем блока памяти, который нужен для размещения нашего эксплоита. Однако перед тем как перейти к описанию процесса разработки кода, нам придется уделить внимание основам программирования на языке ассемблер, так как без этого понять все особенности разработки кода эксплоита будет довольно трудно. В рамках данной статьи я не буду подробно рассматривать все инструкции, ограничусь комментариями кода. Во врезке представлены основные инструкции ассемблера, необходимые при анализе кода.

Простые действия.

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

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

1. Разработка кода эксплоита. Здесь подробно рассмотрим, что собой представляет шелл-код для Windows.

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

3. Получение адресов, используемых в нашем шелл-коде функций kernel32.dll и генерации кода эксплоита.

4. Обнаружение всех «плохих» байтов в уязвимой программе.

5. Замена найденных bad chars в нашем шелл-коде. 

7. Поиск в уязвимой программе команд, необходимых для выполнения перехода на наш шелл-код.

8. Внедрение шелл-кода в уязвимую программу. 

9. Автоматизация разработки эксплоита с помощью средств Metasploit.

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

Программа может состоять из нескольких частей, называемых модулями. В каждом модуле определяется один или несколько сегментов данных, стека и кода. Любая законченная программа на ассемблере должна включать один модуль, с которого начинается ее выполнение. Модуль содержит сегменты кода, сегменты данных и стека, объявленные при помощи соответствующих директив. Перед объявлением сегментов нужно указать модель памяти при помощи директивы .MODEL.

Nessus Essentials - запуск первого скана.

Всем привет.

В своей третьей статье из серии пентестинга Андрей Бирюков рассмотрел  проведение  сканирования  на  уязвимости с помощью Nessus и OpenVAS. Сканер Nessus (впрочем как и OpenVAS) не входит в состав Kali, однако разработчики из компании Tennable подготовили специальную сборку Nessus Essentials для бесплатного теста. Версия Nessus Essentials позвляет сканировать до 16-ти узлов в сети.

Но его активация требует два кода. Вначале проводим код регистрации:

/opt/nessus/sbin/nessuscli fetch --register YAJS-9UK7-AS43-334A-6754

Затем получаем так называемый Challenge code:

/opt/nessus/sbin/nessuscli fetch --challenge

Challenge code: efdc4ab71986d27321f3d51cdb1a2c26b2a9a3b2

и вставлем их оба в онлайн-форму где получаем уже код лицензии.

Перебрасываем код лицензии в файл и проводим саму активацию:

/opt/nessus/sbin/nessuscli fetch --register-offline nessus.license

Далее входим в панель Nessus https://127.0.0.1:8834, назначаем политику для пробного скана и запускаем его.  Однако наш скан подозрительно быстро заканчивается и его отчет пуст. Но не я первый. Если наш первый скан выдает совершенно пустой отчет то причин тому может быть несколько:

- сканируемый хост недоступен

- фаерволл хоста блокирует входящие подключения

- неверно указана авторизация на хосте в политике сканирования

- база плагинов самого Nessus повреждена или пуста.

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

/opt/nessus/sbin/nessuscli update --plugins-only

Далее останавливаем демон Nessus:

sudo systemctl stop nessusd 

Теперь выполним первую компиляцию базы:

sudo /opt/nessus/sbin/nessusd -R

Это займет некоторое время, не менее получаса.

И опять запускаем демон Nessus:

sudo systemctl start nessusd 

Но со входом на https://127.0.0.1:8834 не спешим. Ибо сейчас выполняется повторная компиляция полученных плагинов. Через пару минут входим в панель Nessus и повторно запускаем свой скан. Теперь мой первый скан выполняется минут 15-ть, и результат ниже.

Далее можно экспериментировать с политикой сканирования. Странно, но версию ОС моего подопытного хоста Nessus определил не верно.

Но Вам точно повезет.

Нюансы видеозаписи совещаний в MS Teams.

Всем привет.

В последнее время приходится частенько беседовать в MS Teams. Точно также бывает нужна видеозапись для разбора полетов. Оказалось что формат "Совещание" в MS Teams имеет свои нюансы. 

Главное - кто из участников может начать или остановить запись?

Если администратор установил политику компании для сохранения в Microsoft Stream, нужно принять ее, прежде чем начать запись.

Пользователь, который начал записи получает сообщение электронной почты с Microsoft Stream, когда запись будет доступна. Она также отображается в чате совещания или в разговоре канала, если вы проводили совещание в канале.

Когда запись прекратится, он обрабатывается и сохраняется в Microsoft Stream, а затем готова к воспроизводству.

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

Любой пользователь, который соответствует следующим условиям, может начать или остановить запись, даже если Организатор совещания не присутствует:

• имеет лицензию Office 365 Enterprise E1, E3 или E5
• имеет лицензию на запись от ИТ-администратора
• он не гость или из иной организации.

Парочка полезных примечаний:

• запись продолжается, даже если пользователь, который начал запись, покинул совещание.
• запись прекратится автоматически, как только все пользователи оставят совещание.
• если кто-то забудет покинуть совещание, запись автоматически завершится через 4 часа.

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

1) если пользователь принимал участие в совещании не по вашему приглашению, а ему ссылку подарили, то доступ к записи он не получит, что справедливо.

2) в один момент времени запись ведется тоько одним участником. Вы можете ее перехватить точно также как ее могут перехватить и у вас. Если тот кто вел запись вдруг ее остановит, то запись далее не ведется никем. И все остаются без записи! Это издержки демократии собрания в MS Teams.

Для лучщего контроля участников предлагают проведение совещаний в формате "Трансляция" в том же MS Teams. Но такой формат требует полного участия Организатора в совещании или делегирования роли Организатора на двоих и более участников. Справитесь?

Успехов.

Проводим пентест, часть 5 - поиск уязвимостей в приложениях.

Всем привет.

Сегодня 5-я часть из серии публикаций Андрея Бирюкова, посвященных проведению аудита и теста на проникновение (пентест). Оригинал статьи был опубликован в журнале "Системный администратор" №10(167), октябрь 2016. Эта часть интересна тем, что она затрагивает основы кодирования приложений, которые присутствуют во многих кампаниях, которые предпочитают иметь собственный штат разработчиков.

Часть 5. Поиск уязвимостей в «самописных» приложениях.

Проводить проверку на уязвимости для «самописного» ПО также необходимо, как и для сторонних приложений. Расскажем, как это сделать самостоятельно. В предыдущих статьях цикла [1-4] подробно рассмотрены различные способы проникновения в корпоративную  cеть. При этом был затронут вопрос поиска и эксплуатации уязвимостей. Продолжим обсуждение проведения аудита информационной безопасности и поговорим о поиске уязвимостей в «самописном» программном обеспечении.

Суть вопроса.

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

Зачем это нужно.

Любое ПО содержит ошибки. Разработчика, будь то серьезная  компания,  или  фрилансера,  как  правило,  поджимают сроки. Чтобы успеть, он осознанно или нет допускает ошибки в программном обеспечении. Однако программные продукты (как бесплатные, так и коммерческие), которые разрабатываются для массового использования, находятся, что называется, у всех на виду. На портале Securityfocus.com [5] ежедневно публикуются отчеты о десятках новых дыр, найденных  экспертами  по  информационной  безопасности со всего мира. А вот ПО, разрабатываемое для нужд конкретных  заказчиков,  независимые  специалисты  не  проверяют. Многие могут возразить, что раз об этих приложениях никто не знает, то и эксплуатировать уязвимости в них будет  сложнее.  Но  «безопасность  через  неизвестность» (security through obscurity) – это не очень хорошая практика, так как проникший в корпоративную сеть злоумышленник сможет без труда найти дыру в самописном ПО. Таким  образом,  мы  приходим  к  выводу,  что  проводить проверку на уязвимости для «самописного» ПО также необходимо, как и для сторонних приложений. Однако в силу приведенных выше причин описанные в предыдущих статьях  инструменты  Nessus,  Open  VAS  и  Metasploit  будут  нам не слишком полезны. В лучшем случае мы сможем идентифицировать открытые порты и уязвимые библиотеки, которые использовали разработчики (например, OpenSSL). Далее мы будем рассматривать два варианта поиска уязвимостей: с исходными текстами программы и без него.

Просмотр сеанса пользователя.

Всем привет.

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

Ударение делалось на возможность попадания в сеанс самого пользователя ибо ошибка чаще видна именно в его сеансе, а также желательно обойтись без приглашения самого пользователя (не все шибко тямущие). Результат теста представлен в таблице.

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

Замечания по таблице:

1- при дополнительной настройке GPO можно обойтись и без приглашения;

2- у инженера может быть один монитор.

По итогу первое место занял RcCmViewer от MS SCCM как средство удаленного управления и которое  к тому же можно использовать отдельно от консоли SCCM. Разумеется сам SCCM должен присутствовать в организации.

Увидимся.

Фильтр почты в клиенте MS Outlook.

Всем привет.

На днях пришлось столкнуться с очевидным, но не так наглядным - фильтр входящей почты в клиенте MS Outlook.  

Задача - мне нужно бы тему письма фильтровать через "ИЛИ". Возможно по задумке разработчиков это не так необходимо в работе поэтому на поиск такой возможности у меня ушел не один час. Временами казалось что просто надо сделать еще одно правило, но размер банка правил в клиенте MS Outlook ограничен в 256 Кб. Решение было найдено случайно - оказалось надо просто добавить в поле поиска еще один критерий и он тогда ложится с условием "ИЛИ".

Не раз вспомнилось насколько удобна и широка в этом плане настройка правил в The Bat! При этом сочетаний по условиям там просто уйма. Эх).

Удачи.

Неприятный факт в MS Visio 365.

Всем привет. 

Обращаю ваше внимание на изменения в плане лицензирования для MS Visio 365. 

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

Как перевести классический вариант файла в облачный для дальнейшего редактирования я пока решения не нашел.

Удачи.

Проводим пентест, часть 4 - используем уязвимости.

Всем привет.

Сегодня 4-я часть из серии публикаций Андрея Бирюкова, посвященных проведению аудита и теста на проникновение (пентест). Оригинал статьи был опубликован в журнале "Системный администратор" №07-08(164-165), 2016.

Часть 4. Используем уязвимости

После нахождения уязвимостей хакеру необходимо  ими воспользоваться. Есть много способов это сделать. В  этой  статье  мы  продолжим  тему  практического  теста на  проникновение.  Ранее  [1-3]  мы  подробно  рассмотрели способы  проникновения  в  сеть,  идентификации  ресурсов и  поиска  уязвимостей.  Теперь  поговорим  о  том,  как  злоумышленник может воспользоваться найденными в ПО уязвимостями.

Тему  использования  уязвимостей  мы  поделим  с  вами на три части, каждая из которых будет представлять отдельную статью. Первая будет посвящена эксплуатации уязвимостей с помощью Metaspoit Framework, входящего в состав Kali Linux. Этот фреймворк является основным инструментом при проведении любого пентеста. Во второй мы расскажем об уязвимостях в веб-приложени ях. Будут подробно рассмотрены различные кроссплатформенные инструменты, также входящие в состав Kali. Широкое распространение веб-приложений в корпоративных средах требует особого внимания к вопросам их защищенности, поэтому я планирую посвятить этому отдельную статью. В  третьей  статье  мы  поговорим  о  поиске  уязвимостей в «самописных» приложениях. Практически в любой крупной компании есть ПО, разработанное либо собственными программистами, либо сторонними разработчиками. Зачастую это довольно старые программы, давно не обновлявшиеся. Про уязвимости в них сканеры, описанные в предыдущих  статьях,  могут  не  знать,  так  как  в  силу  закрытости и  нераспространенности  данного  ПО  никто  не  проводил его аудит и, соответственно, никто не знает специфические ошибки. Также и Metasploit вряд ли сможет применить к таким приложениям свои эксплоиты. Поэтому в третьей статье мы рассмотрим, как самостоятельно искать дыры в ПО. 

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

Ну а теперь рассмотрим работу с Metasploit Framework.

Хакерский мультитул.

ПО Metasploit Framework от компании Rapid7 представляет собой  многофункциональный  набор  средств,  с  помощью которых можно осуществлять различные тесты на проникновение.  Есть  несколько  редакций  Metasploit  [4].  Если  Pro и  Express  являются  платными,  то  Community  и  Framework бесплатные. Мы будем рассматривать редакцию Framework как наиболее подходящую для тестов на проникновение. Metasploit Framework входит в состав Kali Linux и для запуска консоли выполним Applications/Exploitation Tools/Metasploit.  В результате мы попадаем в командную строку. Для начала проверим наличие соединения с БД:

msf > db_status

[*] postgresql connected to msf

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