kliMaster

CET вводит понятие теневого стека вызовов (shadow stack), который ведется самим микропроцессором и в котором сохраняется информация об адресах возврата для дальнейшего использования инструкцией ret. При возврате потока из той или иной функции, микропроцессор будет проверять адрес возврата, который сохранен на стеке потока с тем, который сохранен на теневом стеке и в случае их несоответствия будет генерировать исключение, обрабатываемое ОС. CET определяет интерфейсы для ОС, которые позволят автоматизировать этот процесс и эффективно бороться с эксплойтами, использующими ROP.

Под теневой стек будет выделен отдельный регион виртуальной памяти, который будет помечен таковым на уровне элементов PTE таблиц страниц. Таким образом, микропроцессор будет блокировать любые попытки того или иного кода получить доступ к этому стеку (например, через инструкцию mov). Указатель на теневой стек микропроцессор будет хранить в известной структуре сегмента состояния задачи (Task state segment) для отслеживания этого поля при переключении контекста потока и его процесса. Поля этой структуры также частично используются Windows для механизма обслуживания процессов и переключения контекста.

За активацию CET на уровне микропроцессора будет отвечать специальный флаг регистра cr4 под названием CR4.CET. Для него же будет выделен целый набор специальных MSR регистров, которые будут контролировать поведение CET: IA32_U_CET, IA32_S_CET, IA32_PL3_SSP, IA32_PL2_SSP, IA32_PL1_SSP, IA32_PL0_SSP, IA32_INTERRUPT_SSP_TABLE_ADDR. Текущий адрес теневого стека потока будет фиксироваться новым регистром микропроцессора под названием SSP (Shadow Stack Pointer).

Выше Формат кода ошибки известного исключения page fault, которое генерируется микропроцессором при попытке доступа потока к не предназначенной для него странице. Установленный в результате исключения шестой бит говорит о попытке доступа потока к странице виртуальной памяти с теневым стеком.

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

INCSSP — увеличить указатель теневого стека SSP на один шаг, т. е. на 4 байта в 32-битной системе и на 8 байт в 64-битной.

RDSSP — прочитать значение указателя SSP в указанный регистр.

SAVESSP — сохранить текущий «контекст маркера теневого стека» на теневом стеке и выровнять указатель SSP на 8 байт.

RSTORSSP — команда аналогична предыдущий, т. е. записывает в SSP значение сохраненного маркера стека.

WRSS — записать по указателю SSP в виртуальной памяти значение переданного аргумента.

В случае своей активности, CET будет реагировать на следующие инструкции микропроцессора, которые изменяют поток выполнения кода: CALL, INT n/INTO/INT3, JMP, RET, SYSCALL, SYSENTER, SYSEXIT, SYSRET, IRET/IRETD. Как видно, эти инструкции относятся к механизмам вызова функций и выхода из них, а также к вызовам системных сервисов и выходу из них, вызову прерываний и выходу из них.

Выше Часть псевдокода инструкции вызова функции call. Видно, что в случае активности CET, адрес возврата сохраняется на теневом стеке.

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

Выше Элементы таблиц страниц Extended Page Table (EPT), в которых страница теневого стека помечена 59-м битом SSS. Используется для идентификации страниц теневого стека на уровне таблиц страниц.

Напомним, что специфические функции борьбы с ROP-эксплойтами содержаться в бесплатном инструменте EMET. Для этого используются такие настройки как Caller Check, SimExecFlow, MemProt, и StackPivot. Первые две позволяют EMET контролировать поток выполнения и вызова функций API Windows, а также проверить легитимность кода вызывающей стороны. Функция MemProt запрещает потоку модифицировать атрибуты защиты страницы стека, а StackPivot распознает ситуации модификации регистра esp методом stack pivoting.

Источник: https://habrahabr.ru/company/eset/blog/303086/

Одной из самых популярных видеокарт для GPGPU является AMD R9 280X. При скромной цене в ~220-230 долларов она готова поделиться тремя гигабайтами памяти и 2048 потоковыми процессорами на базе архитектуры GCN v1.0, суммарно выдающих около 3.4 TFlops для вычислений одинарной точности и порядка 870 GFlops для вычислений двойной точности. Показатели производительности могут незначительно отличаться в зависимости от вендорской версии и «зашитых» в BIOS тактовых частот.

Для сравнения, у одной скандально известной видеокарты (той, что с «3.5 ГБ памяти из 4 заявленных») цена на сто долларов больше, при этом она показывает внушительные 3.8-4 TFlops для 32-битных чисел с плавающей точкой, но для FP64 – смешные ~120-130 GFlops.

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

Virtual OpenCL

VCL доступен бесплатно и работает с любым железом, поддерживающим стандарт OpenCL 1.0 или 1.1, позволяет объединять различные устройства в одну вычислительную сеть и предоставлять её мощности для любых приложений, умеющих работать с OpenCL.

В качестве примера применения такой технологии хочется рассказать о монструозной ферме по перебору паролей, состоящей из 25 GPU AMD.

Взлом пароля грубой силой часто упирается в вычислительную мощность компьютера, который будет осуществлять перебор. Даже если абстрагироваться от всевозможных уровней защиты от атаки bruteforce’ом (вроде каптчи или удаления/шифрования информации после n-ной попытки войти с неправильным паролем), стандартный пароль из 8 символов перебирать достаточно долго. При использовании только букв нижнего регистра латинского алфавита вам придётся перебрать 268 (208 827 064 576) вариантов, а если использовать цифры, спецсимволы и различный регистр, то число возможных сочетаний перевалит за 728 (722 204 136 308 736). Быть может, сгенерировать 720 триллионов паролей не так уж и сложно, но сами пароли в открытом виде, само собой, никто не хранит, вместо этого используют их хэши.

Современные пароли хранятся в таком виде, который нельзя легко «решить», собрав специальную микросхему, так что на сцену выходят железки, способные играть грубо и эффективно: предоставляя огромное количество FP32 / FP64 операций в секунду, и здесь-то технологии AMD, возможности OpenCL и VCL-фермы придутся как нельзя кстати.

Когда BitCoin «добывали» с помощью видеокарт, любители собирали специальные фермы из большого числа ускорителей:

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

Кластер из GPU работает под управлением Linux, видеокарты объединены системой VCL, которая предоставляет хост-системе все видеокарты как одну большую систему исполнения OpenCL-заказов.

Ферма может делать до 350 миллиардов предполагаемых хэшей паролей в секунду, используя алгоритм NTLM. Он используется в Microsoft Windows со времён Windows Server 2003. Для перебора восьмисимвольного пароля (самого популярного по длине как среди обычных пользователей, так и в корпоративном сегменте), содержащего все символы латинского алфавита в различных регистрах, цифры и спецсимволы, данному монстру достаточно пяти с половиной часов.

Производительность

Возможности подобной фермы из GPU действительно впечатляющи, и они показывают неплохие результаты даже на «тяжёлых» алгоритмах хэширования: MD5 (180 млрд. предположений в секунду), SHA1 (63 млрд. предположений в секунду) и LM (20 млрд. предположений в секунду). Для т.н. «медленных» хэш-алгоритмов результаты тоже неплохие: bcrypt (05) и sha512crypt получили 71 000 и 364 000 предположений в секунду соответственно.

Оптимизация и масштабируемость

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

В июне 2012 года Поул-Хеннинг Камп, автор функции md5crypt(), которая широко используется в FreeBSD и Linux, попросил сообщество перестать пользоваться его функцией.

Автор опасался ситуации, когда атакующий сможет получить больше 1 миллиона проверок в секунду на доступном в обычных магазинах компьютерном железе. Password Cracker на 25 GPU превзошёл опасения Поула-Хеннигна Кампа в 77 раз, а возможность смасштабировать его в 5 и более раз делает перебор хэшей ещё более уязвимым к коллизиям: если сейчас «стандартный» восьмисимвольный пароль перебирается за 6-8 часов, то на 128 GPU такой перебор может сократиться до часа.

Как быть?

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

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

Источник: https://geektimes.ru/company/amd/blog/277068/

VPN-подключение остается за кадром, и после него мы получаем

доступ к единственному внешнему IP компании CyBear32C — 192.168.101.8, который в реальной жизни был бы шлюзом в интернет.

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

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

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

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

изучаем mainsite

Начнем с того чтобы зайти по адресу http://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 не проходят.

Попробуем его обойти…

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

посвятить множество книг и статей.

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

3128 и попробуем настроить браузер на работу через него.

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

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

на этом же сайте.

Создаем текстовый файл со словариком и двумя учетными записями:

b.muncy и r.diaz, и пробуем подобрать пароль:

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

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

Продолжение следует...

Пы.сы. Спасибо за 1000 подписок.

Итак, получил я сегодня письмо от моего регистратора и в поле отправитель вижу привычное: «RU-CENTER <no-replay@nic.ru>». Хотя в это даже особо не вглядываешься, так как тема письма достаточно цепляющая.

И что-то меня в письме смутило, наверно отсутствие значка, которое есть в обычных письмах от руцентра.

То есть раз проверки DKIM не пройдены — значит поле отправитель мог заполнить кто угодно и это явно не руцентр. Но в чём подвох пока понять не могу.

Далее кликаю на ссылку «посмотреть приложенный документ» (которая выглядит как обычная ссылка от яндекса, а не продукт хитрой HTML-вёрстки) — попадаешь на страничку очень похожую на Яндект документ с текстом заявления, но уже через 2 секунды неожиданно «слетает авторизация» и надо ввести пароль. Надо сказать, изобретательно сделано.

Тут стоит обратить внимание на домен. И он явно не от яндекса.

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

Источник: https://geektimes.ru/company/dronk/blog/276950/